Security Principals

As we noted earlier, the fundamental subject within Windows is the process. We also
noted that processes must be associated with a user account in order to access securable
objects. This section will explore the various account types in Windows, since they are
the foundation for most attacks against access control.
Windows offers three types of fundamental accounts, called security principals: Users Groups Computers
Well discuss each of these in more detail shortly, just after we take a brief detour to
discuss SIDs.

SIDs
In Windows, security principals generally have friendly names, such as Administrator o
Domain Admins. However, the NT family manipulates these objects internally using
globally unique 48-bit number called a security identifier, or SID. This prevents the system
from confusing the local Administrator account from Computer A with the identicall
named local Administrator account from Computer B, for example.
The SID comprises several parts. Lets take a look at a sample SID:
S-1-5-21-1527495281-1310999511-3141325392-500
A SID is prefixed with an S, and its various components are separated with hyphens
The first value (in this example, 1) is the revision number, and the second is the identifie
authority value. Then four subauthority values (21 and the three long strings of numbers
in this example) and a relative identifier (RIDin this example, 500) make up the remainde
of the SID.
SIDs may appear complicated, but the important concept for you to understand is tha
one part of the SID is unique to the installation or domain and another part is shared acros
all installations and domains (the RID). When Windows is installed, the local compute
generates a random SID. Similarly, when a Windows domain is created, it is assigned
unique SID (well define domains later in this chapter). Thus, for any Windows computer o
domain, the subauthority values will always be unique (unless purposely tampered wit
or duplicated, as in the case of some low-level disk-duplication techniques).
However, the RID is a consistent value across all computers or domains. For example
a SID with RID 500 is always the true Administrator account on a local machine. RID 50
is the Guest account. On a domain, RIDs starting with 1001 indicate user accounts. (Fo
example, RID 1015 would be the fifteenth user account created in the domain.) Suffice t
say that renaming an accounts friendly name does nothing to its SID, so the account ca
always be identified, no matter what. Renaming the true Administrator account change
only the friendly namethe account is always identified by Windows (or a maliciou
hacker with appropriate tools) as the account with RID 500.

Why You Cant Log on as Administrator Everywhere
As is obvious by now (we hope), the Administrator account on one computer is different
from the Administrator account on another because they have different SIDs, and
Windows can tell them apart, even if humans cant. This feature can cause headaches for
the uninformed hacker.
Occasionally in this book, we will encounter situations where logging on as
Administrator fails. Heres an example:
C:\>net use \\192.168.234.44\ipc$ password /u:Administrator
System error 1326 has occurred.
Logon failure: unknown user name or bad password.

A hacker might be tempted to turn away at this point, without recalling that Windows
automatically passes the currently logged-on users credentials during network logon
attempts. Thus, if the user were currently logged on as Administrator on the client, this
logon attempt would be interpreted as an attempt to log on to the remote system using
the local Administrator account from the client. Of course, this account has no context on
the remote server. You can manually specify the logon context using the same net use
command with the remote domain, computer name, or IP address prepended to the
username with a backslash, like so:
C:\>net use \\192.168.234.44\ipc$ password /u:domain\Administrator
The command completed successfully.
Obviously, you should prepend the remote computer name or IP address if the
system to which you are connecting is not a member of a domain. Remembering this
little trick will come in handy when we discuss remote shells in Chapter 7; the technique
we use to spawn such remote shells often results in a shell running in the context of the
SYSTEM account. Executing net use commands within the LocalSystem context cannot
be interpreted by remote servers, so you almost always have to specify the domain or
computer name, as shown in the previous example.

Viewing SIDs with user2sid/sid2user
You can use the user2sid tool from Evgenii Rudnyi to extract SIDs. Here is user2sid being
run against the local machine:
C:\>user2sid \\caesars Administrator
S-1-5-21-1507001333-1204550764-1011284298-500
Number of subauthorities is 5
Domain is CORP
Length of SID in memory is 28 bytes
Type of SID is SidTypeUser
The sid2user tool performs the reverse operation, extracting a username given a SID.
Heres an example using the SID extracted in the previous example:
C:\>sid2user \\caesars 5 21 1507001333 1204550764 1011284298-500
Name is Administrator
Domain is CORP
Type of SID is SidTypeUser
Note that the SID must be entered starting at the identifier authority number (which is
always5 in the case of Windows Server 2003), and spaces are used to separate components,
rather than hyphens.