Active Directory: Rutas de Ataque que Todo Red Team Explota

Llevo más de una década metido en el barro de los entornos Windows y, te lo digo sin tapujos, Active Directory (AD) sigue siendo el rey del caos. En 2026, tras la migración masiva a la nube y la adopción de Azure AD (ahora Entra ID, para más confusión), muchos creyeron que el AD local iba a ser una reliquia. La realidad en los pasillos de las grandes empresas españolas, especialmente en banca, seguros y sector crítico, es muy distinta: un híbrido complejo, mal documentado y, en nueve de cada diez auditorías que hacemos en Riskitera, un regalo envenenado para cualquier red team. El problema de fondo no es técnico, es de mentalidad. Se sigue viendo AD como un directorio, un servicio de autenticación, cuando en realidad es el sistema nervioso central de la postura de seguridad. Si controlas AD, controlas el negocio. Punto. Y las rutas de ataque que explotamos hoy no son radicalmente distintas a las de hace cinco años; lo que ha cambiado es la sofisticación de las herramientas de detección (Sigma, Sentinel, Falcon) y la necesidad de ser más sigilosos. Vamos al lío.

¿Por qué Active Directory sigue siendo el objetivo principal en 2026?

La respuesta es económica, pura y dura. El retorno de la inversión (ROI) para un atacante en AD es astronómico. No se trata de comprometer una máquina, se trata de comprometer la lógica de negocio encapsulada en los grupos, las relaciones de confianza, los permisos delegados y los certificados. En un entorno cloud puro, los mecanismos de identidad son más jóvenes, tienen más logging (a veces) y los proveedores imponen ciertas barreras. AD local, especialmente esas instancias heredadas de Windows Server 2012 R2 o 2016 que aún pululan por ahí, está lleno de deuda técnica y configuraciones por defecto peligrosísimas. Añádele la capa híbrida, donde sincronizas usuarios con Azure AD Connect, y tienes una superficie de ataque que se extiende desde tu datacenter hasta el tenant de Microsoft 365. Un error de configuración en la sincronización puede dar permisos de administrador global en la nube a una cuenta local que ni siquiera está bien protegida. Esto lo vimos en un pentest el año pasado para un grupo industrial: a través de un hash NTLM robado de una cuenta de servicio local con derechos de replicación de directorio, escalamos hasta conseguir sesión en el tenant de Office 365 del cliente. El salto de lo local a lo cloud a través de AD es, hoy por hoy, la ruta más crítica.

¿Cómo se inicia la mayoría de compromisos en AD? La puerta de entrada nunca cambia

Ojo con esto, porque aquí es donde fallan la mayoría de los equipos blue. Se centran en proteger los controladores de dominio (DCs) con parches y firewalls, pero descuidan los eslabones más débiles: los endpoints. En el 80% de los ejercicios de red team que dirigimos, el punto de entrada inicial no es un ataque de fuerza bruta a un DC. Es un phishing bien dirigido a un usuario del departamento financiero, un exploit en una estación de trabajo con Java desactualizado (sí, aún existe en 2026), o una aplicación web interna vulnerable que corre en un servidor con join al dominio. La clave está en que, una vez tienes un punto de apoyo en una máquina unida al dominio, por humilde que sea, el juego ha cambiado. Esa máquina tiene un contexto de seguridad (una cuenta de ordenador) y puede autenticarse contra otros recursos del dominio. A partir de ahí, la recolección de información es automática. Con una sesión de PowerShell o incluso con herramientas nativas, puedes empezar a mapear el reino.

# Esto lo ejecuto en casi cada compromiso inicial. Es silencioso y usa cmdlets nativos.
# Recolecta información básica del dominio, usuarios y grupos sin llamar la atención.
$DomainInfo = Get-ADDomain
$Computers = Get-ADComputer -Filter * -Properties OperatingSystem, LastLogonDate | Select-Object Name, OperatingSystem, LastLogonDate
$DomainAdmins = Get-ADGroupMember -Identity "Domain Admins" -Recursive | Get-ADObject -Properties SamAccountName, LastLogonDate

# Un truco sucio que sigue funcionando: buscar cuentas de servicio con passwords que no expiran.
# Es un foco de riesgo enorme y muchas empresas ni lo monitorizan.
$ServiceAccounts = Get-ADUser -Filter { (Enabled -eq $true) -and (PasswordNeverExpires -eq $true) -and (SamAccountName -like "*svc*") } -Properties PasswordNeverExpires, LastLogonDate

Write-Host "[+] Dominio:" $DomainInfo.DNSRoot
Write-Host "[+] Total Ordenadores:" $Computers.Count
Write-Host "[+] Admins de Dominio:" $DomainAdmins.Count
Write-Host "[+] Cuentas de servicio con password que no expira:" $ServiceAccounts.Count

Este script es la punta del iceberg, pero te da un mapa mental en segundos. La lección aquí es que la prevención tiene que empezar en el endpoint, con EDRs bien configurados (CrowdStrike Falcon 7.x o Microsoft Defender for Endpoint) que detecten la recolección de información ofensiva, no solo el malware explícito.

active-directory-rutas-de-ataque-que-todo-red-team-explota diagram 1

Movimiento lateral: ¿Cuáles son las técnicas más efectivas hoy en día?

Una vez dentro, el objetivo es claro: alcanzar privilegios de dominio. La época del Mimikatz.exe volcando hashes en texto claro en memoria está, afortunadamente, en declive debido a las protecciones como Credential Guard. Pero la comunidad ofensiva se adapta. Las técnicas han evolucionado hacia el robo de tickets Kerberos y el abuso de la delegación. Sinceramente, la mayoría de empresas españolas no monitorizan los eventos de Kerberos (IDs 4768, 4769) con la profundidad necesaria, y ahí está su talón de Aquiles.

Kerberoasting: ¿Sigue siendo válido en 2026?

Absolutamente sí. Es como el pan de cada día. Si encuentras una cuenta de usuario con un SPN (Service Principal Name) asociado, puedes solicitar un ticket de servicio TGS cifrado con el hash de la contraseña de esa cuenta. Lo puedes crackear offline. Lo grave es que, en 2026, aún encontramos cuentas de servicio de alto privilegio (como las usadas por SQL Server, IIS) con SPNs y contraseñas débiles. Las herramientas han evolucionado. Ya no usamos solo Invoke-Kerberoast.ps1. Ahora, con Rubeus (versión 2.0 o superior), podemos hacerlo más sigiloso, pidiendo tickets sin volcarlos inmediatamente a disco.

# Ejemplo con Rubeus, desde una sesión ya comprometida.
# Primero, enumeramos cuentas con SPNs de forma discreta.
Rubeus.exe kerberoast /stats /nowrap

# Luego, si vemos una candidata jugosa (por ejemplo, sql_svc), pedimos el ticket.
# El parámetro /rc4opsec es clave en entornos con detección: evita el uso de RC4 si no es necesario.
Rubeus.exe kerberoast /user:sql_svc /domain:empresa.local /rc4opsec /nowrap /outfile:hashes.txt

# El hash lo pasamos a Hashcat en nuestra caja de ataque.
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt -O -w 4

La defensa aquí es técnica y procedural: implementar autenticación robusta (AES en lugar de RC4 para el cifrado de tickets), usar cuentas de servicio gestionadas (gMSAs) y, lo más importante, monitorizar peticiones de tickets TGS masivas para una misma cuenta. Un Sigma rule bien afinada en tu SIEM debería cazar esto.

Abuso de la delegación: El camino real hacia Domain Admin

Esto es un error que veo constantemente en auditorías. La delegación de Kerberos (Constrained y Unconstrained) es una funcionalidad legítima para que un servicio pueda suplantar a un usuario y acceder a otros recursos en su nombre. Pero si se configura mal, es un billete de primera clase para el atacante. La técnica "Resource-Based Constrained Delegation" (RBCD) es especialmente peligrosa. Si puedes modificar los atributos de un objeto de ordenador (por ejemplo, a través de la vulnerabilidad MS14-068 - aunque parcheada, sus variantes persisten - o abusando de permisos de escritura genéricos), puedes forzar a ese ordenador a delegar en ti, y a través de él, suplantar a cualquier usuario, incluido un administrador.

Hace unos meses, en un test para una aseguradora, encontramos un grupo de seguridad llamado "Servidores_App" que tenía el permiso WriteProperty sobre los objetos de ordenador de los servidores de aplicaciones. Usando PowerMad (una herramienta que abusa del protocolo MachineAccountQuota, que por defecto permite a los usuarios autenticados unirse con hasta 10 cuentas de ordenador al dominio), creamos una nueva cuenta de ordenador. Luego, con Powerview o el módulo ActiveDirectory de PowerShell, configuramos la delegación basada en recursos en un servidor objetivo para que confíe en nuestra nueva cuenta maliciosa. El proceso, simplificado, es una pesadilla para el blue team si no está cazando la creación de cuentas de ordenador no estándar.

Escalada de privilegios final: ¿Cómo conseguimos las llaves del reino?

Llegados a este punto, asumimos que tenemos algún tipo de acceso privilegiado en un servidor, o hemos comprometido la contraseña de una cuenta de servicio poderosa. El objetivo final suele ser conseguir los hashes NTLM o los tickets de los administradores de dominio. La técnica reina, a pesar de ser conocida, es DCSync. Simular ser un controlador de dominio para solicitar la replicación de datos de usuario, incluyendo los hashes de contraseña, es devastador. Solo se necesita que la cuenta comprometida tenga los permisos de replicación (normalmente concedidos a Domain Admins, Enterprise Admins o al grupo Domain Controllers). La detección es relativamente sencilla (evento 4662 con Directory Service Access), pero requiere que los logs de los DCs estén configurados correctamente y que alguien esté mirando las alertas. En mi experiencia, menos de la mitad de los clientes tienen esta detección activa y afinada.

Pero hay un vector más sigiloso y que está ganando tracción: el abuso de certificados de AD. Con la migación a Windows Server 2025 y el énfasis en PKI, muchas organizaciones están desplegando certificados para autenticación de usuarios y ordenadores. Si encuentras una plantilla de certificado mal configurada (por ejemplo, que permita enrolamiento a usuarios autenticados y que habilite la autenticación de cliente), puedes solicitar un certificado, convertirlo en un ticket de Kerberos (con Rubeus asktgt) y autenticarte como cualquier usuario, incluso Domain Admin. Esto es especialmente peligroso en entornos híbridos, donde los certificados pueden usarse para el SSO en la nube. Un ataque documentado como "ESC8" (parte de la serie de vulnerabilidades "AD CS" de SpecterOps) es algo para lo que debemos prepararnos ya.

# Ejemplo simplificado de uso de Certipy (una herramienta Python moderna) para atacar AD CS.
# Primero, enumeramos las plantillas de certificado vulnerables.
# certipy find -u usuario@empresa.local -p 'Password123!' -dc-ip 10.10.10.1

# Si encontramos una planticia vulnerable, podemos solicitar un certificado.
# certipy req -u usuario@empresa.local -p 'Password123!' -dc-ip 10.10.10.1 -ca EMPRESA-CA -template VulnTemplate

# Con el certificado en formato PFX, podemos autenticarnos y pedir un TGT.
# certipy auth -pfx certificado.pfx -dc-ip 10.10.10.1

# Este TGT nos dará acceso como el usuario asociado al certificado, que puede ser de alto privilegio.

La defensa contra esto requiere un hardening exhaustivo de la PKI de AD, revisar todas las plantillas de certificado, y monitorizar eventos de enrolamiento y solicitud de certificados inusuales.

active-directory-rutas-de-ataque-que-todo-red-team-explota diagram 2

¿Qué debería hacer un Blue Team para defenderse en 2026?

La realidad es que no existe una bala de plata. La defensa de AD es un proceso continuo de hardening, monitorización y respuesta. Basándome en los últimos incidentes que hemos gestionado, estas son mis recomendaciones contundentes:

Primero, implementa el modelo de administración "Tiering" (Tier 0, Tier 1, Tier 2) de forma real, no solo en un documento. Los administradores de dominio (Tier 0) no deben tener sesiones abiertas en estaciones de trabajo de Tier 2. El salto entre tiers debe requerir autenticación fresca y fuerte. Segundo, deshabilita protocolos legacy siempre que sea posible. NTLMv1 está muerto, pero NTLMv2 sigue siendo objetivo de relay attacks. Si puedes, fuerza Kerberos y considera deshabilitar NTLM en segmentos críticos. Tercero, la monitorización es clave. No puedes defender lo que no ves. Necesitas un SIEM (Splunk, Elastic, Microsoft Sentinel) ingiriendo los eventos de seguridad de todos tus DCs, y sobre eso, correr reglas de detección de calidad. El framework Sigma es tu mejor amigo aquí; tiene reglas comunitarias para casi todas las técnicas que he mencionado.

Por último, y esto es una opinión personal fuerte: invierte en ejercicios de Purple Team regulares. De nada sirve tener un blue team que no entiende las tácticas del red team, y viceversa. En Riskitera, forzamos a que nuestros consultores rojos y azules trabajen juntos en simulaciones. Solo así se entienden las limitaciones de las herramientas, los puntos ciegos de los logs y la verdadera eficacia de las reglas de detección. Active Directory, en 2026, no es un problema que se resuelva comprando una herramienta mágica. Se resuelve con conocimiento profundo, procesos rigurosos y una dosis saludable de paranoia.

Recursos y referencias

SpecterOps - The Certified Pre-Owned (AD CS Attacks): La investigación definitiva sobre ataques a Certificate Services. https://posts.specterops.io/certified-pre-owned-d95910965cd2
Microsoft - Securing Privileged Access: La guía oficial de Microsoft, densa pero esencial. https://docs.microsoft.com/en-us/security/privileged-access-workstations/
Sigma HQ - Repository of Sigma Rules: El repositorio central de reglas de detección Sigma para cazar estas técnicas. https://github.com/SigmaHQ/sigma
BloodHound / SharpHound: La herramienta definitiva para mapear el grafo de ataques de AD. La versión 4.3+ incluye soporte mejorado para ataques híbridos y de certificados. https://github.com/BloodHoundAD/BloodHound