Pentesting Active Directory con tier model: ataques y hardening 2026

Active Directory sigue siendo la columna vertebral de identidad en más del noventa y cinco por ciento de las empresas medianas y grandes que operan con stack Microsoft. El pentesting AD es una disciplina técnica madura, con tooling estandarizado y técnicas catalogadas en MITRE ATT&CK, pero el hardening efectivo no se consigue con parches aislados. Requiere un modelo estructural de segregación de privilegios, conocido históricamente como tier model y formalizado por Microsoft como Enterprise Access Model.

Esta guía describe las fases reales de un pentest AD, los vectores que aparecen una y otra vez en informes de Red Team, el desglose del tier model T0/T1/T2 y las contramedidas que cierran de verdad el camino a Domain Admin. Está pensada para responsables de seguridad, equipos azules y técnicos que quieren entender qué se valida en un proyecto serio y qué tienen que arreglar después.

Lo esencial: comprometer el dominio equivale a comprometer la empresa entera. El pentesting AD encuentra el camino más corto a Domain Admin mediante enumeración (BloodHound, SharpHound), ataques Kerberos (Kerberoasting, AS-REP Roasting, Golden Ticket), abuso de ACL y vectores AD CS (ESC1 a ESC11). El hardening efectivo pasa por aplicar tier model T0/T1/T2, LSA Protection, Credential Guard, Protected Users, LAPS, Authentication Silos, gMSA y disciplina absoluta sobre cuentas privilegiadas. Sin segregación de tiers, ninguna mitigación puntual aguanta.

Por qué AD es objetivo prioritario en cualquier pentest

En un entorno corporativo típico, AD controla autenticación de usuarios, autorización a aplicaciones internas, gestión de equipos, políticas de seguridad y, muy frecuentemente, el árbol de PKI y la federación con servicios cloud vía Azure AD Connect. Un atacante que llega a Domain Admin obtiene de facto control sobre todo el parque: file servers, correo, ERP, bases de datos, hipervisores, jump hosts y, en muchos casos, también el entorno híbrido en Microsoft 365.

El cálculo es asimétrico. Un pentester interno entra con credenciales de usuario estándar y, en la mayoría de dominios con deuda de configuración, puede escalar a privilegios totales en cuestión de horas o días. La razón es simple: AD acumula veinte años de configuraciones legacy, cuentas de servicio mal puestas, ACLs heredadas que nadie revisa y delegaciones que se aplicaron una vez "para que funcionara". Cada uno de esos restos es un escalón.

Por eso, en todo pentest interno serio, AD ocupa el bloque más extenso del informe. Y por eso el tier model se ha convertido en el estándar defensivo de referencia: no es una mejora marginal, es la única forma estructural de contener el blast radius cuando una credencial se compromete.

Fases del pentesting AD

Un pentest AD bien ejecutado sigue una secuencia ordenada, alineada con las fases clásicas de un compromiso real:

1. Discovery. Identificación de controladores de dominio, sitios AD, trusts, OUs principales, subnets activas y servicios expuestos en la red interna.
2. Enumeration. Recolección masiva de objetos: usuarios, grupos, equipos, GPOs, ACLs, SPNs, delegaciones, certificados emitidos, sesiones activas.
3. Exploitation. Ejecución de ataques sobre los hallazgos: Kerberoasting, AS-REP Roasting, ESC1, abuso de ACL.
4. Lateral movement. Movimiento entre equipos usando credenciales recuperadas, tickets robados o relays.
5. Escalation. Escalado de privilegios local y de dominio hasta llegar al tier objetivo.
6. Persistence. Mecanismos de mantenimiento de acceso: Golden Ticket, DCShadow, AdminSDHolder, esqueletos en grupos privilegiados.
7. Exfiltration. Demostración controlada de extracción de datos sensibles (no se exfiltra de verdad en un pentest, se documenta el path).

El pentester rota entre fases continuamente. Una nueva credencial recuperada en lateral movement reabre enumeration desde otra perspectiva. Por eso un proyecto serio nunca se mide solo en duración, sino en cobertura de caminos críticos encontrados y validados.

Enumeración y discovery

La enumeración es la fase más larga y la que define la calidad del resto del pentest. Las herramientas estándar:

• SharpHound (collector de BloodHound). Recolecta sesiones activas, miembros de grupos, ACLs, trusts y objetos del dominio. Versiones modernas (BloodHound CE y BloodHound Enterprise) permiten correr el collector en modo stealth y filtrar por OU.
• BloodHound (analyzer). Convierte los datos en un grafo Neo4j navegable. Sus queries built-in identifican "Shortest Paths to Domain Admins", "Kerberoastable Users", "AS-REP Roastable Users", "Unconstrained Delegation", "Computers with Local Admin" y muchas más.
• PowerView. Suite PowerShell con funciones manuales: Get-NetUser, Get-NetGroup, Get-NetComputer, Get-NetSession, Get-DomainObjectAcl. Útil cuando no se quiere desplegar BloodHound completo.
• ldapsearch y ldapdomaindump. Enumeración LDAP plana, válida en Linux o WSL.
• ROADrecon. Equivalente a BloodHound para Entra ID. Imprescindible cuando hay tenant híbrido.
• adPEAS, Snaffler (búsqueda de credenciales en shares), PingCastle (en modo lectura para benchmark).

Las métricas que BloodHound expone y que un pentester reporta siempre: número de paths a Domain Admin desde un usuario estándar, número de usuarios kerberoastables, porcentaje de equipos con admin local compartido, sesiones de cuentas T0 detectadas en equipos T1/T2, computadoras con unconstrained delegation.

Ataques Kerberos clásicos

Kerberos es el protocolo de autenticación por defecto en AD, y por su diseño abre múltiples vías de abuso cuando hay configuraciones débiles:

• Kerberoasting (T1558.003). Cualquier usuario autenticado puede pedir un TGS para cualquier cuenta con SPN. El ticket se cifra con el hash NT de la cuenta de servicio. Si la password es débil, se rompe offline con hashcat -m 13100. Herramientas: Rubeus.exe kerberoast, GetUserSPNs.py de Impacket.
• AS-REP Roasting (T1558.004). Cuentas con el flag DONT_REQ_PREAUTH activado emiten parte del AS-REP cifrada sin necesidad de autenticación previa. Esa parte se crackea offline. Herramientas: Rubeus.exe asreproast, GetNPUsers.py.
• Pass-the-Ticket. Reutilización de un TGT o TGS extraído de memoria con Mimikatz o Rubeus para autenticarse como el usuario propietario sin conocer su password.
• Pass-the-Hash. Reutilización del hash NT de una cuenta para autenticarse vía NTLM contra recursos del dominio.
• Golden Ticket (T1558.001). Forja de un TGT arbitrario firmado con el hash de la cuenta krbtgt. Da Domain Admin persistente hasta que se rota krbtgt dos veces.
• Silver Ticket. Forja de un Service Ticket arbitrario firmado con el hash NT de una cuenta de servicio concreta. Limita el alcance al servicio, pero no genera tráfico al DC y es difícil de detectar.
• Diamond Ticket. Variante que solicita un TGT legítimo al KDC, lo descifra con krbtgt y modifica los claims internos (PAC) para inyectar pertenencia a grupos privilegiados. Más sigiloso que el Golden clásico.
• Sapphire Ticket. Evolución del Diamond que aprovecha el flujo S4U2self para obtener un PAC válido de una cuenta privilegiada arbitraria sin tener que forjarlo desde cero. Detectado por equipos de Red Team avanzados a partir de 2023.

Cada uno de estos vectores tiene mitigaciones específicas, pero todos comparten una contramedida estructural: aplicar tier model y separar credenciales privilegiadas.

ACL abuse y misconfigurations

Active Directory permite delegar permisos granulares sobre objetos mediante ACLs. Cuando esas ACLs no se revisan, se acumulan derechos que un atacante puede encadenar:

• GenericAll. Control total sobre el objeto. Permite cambiar password, añadir SPN, modificar atributos críticos.
• GenericWrite. Modificación de atributos. Permite añadir SPN a una cuenta y luego Kerberoastearla.
• WriteDACL. Modificación del propio descriptor de seguridad del objeto. Equivale a GenericAll porque el atacante se concede a sí mismo los permisos restantes.
• WriteOwner. Permite tomar ownership del objeto y luego concederse permisos.
• ForceChangePassword. Cambio de password sin conocer la anterior.
• AddMember sobre un grupo. Auto-añadirse al grupo, típicamente a uno con privilegios elevados.
• AllExtendedRights. Incluye User-Force-Change-Password, y sobre el objeto dominio incluye DS-Replication-Get-Changes y DS-Replication-Get-Changes-All (DCSync).

BloodHound mapea estos abusos como aristas del grafo y propone el camino más corto a Domain Admin. La pregunta del pentest es siempre la misma: cuántos hops hay desde el usuario estándar hasta el grupo Domain Admins, y por qué ACLs concretas pasa cada hop.

AD Certificate Services attacks

Active Directory Certificate Services (AD CS) gestiona la PKI interna. Will Schroeder y Lee Christensen publicaron en 2021 el paper "Certified Pre-Owned" que catalogó once vectores conocidos como ESC1 a ESC11. Resumen breve:

• ESC1. Plantilla de certificado que permite a un usuario solicitar un certificado especificando el SAN (Subject Alternative Name) con cualquier UPN. Permite solicitar certificado a nombre de Domain Admin.
• ESC2. Plantilla con EKU "Any Purpose" o sin EKU. Equivalente práctico a ESC1.
• ESC3. Plantilla enrollment agent que permite emitir certificados a nombre de otros usuarios.
• ESC4. ACL vulnerable sobre la plantilla de certificado. Permite modificarla y convertirla en ESC1.
• ESC5. ACL vulnerable sobre objetos PKI en AD (CA object, Enrollment Services).
• ESC6. Flag EDITF_ATTRIBUTESUBJECTALTNAME2 en la CA. Permite SAN arbitrario en cualquier plantilla.
• ESC7. Permisos ManageCA o ManageCertificates sobre la CA.
• ESC8. NTLM relay a HTTP Web Enrollment de AD CS. Permite obtener certificado de una cuenta de máquina sin password.
• ESC9 y ESC10. Manipulación de userPrincipalName y mapeo débil entre certificado y cuenta.
• ESC11. Relay a la interfaz RPC de la CA sin firma.

Tool de referencia: Certipy (Python). Permite enumerar (certipy find), explotar (certipy req, certipy auth) y atacar relays. Mitigación general: revisar plantillas, deshabilitar EDITF_ATTRIBUTESUBJECTALTNAME2, exigir aprobación manager para plantillas sensibles, parchear KB5014754 (mapeo fuerte certificado-cuenta), forzar firma LDAP y deshabilitar Web Enrollment HTTP.

Otros vectores 2026

Más allá de Kerberos, ACL y AD CS, el repertorio actual incluye:

• Print Spooler abuse. PrintNightmare (CVE-2021-34527) sigue apareciendo en entornos sin parchear. El servicio Print Spooler, además, se usa para forzar autenticación de cuentas de máquina contra atacantes mediante el RPC RpcRemoteFindFirstPrinterChangeNotificationEx (PrinterBug).
• SCCM/MECM relay. Microsoft Configuration Manager almacena credenciales privilegiadas, gestiona network access accounts y permite distribución de software. Herramienta de referencia: SharpSCCM.
• MSSQL impersonation. Cuentas de servicio de SQL Server con IMPERSONATE sobre sa u otros logins permiten ejecutar comandos como esos logins. Encadenado con xp_cmdshell o linked servers permite movimiento lateral.
• RBCD (Resource-Based Constrained Delegation). Si el atacante controla un objeto computer con GenericWrite, puede escribir msDS-AllowedToActOnBehalfOfOtherIdentity sobre otro computer y suplantar a cualquier usuario contra ese recurso. Herramientas: Rubeus, Impacket.
• DCSync (T1003.006). Solicitud de replicación al DC para extraer hashes de cualquier cuenta, incluyendo krbtgt. Requiere permisos DS-Replication-Get-Changes y DS-Replication-Get-Changes-All. Herramientas: mimikatz lsadump::dcsync, secretsdump.py.
• DCShadow. Registra un DC malicioso temporal en el dominio y replica cambios arbitrarios (modificación de SID History, AdminSDHolder, ACLs). Persistencia avanzada muy difícil de detectar.
• NTLM Relay. Captura de autenticación NTLM y reenvío contra LDAP, SMB, HTTP. ntlmrelayx.py de Impacket es el estándar.

Tier model T0/T1/T2 como defensa estructural

Microsoft retiró formalmente el modelo ESAE / Red Forest en 2020 y lo reemplazó por el Enterprise Access Model, una evolución que mantiene el principio nuclear de la segmentación por tiers pero lo integra con identidad cloud y privileged access workstations modernas.

La definición operativa de tiers:

• Tier 0. Identidad raíz del entorno. Incluye Domain Controllers, ADFS, servidores PKI (AD CS), Azure AD Connect, soluciones de Privileged Access Management, hipervisores que alojan DCs y sistemas de backup que contienen estado de DC. Comprometer cualquier T0 equivale a comprometer todo el dominio.
• Tier 1. Servidores y aplicaciones empresariales. File servers, SQL, ERP, correo on-premise, servidores web internos, gestores documentales. Su compromiso afecta datos y servicios pero no debe poder escalar a T0.
• Tier 2. Estaciones de trabajo y dispositivos de usuarios. Endpoints, equipos de developer, portátiles corporativos. Es el tier más expuesto y donde aterrizan la mayoría de los compromisos iniciales (phishing, drive-by, USB).

Las reglas no negociables:

1. Una cuenta nunca cruza tiers. Un admin T0 no se loguea jamás en un equipo T1 o T2. Un admin T1 no se loguea en T2. Si necesita administrar un equipo de tier inferior, lo hace desde su propia PAW T0 vía RDP saltando o desde un jump server dedicado.
2. Cuentas separadas por tier. El usuario juan tiene tres cuentas distintas: juan (T2, su buzón y workstation), juan-adm-t1 (administración T1), juan-adm-t0 (administración T0). Cada una con password independiente y MFA obligatorio.
3. PAW (Privileged Access Workstation). Estación física o virtual dedicada exclusivamente a tareas administrativas, sin correo, sin navegador general, sin software de productividad. Solo herramientas administrativas y conexión a recursos del tier correspondiente.
4. Authentication Silos. Configuración nativa de AD que impide que cuentas T0 puedan autenticarse contra equipos fuera del silo T0.
5. Tier 0 nunca se administra por RDP desde el resto. Acceso por consola física, PAW dedicada o jump host T0 endurecido.

Implementar tier model en una organización con deuda histórica es trabajo de meses, no de un sprint. Pero es la única defensa que sobrevive a una credencial filtrada.

Hardening efectivo post-pentest

Después de un pentest AD, el informe lista hallazgos individuales. La remediación útil agrupa controles transversales:

• LSA Protection (RunAsPPL). Marca el proceso LSASS como Protected Process Light. Impide volcado de credenciales con Mimikatz sin un driver firmado. Activable con HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL.
• Credential Guard (HVCI). Aísla LSASS en un contenedor de virtualización Hyper-V. Incluso un proceso con privilegios SYSTEM no puede leer secretos. Requiere CPU con virtualización y firmware moderno.
• Protected Users group. Aplica políticas restrictivas: prohibe NTLM, RC4, delegación clásica y cacheo de credenciales. Imprescindible para todas las cuentas privilegiadas.
• Tiered admin accounts + PAW. Implementación operativa del tier model descrita arriba.
• LAPS / Windows LAPS. Password aleatoria por equipo para la cuenta de administrador local, rotada periódicamente y almacenada en AD. Elimina el password de admin local reutilizado en todo el parque, vector principal de movimiento lateral.
• Authentication Silos + Policies. Restringen desde qué equipos puede autenticarse una cuenta y a qué equipos puede autenticarse.
• AD CS hardening. Revisión sistemática de plantillas, deshabilitación de EDITF_ATTRIBUTESUBJECTALTNAME2, parche KB5014754, retirada de plantillas con EKU "Any Purpose" o "Smart Card Logon" abiertas, restricción de enrollment.
• SMB signing required y LDAP signing + channel binding required en todos los DCs y servidores sensibles. Cierra la mayoría de NTLM relays.
• Deshabilitar NTLMv1. Sin excepciones. Auditar primero con Negotiate signing y migrar las aplicaciones que aún lo usen.
• Restringir NTLMv2. GPO Network security: Restrict NTLM para minimizar uso outbound e inbound.
• Auditoría de schema permissions. Permisos sobre objetos del schema (adminSDHolder, Configuration, Schema) deben estar limitados a cuentas T0 puras.
• gMSA para cuentas de servicio. Sustitución progresiva de cuentas de servicio tradicionales por Group Managed Service Accounts. Passwords de 240 bytes, rotación automática cada 30 días.
• Rotación periódica de krbtgt. Doble rotación cada 6-12 meses con script oficial de Microsoft.

Cómo medir madurez AD

Tras aplicar el hardening, hay que medir el resultado. Las herramientas y métricas que se usan:

• BloodHound queries. Las queries built-in de "Shortest Paths to Domain Admins from Owned" y "Critical Assets" cuantifican el progreso. La métrica clave: número de paths existentes en el grafo desde un usuario estándar hasta Domain Admins. Objetivo razonable tras hardening: cero paths directos en menos de cinco hops sin explotación activa.
• PingCastle. Reporte automatizado de salud AD con score 0-100 (cuanto menor, mejor). Cubre anomalías de configuración, cuentas inactivas, trusts, vulnerabilidades conocidas. Es el benchmark más usado en consultoría.
• Purple Knight (Semperis). Herramienta gratuita orientada a detectar indicadores de exposición. Genera reporte categorizado por área (account security, Kerberos, AD delegation, AD infrastructure security).
• Microsoft Defender for Identity. Sensor en los DCs que detecta comportamiento anómalo y mapea identidades a tier. Integrado con Microsoft 365 Defender.
• Scripts ad-hoc. Auditorías custom de SPNs olvidados, cuentas con PasswordNotRequired, delegaciones unconstrained, miembros de Schema Admins y Enterprise Admins.

Una organización madura corre PingCastle trimestralmente, BloodHound tras cada cambio significativo y un pentest AD completo anual.

Preguntas frecuentes

¿Aplica el mismo enfoque a AD on-premise y a Entra ID?

No de la misma forma. Entra ID (antes Azure AD) no usa Kerberos como autenticación primaria, no tiene controladores de dominio en el sentido clásico y su modelo de privilegios se gestiona con roles RBAC y Privileged Identity Management. Sin embargo, casi todas las organizaciones tienen entorno híbrido con Azure AD Connect, lo que crea una superficie de ataque adicional: comprometer el servidor de sincronización es comprometer el tenant. ROADrecon es el equivalente de BloodHound para Entra ID. El tier model aplica conceptualmente: cuentas Global Admin son T0 puro y no deben usarse para tareas operativas.

¿Es legal usar BloodHound contra el dominio de mi empresa?

Sí, siempre que haya autorización formal. BloodHound es una herramienta de auditoría, no un exploit. Cualquier consultor externo necesita scope firmado en el contrato. Internamente, el equipo de seguridad debe tener autorización del responsable de IT y del responsable de seguridad. Sin autorización, ejecutar SharpHound puede considerarse acceso no autorizado bajo el artículo 197 bis del Código Penal.

¿Cuánto tarda un pentest AD completo?

Un pentest AD interno de calidad razonable ocupa entre dos y cuatro semanas de trabajo efectivo, dependiendo del tamaño del dominio, número de OUs, trusts existentes y profundidad solicitada. Las primeras dos semanas se concentran en enumeración, exploitation y lateral movement. Las siguientes en validación de paths críticos, persistencia y redacción de informe. Un Red Team con AD como objetivo principal puede extenderse a seis u ocho semanas.

¿Hay que hacer retest después de aplicar el hardening?

Sí. El retest es la única forma de validar que las contramedidas funcionan en producción y que no se han introducido nuevas exposiciones durante la remediación. Lo habitual es contratar un retest enfocado, no un pentest completo, a los tres o seis meses de la entrega del informe inicial. Si el cliente aplica tier model como parte del hardening, el retest debe incluir validación específica de la segregación.

¿Una pyme puede implementar tier model realmente?

Con escala adaptada, sí. Una pyme con un solo dominio, treinta servidores y doscientos endpoints puede implementar una versión simplificada: una PAW virtual para el admin de dominio, cuentas separadas T0 y T2, LAPS desplegado, Protected Users habilitado para administradores. El esfuerzo razonable es un proyecto de tres a seis semanas. No es el ESAE completo de Microsoft, pero cierra los caminos críticos.

¿ESAE sigue siendo válido como referencia?

Microsoft retiró ESAE como recomendación formal en 2020 y dejó de actualizar la guía. El sucesor oficial es el Enterprise Access Model, que mantiene los principios (segmentación, PAW, separación de cuentas) pero los adapta a entornos híbridos y cloud-first. Implementaciones ESAE legacy siguen siendo válidas si se mantienen; nuevas implementaciones deben seguir Enterprise Access Model.

Recursos relacionados

• Ataques Kerberos en Active Directory: detalle técnico ampliado de Kerberoasting, AS-REP Roasting y Golden Ticket.
• Qué es Mimikatz y credential dumping: la herramienta que sigue marcando el ritmo del post-explotación AD.
• Red Team: guía para empresas: cómo se integra el pentest AD en ejercicios ofensivos más amplios.
• Qué es PKI: fundamento sobre el que se monta AD CS y sus vectores ESC.
• Qué es MITRE ATT&CK: framework que cataloga todas las técnicas mencionadas en esta guía.
• Pentesting de infraestructura interna y externa: metodología y entregables de un proyecto real.
• Top 10 herramientas de pentesting 2026: catálogo actualizado de tooling ofensivo.

Auditoría AD con Secra

En Secra ejecutamos pentesting Active Directory enfocado a hallar el camino real hasta Domain Admin y, sobre todo, a documentar cómo cerrarlo. El proyecto incluye enumeración con BloodHound y ROADrecon, ejecución controlada de ataques Kerberos y AD CS, auditoría de ACLs y delegaciones, diseño de tier model T0/T1/T2 adaptado al tamaño real de la organización y recomendaciones de hardening priorizadas para los seis meses siguientes. Cubrimos también la fase de retest una vez aplicadas las contramedidas. Si tu organización opera sobre AD y nunca ha sido auditada, va por su tercer responsable de sistemas o necesita validar el dominio antes de una auditoría NIS2, DORA o ISO 27001, escríbenos a través de contacto y planificamos el alcance.