Windows NT keeps track of User accounts and groups with Security Identifiers or SIDs. All SIDs are unique within a given system and are issued by what is known as an "Authority" such as a domain. There are five authorities:

SECURITY_NULL_SID_AUTHORITY

There is a universal Well-Known SID S-1-0-0 that represents a group with no members and is generally used when the SID of an object is not known. A universal well-known SID is a SID that is common to all machines. That is the value of the SID is the sa me on my machine as it is on yours.

SECURITY_WORLD_SID_AUTHORITY

This authority is responsible for the Everyone group. The well-known SID of this group is S-1-1-0

SECURITY_LOCAL_SID_AUTHORITY

Responsible for Local issues. Users with the right to Log on locally will have membership of the group SID S-1-2-0.

SECURITY_CREATOR_SID_AUTHORITY

There are two group well-known SIDs issued by this authority namely Creator Owner ID (S-1-3-0) and Creator Group (S-1-3-1)

SECURITY_NT_AUTHORITY

This is, as far as this document is concerned anyway, the most important SID issuing Authority. This will dish out the SIDs for all user accounts, default global (domain) groups, default local groups, as well as both non-default local and global groups . It must be noted that all of these share the same sub-authority except the default local groups and the special internal objects

DIALUP S-1-5-1

Network S-1-5-2

BATCH S-1-5-3

Interactive S-1-5-4

SERVICE S-1-5-6

ANONYMOUS LOGON S-1-5-7

SERVER LOGON S-1-5-9

Authenticated Users S-1-5-11

SYSTEM S-1-5-18

BUILTIN S-1-5-32

Administrators S-1-5-32-544

Users S-1-5-32-545

Guests S-1-5-32-546

Account Operators S-1-5-32-548

Server Operators S-1-5-32-549

Print Operators S-1-5-32-550

Backup Operators S-1-5-32-551

Replicator S-1-5-32-552

All the SIDs below are relative to the domain. All other SIDs (ie those listed above) are universal and are the same on every machine.

Domain Admins S-1-5-21-<number>-<number>-<number>-512

Domain Users S-1-5-21-<number>-<number>-<number>-513

Domain Guest S-1-5-21-<number>-<number>-<number>-514

Example S-1-5-21-<number>-<number>-<number>-n=> 1000

Example S-1-5-21-<number>-<number>-<number>-n=> 1000

Administrator S-1-5-21-<number>-<number>-<number>-500

Guest S-1-5-21-<number>-<number>-<number>-501

jsmith S-1-5-21-<number>-<number>-<number>-n=> 1000

Any group or user that is not created by default will have a RID of 1000 or greater. A RID is a Registered ID. This is the last portion of the SID. Once a RID has been issued it will never be used again. (Going off on a slight tangent this begs the que stion : What would happen if a user created a self-calling batch file that created and then deleted a local group and then let in run? There must be an upper ceiling on the allowable RID value.)

Firstly an attacker must connect to the IPC$ share on the remote machine. More than likely they will connect with a null session:

net use \\remote.compter.com\ipc$ "" /user:""

To be able to suck down the user list from the remote machine the attacker will need to know the value of a SID issued by the SECURITY_NT_AUTHORITY. He will use user2sid.exe for getting such a value. Because the SIDs of the Global groups are issued by the SECURITY_NT_AUTHORITY, renaming the default accounts (Administrator and Guest) to something else will not help (as far as this attack is concerned anyway.) Groups like "Domain Admins" cannot be renamed so the attack will be launched providing "Domain Admins" as the lpAccountName placeholder. Note that this group only exists on domain contollers. For workstations or member servers the guest or administrator account will be tried and will fail if they have been renamed. Then it is a case of guessing or running nbtstat against the remote machine to get the logged on user account name etc.

c:\>user2sid \\remote.computer.com "Domain Admins"

The response will be similar to the following :

S-1-5-21-1125394485-807628933-549785860-512

Number of subauthorities is 5

Domain is OLYMPUS

Length of SID in memory is 28 bytes

Type of SID is SidTypeGroup

Once this SID has been retrieved it is now a simple case of changing the RID and counting from 1000 upwards until "LookupSidName" fails.

c:\>sid2user \\remote.machine.com 5 21 1125394485 807628933 549785860 1000

This whole process can be automated by using a Perl script like the one I provide here (sid.zip)Sid.zip contains sid2user.exe, user2sid.exe and userlist.pl. Command line = c:\>perl userlist.pl target

This will connect to the IPC$ shareon the target eg www.victim.com with a null session get the SID of the Guest account (rarely renamed) and then automatically run sid2user and get the 1st 100 accounts.

Once the user list is obtained it is then a simple case of trying to guess the passwords.

Net use, user2sid and sid2user all operate over TCP port 139 - NetBIOS session.

Because you can't stop a null session connecting to the IPC$ share the only sure way to prevent this attack is to prevent inbound traffic to TCP port 139. This can be done by enabling security from the TCP/IP advanced properties window and then configuring it to disallow inbound traffic to this port or if you had a multihomed host with MS-Proxy server you could enable dynamic packet filtering. This can be achieved from the Packet filter tab reached from the Security button on the Web Proxy Serv ice properties in Internet Service Manager.

If for whatever reason that disallowing inbound traffic to this port is not an option it is important to ensure that a strong password policy is enforced. This is good administrative practice anyway.