ADDOM-004: Domain Controller Inventory
- Plataforma
- Active Directory
- Categoría
- AD Domain & Forest Configuration
- Severidad
- High
- Pilar de Zero Trust
- Governance (peso 1)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
The check performs three parallel evaluations against the forest. First, it queries the default Domain Controllers OU (OU=Domain Controllers,DC=<domain>) and enumerates all computer objects whose userAccountControl bits 0x2000 (SERVER_TRUST_ACCOUNT) or 0x82000 (PARTIAL_SECRETS_ACCOUNT, indicating a read-only DC) are set. Second, it binds to CN=Sites,CN=Configuration,DC=<forest> and enumerates every nTDSDSA object under CN=NTDS Settings of each server container; this is the replication-topology view of the forest and is the authoritative list of DCs that participate in replication. Third, it calls DsGetDcName via the NetLogon API to retrieve the runtime DC list as the operating system sees it. The check then joins the three lists on dnsHostName and reports any mismatch: a computer object in the Domain Controllers OU that has no nTDSDSA child, an nTDSDSA object whose parent server has no matching computer object, or a DC visible to DsGetDcName but absent from LDAP. For each DC that passes the inventory join, the check reads operatingSystem, operatingSystemVersion, operatingSystemServicePack, msDS-isGC (global catalog), msDS-isRODC, serverReference, and the site DN. The check also reads HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR (Update Build Revision) on each DC via remote registry to determine the current cumulative-update level and compares the resulting build to the latest Patch-Tuesday build published by Microsoft for that OS family. A finding is raised when any DC is more than two cumulative updates behind, when any DC runs an operating system that is past its extended-support end-of-life date, or when the three list joins do not reconcile.
Por qué importa
Domain controllers are Tier 0. Compromise of any single DC is equivalent to compromise of the entire forest: an attacker who code-executes on a DC can extract the krbtgt secret (and forge Golden Tickets), extract every account password hash via DCSync, replicate arbitrary changes via DCShadow, or simply read ntds.dit offline. An undocumented DC is the worst possible variant of this risk because it sits outside the patch cycle, outside EDR coverage, and outside log forwarding. Real environments accumulate ghost DCs in several ways: a DC was demoted with dcpromo /forceremoval and the metadata was never cleaned up, leaving an orphan nTDSDSA object that still appears as a replication partner; a DC was built in a remote site by a third party and never registered with central IT; a virtual DC snapshot was reverted, creating a USN rollback condition that is invisible until replication breaks; an attacker promoted a server they control to a DC and registered it with the forest. The blast radius of any of these conditions is the entire forest. Inventory hygiene is also a prerequisite for every other DC-scoped control: you cannot enforce LDAP signing, SMB signing, Restricted Admin mode, or Credential Guard on DCs you do not know about. Mandiant has repeatedly observed APT operators (notably UNC2452 / SVR in the SolarWinds intrusions and several China-nexus groups) abusing DCShadow and rogue-DC techniques against forests where DC inventory was incomplete.
Ruta de ataque
Step 1: Reconnaissance. The attacker, holding a domain-user foothold, queries LDAP for (userAccountControl:1.2.840.113556.1.4.803:=8192) to enumerate all SERVER_TRUST_ACCOUNT computer objects. They cross-reference this with nltest /dclist:contoso.local and with the SRV records under _ldap._tcp.dc._msdcs.<domain>. Mismatches between these lists are immediate targets: a DC visible in DNS but absent from the Domain Controllers OU is almost always a stale or unmanaged DC. Step 2: Target selection. The attacker picks the DC running the oldest OS or the most outdated build. Build numbers are obtainable remotely via SMB negotiation (Windows version banner), NetWkstaGetInfo, or by querying the operatingSystemVersion attribute on the corresponding computer object. A DC missing the August 2024 SAM RPC hardening patch, the November 2022 Kerberos PAC patch, or any pre-2022 cumulative update is a high-value target for known privilege-escalation chains (CVE-2022-26923 Certifried, CVE-2022-37966 / CVE-2022-37967 Kerberos signature bypass, CVE-2020-1472 Zerologon). Step 3: Lateral movement to the unpatched DC. The attacker exploits the unpatched primitive, or, if they already have privileged credentials in a non-Tier 0 zone, they pivot via WMI, PSRemoting, or admin SMB to the under-monitored DC. Because the DC is not on the monitoring inventory, EDR alerts and 4624 / 4672 forwarders do not fire to the SOC. Step 4: Persistence via rogue DC promotion. Alternatively, an attacker with Domain Admin or with Enterprise Admin temporarily can promote a server they control to a DC (Install-ADDSDomainController), wait for replication to seed the new DC, and then leverage that DC for DCSync, ntds.dit theft, or DCShadow injection. Because the rogue DC is not in the central inventory, defenders cannot revoke its computer account or force replication metadata cleanup before damage occurs. Step 5: DCShadow. With a registered (or rogue) DC, the attacker runs mimikatz lsadump::dcshadow to register temporary replication state, push arbitrary attribute changes (sidHistory injection, primaryGroupID change, msDS-AllowedToActOnBehalfOfOtherIdentity write), and deregister, leaving no Event 4662 trail on legitimate DCs because the change was committed as a replication operation rather than a normal LDAP write. Detection requires correlating the unknown DC server name in Directory Service replication events, which only works if the legitimate inventory is complete.
Cómo lo evalúa Guerrilla
Guerrilla binds to the default naming context and performs an LDAP search with filter (&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=8192)) under OU=Domain Controllers to retrieve the domain-partition view of all DCs. It then binds to the configuration naming context and enumerates (objectClass=nTDSDSA) under CN=Sites to retrieve the replication-topology view. For each nTDSDSA object the check walks the parent server container, reads the serverReference attribute, and resolves the linked computer object. The third view comes from DsGetDcName called once per site discovered in the configuration partition with the DS_DIRECTORY_SERVICE_REQUIRED and DS_RETURN_DNS_NAME flags. The three lists are joined on the dnsHostName attribute (case-insensitive) and any row present in only one or two of the three views is reported. For each reconciled DC the check reads operatingSystem, operatingSystemVersion, whenCreated, lastLogonTimestamp, msDS-isGC, msDS-isRODC, and managedBy. The OS build is extracted by combining operatingSystemVersion (which carries the major.minor.build triple) with a remote registry read of HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR over WinRM or RPC; the resulting full build (for example 10.0.20348.2700) is compared against the current Microsoft monthly cumulative-update floor for that OS family pulled from a local manifest. Findings are emitted for DCs with build delta greater than two months, for DCs running OS families past extended-support end of life (Server 2012, 2012 R2, 2008 R2, 2008, 2003), and for any DC where the three list join shows a gap. Replication metadata is also checked: repadmin-style RPC calls (DsReplicaGetInfo, DS_REPL_INFO_REPSTO) surface nTDSDSA objects that are still advertised as replication partners but no longer correspond to a live server, the classic signature of a half-demoted DC.
Valor recomendado
All domain controllers documented with current OS version, site membership, and patch status
Remediación
Query all DC computer objects from the Domain Controllers OU. Verify each DC is accounted for, running a supported OS, and receiving regular patches. Remove or demote any unauthorized DCs immediately
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- CM-8, CM-8(1)
- CIS Benchmark
- 1.1
- ANSSI
- R8
- CIS AD Benchmark
- 1.2.1
- MITRE ATT&CK
- T1018, T1078.002