How to understand the anatomy of security identifiers | TechRepublic (2024)

As an administrator of a Windows network, you’re probably no stranger to security identifiers (SIDs). Any object that you can apply security to has a unique SID. If you’ve ever looked at a SID, you know that it appears to be some huge, random number. However, there is a method to the madness, and you can learn a lot about an object by examining its SID. It’s sometimes even possible to manipulate the security that applies to an object by manipulating the object’s SID.

The components of a SID
A SID is merely a number that uniquely identifies an object. Windows doesn’t assign permissions directly to a SID, but rather to an SD, or Security Descriptor. An SD contains a set of permissions or denials related to a particular SID. SIDs are similar in nature to the UIDs (Unique IDs) used in UNIX environments. What makes them different, though, is that SIDs are unique, even across a network.

For example, suppose that you had a network consisting of two domains. Each domain has a user named Administrator. However, even if the Administrator’s password, description, and anything else were set to be identical, the accounts would be different from each other from Window’s perspective because they would have different SIDs. Likewise, Windows treats a domain administrator account differently from a local administrator account because of the differences in SIDs. Even local administrative accounts on workstations within a domain are considered unique from Windows’ perspective.

The reason that it’s possible for Windows to distinguish between SIDs, even on different machines across a network, is because of the way that SIDs are structured. In a domain environment, all objects within a domain have SIDs that are based on a root SID, which identifies the domain. I’ll show you the full anatomy of a SID later, but here’s a quick example. Suppose that you had a domain named TEST, which used the following SID:
S-1-5-21-186985262-1144665072-74031268

A user within that domain would have a SID that reflected the domain. For example, an individual user’s SID might be:
S-1-5-21-186985262-1144665072-74031268-1309

As you can see, the number 1309 was appended to the end of the domain SID, uniquely identifying the user object within the domain. The last portion of the SID, in this case 1309, is what’s known as a relative identifier, or RID. If multiple machines have objects with identical names, such as the Administrator account, then it is possible for the object to have an identical RID across the various machines. However, when the RID is combined with the SID, the SID becomes unique, and the object can be uniquely identified across the network.

What do the SID numbers mean?
You have probably noticed that a SID consists of numbers separated by dashes. These numbers are not completely random, but rather have specific meanings. The first digit of a SID is always an S. The S designates the number as a SID. This prevents the SID from being mistaken for a security descriptor, globally unique identifier (GUID), or anything else.

The next number in the series is the version number. All currently existing versions of Windows use a 1 as the version number. The next number is the identifier for the top level authority. Most of the time, this number will be 5, but the numbers 0 through 4 are also used. This is because there are five different security authorities:

• SECURITY_NULL_SID_AUTHORITY: This SID refers to a group with no members, essentially a null group. This authority is designated with the number 0. It is used primarily for universal SID numbers. That is to say SIDs that would be the same on my machine as they are on yours.
• SECURITY_WORLD_SID_AUTHORITY: This SID is represented by the number 1. This authority is responsible for the Everyone group. The Everyone group is designated by the SID prefix S-1-1-0.
• SECURITY_LOCAL_SID_AUTHORITY: This SID authority manages local users and is designated by the number 2. Any one with the log on locally permission will be a member of a group with the SID prefix of S-1-2-0.
• SECURITY_CREATOR_SID_AUTHORITY: This SID, designated by the number 3, is associated with the Creator Owner ID (S-1-3-0), and the Creator Group (S-1-3-1).
• SECURITY_NT_AUTHORITY: This SID, designated by the number 5, is by far the most heavily used SID authority. It is responsible for generating SIDs for all user accounts, global groups, and local groups (for example, S-1-5-21).

(The number 4 allows the creation of SIDs that are not unique. We won’t discuss the use of the SECURITY_NON_UNIQUE_AUTHORITY in this article, however.)

The next set of numbers in the series has different meanings, but are commonly used to reflect groups. For example, the Everyone group is designated with the SID prefix of S-1-1-0. In a domain environment, here are some other commonly used SID prefixes:

• Everyone—S-1-1-0
• Creator/Owner—S-1-3-0
• Batch Process—S-1-5-3
• Authenticated User—S-1-5-11
• System—S-1-5-18

The SID prefix works a little differently for local systems. A SID prefix of S-1-5-32 indicates that the object is interpreted only locally. Some common local SID prefixes are as follows:

• Administrators—S-1-5-32-544
• Users—S-1-5-32-545
• Guests—S-1-5-32-546

You can find a more thorough listing of well-known SIDs at Microsoft’s Support Web Site.

Now that I have explained the various SID components, let’s take another look at the example SID that I used earlier. As you may recall, the example SID was S-1-5-21-186985262-1144665072-74031268-1309. In this example SID, the numbers have the following functions:

• S—Identifies the number as a SID
• 1—Version number
• 5—Designates the SECURITY_NT_AUTHORITY SID authority.
• 21-186985262-1144665072-74031268—The domain identifier
• 1309—The object’s relative identifier

Working with SIDs
Now that you know how to read a SID number, you might be wondering what you can do with it. From an administrative standpoint, being able to understand the meaning of a SID will help you to identify the function of many registry entries. On a darker note, SID manipulation can also be used for hacking a system. In the sections below, I’m going to demonstrate a few SID-related hacking techniques.

An elevation of privileges attack
One of the more common techniques for SID-based hacking is called an elevation of privileges attack. It’s difficult for a hacker to simply modify a SID in the local domain and gain administrative access to the domain. There are two reasons for this. First, modifying a SID isn’t a simple process. Second, the process requires administrative privileges. Although this technique has supposedly been used on occasion, a more common technique is to exploit the way that Windows implements trust relationships between domains.

In Windows 2000, transitive trusts are used. This means that if Domain A trusts Domain B, and Domain B trusts Domain C, then by nature of the transitive trusts, Domain A trusts Domain C. A hacker can use this relationship to gain access to a trusting domain from a trusted domain.

Normally, when a request is passed from a trusted domain to a trusting domain, the request is passed to the domain along with the SID of the user who is making the request. Since the request is coming from a trusted domain, the SID would be based on the trusted domain’s root SID.

Now, suppose that a hacker wanted to gain administrative access to the trusting domain. They could modify the SID that is passed along with the request in a way that would reflect a membership in the administrative group. This would be a SID with the number S-1-5-domain SID-500 (domain administrator account), or S-1-5-domain SID-512 (Domain Admins group).

The real trick to pulling off this sort of attack, though, is that the hacker must use a fake domain SID. The reason for this is that when a trust relationship is used, the trusting domain verifies the legitimacy of the SID that’s associated with the inbound request. However, it does not verify that the trusted domain is authoritative for all of the inbound SIDs. Therefore, if the domain portion of the SID points to an unknown or unauthorized domain, then the trusting domain assumes that the request is related to a transitive trust relationship and must therefore belong to an unknown domain that’s trusted by the trusted domain. The request is then validated, and the hacker gets into the trusting domain with administrative privileges.

So how can you prevent this sort of attack? To stop this sort of attack, you must use SID filtering. SID filtering is a technique by which Windows 2000 verifies the legitimacy of inbound requests. Essentially, SID filtering disables transitive trusts, and therefore should not be used in organizations that make legitimate use of transitive trust relationships.

If you do want to implement SID filtering, you must make sure that each domain controller is running Windows 2000 Service Pack 2 or higher. You can then use the NETDOM utility to implement SID filtering. You must use the version of NETDOM that’s included in Service Pack 2’s Support Tools folder. This version of NETDOM includes a switch called /FILTERSIDS You must run NETDOM with the /FILTERSIDS switch and all of the other appropriate switches against every domain controller in the domain.

Gaining access to the user list
Another way that SIDs can be exploited is by using them to gain access to the user list. Once someone knows the user names within a domain, it’s easy to crack the corresponding passwords. It’s absolutely frightening to see how easy it is to acquire the user list.

Begin by establishing a null session with the machine that you intend to hack by exploiting the machine’s IPC$ share. You can do this through the NET USE command. For example, for this demonstration, I will be hacking a machine called DR-EVIL. Therefore, I would enter the following command:
NET USE \\dr-evil\ipc$

Once the session has been established, you must use a utility called USER2SID, which is available on a number of different hacker Web sites. The USER2SID utility allows you to find the SID for a specific user or group. For example, if you wanted to find the SID for the Domain Admins group on DR-EVIL, you’d enter the following command:
USER2SID \\dr-evil “Domain Admins”

When I ran the utility against my test machine, the following information was returned:
S-1-5-21-746137067-764733703-83952215-512
Number of subauthorities is 5
Domain is TEST
Length of SID in memory is 28 bytes
Type of SID is SidTypeGroup

The next step in the process is to know a little bit about how SIDs work. Earlier, I explained that user and group objects within a domain use the domain’s SID and an appended RID. If a RID number is below 1000, it relates to a built-in user or group, while values of 1000 or higher relate to nondefault objects. This means that you can calculate the user and group SIDs by starting with the domain SID, adding an RID value of 1000, and counting up from there.

The next piece of the attack is the use of the USER2SID companion tool SID2USER. This tool comes with USER2SID, and converts SID numbers into user names. Now, let’s work backward to find the user names.

Earlier, we determined that the Domain Admin group had a SID of S-1-5-21-746137067-764733703-83952215-512. This means that we could determine the user names for the domain by starting with the SID S-1-5-21-746137067-764733703-83952215-1000, and then working our way up to S-1-5-21-746137067-764733703-83952215-1001, S-1-5-21-746137067-764733703-83952215-1002, etc. You could even write a script that would check each SID for you.

Now, just enter the following command to acquire the user names:
SID2USER \\machine_name SID

For example, if you were trying to find the users on DR-EVIL, you would use this command:
SID2USER \\DR-EVIL 5 21 746137067 764733703 83952215 1000

Notice in the above command that the dashes have been replaced with spaces. You will also notice that the S and the 1 at the beginning of the SID have been skipped, and that the SID starts with the SID authority number, in this case 5. When you run this command, the output will look something like this:
Name is User1
Domain is Test
Type of SID is SidTypeAlias

You can see the actual screen capture from this type of hack below in Figure A:

Figure A

Here is a sample of a SID-based hack.

In this case, we targeted the users found in the Domain Admins group. However, we could have just as easily targeted any other group by simply specifying a different group to look up the SID for.

So how do you protect yourself against this type of hack? Internally, the only protection is to use strong passwords that are not easily guessed or cracked. Externally, you can block this sort of attack by blocking TCP port 139.

Troubleshooting tools
Trying to understand how SIDs work may drive you crazy, but once you understand how they’re constructed, they can actually be useful. When used in tandem with hacking utilities, they can give you a powerful tool to help troubleshoot problems on your Windows 2000 Server.