ADPRIV-003: Schema Admins Enumeration
- Platform
- Active Directory
- Category
- AD Privileged Account Security
- Severity
- High
- Zero Trust pillar
- Identity (weight 1)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check binds to the forest root domain (Schema Admins is a Universal group that only exists in the forest root) and reads the member attribute on CN=Schema Admins,CN=Users,DC=forestRoot. It resolves each member to a security principal (user, computer, or group), expands nested groups one level so a Domain Admins -> Schema Admins arrangement is not hidden, and records: - objectSid (RID 518, well known SID S-1-5-21-<domain>-518) - sAMAccountName, distinguishedName, objectClass - adminCount value (1 indicates the principal has been stamped by SDProp) - userAccountControl flags (especially ACCOUNTDISABLE and DONT_EXPIRE_PASSWORD) - lastLogonTimestamp and pwdLastSet - whenChanged on the group object, used to detect recent membership manipulation The check also reads the nTSecurityDescriptor of the Schema partition (CN=Schema,CN=Configuration,DC=forestRoot) and confirms that no principal outside Schema Admins, Enterprise Admins, SYSTEM, or Enterprise Domain Controllers holds WriteProperty, WriteDacl, GenericWrite, or GenericAll. A non-empty member list is the primary finding; an unexpected ACE on the Schema NC is reported as a secondary finding referencing ADACL-001.
Why it matters
Schema modifications are forest scoped, replicate to every Domain Controller in every domain of the forest, and cannot be rolled back through normal means (deactivation and reuse of attributeIDs is constrained, classes cannot be deleted, and a bad schema change in many cases requires a forest recovery from backup). Any member of Schema Admins can therefore degrade or backdoor the entire forest with a single LDAP modification. Concrete abuse paths include adding a new attribute to the user class that is silently included in default replication and used for credential storage, modifying the defaultSecurityDescriptor on the user or computer class so every newly created object grants the attacker FullControl, weaponizing certificate template attributes consumed by AD CS (linking to ESC4 and ESC5 abuse paths), and altering the mustContain or systemMustContain sets so legitimate object creation fails (denial of service against onboarding and DC promotion). Because the group is rarely needed, every standing member is a Tier-0 principal whose compromise produces forest-wide impact, and ransomware operators and state-aligned intrusion sets routinely target Schema Admins membership both for impact and for persistence.
Attack path
1. Reconnaissance: the attacker enumerates Schema Admins membership using Get-ADGroupMember -Identity "Schema Admins" -Server <forestRoot>, BloodHound (the SchemaAdmins node and its inbound edges), or net group "Schema Admins" /domain. 2. Path selection: BloodHound highlights any principal with an inbound edge (GenericAll, WriteDacl, WriteOwner, AddMember, ForceChangePassword) to a Schema Admins member or to the group itself. A frequent finding is a help desk role or a stale service account that can reset the password of a Schema Admins member. 3. Credential capture: the attacker uses the abusive edge to take control of the Schema Admins principal, for example resetting its password, adding their controlled account as a nested member, or coercing authentication followed by NTLM relay to LDAPS. 4. Schema modification: with Schema Admins rights, the attacker enables schema write on the Schema FSMO holder (Registry value Schema Update Allowed = 1 under HKLM\System\CurrentControlSet\Services\NTDS\Parameters) and performs an LDAP modify against CN=Schema,CN=Configuration,DC=forestRoot. Typical primitives include adding a backdoor attribute, modifying defaultSecurityDescriptor on the user class to grant the attacker FullControl on every future user, or altering an existing attribute mapping to harvest credentials. 5. Persistence: schema changes replicate to every DC in every domain and are not removed by password rotation, krbtgt reset, or even a domain-level rebuild. The only reliable recovery from a malicious schema change is forest recovery from backup, which is operationally catastrophic and gives the attacker durable leverage. 6. Cleanup: the attacker removes themselves from Schema Admins to evade routine membership audits, leaving the schema change in place as a silent persistence mechanism.
How Guerrilla assesses it
Guerrilla resolves the forest root domain via Get-ADForest and queries Schema Admins on a writable DC in that domain using Get-ADGroup -Identity "Schema Admins" -Server <forestRoot> -Properties Members,whenChanged. Membership is enumerated through Get-ADGroupMember with -Recursive disabled by default so direct and nested members are reported separately and the analyst can see the chain. Each member is enriched via Get-ADObject with adminCount, userAccountControl, lastLogonTimestamp, pwdLastSet, and objectClass. The forest root is identified by walking RootDSE rootDomainNamingContext rather than assuming the connected domain is root, so the check is correct in multi-domain forests. The Schema NC DACL is read via Get-ADObject -Properties nTSecurityDescriptor against CN=Schema,CN=Configuration,DC=forestRoot and walked using the .NET ActiveDirectorySecurity surface so the check does not depend on the AD PSDrive. Findings are emitted with the well known SID (ending in -518) so downstream correlation works even when the group has been renamed.
Recommended value
Empty during normal operations. Members added temporarily only for schema modifications with change management approval
Remediation
Enumerate Schema Admins membership using Get-ADGroupMember -Identity 'Schema Admins'. Remove all permanent members. Add members only when schema changes are required through a formal change management process
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 | FAIL |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- AC-6(1), AC-6(5)
- CIS Benchmark
- 9.2.3
- ANSSI
- R2
- CIS AD Benchmark
- 4.1.3
- MITRE ATT&CK
- T1078.002, T1069.002