Relative IDentifier


Relative IDentifier within Microsoft Active Directory and Microsoft Windows is the last part of a Security Identifier (SID)

Relative IDentifier is a Unique Identifier a security principal relative to the local or domain security authority that issued the SID. Any group or user that the Microsoft Windows Operating System does NOT create has a RID of 1000 or greater by default.

Relative IDentifier Microsoft Windows#

Regardless of the version since Windows XP, Windows uses the Security Account Manager (SAM) to store the Security Descriptor of local Identity and built-in accounts. As is mentioned in How Security Principals Work [1], every account has an assigned Unique Identifier of a RID. Unlike Domain Controllers, which use Microsoft Active Directory, Microsoft Windows (workstations and servers) will store this data in the HKLM\SAM\SAM\Domains\Account\Users SubKey, which requires SYSTEM privileges to be accessed.

Each HKLM\SAM\SAM\Domains\Account\Users SubKey has:

These values are used by the Local Security Authority Subsystem Service (LSASS) and Security Reference Monitor (SRM) to generate the Primary Access Token right after the first communication between the NTLM and SAMSRV.dll when translating from username to Security Identifier (SID).

Since Local Security Authority Subsystem Service, which loaded the connection with the kernel-process Security Reference Monitor, trusts the data obtained from the SAMSRV – SAM registry hive, the Primary Access Token will be created based on all the security data retrieved from the SAM, including the RID copy, which is the value used to define the security context of the owner when he logs on.

The Names subkey contains all the Local Identity account names, including the built-in accounts. Each of these subkeys has stored a binary value, which has defined its type attribute as the account's Relative IDentifier in hex format (0x1f4 = 500, 0x1f5 = 501). Each of the Names

The RID Hijacking Attack [2]#

The The RID Hijacking Attack consists on overwriting these bytes by setting the intended RID on the "F" value at the mentioned offset (i.e. F4 01). Changing this binary will make Microsoft Windows to assume the Digital Identity of the hijacker account as the hijacked one on most of the critical Operating Systems processes. This can be done not only using the built-in accounts, but also with Local Users.

By using only Microsoft Windows resources, it is possible to hijack the RID of any existing account on the victim (even the 500 Local Administrative Accounts), and assign it to another user account. This attack will:

  • Assign the privileges of the hijacked account to the hijacker account, even if the hijacked account is Administratively Disabled.
  • Allow to authenticate with the hijacker account credentials (also remotely, depending on machine's configuration), and obtain authorized access as the hijacked user.
  • Register any operation executed on the Windows Event Log as the hijacked user, despite of being logged in as the hijacker.

More Information#

There might be more information for this subject on one of the following: