ADSTALE-011: Obsolescencia de registros DNS
- Plataforma
- Active Directory
- Categoría
- AD Stale & Obsolete Objects
- Severidad
- Medium
- Pilar de Zero Trust
- Governance (peso 0)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
Los registros DNS obsoletos en zonas DNS integradas en Active Directory apuntan a direcciones IP que ya no están asignadas a los hosts originales. Los atacantes pueden reclamar estas direcciones IP abandonadas e interceptar el tráfico destinado a los hosts originales, lo que permite ataques de intermediario, recolección de credenciales y suplantación de servicios. Debe habilitarse la limpieza automática de DNS (scavenging) para eliminar automáticamente los registros obsoletos
Por qué importa
DNS is a trust anchor for intranet authentication. Windows clients silently negotiate Kerberos and NTLM against whatever IP a hostname resolves to, and most internal web applications, file shares, and management consoles do not pin TLS certificates or validate the server identity beyond the hostname-to-IP DNS lookup. When a DNS record outlives the host it pointed to, three exposure paths open. First, IP reclaim: an attacker on the same subnet (or with influence over a flat DHCP scope, a cloud VPC, or a sloppily decommissioned VM pool) can claim the abandoned IPv4 address and immediately receive every connection still resolving the stale name. This is the classic subdomain takeover pattern moved inside the perimeter. Second, NTLM coercion and relay: tools such as PetitPotam, PrinterBug, and DFSCoerce can coerce a Windows host to authenticate to an arbitrary name; if that name resolves to attacker-controlled infrastructure thanks to a stale record, the authentication is relayed to ADCS Web Enrollment, LDAP, or SMB on a real target and converts to a certificate or a session. Third, credential and data theft via impersonation: intranet portals (helpdesk, SharePoint, Confluence, Jenkins, internal IdP, legacy OWA) routinely use Windows Integrated Authentication, so any browser silently passes the NTLM challenge or Kerberos ticket to the attacker the moment the user types the old URL. Stale records also defeat detection: SIEM rules keyed on hostnames trust the DNS answer, so traffic to the attacker arrives labelled with the legitimate decommissioned host name. Because DNS scavenging is off by default on every Windows DNS server and every zone created with it, this exposure accumulates silently for the life of the forest unless explicitly remediated.
Ruta de ataque
Step 1: Reconnaissance. An attacker with any authenticated foothold (or even an unauthenticated attacker on the LAN with a captured netlogon broadcast) enumerates the DNS zone. AD-integrated zones are world-readable by Authenticated Users: a single zone transfer via dnscmd /ZoneExport, an AXFR if allowed, or an LDAP query against CN=MicrosoftDNS,CN=System,DC=domain pulls every record name, type, and timestamp. Tools such as adidnsdump (dirkjanm), PowerView Get-DomainDNSRecord, and BloodHound CE collection extract the same data. Step 2: Stale-record triage. The attacker filters for A and AAAA records whose timestamp is older than the password-policy or patch-cycle horizon (90 days is a typical threshold). They cross-reference the target IPv4 address against the DHCP scope range, the cloud VPC CIDR, or a recently decommissioned hypervisor pool. Records pointing into a DHCP scope are top priority because the address can be requested back trivially. Step 3: IP acquisition. The attacker requests the orphan IPv4 address. Inside a DHCP scope this is a matter of releasing the current lease and requesting the desired address, or running a DHCP starvation that exhausts the pool and forces the server to hand back the wanted address. Inside a cloud VPC it is a matter of provisioning a new ENI with the desired private IP. On a flat segment with static addressing it is a matter of plugging in and self-assigning. Step 4: Service impersonation. The attacker stands up the service the original host ran (a simple SMB responder, an HTTP listener with NTLM challenge enabled, an LDAP bind capture, or Responder / ntlmrelayx in relay mode) on the newly claimed IP. Any client that resolves the stale name and connects now hands the attacker a credential or a session. Step 5: Coercion amplification. The attacker uses PetitPotam, PrinterBug, DFSCoerce, or the WebDav abuse path to coerce specific high-value computer accounts (DCs, ADFS servers, ADCS CAs) to authenticate to a UNC path whose hostname is a stale A record they now control. The coerced authentication is relayed via ntlmrelayx to ADCS Web Enrollment, which issues a certificate for the coerced machine account, which converts to a Kerberos TGT via PKINIT and to DCSync against the domain. Step 6: Persistence. The attacker leaves the stale-record claim in place. Because the record is still in DNS, still timestamped (or not, if the attacker triggers a dynamic update from the squatting host), and still resolves cleanly, defenders investigating the original incident often miss that the DNS record itself is the persistence primitive.
Cómo lo evalúa Guerrilla
Guerrilla loads the DnsServer PowerShell module and queries each Domain Controller (or the AD-integrated DNS server set) for server-wide aging configuration (Get-DnsServerScavenging) and per-zone aging configuration (Get-DnsServerZoneAging on every zone returned by Get-DnsServerZone where ZoneType is Primary and IsDsIntegrated is True). For each AD-integrated zone the check enumerates every resource record via Get-DnsServerResourceRecord -ZoneName <zone> -RRType A,AAAA,PTR, reads the TimeStamp property on each record, and computes (Get-Date).ToUniversalTime() minus TimeStamp. Records where TimeStamp is null or zero are reported as static (eligible for manual review but exempt from scavenging by design). Records where the timestamp delta exceeds the configured threshold are reported as stale. The check separately validates that AllowUpdate equals 2 (Secure only) on each AD-integrated zone, that ScavengingInterval is non-zero on at least one DNS server, and that NoRefreshInterval and RefreshInterval sum to a value that matches the configured threshold. Reverse lookup zones are walked to identify PTR records whose paired A record no longer exists. The check also queries the DnsAdmins group membership and surfaces any non-Tier-0 members for cross-reference with ADPRIV checks. All queries are read-only and run against the DNS-server RPC interface or LDAP, requiring authenticated-user access plus DNS read rights, which the Authenticated Users principal holds on AD-integrated zones by default.
Valor recomendado
Limpieza automática de DNS habilitada con intervalos de no actualización y actualización apropiados; ningún registro DNS obsoleto de más de 30 días
Remediación
Habilite la limpieza automática de DNS (scavenging) en las propiedades del servidor DNS y en cada zona DNS integrada en AD. Configure el intervalo de no actualización en 7 días y el intervalo de actualización en 7 días. Establezca el período de limpieza en al menos un servidor DNS. Revise manualmente los registros DNS antiguos antes de la primera ejecución de limpieza para identificar registros estáticos críticos que deban excluirse. Marque como estáticos los registros que no deban limpiarse
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-2
- CIS AD Benchmark
- 9.5.3