ADPRIV-030: Privileged Users Not in Protected Users

Platform: Active Directory
Category: AD Privileged Account Security
Severity: High
Zero Trust pillar: Identity (weight 2)
Golden fixtures: 3
Branch coverage: Observed: fixtures prove the verdicts they exercise
Provenance: baseline

What it checks

The check builds three sets and computes a difference. Set A is the union of transitive members of the AdminSDHolder-protected groups, resolved by SID rather than by name to defeat renamed built-ins: Domain Admins (S-1-5-21-<domain>-512), Enterprise Admins (S-1-5-21-<root>-519), Schema Admins (S-1-5-21-<root>-518), Administrators (S-1-5-32-544), Account Operators (S-1-5-32-548), Backup Operators (S-1-5-32-551), Server Operators (S-1-5-32-549), Print Operators (S-1-5-32-550), Replicator (S-1-5-32-552), Cert Publishers, Key Admins, and Enterprise Key Admins. Set B is the transitive membership of Protected Users (S-1-5-21-<domain>-525). Set C is the set of accounts that are not eligible for enrollment, namely service accounts (objectClass=msDS-GroupManagedServiceAccount or msDS-ManagedServiceAccount, accounts with servicePrincipalName populated, accounts flagged by naming convention such as svc-* or gmsa-*), computer accounts, the built-in domain Administrator (S-1-5-21-<domain>-500, which is always exempt from authentication policies and which Microsoft explicitly warns against placing in Protected Users), and the krbtgt account. The check then reports A minus B minus C: privileged human accounts that should be in Protected Users and are not. For each finding the check additionally reads userAccountControl for SMARTCARD_REQUIRED and TRUSTED_FOR_DELEGATION, msDS-SupportedEncryptionTypes for the AES bits (0x08 AES128 and 0x10 AES256), pwdLastSet to confirm the account has rotated since the domain reached the 2008 functional level (a prerequisite for AES keys to exist on the account), and the domain functional level itself, which must be Windows Server 2012 R2 or later for Protected Users protections to apply at the DC.

Why it matters

Every credential-theft technique that has driven the last decade of AD compromise relies on a primitive that Protected Users removes. Mimikatz sekurlsa::logonpasswords extracts cached NT hashes, Kerberos long-term keys, and WDigest plaintext from LSASS; for a Protected User the only artifact in memory after initial TGT acquisition is the TGT session key, and only for the 240-minute lifetime. NTLM relay against SMB, LDAP, HTTP (ADCS Web Enrollment, EWS, ADFS), and RPC requires the victim account to be able to authenticate over NTLM at all; a Protected User cannot, and the DC logs event 100 in Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController for the attempt. Kerberoasting and AS-REP roasting against a Protected User return only AES-encrypted tickets, raising the offline cracking cost from commodity GPU-hours to economically infeasible. Unconstrained-delegation abuse (printer bug, PetitPotam coerce-and-relay against ADCS, S4U2Self-then-S4U2Proxy chains) cannot impersonate a Protected User because the DC will not issue a forwardable TGT for them and will not honor any S4U request that targets them. Pass-the-hash and overpass-the-hash are dead for Protected Users because no NT hash and no RC4 long-term key exist in cacheable form on the client. The blast radius of leaving a Domain Admin out of Protected Users is the entire forest: a single workstation foothold where that admin has ever logged on interactively, or a single relay opportunity against a service they authenticate to, hands the attacker their credential. The blast radius of placing them in Protected Users is, conservatively, the cost of one round of compatibility testing and a 240-minute reauthentication every four hours.

Attack path

1. Foothold and harvest. The attacker compromises a workstation or member server where a privileged human account has recently logged on (RDP, RunAs, Enter-PSSession). They run Mimikatz sekurlsa::logonpasswords or its modern equivalent (Nanodump, Dumpert, or a stealthy MiniDumpWriteDump variant against lsass.exe) and extract NT hashes, Kerberos AES and RC4 long-term keys, WDigest plaintext (if UseLogonCredential is set), and any cached TGT. For a non-Protected User every one of these is present and reusable; for a Protected User only the TGT session key is, and only for the remaining ticket lifetime. 2. Lateral movement. With the NT hash the attacker performs pass-the-hash against SMB, WMI, or WinRM on any host the admin has rights to. With the RC4 long-term key they perform overpass-the-hash to mint a new TGT (Rubeus asktgt /user:admin /rc4:<hash> /opsec) and then access any service in the domain. Neither primitive exists for a Protected User. 3. NTLM relay. The attacker positions an NTLM relay (ntlmrelayx, Inveigh, Responder with multi-relay) and coerces the privileged account to authenticate. Coercion vectors include MS-RPRN printer bug, PetitPotam MS-EFSRPC, MS-DFSNM, MS-FSRVP, and Outlook ICS calendar pull. For a non-Protected User the inbound NTLM auth is relayed to LDAP (to add the attacker to Domain Admins), to LDAPS (to delegate WriteDACL on the domain object), to ADCS Web Enrollment (to issue a client-auth certificate as the victim, then PKINIT for a persistent TGT), or to SMB on a target host. For a Protected User the DC rejects the NTLM exchange outright and writes event 100, no relay completes. 4. Kerberoast and AS-REP roast. The attacker requests a service ticket for any SPN-bound account the privileged user owns, or requests AS-REPs for accounts with DONT_REQUIRE_PREAUTH set. For a non-Protected User the ticket may be encrypted with the RC4 long-term key (etype 23), which hashcat mode 13100 cracks at multi-billion guesses per second on commodity hardware. For a Protected User the DC will only issue AES-encrypted tickets (etype 17 or 18), raising the cracking cost by orders of magnitude. 5. Delegation abuse. The attacker compromises a server trusted for delegation (constrained or unconstrained) and uses S4U2Self plus S4U2Proxy to impersonate the privileged user to a back-end service, or coerces the privileged user to authenticate to the trusted server to capture a forwardable TGT. For a Protected User the DC sets the TGT non-forwardable and refuses S4U2Self where the target is a Protected User, breaking the chain. 6. Persistence. The attacker who briefly held the credential plants a golden ticket, a silver ticket, a skeleton key, or a DSRM backdoor. None of these require Protected Users to be bypassed once initial credential theft has succeeded, which is why the entire delta between Protected Users membership and non-membership is the initial-theft surface in steps 1 through 5.

How Guerrilla assesses it

Guerrilla queries the directory via LDAP and resolves the protected-group membership set by walking each well-known SID (rather than the CN, which can be renamed). For each member it issues a tokenGroups expansion against the user object to capture nested membership through any path. The Protected Users group is resolved separately by S-1-5-21-<domain>-525 and its transitive membership computed the same way. The check then computes A minus B and applies the eligibility filter: it drops objectClass msDS-GroupManagedServiceAccount and msDS-ManagedServiceAccount, drops any account with servicePrincipalName populated (service accounts must not be in Protected Users because the host always has the credential anyway), drops the built-in domain Administrator (RID 500, exempt by Kerberos design), drops krbtgt, and drops computer objects. For each remaining finding it pulls userAccountControl to surface SMARTCARD_REQUIRED (0x40000) and TRUSTED_FOR_DELEGATION (0x80000), pulls msDS-SupportedEncryptionTypes to confirm AES is available (0x18 or higher), pulls pwdLastSet to verify the password has been set since the domain reached 2008 functional level so AES keys exist, and reads the domain functional level (msDS-Behavior-Version on the domainDNS object: 5 = Windows Server 2012 R2, the minimum for Protected Users DC-side protections to apply). The check also reads the operational log Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController (event 303) and ProtectedUserFailures-DomainController (events 100 and 104) from each DC where the log has been enabled, so the operator can correlate enrollment to actual KDC behavior.

Recommended value

All eligible privileged user accounts enrolled in Protected Users group. Exceptions documented with compensating controls

Remediation

Compare privileged group members against Protected Users membership. For each privileged account not in Protected Users, evaluate compatibility (NTLM dependencies, delegation requirements) and add to the group. Document any exceptions with specific technical reasons and compensating controls

Fixture-proven verdicts

Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.

Verdict scenarios for ADPRIV-030
Scenario	Expected verdict
clean	PASS
known-bad	FAIL
throttled	Not Assessed

Framework mappings

NIST SP 800-53: AC-6, IA-5(2)
ANSSI: R5
CIS AD Benchmark: 4.12.2
MITRE ATT&CK: T1003, T1557, T1078.002