Active Directory sigue siendo una pieza central de identidad y autorización en muchos entornos corporativos Windows. Usuarios, equipos, grupos, servidores, cuentas de servicio, permisos, políticas y sistemas de autenticación terminan relacionados de una forma u otra con el directorio.
Eso hace que una auditoría interna de Active Directory sea muy diferente a buscar una única vulnerabilidad crítica. Normalmente el riesgo aparece en las relaciones entre objetos: una cuenta con más permisos de los necesarios, una contraseña de servicio débil, una delegación mal planteada, una plantilla de certificados demasiado permisiva o una identidad que conserva privilegios tanto en el entorno local como en la nube.
Un hallazgo individual puede parecer poco importante. El problema aparece cuando varios de ellos forman un camino que permite pasar de una identidad de bajo privilegio a otra con capacidad para administrar servidores, modificar el directorio o acceder a recursos críticos.
En entornos híbridos, además, la frontera ya no termina necesariamente en el dominio local. Active Directory puede convivir con Entra ID, dispositivos registrados, identidades sincronizadas, aplicaciones cloud y mecanismos de Single Sign-On. La auditoría moderna debe entender qué relaciones existen entre ambos mundos y, sobre todo, cuáles no deberían existir.
En esta guía
- Active Directory no se rompe con una única vulnerabilidad
- El primer paso: entender relaciones y privilegios
- Kerberos y las cuentas de servicio
- Cuentas sin preautenticación
- Permisos y ACLs: cuando un permiso pequeño cambia todo
- AD CS y la identidad basada en certificados
- Credenciales y movimiento lateral
- Replicación del directorio y compromiso del dominio
- Qué significa comprometer la cuenta krbtgt
- La frontera híbrida con Entra ID
- Cómo detectar caminos de ataque
- Cómo reducir realmente la superficie
- Cómo plantear un pentest interno
- Qué significa para seguridad ofensiva
- Preguntas frecuentes
Active Directory no se rompe con una única vulnerabilidad
Una de las ideas más importantes al aprender pentesting interno es abandonar la búsqueda constante de “la vulnerabilidad crítica”.
Active Directory funciona como un sistema de relaciones. Una cuenta pertenece a grupos. Los grupos reciben permisos. Esos permisos afectan a usuarios, equipos, unidades organizativas, políticas y otros objetos. Los servicios se ejecutan bajo determinadas identidades. Los administradores inician sesión en máquinas que posteriormente almacenan material de autenticación.
Desde el punto de vista ofensivo, el objetivo consiste en comprender cómo se relacionan esas piezas.
Una cuenta de servicio con una contraseña débil puede no ser especialmente interesante si no tiene privilegios. Sin embargo, esa misma cuenta puede administrar un servidor. En ese servidor puede existir una sesión privilegiada. Esa identidad privilegiada puede, a su vez, modificar un grupo o un objeto del directorio.
La vulnerabilidad real aparece en la composición.
Esto explica por qué dos dominios aparentemente similares pueden tener superficies de ataque completamente distintas. No importa únicamente qué tecnologías utilizan, sino cómo se han delegado los privilegios durante años de operación.
El primer paso: entender relaciones y privilegios
Una evaluación interna debería empezar construyendo un inventario de confianza.
Hay que identificar usuarios, equipos, grupos privilegiados, cuentas de servicio, sesiones administrativas, políticas, relaciones de confianza, delegaciones, autoridades de certificación y cualquier componente que intervenga en la autenticación.
Después llega la pregunta importante: ¿quién puede controlar a quién?
El control no siempre significa pertenecer a un grupo administrativo. Una identidad puede tener permiso para cambiar la contraseña de otra cuenta, modificar sus atributos, alterar la pertenencia a un grupo, cambiar una lista de control de acceso o modificar un objeto del que dependen otros sistemas.
Por eso las auditorías modernas suelen representar estas relaciones como caminos. El valor no está únicamente en saber que existe un permiso incorrecto, sino en comprender qué activo sensible podría alcanzarse a partir de él.
Desde el lado defensivo, esta misma metodología resulta especialmente útil. Permite descubrir caminos de escalada que no aparecen cuando se revisan únicamente los miembros directos de grupos administrativos.
Kerberos y las cuentas de servicio
Kerberos es el protocolo de autenticación principal de un dominio Active Directory y su funcionamiento introduce una superficie especialmente interesante alrededor de las cuentas de servicio.
Cuando un usuario necesita acceder a un servicio registrado mediante un Service Principal Name, solicita al controlador de dominio un ticket de servicio. Ese ticket contiene información protegida criptográficamente con una clave derivada de las credenciales de la identidad que ejecuta el servicio.
Este comportamiento es completamente legítimo. El problema aparece cuando esa identidad utiliza una contraseña débil o predecible.
Una identidad autenticada en el dominio puede solicitar tickets para servicios disponibles y realizar posteriormente intentos de recuperación de la contraseña fuera de línea. Al realizarse esa fase fuera del dominio, no genera bloqueos de cuenta por cada intento realizado contra el material obtenido.
Esta técnica se conoce como Kerberoasting.
La severidad no depende únicamente de que una cuenta sea susceptible de Kerberoasting. Hay que estudiar también qué privilegios tendría un atacante si consiguiera recuperar sus credenciales.
Una cuenta con una contraseña débil pero sin capacidad relevante puede tener un impacto limitado. Una cuenta de servicio con privilegios administrativos sobre servidores, bases de datos o componentes del directorio puede convertirse en un camino de escalada importante.
Cómo reducir el riesgo
La medida más efectiva es evitar contraseñas humanas en identidades de servicio siempre que sea posible. Las cuentas de servicio administradas permiten que el sistema gestione y renueve automáticamente sus credenciales, reduciendo significativamente el problema de contraseñas estáticas que permanecen durante años.
Para las cuentas que no puedan migrarse, deben utilizarse contraseñas largas, aleatorias y rotadas de forma controlada, además de aplicar privilegio mínimo.
Qué observar
El evento de seguridad 4769 registra solicitudes de tickets de servicio Kerberos en los controladores de dominio cuando la auditoría correspondiente está habilitada.
Una única solicitud no demuestra un ataque. Lo útil es buscar comportamiento anómalo: una identidad solicitando una cantidad inusual de tickets, servicios con los que normalmente no interactúa, orígenes inesperados o tipos de cifrado heredados que no deberían formar parte del comportamiento habitual.
Cuentas sin preautenticación
Kerberos dispone normalmente de un mecanismo de preautenticación que obliga a demostrar conocimiento de la credencial antes de que el controlador de dominio entregue determinada información de autenticación.
Active Directory permite deshabilitar esta protección para una cuenta mediante la opción DONT_REQ_PREAUTH.
Cuando esto ocurre, una persona que conozca el nombre de la cuenta puede solicitar una respuesta de autenticación que contiene información cifrada con material derivado de su contraseña. Esa información puede utilizarse posteriormente para realizar intentos de recuperación de la contraseña fuera de línea.
Es lo que se conoce como AS-REP Roasting.
A diferencia de Kerberoasting, el problema no depende de que la cuenta tenga un SPN. La condición relevante es que la preautenticación esté deshabilitada.
La mitigación es especialmente clara: salvo que exista una necesidad técnica documentada, las cuentas deben requerir preautenticación Kerberos.
Desde detección, las solicitudes Kerberos aparecen en eventos como 4768. De nuevo, el evento por sí mismo no demuestra actividad ofensiva: es necesario analizar los campos de preautenticación, las identidades implicadas y el comportamiento esperado del entorno.
Permisos y ACLs: cuando un permiso pequeño cambia todo
Uno de los aspectos más interesantes de Active Directory es que prácticamente todos sus objetos tienen una lista de control de acceso.
Esto permite delegar administración de forma muy granular. Un equipo puede gestionar usuarios de una unidad organizativa sin ser administrador del dominio, por ejemplo.
El mismo mecanismo puede convertirse en un camino de escalada cuando la delegación es demasiado amplia.
Permisos como escritura sobre atributos, modificación de la DACL, cambio de propietario o control total tienen implicaciones distintas dependiendo del objeto sobre el que se apliquen.
Con determinados permisos sobre un usuario puede ser posible modificar propiedades relacionadas con su autenticación. Sobre un grupo puede ser posible cambiar miembros. Sobre un equipo pueden modificarse aspectos relacionados con delegación. Sobre el propio dominio, ciertos derechos pueden llegar a afectar a la replicación.
Lo importante durante una auditoría no es memorizar nombres como GenericWrite, WriteDACL o GenericAll, sino entender qué capacidad efectiva concede cada ACE sobre ese objeto concreto.
También hay que estudiar la herencia. Un permiso aparentemente inocuo aplicado sobre una unidad organizativa puede afectar a decenas o cientos de objetos debajo de ella.
Qué debería revisar el defensor
Las delegaciones deberían tener propietario, justificación y alcance conocidos. Los permisos heredados que ya no responden a una necesidad operativa son especialmente importantes porque tienden a permanecer invisibles durante años.
Los cambios sobre objetos del directorio pueden generar eventos como 5136 cuando se ha configurado la auditoría necesaria. Esta telemetría resulta útil para detectar modificaciones sensibles sobre atributos, grupos, permisos o material de autenticación.
AD CS y la identidad basada en certificados
Active Directory puede utilizar una infraestructura de clave pública para emitir certificados a usuarios, equipos y servicios.
Estos certificados no sirven únicamente para cifrar tráfico. Dependiendo de su configuración, pueden utilizarse también para autenticar identidades.
Eso convierte a la infraestructura de certificados en una parte crítica del modelo de confianza del dominio.
Una plantilla mal configurada puede permitir que determinados usuarios soliciten certificados con propiedades que no deberían controlar. También pueden existir permisos de inscripción excesivamente amplios, usos de clave demasiado permisivos, autoridades de certificación con controles insuficientes o delegaciones que permiten modificar objetos relacionados con la PKI.
El resultado potencial es especialmente grave porque un certificado válido puede convertirse en una nueva forma de demostrar una identidad sin necesidad de conocer su contraseña.
Una auditoría debería revisar al menos quién puede solicitar cada plantilla, qué identidades puede representar, qué usos admite el certificado, quién puede modificar la plantilla y qué controles aplica la autoridad durante la emisión.
Detección
Los eventos 4886 y 4887 pueden registrar solicitudes y emisión de certificados cuando la auditoría de los servicios de certificación está correctamente habilitada.
El análisis debería centrarse en solicitudes inesperadas: cuentas de bajo privilegio utilizando plantillas sensibles, identidades o atributos poco habituales y certificados emitidos fuera de los patrones operativos conocidos.
También es importante monitorizar cambios en las plantillas y en los objetos que controlan la infraestructura de certificación.
Credenciales y movimiento lateral
Conseguir una credencial no implica necesariamente que el atacante haya llegado a su objetivo. Normalmente esa identidad se utiliza para intentar alcanzar otros sistemas y obtener nuevas capacidades.
Ese proceso se conoce como movimiento lateral.
En Windows, el material de autenticación puede adoptar varias formas: contraseñas, hashes NTLM, tickets Kerberos, certificados o tokens.
Esto explica por qué comprometer una estación de trabajo utilizada por un administrador puede ser mucho más grave que comprometer otra máquina idéntica utilizada exclusivamente por una cuenta sin privilegios.
Si material reutilizable de autenticación queda disponible en el sistema, puede permitir autenticarse frente a otros recursos sin conocer necesariamente la contraseña original.
Pass-the-Hash aprovecha material NTLM reutilizable. Pass-the-Ticket utiliza tickets Kerberos. El relay de NTLM, cuando las protecciones del servicio lo permiten, intenta aprovechar una autenticación capturada frente a otro destino.
Otra fuente históricamente importante es la memoria del proceso responsable de la seguridad local, donde pueden existir distintos tipos de material de autenticación asociado a sesiones activas.
Las defensas modernas han endurecido esta superficie, pero sigue siendo fundamental evitar que las cuentas privilegiadas inicien sesión innecesariamente en estaciones o servidores de menor confianza.
Contraseñas administrativas locales
Reutilizar la misma contraseña de administrador local en múltiples equipos amplifica enormemente el impacto de comprometer uno solo.
Windows LAPS permite gestionar contraseñas locales diferentes para cada dispositivo y rotarlas automáticamente, reduciendo esa vía clásica de movimiento lateral.
Replicación del directorio y compromiso del dominio
Los controladores de dominio necesitan replicar información entre sí. Para ello existen derechos específicos que permiten solicitar cambios del directorio.
Esos derechos son extremadamente sensibles porque determinados datos replicados incluyen material relacionado con credenciales.
Un ataque conocido como DCSync consiste en utilizar derechos legítimos de replicación desde una identidad que no debería disponer de ellos, haciendo que el controlador de dominio entregue información como si estuviera hablando con otro componente autorizado para replicar.
No es necesario acceder físicamente al fichero de base de datos del controlador de dominio. El abuso se realiza a través del propio mecanismo de replicación.
El impacto depende de los derechos obtenidos y de los objetos solicitados, pero una identidad con permisos de replicación suficientemente amplios puede acceder a material de credenciales de cuentas muy sensibles.
Detección
El evento 4662 puede ser útil para identificar el uso de derechos de replicación cuando se encuentra habilitada la auditoría de acceso al servicio de directorio y existen las SACL adecuadas.
Sin esas condiciones, la ausencia del evento no demuestra que no haya ocurrido nada.
La telemetría de red también tiene mucho valor. Tráfico de replicación originado desde un sistema que no es un controlador de dominio merece una investigación inmediata salvo que exista una excepción operativa conocida y documentada.
Defensa
Los derechos de replicación deben estar limitados únicamente a las identidades que realmente los necesiten. La auditoría debería localizar cualquier delegación adicional y comprobar su justificación.
Qué significa comprometer la cuenta krbtgt
Dentro de cada dominio existe una cuenta especial denominada krbtgt. Su material criptográfico participa en la protección de los Ticket Granting Tickets utilizados por Kerberos.
Si un atacante consigue el material secreto de esta cuenta, puede crear TGT falsificados que el dominio puede interpretar como válidos.
Es lo que se conoce como Golden Ticket.
Este escenario representa una situación de compromiso muy grave porque permite falsificar información de autenticación y autorización sin depender de una cuenta de usuario convencional.
Sin embargo, conviene separar correctamente las técnicas: realizar DCSync no significa automáticamente tener un Golden Ticket. Primero sería necesario obtener material de la cuenta krbtgt y posteriormente utilizarlo para generar tickets falsificados.
Si existe evidencia de que esa cuenta ha sido comprometida, la recuperación requiere restablecer su contraseña siguiendo el procedimiento soportado. La operación se realiza dos veces y debe respetarse un intervalo suficiente entre ambos cambios para que el entorno pueda renovar correctamente las claves y los tickets existentes.
Es una operación de recuperación sensible y no debería realizarse improvisadamente en producción.
La frontera híbrida con Entra ID
Muchas organizaciones combinan Active Directory local con Entra ID para gestionar identidades, aplicaciones cloud y dispositivos.
Eso no significa que comprometer el dominio local proporcione automáticamente control sobre la nube.
El riesgo depende de cómo se haya diseñado la relación entre ambos entornos.
Una de las situaciones más peligrosas aparece cuando una misma identidad mantiene privilegios importantes tanto en Active Directory como en Entra ID. Comprometer una sola cuenta puede entonces afectar a dos planos administrativos que deberían estar separados.
Los componentes de sincronización también deben considerarse activos de alta sensibilidad. Gestionan relaciones entre ambos directorios y utilizan identidades y permisos que deben limitarse estrictamente a lo necesario.
Otro elemento importante son los dispositivos que utilizan Single Sign-On con Entra ID.
En determinados sistemas existe un Primary Refresh Token (PRT) que facilita el acceso SSO a recursos cloud. Es un artefacto de autenticación sensible, pero no debería entenderse como una simple cookie que puede copiarse libremente de un equipo a otro.
En plataformas compatibles, el PRT está vinculado criptográficamente al dispositivo y puede apoyarse en hardware como TPM para proteger las claves utilizadas durante las solicitudes de tokens.
Por eso el análisis de un endpoint híbrido debe estudiar no solo la presencia de tokens, sino también su protección, el estado del dispositivo, las políticas de acceso condicional y qué aplicaciones aceptan cada tipo de sesión.
El verdadero riesgo híbrido
El problema aparece cuando las fronteras que deberían separar el plano local del cloud se difuminan.
Algunos ejemplos son identidades con privilegios administrativos en ambos entornos, sincronización de cuentas que no deberían disponer de privilegios cloud, componentes de sincronización con permisos excesivos o aplicaciones con consentimientos demasiado amplios.
Cómo detectar caminos de ataque
Uno de los errores más habituales al defender Active Directory es intentar asociar cada ataque a un único Event ID.
Los registros son piezas de contexto, no veredictos.
Una solicitud 4769 es una operación normal de Kerberos. Un 4887 puede representar un certificado completamente legítimo. Un 4662 puede corresponder a una operación autorizada sobre el directorio.
La detección aparece al correlacionar identidad, origen, destino, volumen, horario y comportamiento histórico.
| Área | Telemetría útil | Qué merece atención |
|---|---|---|
| Kerberos | 4768, 4769 |
Patrones anómalos de tickets, cuentas poco habituales, cifrado heredado o solicitudes fuera del comportamiento esperado. |
| Objetos de AD | 5136 |
Cambios sobre atributos de autenticación, delegación, grupos o permisos sensibles. |
| Replicación | 4662 y telemetría de red |
Uso de derechos de replicación por identidades o sistemas que no sean replicadores legítimos. |
| Certificados | 4886, 4887 |
Solicitudes de plantillas sensibles por cuentas inesperadas o cambios en patrones de emisión. |
| Movimiento lateral | Logons, procesos, servicios y autenticación | Nuevos orígenes, cuentas administrativas utilizadas en equipos poco habituales o protocolos inesperados. |
También hay una condición previa fundamental: la auditoría tiene que estar habilitada.
Algunos eventos dependen de políticas de auditoría específicas y, en determinadas operaciones de directorio, de SACL configuradas sobre los objetos. Un SIEM no puede detectar telemetría que nunca se ha generado.
Cómo reducir realmente la superficie
La defensa de Active Directory no depende de una única configuración. El objetivo es evitar que un compromiso inicial pueda transformarse fácilmente en otro privilegio.
Separa las identidades privilegiadas
Las cuentas administrativas deberían utilizarse únicamente para tareas administrativas y desde sistemas de confianza adecuados.
Una persona que dispone de privilegios elevados no debería navegar, leer correo o trabajar diariamente utilizando esa misma identidad.
En entornos híbridos es igualmente importante evitar, siempre que sea posible, que una sola identidad acumule privilegios administrativos importantes tanto en AD como en Entra ID.
Reduce el privilegio permanente
Las pertenencias a grupos privilegiados y las delegaciones deben revisarse periódicamente.
Si una cuenta necesita un permiso solo para una operación puntual, mantenerlo durante años aumenta innecesariamente la superficie de ataque.
Protege las cuentas de servicio
Las cuentas de servicio administradas reducen la dependencia de contraseñas humanas y permiten que el sistema gestione su renovación.
También es fundamental revisar sus privilegios. Una contraseña excelente no compensa una cuenta con permisos administrativos innecesarios.
Elimina excepciones de Kerberos innecesarias
Las cuentas sin preautenticación deberían revisarse y justificarse. Los SPN antiguos o asociados a servicios que ya no existen deberían eliminarse.
También conviene reducir progresivamente la dependencia de mecanismos criptográficos heredados cuando el entorno lo permita.
Audita ACLs y delegaciones
Los permisos deben analizarse como caminos de control, no simplemente como listas.
Es especialmente importante revisar quién puede modificar grupos privilegiados, cuentas administrativas, objetos de equipos, políticas, la raíz del dominio y la infraestructura de certificados.
Protege las credenciales locales
Windows LAPS permite mantener contraseñas administrativas diferentes por dispositivo y rotarlas automáticamente, evitando que una contraseña local reutilizada facilite el movimiento lateral por toda la red.
Protege las identidades de alto valor
Las cuentas más sensibles pueden beneficiarse de controles específicos que reduzcan el almacenamiento y reutilización de credenciales, además de políticas de autenticación más restrictivas.
El objetivo es que comprometer un endpoint de usuario no proporcione inmediatamente material reutilizable perteneciente a una identidad administrativa.
Trata la PKI como infraestructura crítica
La autoridad de certificación, sus plantillas y sus permisos forman parte del sistema de identidad.
Deben protegerse con un nivel equivalente al de los controladores de dominio, porque una PKI mal configurada puede permitir autenticación como identidades de mucho mayor privilegio.
Protege el entorno híbrido como dos planos conectados
Las cuentas sincronizadas, componentes de sincronización, aplicaciones, consentimientos, dispositivos y roles cloud deberían revisarse buscando relaciones innecesarias entre ambos entornos.
Separar privilegios locales y cloud reduce enormemente el radio de impacto de una única cuenta comprometida.
Cómo plantear un pentest interno
Una auditoría profesional no debería empezar intentando conseguir Domain Admin lo antes posible.
Debería empezar entendiendo el entorno.
1. Define el punto de partida
El escenario cambia completamente dependiendo de si se entrega al auditor una cuenta de dominio estándar, un equipo unido al dominio, acceso a una red concreta o únicamente conectividad interna.
Ese punto inicial debe quedar claramente documentado porque determina qué conclusiones pueden extraerse del ejercicio.
2. Construye el mapa de identidad
Identifica cuentas, grupos, equipos, servicios, delegaciones, permisos y activos críticos.
No se trata todavía de explotar, sino de comprender dónde existen relaciones de confianza.
3. Prioriza caminos por impacto
No todas las rutas merecen ser explotadas.
Si un conjunto de permisos demuestra claramente que una cuenta puede controlar otra identidad crítica, puede ser suficiente validar el camino con el mínimo impacto necesario.
El pentesting profesional no consiste en ejecutar todas las técnicas posibles, sino en obtener evidencia suficiente para demostrar el riesgo.
4. Analiza credenciales y autenticación
Revisa cuentas de servicio, configuración Kerberos, credenciales locales, sesiones administrativas, certificados y cualquier otro material de autenticación que pueda facilitar movimiento lateral.
5. Revisa infraestructura crítica de identidad
Controladores de dominio, PKI, sistemas de administración y componentes híbridos deberían tratarse como objetivos de máxima sensibilidad.
6. Evalúa el entorno híbrido por separado
Si existe Entra ID, hay que estudiar qué objetos se sincronizan, qué identidades mantienen privilegios a ambos lados y qué componentes relacionan el plano local con el cloud.
No debe asumirse que existe un pivote simplemente porque ambos directorios estén conectados.
7. Documenta la cadena, no únicamente el último paso
Un informe que únicamente indica “se obtuvo Domain Admin” pierde gran parte del valor de la auditoría.
Lo importante es explicar qué condiciones permitieron llegar hasta allí: qué delegación era excesiva, qué cuenta tenía demasiados privilegios, qué control faltaba y qué ruptura concreta habría detenido la cadena.
Eso convierte una demostración ofensiva en una hoja de ruta defensiva.
Qué significa para seguridad ofensiva
El pentesting de Active Directory obliga a pensar de una manera diferente a la explotación de una vulnerabilidad aislada.
No basta con conocer una colección de técnicas. Hay que entender autenticación, permisos, protocolos, sistemas Windows, redes, identidad y relaciones de confianza.
Sobre todo, hay que aprender a pensar en caminos.
Una configuración individual puede parecer aceptable. Una segunda también. El trabajo del auditor consiste en descubrir qué ocurre cuando ambas se combinan.
Esa mentalidad es aplicable mucho más allá de Active Directory. Es la misma que utilizamos en seguridad web cuando varios hallazgos de severidad aparentemente limitada terminan formando una cadena de compromiso mucho mayor.
En SixHack Academy trabajamos precisamente esa metodología: entender primero el sistema, identificar sus fronteras de confianza, validar el impacto con la mínima intrusión necesaria y documentar una evidencia que pueda reproducirse.
El pentesting interno amplía ese razonamiento desde las aplicaciones hacia identidades, endpoints, redes y servicios de infraestructura.
Una auditoría no termina cuando encuentras una vulnerabilidad. Empieza cuando entiendes hasta dónde puede llevar.
En SixHack Academy enseñamos una metodología ofensiva basada en comprender sistemas, validar riesgos y encadenar relaciones de confianza con criterio profesional.
Preguntas frecuentes
¿Qué es Kerberoasting?
Es una técnica que aprovecha el funcionamiento normal de Kerberos para obtener tickets de servicios asociados a cuentas con SPN y realizar intentos de recuperación de sus contraseñas fuera de línea. El riesgo aumenta especialmente cuando esas cuentas utilizan contraseñas débiles o disponen de privilegios elevados.
¿Qué diferencia existe entre Kerberoasting y AS-REP Roasting?
Kerberoasting está relacionado con cuentas que ejecutan servicios registrados mediante SPN. AS-REP Roasting afecta a cuentas que tienen deshabilitada la preautenticación Kerberos. En ambos casos puede existir una fase de análisis de contraseña fuera de línea, pero la condición que permite cada técnica es diferente.
¿Qué es DCSync?
Es el abuso de derechos de replicación de Active Directory para solicitar al controlador de dominio información que normalmente intercambiarían componentes autorizados de replicación. Con permisos suficientemente amplios puede exponer material de credenciales de cuentas sensibles.
¿DCSync implica automáticamente un Golden Ticket?
No. Un Golden Ticket requiere disponer del material criptográfico de la cuenta krbtgt. DCSync puede ser una forma de llegar a ese material si la identidad comprometida dispone de los derechos adecuados, pero son técnicas diferentes.
¿Por qué hay que cambiar dos veces la contraseña de krbtgt tras un compromiso?
El dominio conserva la clave actual y la anterior para facilitar la transición de tickets. En un procedimiento de recuperación, dos restablecimientos correctamente espaciados permiten retirar del historial las claves comprometidas. Debe seguirse siempre el procedimiento soportado y respetar los tiempos de vida de tickets configurados en el entorno.
¿Qué riesgo supone AD CS?
Los certificados pueden utilizarse como mecanismo de autenticación. Si las plantillas, permisos o políticas de emisión están mal configurados, una identidad puede conseguir un certificado con capacidades superiores a las que debería tener, convirtiendo la PKI en una vía de escalada de privilegios.
¿Comprometer Active Directory significa comprometer automáticamente Entra ID?
No. El impacto depende de la arquitectura híbrida. Las identidades con privilegios cruzados, configuraciones de sincronización, aplicaciones y relaciones de confianza pueden crear caminos entre ambos entornos, pero el simple hecho de utilizar sincronización no implica que exista un pivote automático.
¿Un PRT se puede copiar a otro equipo y reutilizar?
No debería asumirse así. En plataformas compatibles, el Primary Refresh Token está ligado criptográficamente al dispositivo y puede utilizar claves protegidas mediante hardware. La seguridad real depende del dispositivo, de su estado y de los controles de protección de tokens y acceso condicional habilitados.
¿Qué eventos debería monitorizar?
No existe una lista capaz de detectar por sí sola todos los ataques. Eventos como 4768, 4769, 4662, 5136, 4886 y 4887 aportan información útil, siempre que la auditoría necesaria esté configurada. Su valor aparece al correlacionarlos con identidad, origen, volumen y comportamiento habitual.
¿Cuál es el objetivo de un pentest de Active Directory?
No debería ser simplemente “conseguir Domain Admin”. El objetivo es identificar caminos reales de compromiso, demostrar su impacto con la mínima intrusión necesaria y explicar qué controles deben modificarse para romper cada cadena.
Referencias
- Documentación oficial — Evento 4769 : solicitudes de tickets de servicio Kerberos y campos disponibles para monitorización.
- Documentación oficial — Group Managed Service Accounts : gestión automática de credenciales para cuentas de servicio.
- Documentación oficial — Windows LAPS : gestión y rotación de contraseñas administrativas locales.
- Documentación oficial — Protected Users : protecciones adicionales frente al robo y almacenamiento de credenciales de identidades sensibles.
- Documentación oficial — Reset de krbtgt : procedimiento soportado para renovar las claves de la cuenta durante la recuperación de un dominio.
- Documentación oficial — Seguridad de Active Directory : recomendaciones sobre credenciales privilegiadas y reducción de superficie.
- Documentación oficial — Primary Refresh Token : funcionamiento, protección y vinculación al dispositivo de los PRT.
- Documentación oficial — Protección de tokens : mecanismos para reducir la reutilización de tokens robados.
- Documentación oficial — Riesgo de identidades con privilegios híbridos : recomendaciones para separar privilegios de Active Directory y Entra ID.
- Documentación oficial — Protección de entornos híbridos : relaciones de confianza entre infraestructura local y recursos cloud.
- Documentación oficial — Plantillas de certificados de AD CS : diseño, permisos, identidad del sujeto y gestión segura de plantillas.