RID Hijacking: The Registry Trick That Turns a Guest Account Into SYSTEM

Most persistence techniques are about planting something new: a scheduled task, a service, a run key. RID hijacking is different, and that is exactly why it is dangerous. It plants nothing. It leaves your account list looking completely normal — the Guest account is still disabled, the low-privilege service account still shows up as a plain user — while quietly granting one of those accounts the full authority of the built-in Administrator. To the eye, and to most inventory tooling, nothing changed. Under the hood, Windows now treats a throwaway login as SYSTEM's peer.

What a RID actually is

Every Windows security principal has a SID (Security Identifier), and the last chunk of that SID is the Relative Identifier, or RID. The RID is what actually distinguishes one local account from another. Some RIDs are well known and fixed by the OS:

• 500 — the built-in Administrator
• 501 — Guest
• 503 — DefaultAccount
• 1000+ — every account you create afterward

Windows does not decide "is this the admin?" by looking at the account name. It looks at the RID. When you log in, the LSA builds your access token from the RID stored in the SAM, not from the friendly username in Computer Management. That indirection is the whole vulnerability.

The attack

The SAM database stores each account's RID in the registry under HKLM\SAM\SAM\Domains\Account\Users\. Buried in each user's F binary value is a two-byte field holding the RID. That hive is normally invisible — even administrators cannot read it directly. But SYSTEM can. An attacker who has already reached SYSTEM (the usual precondition) opens the SAM, finds a low-value account such as Guest, and overwrites its stored RID with 0x1F4 — decimal 500.

The account keeps its name, its group membership shows as unchanged, and it can even stay "disabled" in the GUI — yet authenticating with it now yields a full Administrator token.

Because the account still appears low-privilege in every normal listing, defenders re-enabling MFA, rotating admin passwords, or auditing group membership will look right past it. The attacker sets a password on Guest (or leaves an existing one), and they have a durable, camouflaged foothold that survives password resets on the real Administrator account.

Why traditional tooling misses it

Run net user Guest or open lusrmgr.msc and the account membership still reads "Guests." Group Policy reporting shows the Administrators group with its expected members. The mismatch only surfaces if you compare the effective SID the account resolves to against the account name you expect it to have. That is not a check most inventory or AV products perform, because it requires reading a hive they cannot touch and doing a name-to-RID reconciliation.

You can surface it manually from an elevated context:

PS> wmic useraccount get name,sid
Name     SID
Guest    S-1-5-21-1560randomdomain-500   <-- should end in 501
Administrator  S-1-5-21-1560randomdomain-500

Two accounts resolving to RID 500 is the tell. So is a Guest or DefaultAccount whose SID does not end in its canonical RID. Event log 4720/4738 (account created/changed) may not even fire, because the tampering is a raw registry write, not an account API call.

How WinSentinel catches it

WinSentinel's account-integrity module reads the SAM under a SYSTEM-level context and reconciles every local account's name against the RID it actually resolves to. When a well-known account (Guest, DefaultAccount, or any account whose name implies a canonical RID) maps to a RID it should not — or when two accounts collide on RID 500 — it flags a high-severity finding with the offending account and its real effective privilege. This is one of the 33 modules that run in full on a single machine on the free tier: there is no paywall on catching a SYSTEM-level backdoor on your own box.

Detection is only step one. WinSentinel pairs the finding with concrete remediation guidance:

1. Restore the account's canonical RID and disable it properly.
2. Treat the host as compromised — RID hijacking implies the attacker already had SYSTEM.
3. Rotate credentials and hunt for the original escalation path that granted SYSTEM in the first place.

Why this matters at fleet scale

On one machine, a mismatched RID is a clear local alarm. Across an organization, the same tampering is nearly impossible to find by hand — nobody is diffing SAM hives on 200 endpoints. WinSentinel Pro rolls each machine's account-integrity findings up to the central node, so a single hijacked Guest account anywhere in the fleet becomes a drift alert instead of a needle in a haystack. Compliance rollups (CIS, SOC 2) get the same signal: an endpoint with a covert RID-500 account is not "least privilege," and the fleet view says so without an admin logging into every box.

The takeaway

RID hijacking is a reminder that on Windows, the name of an account tells you almost nothing about its power. Privilege lives in the RID, and the RID lives in a hive most tools never read. Audit the SID-to-name mapping of every local account, treat any RID-500 collision as an incident, and remember that a "disabled Guest" is only reassuring if its SID still ends in 501.