Transferencia de Zona DNS Active Directory Actualización Dinámica Insegura: Detección y Remediación

Transferencia de zona DNS Active Directory actualización dinámica insegura: no es un único ajuste — son tres fallos distintos, próximos a los valores por defecto, en cómo se configuran las zonas DNS integradas en AD, y juntos permiten a un atacante mapear o reescribir el DNS de su dominio sin tocar nunca Kerberos ni LDAP. Una transferencia de zona DNS de Active Directory dejada abierta, un ajuste de actualización dinámica inseguro y una ACL por defecto que permite al grupo Authenticated Users crear registros DNS son tres debilidades distintas y de bajo esfuerzo — y la seguridad DNS, en la mayoría de entornos AD, sigue tratándolas como ruido de fondo en lugar de como superficie de ataque.

Ninguna de las tres requiere una CVE ni un exploit reciente. Son ajustes próximos al valor por defecto, que vienen «funcionales» de fábrica y raramente se revisan una vez el dominio está en producción. Encadenadas, permiten a un atacante no autenticado o con pocos privilegios mapear la red interna gratis, inyectar registros en ella, o ambas cosas.

Transferencia de Zona DNS Active Directory Actualización Dinámica Insegura: la superficie de ataque del DNS integrado en AD

Cuando una zona DNS está integrada en Active Directory, sus registros viven como objetos dnsNode dentro de la partición de directorio (DomainDnsZones o ForestDnsZones), no en un archivo de zona plano. Microsoft documenta este modelo en Active Directory-Integrated DNS Zones: todo controlador de dominio con permisos de escritura que ejecute el rol DNS Server puede aceptar actualizaciones de la zona, y esas actualizaciones se replican mediante la replicación AD normal en lugar de un mecanismo de transferencia de zona independiente entre primario y secundarios.

Ese diseño tiene dos consecuencias que importan para la seguridad, no solo para la disponibilidad:

• La propia zona tiene una ACL, exactamente igual que una UO o un grupo. Quien tenga derechos de escritura sobre esa ACL puede crear, modificar o eliminar registros DNS — y los derechos por defecto son más amplios de lo que la mayoría de administradores espera.
• Dos protecciones heredadas e independientes siguen custodiando el perímetro de la zona: la transferencia de zona clásica (AXFR, para replicar hacia secundarios no-AD o para reconocimiento) y la actualización dinámica (el mecanismo que usan los clientes para autorregistrarse). Ambas son anteriores a la integración con AD y ambas tienden por defecto a ser permisivas.

Kerberos, LDAP y el abuso de ACL acaparan la mayor parte de la atención en la literatura de seguridad de AD. El DNS es distinto: pertenece a la categoría Red, no a la categoría Identidad, y suele quedar completamente fuera de las checklists de hardening — junto a vecinos como la firma LDAP dejada deshabilitada o un TLS LDAPS débil y un Spooler de Impresión que nadie deshabilitó, tratados en esta checklist de higiene de red del controlador de dominio — lo que explica exactamente por qué un dominio puede aprobar una revisión de Kerberos y ACL y aun así filtrar toda su topología a través del DNS.

Cómo funciona: tres configuraciones incorrectas encadenables

1. Transferencia de zona sin restricciones (AXFR)

AXFR es el protocolo original de replicación de zona DNS, y nunca se diseñó pensando en la autenticación. Como indica el aviso de CISA sobre el tema, si un servidor DNS no está explícitamente configurado para restringir las transferencias, cualquier cliente que pueda alcanzarlo por TCP/53 puede solicitar — y recibir — una copia completa de la zona. Para una zona integrada en AD eso significa que cada nombre de host, dirección IP, registro de servicio (incluyendo _ldap._tcp, _kerberos._tcp y otros registros SRV que identifican controladores de dominio), y cualquier subdominio olvidado, se entregan en una sola consulta.

Set-DnsServerPrimaryZone expone la corrección directamente: el parámetro -SecureSecondaries controla si las transferencias se permiten hacia cualquier servidor, solo hacia los servidores listados en la pestaña Name Servers, o solo hacia una lista de IP explícita — NoTransfer es la opción endurecida cuando ningún secundario externo necesita la zona.

2. Actualización dinámica insegura

La actualización dinámica permite a un cliente registrar o actualizar su propio registro DNS sin que un administrador lo haga manualmente — algo normal y necesario para las estaciones de trabajo unidas al dominio. La frontera de seguridad es qué modo de actualización usa la zona. La propia documentación de Microsoft sobre Dynamic DNS Update in Windows and Windows Server y la guía heredada Allow Only Secure Dynamic Updates son explícitas: la actualización dinámica segura — disponible solo en zonas integradas en AD — restringe las actualizaciones a equipos autenticados y unidos al dominio, aplicada mediante las ACL de la zona. Una zona dejada en Nonsecure and secure, en cambio, acepta actualizaciones de cualquiera que pueda alcanzar el servicio DNS, autenticado o no — lo que significa que un host no autenticado en el segmento de red puede crear o sobrescribir registros a voluntad.

3. Authenticated Users puede crear registros hijos directamente

Esta es la que la mayoría de equipos nunca ha examinado directamente. Por defecto, el grupo Authenticated Users tiene el derecho Create All Child Objects en la ACL de la zona integrada en AD — confirmado en la propia guía comunitaria de Microsoft sobre permisos de creación de registros DNS y documentado en investigación ofensiva como la base del abuso de ADIDNS (Active Directory-Integrated DNS). La investigación de NetSPI sobre la explotación del DNS integrado en Active Directory y ADIDNS Revisited exponen el efecto práctico: cualquier cuenta de dominio, incluyendo usuarios con pocos privilegios y cuentas de equipo, puede registrar nuevos registros DNS en la zona sin ningún derecho elevado. La página de ADIDNS poisoning de The Hacker Recipes y la referencia AD DNS Records de HackTricks documentan ambas esto como una técnica establecida y bien conocida — no un exploit nuevo. Se enmarca en un patrón más amplio que merece su propia auditoría: Authenticated Users y Everyone sobre-incluidos en silencio en ámbitos privilegiados a lo largo de un dominio, del cual la ACL por defecto de la zona DNS es una instancia concreta y fácil de pasar por alto.

Dos tipos de registro hacen esto inmediatamente peligroso:

• Un registro para un nombre que aún no existe — por ejemplo, registrar el nombre de host de un servidor dado de baja o un nombre que una aplicación legacy sigue consultando, y apuntarlo a una IP controlada por el atacante.
• Un registro comodín (*) — dado que un comodín responde a cualquier consulta que no tenga ya un registro explícito en la zona, un atacante que crea uno se convierte en el resolutor de último recurso para toda la zona. La propia regla de detección predefinida de Elastic para el envenenamiento ADIDNS con comodín describe exactamente esto: un atacante se posiciona como adversario-en-el-medio resolviendo nombres arbitrarios sin coincidencia, lo que permite la interceptación de credenciales o el relay NTLM, conceptualmente similar en resultado al spoofing LLMNR/NBNS pero persistente y a nivel de toda la zona en lugar de una única difusión.

La Global Query Block List (GQBL) es la mitigación de Microsoft para el objetivo más infame de esta técnica — WPAD — pero la investigación de seguimiento de NetSPI señala que los registros NS aún la eluden en sistemas completamente parcheados, por lo que la GQBL es un control parcial, no un sustituto de corregir la ACL subyacente.

Las dos brechas complementarias: DNSSEC deshabilitado y registros comodín ya presentes

DNSSEC_NOT_ENABLED y DNS_WILDCARD_RECORDS agravan las tres configuraciones incorrectas anteriores en lugar de constituir rutas de ataque independientes:

• Sin DNSSEC, nada sobre el origen de un registro es verificable criptográficamente — una respuesta envenenada o suplantada no se puede distinguir de una legítima. Microsoft cubre la firma de zona en Sign DNS Zones with DNSSEC on Windows Server y la mecánica subyacente en el resumen de DNSSEC — para una zona integrada en AD, las claves de firma de zona se replican automáticamente a los servidores DNS primarios mediante la replicación AD normal, lo que hace que DNSSEC sea comparativamente poco costoso de desplegar específicamente en esta plataforma.
• Un registro comodín ya existente, hallado durante una auditoría — a diferencia de uno que un atacante acaba de crear — suele indicar que la ACL de la zona ya ha sido abusada, o que un equipo de aplicación legacy lo solicitó sin revisión de seguridad. En cualquier caso, merece tratarse como una cuestión de respuesta a incidentes, no como una simple limpieza de configuración, hasta que se demuestre lo contrario.

La cadena de ataque

Paso 1 — Reconocimiento vía transferencia de zona

Un atacante en la red (o, si la zona es alcanzable desde el exterior, desde internet) solicita una transferencia de zona al servidor DNS:

dig axfr corp.local @10.10.10.10

Si la zona no está restringida, la respuesta es el conjunto completo de registros: controladores de dominio, registros SRV para Kerberos/LDAP, todos los nombres de host de estaciones y servidores, y cualquier subdominio que nunca debió ser público.

Paso 2 — Elegir un nombre objetivo y registrar un registro

Usando nada más que una cuenta de dominio estándar, el atacante registra un registro DNS para un nombre de interés — un host dado de baja, un nombre que una aplicación legacy sigue resolviendo, o un comodín:

# Desde cualquier máquina unida al dominio, como cualquier usuario de dominio autenticado
Add-DnsServerResourceRecordA -ZoneName "corp.local" -Name "legacy-app" -IPv4Address 10.10.10.50 -ComputerName dc01.corp.local

Si la zona todavía permite la actualización dinámica insegura, este paso ni siquiera requiere una credencial de dominio válida — un host no autenticado en el segmento puede enviar la misma actualización directamente mediante el protocolo de actualización dinámica.

Paso 3 — Relay o interceptación

Con el registro activo, todo el tráfico destinado a ese nombre llega en su lugar al host del atacante. Para la resolución de nombres SMB/HTTP esto es un análogo directo del spoofing LLMNR/NBNS — salvo que persiste en el DNS en lugar de requerir que el atacante gane una carrera en cada consulta broadcast — y alimenta directamente el tooling de relay NTLM (Responder, ntlmrelayx) de la misma forma que lo haría una respuesta broadcast envenenada. La técnica es aún más fiable cuando la firma SMB está deshabilitada o no es obligatoria, ya que nada impide que la sesión reenviada se acepte como legítima.

Detección

Windows Server incluye dos canales de log DNS dedicados, ambos cubiertos en la documentación de Microsoft Enable DNS Logging and Diagnostics: los eventos DNS Audit (habilitados por defecto, baja sobrecarga) que cubren acciones administrativas — creación/eliminación de zona, cambios de registros y operaciones de firma DNSSEC — y los eventos DNS Analytical (deshabilitados por defecto, mayor volumen) que cubren el propio tráfico de consulta/respuesta/actualización dinámica. Ambos se encuentran bajo Applications and Services Logs > Microsoft > Windows > DNS-Server en el Visor de eventos.

Remediación

1. Restrinja las transferencias de zona. Configure las transferencias solo hacia secundarios de confianza, o desactívelas por completo si no existe ninguno:

   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries TransferToSecureServers
   # o, si ningún secundario externo necesita esta zona:
   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries NoTransfer
   

2. Fuerce la actualización dinámica solo segura en cada zona integrada en AD. Nonsecure and secure no debería aparecer en ninguna zona de producción:

   Set-DnsServerPrimaryZone -Name "corp.local" -DynamicUpdate Secure
   

3. Ajuste la ACL por defecto de la zona. Eliminar por completo los derechos create-child de Authenticated Users romperá el autorregistro legítimo de las máquinas unidas al dominio, así que hay que acotarlo, no simplemente revocarlo — la propia guía de Microsoft sobre este permiso (ver el hilo comunitario sobre el tema) confirma que el valor por defecto es más amplio de lo que la mayoría de equipos cree. Revise la pestaña de seguridad de la zona (o dsacls contra CN=<zone>,CN=MicrosoftDNS,DC=DomainDnsZones,DC=...) y acote los derechos create-child a las cuentas y grupos que realmente necesitan autorregistrarse — normalmente los equipos de dominio vía actualización dinámica segura, no todo el grupo Authenticated Users sin condición.

4. Elimine los registros comodín inesperados encontrados durante el barrido de auditoría, y trate cualquiera que no haya provisionado como un posible indicador de compromiso previo, no solo como limpieza.

5. Habilite la Global Query Block List para las trampas de nombre clásicas de alto valor (WPAD, ISATAP) como capa de defensa en profundidad — dnscmd /config /enableglobalqueryblocklist 1 — recordando el hallazgo de NetSPI de que los registros NS aún la eluden, por lo que esto complementa la corrección de la ACL, no la sustituye.

6. Habilite DNSSEC en las zonas integradas en AD según la guía de firma de zona de Microsoft — las claves de firma se replican automáticamente vía AD, así que una vez configurado el Key Master, el despliegue es en gran medida automático en el resto de controladores de dominio que alojan la zona.

El DNS es solo un punto en una lista mucho más larga — para un repaso completo de qué revisar primero en exposición Tier 0, abuso de ACL, Kerberos y logging, vea Auditar la seguridad de Active Directory: qué revisar primero.

Cómo lo detecta EtcSec

La auditoría de categoría Red de EtcSec verifica directamente las zonas DNS integradas en AD frente a estas cinco brechas: DNS_ZONE_TRANSFER_UNRESTRICTED y DNS_DYNAMIC_UPDATE_INSECURE marcan zonas cuyos ajustes de transferencia o actualización son más amplios que el valor seguro por defecto, DNS_ZONE_AU_CREATE_CHILD marca zonas donde Authenticated Users aún conserva los derechos create-child en la ACL de la zona, DNSSEC_NOT_ENABLED marca zonas integradas en AD sin firmar, y DNS_WILDCARD_RECORDS marca entradas comodín existentes para revisión manual.