ADPRIV-029: Protected Users Group Audit
- Platform
- Active Directory
- Category
- AD Privileged Account Security
- Severity
- High
- Zero Trust pillar
- Identity (weight 3)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check resolves the Protected Users group by its well-known RID (S-1-5-21-<domain>-525) and reads the member attribute, then cross-references the membership list against the Tier 0 privileged account roster derived from Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, Key Admins, Enterprise Key Admins, and the holders of replication rights on the domain head (Replicating Directory Changes, Replicating Directory Changes All). For each Tier 0 principal the check evaluates: - objectClass: only user objects gain protection; computer accounts and gMSAs/sMSAs in Protected Users are a misconfiguration (the protections are user-only and adding a computer account can break the host). - Forest functional level and domain functional level: the client-side protections require Windows 8.1 or later, the DC-side protections require a Windows Server 2012 R2 or later DC, and the domain functional level must be 2012 R2 or higher for the full TGT lifetime enforcement. - Membership in Protected Users (direct only: nested membership is ignored by the DC enforcement, so the check reports the direct member list as authoritative). - Whether the account is also flagged with the "Account is sensitive and cannot be delegated" UserAccountControl bit (NOT_DELEGATED, 0x100000), which is a complementary control. - Whether an authentication policy or authentication policy silo is bound to the account (msDS-AssignedAuthNPolicy, msDS-AssignedAuthNPolicySilo), which works in tandem with Protected Users to bind the account to specific privileged access workstations. The finding is generated when one or more Tier 0 user accounts are absent from Protected Users, or when a non-user object (computer, gMSA, sMSA) is incorrectly present.
Why it matters
Protected Users is the single most effective AD-native mitigation against the credential theft toolchain that drives every modern human-operated ransomware engagement. The group applies five protections that are enforced by the Local Security Authority and the KDC and cannot be disabled per-account: 1. NTLM authentication is blocked. The account cannot complete an NTLM challenge-response, which defeats pass-the-hash, NTLM relay (including the ADCS Web Enrollment ESC8 chain), and SMB/LDAP signing downgrade attacks against that identity. 2. Kerberos pre-authentication can no longer use DES or RC4. The KDC will only issue AES128 or AES256 tickets for the account, which makes the offline cracking step of Kerberoasting effectively infeasible (RC4-HMAC TGS tickets can be cracked at billions of guesses per second on commodity GPUs; AES256 tickets cannot). 3. The account cannot be delegated via unconstrained, constrained, or resource-based constrained delegation. A compromised front-end service that holds a TGT for a Protected User cannot reuse it against a back-end service, which neutralizes the entire S4U2Self/S4U2Proxy abuse class (printer bug, KrbRelayUp, RBCD takeover). 4. Long-term keys (the NT hash and the Kerberos long-term keys) are not cached in LSASS on the workstation after sign-in. This defeats sekurlsa::logonpasswords and sekurlsa::ekeys against the Protected User, so an attacker who lands code execution on a host where the admin signed in cannot extract reusable credential material. 5. The TGT lifetime is capped at four hours and cannot be renewed. Even if an attacker steals the TGT in-memory before it ages out, the window for pass-the-ticket reuse is dramatically reduced. The blast radius of leaving Tier 0 admins out of Protected Users is the entire credential theft chain. Mandiant and Microsoft Incident Response have both observed that the median ransomware deployment relies on at least one of pass-the-hash, Kerberoasting, or unconstrained-delegation abuse against a Domain Admin who was not in Protected Users. Adding those admins to the group closes all three paths simultaneously with no software to deploy and no agent to maintain.
Attack path
1. Reconnaissance: the attacker enumerates Domain Admins, Enterprise Admins, and Administrators via LDAP (Get-ADGroupMember, net group, BloodHound) and pulls the membership of Protected Users (S-1-5-21-<domain>-525) in the same pass. Any DA not in Protected Users is a high-value target. 2. Kerberoasting an unprotected admin: if the target DA carries a servicePrincipalName, the attacker runs Rubeus kerberoast /user:<DA> /nowrap and receives an RC4-HMAC TGS (etype 23) because RC4 is still permitted for the account. Hashcat mode 13100 cracks the TGS offline at billions of candidates per second on a single GPU. A Protected User would force AES256 (etype 18), which cracks at three to four orders of magnitude slower and is operationally infeasible for any non-trivial passphrase. 3. NTLM relay against an unprotected admin: the attacker coerces authentication from a host where the DA is signed in (PetitPotam, PrinterBug, DFSCoerce) and relays the NTLM exchange to LDAP, ADCS Web Enrollment, or SMB on another host. A Protected User cannot complete the NTLM exchange, so the relay fails with STATUS_LOGON_FAILURE. 4. Credential extraction from LSASS: with SYSTEM on a host where the DA recently signed in, the attacker runs mimikatz sekurlsa::logonpasswords, sekurlsa::ekeys, or comsvcs.dll MiniDump. For a non-Protected User, the NT hash and the AES256 long-term key are returned and reusable for pass-the-hash, overpass-the-hash, and Silver Tickets. For a Protected User, those fields are blank. 5. Delegation abuse: the attacker compromises a service account configured for unconstrained or constrained delegation, waits for the DA to authenticate to it, then captures and reuses the resulting TGT (Rubeus monitor, S4U2Proxy). A Protected User cannot be delegated, so the captured ticket is unusable against any other service. 6. Pass-the-ticket: even if the attacker steals a TGT in-memory before sign-out, a Protected User TGT expires within four hours and cannot be renewed, sharply reducing the persistence window.
How Guerrilla assesses it
Guerrilla binds to a writable DC, resolves the domain SID, and queries the group at S-1-5-21-<domain>-525 via Get-ADGroup -Properties member, member;range. The member list is read directly (no recursion) because the DC-side enforcement (NTLM block, AES-only Kerberos, no delegation, no caching, four-hour TGT) is evaluated against direct membership only; nested groups in Protected Users do not propagate the protection. In parallel, the check builds the Tier 0 roster by enumerating the well-known privileged groups (RIDs 512, 519, 518, 544, 548, 549, 550, 551, 552, plus the Key Admins groups) and resolving every direct and nested member to a unique set of user-object SIDs. The two sets are diffed: Tier 0 users absent from Protected Users are emitted as primary findings, and non-user objects (computer, gMSA, sMSA) present in Protected Users are emitted as misconfiguration findings. The check also reads the domain functional level (msDS-Behavior-Version on the domain head) and warns if it is below DS_BEHAVIOR_WIN2012R2 (5), because the full set of TGT lifetime protections requires that level. All queries are pure LDAP and run against any reachable DC.
Recommended value
All Tier 0 privileged user accounts are members of the Protected Users group
Remediation
Add all Tier 0 accounts to the Protected Users group using Add-ADGroupMember -Identity 'Protected Users' -Members <account>. Test each account first as Protected Users disables NTLM and credential delegation which may break legacy applications. Note: service accounts and computer accounts should NOT be added
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.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | WARN |
| no-data | Not Assessed |
Framework mappings
- NIST SP 800-53
- AC-6, IA-5(2)
- CIS Benchmark
- 18.3.1
- ANSSI
- R5
- CIS AD Benchmark
- 4.12.1
- MITRE ATT&CK
- T1003, T1550.003, T1078.002