Arquitectura de AD y superficie de ataque

Aviso legal y ético: los comandos de enumeración y la cadena de ataque de este módulo están pensados para ejecutarse exclusivamente en un laboratorio propio (VM que controles, red aislada sin salida a producción) o con autorización expresa y por escrito del propietario del sistema. Enumerar o intentar comprometer un dominio de Active Directory ajeno sin autorización es delito en España conforme al art. 197 bis del Código Penal (acceso ilícito a sistemas de información) y al art. 197 ter (facilitación de medios para cometerlo), con equivalentes en cualquier jurisdicción (CFAA en EE. UU., Computer Misuse Act en Reino Unido). Un AD de producción sostiene la identidad de toda la organización: una enumeración agresiva puede provocar bloqueos de cuenta masivos o caídas de un DC. Practica siempre en tu propio laboratorio.

Qué aprenderás

Los componentes estructurales de Active Directory Domain Services (bosque, dominio, OU, sitio, esquema, catálogo global) y cómo se relacionan.
Qué son los cinco roles FSMO, por qué existen y qué ocurre —en seguridad y disponibilidad— cuando cada uno falla o es tomado por un atacante.
El controlador de dominio y la base NTDS.dit como el activo más crítico y más buscado en cualquier intrusión.
Kerberos, NTLM y LDAP/LDAPS: sus diferencias de seguridad fundamentales.
Los niveles funcionales de bosque y dominio de 2003 a 2016+, y qué característica de seguridad desbloquea cada salto.
Por qué AD es el objetivo número uno en casi cualquier intrusión corporativa y cómo se articula la cadena de ataque típica.
La evolución de la postura de seguridad por defecto, de un WS2003 permisivo a un WS2022/2025 + Entra ID endurecido de fábrica.
Comandos reales —modernos (PowerShell, módulo ActiveDirectory) y legacy (dsquery, repadmin, netdom)— para enumerar un bosque.

1. Por qué Active Directory es el sistema nervioso de casi cualquier red Windows

Active Directory Domain Services (AD DS) es el servicio de directorio de Microsoft presente en la inmensa mayoría de organizaciones medianas y grandes que usan Windows. Centraliza tres funciones que, sin él, habría que resolver máquina a máquina: identidad (quién es cada usuario y equipo), autenticación (demostrar que lo es) y autorización (qué puede hacer, aplicado sobre todo vía GPO y ACL). Esa centralización es su mayor virtud operativa y su mayor riesgo: quien controla AD controla la identidad de toda la organización. Por eso en casi cualquier informe de intrusión seria (APT, ransomware, red team) el objetivo intermedio es «llegar a Domain Admin», o en términos más precisos, alcanzar dominancia del dominio (domain dominance): control suficiente para emitir credenciales válidas para cualquier identidad a voluntad.

Este módulo recorre la arquitectura de AD DS desde Windows Server 2003 hasta Windows Server 2025 y su integración híbrida con Microsoft Entra ID (antiguo Azure AD). El objetivo no es solo «qué es cada pieza», sino por qué cada pieza es superficie de ataque, y qué ha hecho Microsoft en veinte años para endurecer un diseño pensado, en origen, para la compatibilidad hacia atrás antes que para la seguridad por defecto.

2. Componentes estructurales de AD DS

Antes de hablar de ataques hay que fijar vocabulario: en AD los términos no son intercambiables.

2.1 Bosque (forest)

El bosque es el límite de seguridad superior de una implantación de AD: una colección de uno o más dominios que comparten esquema, catálogo global y confianza transitiva entre todos ellos. Un compromiso del bosque raíz (forest root domain) —el primer dominio creado, que aloja Schema Admins y Enterprise Admins— equivale, en la práctica, al compromiso de todo lo que cuelga de él, aunque haya dominios hijos con administradores distintos.

2.2 Dominio (domain)

Límite administrativo y de replicación dentro de un bosque. Cada dominio tiene su propia base de objetos, su política de contraseñas por defecto y su propio grupo Domain Admins. Los dominios de un mismo bosque confían entre sí de forma transitiva (Kerberos bidireccional): un atacante que compromete un dominio hijo débil puede escalar hasta el dominio raíz —el ataque clásico es la falsificación del SID history o el abuso del krbtgt del hijo—.

2.3 Unidad organizativa (OU)

Contenedor administrativo dentro de un dominio para agrupar objetos y aplicar delegación de permisos y GPO de forma granular. A diferencia del dominio, la OU no es un límite de seguridad, sino de administración. Delegar «Restablecer contraseña» o «Modificar pertenencia a grupos» sobre una OU sin comprobar que no contiene, directa o por herencia, cuentas privilegiadas es una fuente constante de escalada en auditorías reales.

2.4 Sitios y replicación

Un sitio representa una ubicación física o de red (subredes de baja latencia) y optimiza el tráfico de replicación y la autenticación (el cliente prioriza un DC de su propio sitio). Desde una óptica ofensiva, la topología de sitios revela la estructura física de la organización y qué DC son más accesibles desde una ubicación comprometida.

2.5 Esquema

Define la estructura de todos los objetos posibles del bosque (qué atributos puede tener un usuario, equipo o grupo). Es único por bosque. Modificarlo exige pertenencia a Schema Admins: la práctica recomendada es mantenerlo vacío y añadir una cuenta solo temporalmente cuando una extensión de esquema (Exchange, una PKI) lo requiere.

2.6 Catálogo global (GC)

Subconjunto parcial y replicado de atributos de todos los objetos de todos los dominios del bosque, alojado en DC designados como servidores GC. Permite resolver, por ejemplo, la pertenencia a grupos universales durante el logon sin consultar cada dominio por separado. Un DC sin rol GC no puede procesar por sí solo ciertos tipos de autenticación en bosques multidominio.

3. Los cinco roles FSMO y por qué importan en seguridad

A diferencia de una base multi-maestro pura, ciertas operaciones de AD no admiten escritura simultánea en todos los DC sin riesgo de conflicto. Para ellas, Microsoft definió cinco roles FSMO (Flexible Single Master Operations), «propiedad» de un único DC en cada momento: dos de ámbito bosque y tres de ámbito dominio.

Rol FSMO	Ámbito	Función	Impacto de seguridad si falla o es comprometido
Schema Master	Bosque (uno por bosque)	Único DC que admite modificaciones al esquema de AD.	Comprometido, permite inyectar atributos o clases maliciosas; si falla, no se pueden hacer extensiones de esquema, pero la operación diaria no se ve afectada.
Domain Naming Master	Bosque (uno por bosque)	Controla altas/bajas de dominios y particiones de directorio de aplicación.	Comprometido, permite manipular la topología del bosque; si falla, no se pueden añadir/quitar dominios, el resto sigue funcionando.
RID Master	Dominio (uno por dominio)	Asigna bloques de Relative ID a cada DC para generar SID únicos de objetos nuevos.	Si falla de forma prolongada, los DC agotan su bloque local y no pueden crear objetos de seguridad nuevos; un atacante con este rol puede influir en la asignación de identificadores.
PDC Emulator	Dominio (uno por dominio)	Referencia horaria del dominio (crítico para Kerberos), procesa cambios de contraseña y bloqueos de cuenta con prioridad, aplica GPO por defecto.	El rol con más impacto directo en seguridad. Kerberos exige sincronización horaria estricta (por defecto, más de 5 minutos de desviación invalida tickets); si falla o se manipula la hora, hay fallos de autenticación masivos o ventanas de replay.
Infrastructure Master	Dominio (uno por dominio)	Mantiene actualizadas las referencias entre objetos de distintos dominios cuando uno se mueve o renombra.	Si falla, quedan desactualizados los nombres de miembros de grupos de otro dominio, sin afectar a la autenticación. Si el DC es también GC, el rol queda inactivo por diseño (normal en bosques de un solo dominio).

Dato clave: los cinco roles FSMO residen, salvo reconfiguración explícita, en el primer DC instalado del bosque/dominio, lo que lo convierte en objetivo de alto valor histórico. En despliegues maduros conviene distribuir los roles entre DC robustos (nunca uno de sucursal con seguridad física débil) y documentar dónde está cada uno: perder el PDC Emulator o el RID Master sin un procedimiento claro de seizure (transferencia forzada) puede paralizar la creación de cuentas o la autenticación de todo un dominio.

4. El controlador de dominio y NTDS.dit: el activo más crítico

Un controlador de dominio (DC) es un servidor Windows Server que ejecuta AD DS y aloja una réplica —completa, salvo en RODC— de la base del dominio: el fichero NTDS.dit (NT Directory Services, Directory Information Tree), en %SystemRoot%NTDSntds.dit, formato ESE (el mismo motor que usa Exchange). Contiene todos los objetos del dominio y, sobre todo, los hashes de contraseña de todas las cuentas, incluida krbtgt, clave con la que el KDC firma y cifra todos los tickets Kerberos del dominio.

Extraer NTDS.dit junto con el registro SYSTEM (que contiene la clave de arranque para descifrar los secretos) equivale a obtener offline todas las credenciales del dominio. Es la técnica detrás de DCSync (abuso de los permisos de replicación DS-Replication-Get-Changes/DS-Replication-Get-Changes-All para pedir a un DC legítimo que «replique» los hashes como si el atacante fuera otro DC, sin tocar el fichero) y de la extracción clásica con ntdsutil o una instantánea de volumen (vssadmin). Comprometer un solo DC —físico, virtual, o un backup mal protegido con NTDS.dit— equivale a comprometer todo el dominio: el hardening de los DC (parcheo prioritario, sin navegación web, sin agentes de terceros innecesarios, acceso restringido a un modelo Tier 0) es la medida de mayor retorno en cualquier entorno AD.

5. Protocolos de autenticación y directorio

AD DS se apoya en tres protocolos con historiales de seguridad muy distintos.

5.1 Kerberos

Kerberos (RFC 4120, con extensiones propietarias de Microsoft) es el protocolo de autenticación por defecto desde Windows 2000. Un Key Distribution Center (KDC, rol de todo DC) emite dos tickets: el TGT (Ticket Granting Ticket, tras AS-REQ/AS-REP) y el TGS (Ticket Granting Service, presentando el TGT vía TGS-REQ/TGS-REP para acceder a un servicio). No transmite la contraseña ni su hash por la red y usa claves derivadas de la contraseña (o del hash krbtgt para firmar TGT). Es mucho más robusto que NTLM, pero no inmune: Kerberoasting (pedir un TGS para una cuenta con SPN y romper offline su cifrado), AS-REP Roasting (contra cuentas sin preautenticación) y Golden/Silver Ticket (falsificar TGT o TGS con el hash de krbtgt o de una cuenta de servicio) abusan del protocolo, no lo rompen.

5.2 NTLM

NTLM (NT LAN Manager) es el protocolo challenge-response heredado de antes de Windows 2000, mantenido por compatibilidad. NTLMv1 es criptográficamente débil (DES sobre claves derivadas del hash NT, rompible con hardware moderno, vulnerable a downgrade y relay); NTLMv2 añade desafío de cliente y HMAC-MD5, más resistente pero igualmente vulnerable a NTLM relay (retransmitir una respuesta de autenticación capturada hacia otro servicio que la acepte, sin romper el hash). NTLM no valida la identidad del servidor ante el cliente como sí hace Kerberos, lo que lo expone estructuralmente al ataque de intermediario. Microsoft recomienda restringir NTLMv1 desde Windows Server 2008/Vista (directiva Network security: LAN Manager authentication level), y Windows Server 2025/Windows 11 24H2 ya deshabilita NTLM por defecto en escenarios concretos.

5.3 LDAP y LDAPS

LDAP (RFC 4511) es el protocolo con el que clientes y aplicaciones consultan y modifican el directorio. Sin cifrar, circula en claro por 389/TCP (636/TCP para LDAPS con TLS), lo que durante años permitió capturar credenciales de aplicaciones mal configuradas. Un problema independiente del cifrado es la firma LDAP: sin ella, un simple bind es vulnerable a manipulación y relay igual que NTLM. Microsoft ha ido endureciendo esto con actualizaciones acumulativas (relacionadas con CVE-2017-8563 y el endurecimiento posterior a los CVE de relay contra ADCS), y desde Windows Server 2022 la exigencia de firma y channel binding es más agresiva por defecto, aunque en entornos legacy sigue requiriendo verificación explícita del administrador.

6. Niveles funcionales de bosque y dominio

El nivel funcional determina qué características están disponibles en un bosque o dominio y garantiza que todos los DC presentes soportan un mínimo común. Elevarlo es, en la práctica habitual, de un solo sentido, y exige que todos los DC del ámbito ejecuten como mínimo la versión de SO asociada. La tabla resume la evolución y la característica de seguridad clave de cada nivel.

Nivel funcional	SO mínimo requerido / año aprox.	Característica de seguridad clave que desbloquea
Windows2000 / Windows2003	Windows Server 2003 (2003)	Nivel base heredado: sin AES para Kerberos (solo DES/RC4), sin Recycle Bin de AD, sin Protected Users. Referencia del estado «legacy inseguro por defecto».
Windows2008	Windows Server 2008 (2008)	Cifrado Kerberos AES-128/AES-256 (frente a RC4/DES) y DFS-R para SYSVOL en lugar del FRS heredado.
Windows2008R2	Windows Server 2008 R2 (2009)	Papelera de reciclaje de AD: restaura objetos eliminados —con sus atributos de seguridad— sin restauración autoritativa completa.
Windows2012	Windows Server 2012 (2012)	KDC con soporte de reclamos (claims) y Dynamic Access Control: autorización granular basada en atributos, no solo en grupos.
Windows2012R2	Windows Server 2012 R2 (2013)	Protected Users (impide credenciales reutilizables en memoria vía NTLM/tickets de larga duración) y Authentication Policy Silos (restringen desde qué equipos autentica una cuenta privilegiada). El salto más citado en hardening de cuentas Tier 0.
Windows2016	Windows Server 2016 (2016)	PAM vía bosque bastión (bosque administrativo aislado, pertenencia a grupos con expiración automática, shadow principals) y clonación segura de DC. Es el nivel funcional más alto que existe: no hay «Windows2019» ni «Windows2022» — esas versiones de Windows Server operan como DC con normalidad, pero el techo del bosque/dominio sigue siendo 2016.

Esto genera confusión y merece subrayarse: instalar Windows Server 2022 o 2025 como DC no eleva por sí solo el nivel funcional a un supuesto «2022» —ese valor no existe en ForestMode/DomainMode—. Un DC más moderno aporta mejoras que no dependen del nivel funcional: parches más recientes, TLS 1.3, mejor Credential Guard, hardening del propio SO; el nivel funcional sigue topando en 2016.

7. DNS integrado, replicación, SYSVOL y GPO

Cuatro piezas más completan la arquitectura y son, también, superficie de ataque.

DNS integrado en AD: la práctica estándar aloja las zonas DNS directamente en AD (Active Directory-Integrated Zones), con replicación multi-maestro segura junto al resto del directorio. Riesgo doble: un DNS mal asegurado permite envenenamiento o registro dinámico no autenticado (mitigable exigiendo actualizaciones dinámicas seguras), y el propio servicio ha tenido RCE críticas (CVE-2020-1350, «SIGRed»), por lo que el rol DNS Server en un DC exige el mismo rigor de parcheo que el propio AD DS.

Replicación: los cambios se propagan entre DC vía RPC sobre IP dentro del mismo sitio, y habitualmente SMTP o IP comprimido entre sitios, siguiendo una topología calculada por el Knowledge Consistency Checker (KCC). El comando de referencia para diagnosticarla es repadmin, cubierto en el laboratorio.

SYSVOL: recurso compartido (\dominioSYSVOL) presente en todo DC, con scripts de logon y, sobre todo, las plantillas de las GPO. Se replica vía DFS-R desde nivel funcional 2008 (antes, el obsoleto FRS). Es objetivo histórico porque, durante años, se almacenaron contraseñas en claro o cifradas de forma reversible en preferencias de GPO (Groups.xml y similares) para tareas como cambiar la contraseña de administrador local; Microsoft corrigió esta práctica con el boletín MS14-025 (2014).

GPO: mecanismo de aplicación centralizada de configuración y seguridad, desde políticas de contraseña hasta restricción de software. Su riesgo es la delegación: cualquier cuenta con permiso de escritura sobre una GPO enlazada a una OU con equipos o cuentas privilegiadas puede ejecutar código con privilegios de sistema en el siguiente ciclo de actualización de política, una de las rutas de escalada lateral más explotadas en pentest sobre AD.

8. La superficie de ataque de Active Directory

8.1 Por qué AD es el objetivo número uno

Lógica de coste-beneficio: comprometer una estación de trabajo da acceso a un usuario y sus recursos. Comprometer AD —alcanzar Domain Admin o equivalente, o extraer el hash de krbtgt— da acceso equivalente a cualquier identidad del dominio, y por extensión a todo lo que confía en ella: ficheros, bases de datos, correo, VPN, VDI, y en entornos híbridos, potencialmente Entra ID si hay sincronización de contraseñas o federación mal segmentada. De ahí la máxima de la comunidad de seguridad de AD: «una sola cuenta de Domain Admin comprometida es, en la práctica, el compromiso de todo el dominio».

8.2 Autenticación vs. autorización

Distinción que se confunde a menudo. La autenticación responde a «¿eres quien dices ser?» (Kerberos/NTLM validando una credencial). La autorización responde a «¿qué te permito hacer?» (ACL, permisos NTFS, grupos, GPO). Fallan de formas distintas: Pass-the-Hash/Pass-the-Ticket abusan de la autenticación (usar un secreto capturado sin conocer la contraseña en claro); el abuso de ACL (por ejemplo, GenericAll heredado sobre un grupo privilegiado, detectable con BloodHound) abusa de la autorización sin robar ninguna credencial: el atacante ya está autenticado legítimamente como usuario de bajo privilegio, y el fallo está en qué se le permitió hacer.

8.3 La cadena de ataque típica contra un dominio AD

Cada intrusión tiene matices, pero esta secuencia es lo bastante consistente entre informes de red team y post-mortems de incidentes como para servir de patrón de referencia:

[1] COMPROMISO INICIAL
    Phishing con macro/LNK, credenciales filtradas y reutilizadas,
    explotación de servicio expuesto, contraseña débil en VPN/RDP.
    -> Resultado: ejecución de código o sesión válida como usuario estándar.
        |
        v
[2] RECONOCIMIENTO INTERNO
    Enumeración de AD sin privilegios: usuarios, grupos, ACL, sesiones,
    SPN activos, delegación configurada. Herramientas: PowerView,
    BloodHound/SharpHound, net.exe, herramientas nativas LDAP.
        |
        v
[3] ESCALADA DE PRIVILEGIOS LOCAL/LATERAL
    Kerberoasting, AS-REP Roasting, abuso de ACL mal delegadas,
    credenciales cacheadas en memoria (LSASS), relay NTLM/LDAP,
    movimiento lateral a un equipo con sesión de cuenta más privilegiada.
        |
        v
[4] DOMINANCIA DEL DOMINIO (Domain Dominance)
    Obtención de credenciales de Domain Admin o del hash de krbtgt
    (DCSync, extracción de NTDS.dit). A partir de aquí el atacante
    puede autenticarse como cualquier identidad del dominio.
        |
        v
[5] PERSISTENCIA
    Golden Ticket / Silver Ticket, backdoors en ACL (AdminSDHolder,
    permisos ocultos sobre objetos privilegiados), cuentas de servicio
    adicionales, Skeleton Key, confianzas de bosque manipuladas.
        |
        v
[6] OBJETIVOS FINALES
    Exfiltración de datos, despliegue masivo de ransomware vía GPO,
    fraude, espionaje persistente (dwell time de meses).

El dato más citado en informes de respuesta a incidentes es que el tiempo entre compromiso inicial y dominancia completa (time to domain dominance) se ha reducido drásticamente, en muchos casos a menos de un día, porque las fases 2 y 3 se automatizan con herramientas públicas bien documentadas. Esto invierte la prioridad defensiva clásica: ya no basta con impedir el compromiso inicial (inevitable a cierta escala); hay que asumirlo y diseñar el propio AD para que las fases 3 y 4 sean lentas, ruidosas y detectables.

9. Evolución histórica: de 2003 a 2025/Entra ID

Contrastar el estado por defecto de un dominio de 2003 frente a uno actual explica por qué buena parte del hardening moderno de AD consiste en deshacer decisiones de compatibilidad de hace veinte años.

NTLMv1 y hash LM: en 2003, el nivel LAN Manager por defecto permitía NTLMv1 e incluso el hash LM heredado (partición de la contraseña en mitades de 7 caracteres, trivialmente débil). Hoy, WS2022/2025 desactiva el hash LM por defecto y Microsoft empuja hacia la eliminación completa de NTLM.
SMBv1: habilitado por defecto en WS2003/2008, sin firmado obligatorio, vector de WannaCry y NotPetya en 2017 vía EternalBlue (MS17-010). Desde WS2016 no se instala por defecto, y en versiones recientes requiere activación explícita.
Cifrado Kerberos: solo DES/RC4 hasta el nivel funcional 2008; AES-128/256 disponible desde entonces, pero msDS-SupportedEncryptionTypes en muchas cuentas de servicio antiguas sigue permitiendo RC4, lo que hace viable el Kerberoasting incluso en dominios con nivel funcional moderno.
LDAP sin firmar: aceptado sin advertencia en 2003/2008; WS2022 introdujo channel-binding y firma más agresivos por defecto.
Auditoría avanzada: en 2003, nueve categorías básicas poco granulares. Desde WS2008 R2 existe Advanced Audit Policy Configuration, con decenas de subcategorías —incluida la de Kerberos que genera los Event ID 4768/4769/4771 usados hoy para detectar Kerberoasting y Golden Tickets—.
Credential Guard: inexistente en 2003/2008. Desde Windows 10/WS2016, Windows Defender Credential Guard usa virtualización basada en hardware (VBS) para aislar los secretos de LSASS del kernel, dificultando el volcado de credenciales con herramientas como Mimikatz.
Modelo híbrido con Entra ID: inexistente hasta Azure AD Connect (hoy Entra Connect). Hoy la mayoría de organizaciones sincronizan AD on-premises hacia Entra ID, lo que añade superficie nueva —abuso de la cuenta de sincronización, ataques a la federación ADFS— y exige tratar el servidor Entra Connect como activo Tier 0.

El patrón es consistente: Microsoft ha ido moviendo la postura por defecto de «máxima compatibilidad, seguridad opcional» a «seguro por defecto, legacy explícito». El problema práctico es que muchos dominios en producción arrastran configuraciones y GPO de hace diez o quince años nunca revisadas: ni el nivel funcional ni la versión del SO del DC garantizan, por sí solos, que las protecciones modernas estén realmente activas.

10. Comandos de enumeración: moderno vs. legacy

Base de cualquier auditoría sobre un bosque AD, en su forma moderna (PowerShell, módulo ActiveDirectory de RSAT) y legacy (utilidades desde Windows 2000/2003 Support Tools).

10.1 Enumerar el bosque

# PowerShell moderno (requiere módulo ActiveDirectory de RSAT)
Get-ADForest

# Solo el nivel funcional del bosque
(Get-ADForest).ForestMode

# Legacy equivalente (Support Tools / dsquery, disponible desde Windows 2000/2003)
dsquery * "cn=partitions,cn=configuration,dc=midominio,dc=local" -scope base -attr *

10.2 Enumerar el dominio

# PowerShell moderno
Get-ADDomain

# Solo el nivel funcional del dominio
(Get-ADDomain).DomainMode

# Legacy: netdom también reporta información básica de dominio y confianzas
netdom query domainlist
netdom query trust

10.3 Enumerar los roles FSMO

# PowerShell moderno: los dos roles de bosque
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

# PowerShell moderno: los tres roles de dominio
Get-ADDomain | Select-Object RIDMaster, PDCEmulator, InfrastructureMaster

# Legacy, el comando más usado durante casi veinte años para esta tarea
netdom query fsmo

# Legacy alternativo vía ntdsutil (interactivo)
ntdsutil
# dentro de ntdsutil:
#   roles
#   connections
#   connect to server dc01.midominio.local
#   quit
#   select operation target
#   list roles for connected server
#   quit
#   quit

10.4 Enumerar controladores de dominio

# PowerShell moderno: todos los DC del dominio, con IPv4, sitio y versión de SO
Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, Site, OperatingSystem

# Legacy
dsquery server -o rdn
netdom query dc

10.5 Estado de la replicación

# repadmin existe desde Windows 2000 Server Support Tools y sigue siendo
# la herramienta de referencia, tanto en auditoría legacy como moderna
repadmin /replsummary
repadmin /showrepl dc01.midominio.local

# Diagnóstico general de salud del DC (también disponible desde hace muchas versiones)
dcdiag /v

10.6 Enumerar cuentas privilegiadas y con SPN (relevante para escalada)

# Miembros actuales de Domain Admins
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object Name, SamAccountName

# Cuentas de usuario con SPN configurado (candidatas a Kerberoasting si el
# cifrado permitido incluye RC4 -- auditoría defensiva, no ataque)
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes

# Legacy: localizar cuentas con SPN mediante setspn (incluida desde Windows Server 2003 Support Tools)
setspn -Q */*

11. Laboratorio: levantar e inspeccionar un DC de laboratorio

Objetivo: desplegar un controlador de dominio en un entorno virtual aislado y practicar la enumeración de bosque, dominio, FSMO y nivel funcional de la sección anterior.

Levanta una VM con Windows Server (2019, 2022 o 2025 según licencia de evaluación disponible) en una red interna aislada, sin salida a Internet ni a tu red doméstica.
Asigna IP estática y renombra el equipo (por ejemplo, LAB-DC01) antes de promoverlo.

Instala el rol AD DS y promueve el servidor a controlador de un bosque nuevo (por ejemplo, lab.local), vía asistente gráfico (Server Manager > Add Roles and Features) o PowerShell:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Install-ADDSForest `
  -DomainName "lab.local" `
  -DomainNetbiosName "LAB" `
  -InstallDns `
  -SafeModeAdministratorPassword (ConvertTo-SecureString "CambiaEstaClave!2026" -AsPlainText -Force) `
  -Force

Tras el reinicio, inicia sesión como LABAdministrator e instala RSAT si no se instaló junto al rol: Install-WindowsFeature RSAT-AD-PowerShell.
Ejecuta Get-ADForest y Get-ADDomain, y anota nombre de bosque, dominio raíz y ForestMode/DomainMode (un bosque nuevo con DC en WS2019/2022/2025 se instala directamente en nivel Windows2016, el máximo disponible).
Ejecuta Get-ADForest | Select SchemaMaster, DomainNamingMaster y Get-ADDomain | Select RIDMaster, PDCEmulator, InfrastructureMaster, y confirma que los cinco roles residen en tu único DC.
Ejecuta netdom query fsmo y compara con la salida anterior: deben coincidir en qué servidor sostiene cada rol.
Ejecuta Get-ADDomainController -Filter * y repadmin /replsummary. Con un solo DC, repadmin reportará que no hay pareja de replicación (normal, no un error).
(Opcional) Añade una segunda VM, únela al dominio, crea un usuario con New-ADUser y observa en el visor de eventos (categoría Seguridad) los Event ID 4768 (TGT) y 4624 (logon correcto) al iniciar sesión desde la VM miembro.

12. Errores comunes

Asumir que «nivel funcional alto» equivale a «seguro». Solo garantiza que la capacidad técnica existe (Protected Users desde 2012 R2); no que esté configurada. Un dominio en nivel 2016 puede seguir teniendo cuentas con RC4 y ningún miembro en Protected Users.
Confundir «instalar un DC con WS2022/2025» con «elevar el nivel funcional». No existe nivel superior a 2016 (sección 6); un SO más reciente aporta mejoras propias, no un nuevo ForestMode.
Dejar Schema Admins o Enterprise Admins con miembros permanentes. Deberían estar vacíos salvo durante la ventana concreta de una operación que los requiera.
Tratar la OU como límite de seguridad. No lo es, es límite administrativo; la delegación mal calculada sobre una OU es una de las rutas de escalada más comunes en auditorías reales.
No saber dónde residen los roles FSMO ni tener documentado el procedimiento de seizure. Un incidente sobre el DC del PDC Emulator o RID Master, sin plan de recuperación, convierte un problema técnico en crisis operativa.
Ignorar cuentas de servicio con SPN y RC4 heredado. Es hoy el vector de Kerberoasting más explotado en pentest reales, porque sobreviven sin revisión tras cada actualización de nivel funcional.
Suponer que un modelo híbrido con Entra ID «reduce» la superficie de AD on-premises. La añade: el servidor de sincronización y sus cuentas pasan a ser un activo Tier 0 tan crítico como un DC.

13. Ejercicio

Sobre el laboratorio anterior:

Documenta en un fichero de texto la arquitectura completa de tu bosque: nombre de bosque y dominio, ForestMode/DomainMode, los cinco roles FSMO y en qué servidor reside cada uno, y el resultado de Get-ADDomainController -Filter *.
Crea con New-ADUser una cuenta de servicio ficticia con SPN asociado (setspn -A) simulando una cuenta de aplicación, y comprueba con Get-ADUser -Filter {ServicePrincipalName -like "*"} que aparece en la enumeración.
Revisa msDS-SupportedEncryptionTypes de esa cuenta y determina si permite RC4 por defecto (comportamiento típico salvo que fuerces AES explícitamente), razonando por escrito la implicación de seguridad a la luz de la sección 5.1.
Compara en una tabla propia de dos columnas tres decisiones de tu laboratorio (nivel funcional, cifrado Kerberos por defecto, estado de NTLM) frente al comportamiento por defecto de un Windows Server 2003, citando la sección 9.

Preguntas frecuentes

¿Puedo tener los cinco roles FSMO en controladores de dominio distintos?

Sí, es la práctica recomendada en bosques con más de un DC robusto: distribuir los roles evita que un único punto de fallo afecte a toda la funcionalidad FSMO a la vez. La única restricción real afecta al Infrastructure Master, que no debería coexistir con un catálogo global si el bosque tiene más de un dominio (en bosques de un solo dominio, o si todos los DC son GC, el rol queda inactivo sin ser un problema).

¿Qué diferencia real hay, en seguridad, entre el nivel funcional de dominio y el de bosque?

El de bosque es un techo: nunca puede ser inferior al nivel más bajo entre los dominios que lo componen, y habilita características a escala de todo el bosque (por ejemplo, PAM/bosque bastión en 2016). El de dominio habilita características que solo afectan a ese dominio (Protected Users, Authentication Policy Silos). En una migración progresiva es frecuente tener dominios hijos en un nivel funcional inferior al del bosque mientras se actualizan sus DC.

¿Por qué Kerberos, más seguro que NTLM, sigue siendo abusado en ataques modernos (Kerberoasting, Golden Ticket)?

Porque su robustez criptográfica protege la transmisión y validación del ticket, no el hecho de que el ticket, una vez emitido, es un secreto robable, reutilizable o falsificable si el atacante conoce la clave con la que se firmó. Kerberoasting no rompe el protocolo: aprovecha que cualquier usuario autenticado sin privilegios puede pedir legítimamente un TGS para cualquier cuenta con SPN, cifrado con el hash de esa cuenta de servicio, que puede intentar romperse offline si es débil. Un Golden Ticket tampoco rompe Kerberos: falsifica un TGT válido porque el atacante ya posee el secreto (krbtgt) con el que el KDC lo valida. El protocolo funciona como está diseñado; el fallo está en la gestión de los secretos que lo sostienen.

¿Tiene sentido seguir estudiando AD DS on-premises si la tendencia es Entra ID cloud-only?

Sí, por dos razones. Primera: la inmensa mayoría de organizaciones con cierta antigüedad operan hoy, y seguirán operando bastante tiempo, un modelo híbrido —no una migración completa a cloud-only—, porque hay aplicaciones legacy, impresoras, IoT y procesos que dependen de Kerberos/NTLM/LDAP on-premises. Segunda: entender AD on-premises es la base conceptual para los ataques híbridos más relevantes hoy (abuso de Entra Connect, ataques de federación, escalada desde on-prem hacia el tenant cloud).

¿Qué Event ID vigilar primero para detectar abuso de Kerberos?

Como mínimo: 4768 (solicitud de TGT, útil para AS-REP Roasting si el cifrado solicitado es débil), 4769 (solicitud de TGS, evento clave para Kerberoasting ante un volumen inusual de solicitudes con cifrado RC4 desde una misma cuenta), 4771 (fallo de preautenticación, útil contra fuerza bruta al KDC) y 4672 (asignación de privilegios especiales en el logon). Correlacionados, cubren la mayoría de los patrones de este módulo, siempre que la directiva de auditoría avanzada de Kerberos esté habilitada explícitamente —no lo está por defecto en todas las configuraciones—.

«Compromising Active Directory is often the primary objective of an attacker… Since AD is the core identity system for most organizations, gaining Domain Admin (or equivalent) rights effectively means gaining control over the entire environment.»

— Sean Metcalf, ADSecurity.org, «Active Directory Security», adsecurity.org.

Módulo 1: Arquitectura de Active Directory y su superficie de ataque