En un entorno híbrido con Active Directory on-premise y Microsoft Entra ID, un atacante no necesita comprometer toda la organización de golpe. Puede encadenar una cuenta de servicio mal gobernada, un secreto expuesto, una plantilla de certificados permisiva y, finalmente, mecanismos de persistencia difíciles de erradicar.
Ese es el verdadero problema del abuso de Active Directory en entornos híbridos: no suele aparecer como una única alerta crítica, sino como una secuencia de señales que, vistas por separado, pueden parecer asumibles.
Kerberoasting, abuso de AD CS y Golden Ticket no son tres riesgos independientes. Son piezas de una misma cadena de compromiso de identidad.
En Hard2bit abordamos este tipo de escenarios desde una perspectiva técnica y operativa: visibilidad, detección, contención, hardening y validación continua. Si tu organización necesita evaluar su exposición real en identidad híbrida, puedes revisar nuestro enfoque de IAM y postura cloud o solicitar una sesión técnica desde contacto.
Resumen ejecutivo
El riesgo principal en Active Directory híbrido no está en una técnica aislada, sino en la cadena completa de abuso de identidad.
Una secuencia típica puede empezar con Kerberoasting, continuar con escalada lateral mediante cuentas de servicio, aprovechar una mala configuración de AD CS y terminar en persistencia avanzada mediante Golden Ticket.
Para reducir el riesgo, una organización debe trabajar en cinco frentes:
- Inventario y gobierno de cuentas de servicio.
- Monitorización específica de Kerberos, AD CS, controladores de dominio y Entra ID.
- Hardening de rutas administrativas y activos Tier 0.
- Runbooks de contención probados para identidad híbrida.
- Validación continua mediante purple team, threat hunting y simulaciones controladas.
El objetivo no es tener más alertas, sino detectar antes la cadena, contener mejor y evitar que el atacante consolide persistencia.
Qué es Active Directory abuse en un entorno híbrido
Hablamos de Active Directory abuse cuando un atacante utiliza características legítimas de Active Directory, Kerberos, certificados, delegaciones, grupos, cuentas de servicio o relaciones de confianza para escalar privilegios, moverse lateralmente o mantener acceso persistente.
En un entorno híbrido, el riesgo aumenta porque la identidad local puede estar conectada con servicios cloud mediante sincronización, federación, aplicaciones empresariales, service principals, políticas de acceso y sesiones activas en Microsoft Entra ID.
Esto significa que una debilidad en AD on-premise puede tener impacto en Microsoft 365, Azure, SaaS corporativos y aplicaciones críticas.
Por eso, la seguridad de identidad híbrida debe analizarse como un sistema completo, no como dos mundos separados.
Si quieres ampliar la visión sobre riesgos en Microsoft 365, te recomendamos también esta guía sobre auditoría de Microsoft 365 para empresas y este análisis sobre secuestro de cuentas en Microsoft 365.
Anatomía de una cadena real de abuso de Active Directory
Una cadena habitual de compromiso en identidad híbrida puede seguir esta lógica:
- Acceso inicial a un endpoint o servidor con visibilidad del dominio.
- Enumeración de Active Directory para identificar usuarios, grupos, SPN, rutas administrativas y cuentas de servicio.
- Kerberoasting contra cuentas de servicio con SPN y contraseñas débiles o antiguas.
- Movimiento lateral aprovechando privilegios excesivos, delegaciones débiles o reutilización de credenciales.
- Abuso de AD CS mediante plantillas de certificado permisivas, ACL inadecuadas o emisión fuera de patrón.
- Compromiso de secretos críticos, incluyendo material relacionado con cuentas privilegiadas o krbtgt.
- Persistencia mediante Golden Ticket u otros mecanismos de control de identidad.
- Pivot híbrido hacia Entra ID, Microsoft 365 o aplicaciones cloud mediante identidades sincronizadas, sesiones, permisos o aplicaciones.
El error más frecuente es tratar cada técnica como un silo. El atacante no lo hace. La defensa tampoco debería hacerlo.
Kerberoasting: por qué sigue siendo relevante
Kerberoasting es una técnica de abuso de Kerberos en la que un atacante solicita tickets de servicio asociados a cuentas con SPN y trata de descifrarlos offline para recuperar la contraseña de la cuenta de servicio.
MITRE ATT&CK la clasifica como T1558.003 – Kerberoasting, dentro de las técnicas de robo o falsificación de tickets Kerberos.
El problema no es solo la técnica, sino lo que suele revelar:
- cuentas de servicio antiguas;
- contraseñas de larga vida;
- privilegios excesivos;
- cifrados heredados;
- falta de owner claro;
- ausencia de rotación;
- cuentas reutilizadas en múltiples sistemas.
Una cuenta de servicio mal gobernada puede convertirse en una vía directa hacia movimiento lateral, escalada de privilegios o compromiso de sistemas críticos.
Este riesgo está muy conectado con la gestión de identidades no humanas. Si tu organización utiliza cuentas de servicio, tokens, integraciones o API keys sin ciclo de vida claro, te recomendamos revisar también este artículo sobre identidades no humanas y cuentas de servicio.
Señales de detección de Kerberoasting
Kerberoasting no siempre genera un volumen de ruido evidente. En muchos casos, la clave está en detectar el patrón operativo.
Señales relevantes:
- solicitudes TGS inusuales desde estaciones no administrativas;
- picos de solicitudes hacia múltiples SPN;
- uso de cuentas sin relación funcional con los servicios solicitados;
- actividad posterior desde el mismo host hacia servidores internos;
- autenticaciones fallidas o exitosas fuera de patrón;
- exposición de cuentas con SPN y privilegios superiores a los necesarios;
- uso de cifrados heredados cuando ya no deberían estar permitidos.
La detección eficaz debe correlacionar logs de Kerberos, inventario de cuentas de servicio, criticidad de activos, telemetría EDR y comportamiento de red.
No basta con mirar un evento aislado. Lo importante es reconstruir la secuencia.
AD CS abuse: el riesgo que muchas organizaciones todavía no monitorizan bien
Active Directory Certificate Services, o AD CS, suele verse como una capa técnica secundaria. En realidad, en muchos entornos debe tratarse como Tier 0, porque puede emitir certificados válidos para autenticación y convertirse en un atajo de privilegio.
Una plantilla de certificado mal configurada puede permitir que una identidad solicite certificados con usos, atributos o permisos que no debería tener. Si esa emisión permite autenticación como una cuenta privilegiada, el impacto puede ser crítico.
Microsoft documenta que las plantillas de certificado en AD CS permiten definir configuraciones preestablecidas para la emisión de certificados. Precisamente por eso, sus permisos, usos permitidos y controles de emisión deben gobernarse con rigor.
En entornos híbridos, AD CS es especialmente sensible porque puede estar conectado con autenticación fuerte, acceso a recursos internos, VPN, WiFi corporativo, autenticación de dispositivos o flujos que terminan impactando en servicios cloud.
Señales de detección de abuso de AD CS
Una organización debería monitorizar, como mínimo:
- cambios en plantillas de certificado;
- modificaciones de ACL en plantillas o CA;
- emisión de certificados fuera de patrón;
- solicitudes desde usuarios, equipos o grupos no habituales;
- cambios en EKU, enrolment permissions o subject settings;
- emisión de certificados para identidades privilegiadas;
- autenticaciones posteriores usando certificados en cuentas que históricamente usaban contraseña;
- actividad administrativa sobre la CA sin ticket de cambio aprobado.
La telemetría de AD CS no debe quedar enterrada dentro de un logging generalista. Debe formar parte de los casos de uso del SOC y de los runbooks de respuesta a incidentes.
Si tu organización necesita mejorar la detección y respuesta operativa, puedes revisar nuestros servicios de SOC gestionado y threat hunting.
Golden Ticket: persistencia avanzada en Active Directory
Un Golden Ticket es un ticket Kerberos TGT falsificado que permite al atacante generar material de autenticación válido dentro del dominio si ha comprometido los secretos necesarios, especialmente los asociados a la cuenta krbtgt.
MITRE ATT&CK lo clasifica como T1558.001 – Golden Ticket.
Su gravedad está en la persistencia. Aunque se cambien contraseñas de usuarios concretos, el atacante puede mantener capacidad de acceso si no se eliminan los secretos y condiciones que permiten la falsificación de tickets.
Por eso, ante sospecha fundada de Golden Ticket o compromiso de krbtgt, la respuesta debe ser extremadamente disciplinada. La rotación de krbtgt no debe improvisarse. Microsoft indica que la cuenta krbtgt conserva histórico de dos contraseñas recientes, por lo que resetearla dos veces permite eliminar contraseñas antiguas del histórico, pero esta operación debe planificarse y validarse correctamente.
Señales de detección de Golden Ticket
Un Golden Ticket bien construido puede ser difícil de identificar mediante una única señal. La detección robusta se basa en inconsistencias.
Señales relevantes:
- uso de privilegios elevados desde hosts no administrativos;
- autenticaciones privilegiadas sin elevación previa trazable;
- comportamiento de cuenta incoherente con su histórico;
- actividad desde activos que no forman parte del flujo normal de administración;
- tickets con tiempos de vida o patrones anómalos;
- acceso a múltiples servicios críticos desde un mismo origen sospechoso;
- divergencia entre actividad de endpoint, identidad y logs de dominio.
La conclusión operativa es clara: para detectar Golden Ticket no basta con IOC puntuales. Hace falta correlación de identidad, endpoint, Kerberos, red y comportamiento.
Identidad híbrida: el punto donde AD y Entra ID se conectan
En un entorno híbrido, responder solo en Active Directory local es insuficiente.
Hay que verificar también:
- qué identidades sincronizadas están afectadas;
- si se han modificado métodos de autenticación;
- si existen sesiones activas emitidas durante la ventana de compromiso;
- si se han creado o modificado aplicaciones empresariales;
- si hay service principals con permisos elevados;
- si se han cambiado políticas de acceso condicional;
- si existen cambios en roles privilegiados;
- si se han generado tokens o consentimientos sospechosos.
Microsoft Entra ID permite revocar acceso y sesiones, pero la revocación no debe entenderse como un botón mágico que resuelve toda la exposición. En una crisis de identidad, la revocación debe formar parte de un plan coordinado con AD, endpoints, controladores de dominio, CA, SOC e infraestructura.
Para ampliar este enfoque, puedes revisar nuestras páginas de seguridad Microsoft 365 y auditoría Microsoft 365.
Fuentes de telemetría recomendadas
La clave no es activar todas las fuentes de golpe, sino priorizar las que permiten reconstruir la cadena de ataque.
Hardening preventivo: reducir superficie antes del incidente
El hardening efectivo no consiste en endurecer todo a la vez. Consiste en romper los eslabones más probables de la cadena.
1. Gobierno de cuentas de servicio
Prioridades:
- inventario completo de cuentas con SPN;
- owner técnico y owner de negocio;
- clasificación por criticidad;
- rotación de secretos;
- eliminación de contraseñas estáticas de larga vida;
- prohibición de reutilización entre servicios;
- aplicación de mínimo privilegio;
- revisión de delegaciones;
- caducidad y revisión periódica de excepciones.
Una cuenta de servicio sin dueño es deuda operativa. Una cuenta de servicio con privilegio excesivo es una ruta de ataque.
Puedes ampliar este enfoque en nuestro contenido sobre gestión de vulnerabilidades y credenciales comprometidas.
2. Kerberos y cifrados heredados
Recomendaciones:
- revisar tipos de cifrado permitidos;
- retirar compatibilidad heredada cuando el parque lo permita;
- identificar cuentas que siguen utilizando configuraciones débiles;
- definir excepciones con fecha de expiración;
- monitorizar cambios en atributos sensibles;
- validar dependencias antes de eliminar compatibilidad legacy.
Cada excepción sin fecha de caducidad es una deuda explotable.
3. AD CS como activo Tier 0
AD CS debe gobernarse como infraestructura crítica de identidad.
Controles mínimos:
- revisión de plantillas sensibles;
- control estricto de ACL;
- separación de roles administrativos;
- monitorización de emisión y revocación;
- alertas ante cambios de configuración;
- revisión de EKU y permisos de enrolment;
- validación periódica de rutas de abuso;
- documentación de responsables y cambios.
AD CS no es infraestructura secundaria. Es un multiplicador de identidad.
4. Modelo de tiering administrativo
Medidas recomendadas:
- separar administración de Tier 0;
- usar estaciones administrativas dedicadas;
- impedir saltos desde endpoints de usuario hacia sistemas críticos;
- limitar delegaciones amplias;
- revisar pertenencia a grupos privilegiados;
- aplicar mínimo privilegio;
- controlar rutas administrativas reales, no solo grupos nominales.
Este punto conecta directamente con un modelo de identidad y Zero Trust.
5. Superficie de ataque y exposición continua
La exposición de identidad debe revisarse de forma continua, no solo durante auditorías anuales.
Esto incluye:
- rutas de escalada;
- cuentas privilegiadas;
- grupos anidados;
- endpoints con sesiones administrativas;
- secretos expuestos;
- relaciones de confianza;
- aplicaciones conectadas;
- cambios en cloud e identidad híbrida.
Para organizaciones con entornos complejos, puede tener sentido implantar un enfoque de gestión de superficie de ataque y gestión de vulnerabilidades.
Contención: qué hacer cuando la cadena ya ha empezado
Cuando existe sospecha fundada de abuso de Active Directory, el objetivo no es “limpiar rápido”. El objetivo es recuperar control sin destruir evidencia ni agravar el impacto operativo.
La contención debe equilibrar tres necesidades:
- cortar la capacidad del atacante;
- preservar evidencias;
- mantener servicios críticos funcionando cuando sea posible.
Fase 0: activación y alcance inicial
Objetivo: declarar el incidente, limitar ruido y entender alcance inicial.
Acciones recomendadas:
- declarar incidente de identidad con severidad alta;
- activar equipo técnico de AD, Entra ID, SOC, infraestructura y negocio;
- congelar cambios no esenciales en AD, CA y plataformas críticas;
- identificar controladores de dominio, CA, bastiones y hosts origen;
- preservar evidencias relevantes;
- definir una ventana temporal de análisis;
- identificar cuentas, hosts y servicios potencialmente afectados.
En esta fase no conviene ejecutar acciones destructivas sin hipótesis clara. Un reset mal planificado puede ocultar evidencias o provocar indisponibilidad.
Fase 1: freno táctico
Objetivo: reducir capacidad operativa del atacante.
Acciones recomendadas:
- aislar endpoints o servidores con actividad fuente;
- bloquear cuentas comprometidas o de alto riesgo inmediato;
- revocar sesiones y tokens cuando proceda;
- cortar rutas administrativas no imprescindibles;
- restringir accesos desde hosts no confiables;
- elevar logging y retención;
- aplicar reglas temporales de contención en EDR, firewall o proxy.
En híbrido, esta fase debe coordinar AD on-premise y Entra ID. Si solo se actúa en uno de los dos planos, puede quedar una vía abierta.
Fase 2: neutralización de persistencia
Objetivo: eliminar mecanismos de permanencia.
Acciones recomendadas:
- revisar grupos privilegiados;
- detectar principals añadidos o modificados;
- revisar delegaciones;
- sanear plantillas y ACL de AD CS;
- revocar certificados emitidos de forma sospechosa;
- rotar credenciales de cuentas de servicio expuestas;
- revisar relaciones de confianza;
- analizar service principals y aplicaciones en Entra ID;
- planificar rotación de krbtgt cuando proceda;
- validar replicación y consistencia entre controladores de dominio.
La rotación de krbtgt debe ejecutarse con procedimiento controlado, no como reacción improvisada.
Fase 3: recuperación segura
Objetivo: volver a operación normal con garantías.
Acciones recomendadas:
- reintroducir servicios de forma progresiva;
- validar autenticación en sistemas críticos;
- reforzar monitorización de recaída;
- revisar alertas durante la ventana posterior;
- documentar causa raíz;
- cerrar deuda técnica priorizada;
- actualizar runbooks;
- presentar informe técnico y ejecutivo.
La recuperación no termina cuando desaparece la alerta. Termina cuando se ha eliminado la persistencia, reducido la superficie y aprendido del incidente.
Si necesitas apoyo especializado, Hard2bit ofrece servicios de respuesta a incidentes y retainer de respuesta a incidentes.
Casos de uso recomendados para SOC y Blue Team
Caso A: posible Kerberoasting orientado a privilegio
Hipótesis:
Un actor con acceso inicial enumera SPN y solicita tickets de servicio para intentar descifrar credenciales offline.
Correlaciones mínimas:
- solicitudes TGS anómalas;
- cuenta solicitante fuera de patrón;
- host origen no administrativo;
- SPN asociados a servicios críticos;
- actividad lateral posterior desde el mismo origen.
Escalado:
Medio. Alto si afecta a cuentas con privilegio efectivo o servicios críticos.
Caso B: abuso de plantilla AD CS
Hipótesis:
Un actor modifica o aprovecha permisos de plantilla para emitir un certificado utilizable en autenticación privilegiada.
Correlaciones mínimas:
- cambio de ACL o configuración sin ticket aprobado;
- emisión de certificado desde usuario o equipo no habitual;
- uso posterior de la identidad para acceso privilegiado;
- cambios en EKU o permisos de enrolment.
Escalado:
Alto, por potencial de escalada silenciosa.
Caso C: persistencia tipo Golden Ticket
Hipótesis:
Un actor mantiene acceso mediante TGT falsificado tras comprometer secretos críticos del dominio.
Correlaciones mínimas:
- uso de privilegio desde hosts no administrativos;
- tickets o patrones Kerberos anómalos;
- actividad sin elevación previa trazable;
- accesos repetidos a sistemas críticos;
- divergencia entre endpoint, identidad y origen.
Escalado:
Crítico.
Caso D: pivot híbrido hacia Entra ID
Hipótesis:
Tras comprometer identidad local, el atacante intenta consolidar acceso en servicios cloud.
Correlaciones mínimas:
- cambios en aplicaciones empresariales;
- nuevos permisos en service principals;
- modificaciones de métodos de autenticación;
- cambios de políticas de acceso condicional;
- sesiones activas emitidas durante la ventana de compromiso;
- inicios de sesión desde ubicaciones o dispositivos anómalos.
Escalado:
Alto o crítico, según privilegios afectados.
Métricas que sí importan
Medir el número total de alertas aporta poco. En identidad híbrida, las métricas deben reflejar capacidad real de detección y contención.
Métricas recomendadas:
- MTTD de cadena: tiempo desde la primera señal hasta la hipótesis consolidada.
- MTTC: tiempo hasta la contención efectiva.
- Porcentaje de cuentas de servicio con owner activo.
- Porcentaje de cuentas con SPN revisadas y clasificadas.
- Porcentaje de plantillas AD CS revisadas.
- Número de rutas críticas de escalada abiertas.
- Número de rutas críticas cerradas por trimestre.
- Tiempo de revocación de sesiones en plano híbrido.
- Porcentaje de activos Tier 0 con administración segregada.
- Runbooks probados en los últimos 6 meses.
Estas métricas conectan seguridad técnica con riesgo real de negocio.
Para una visión ejecutiva, puedes complementar este enfoque con un cuadro de mando de ciberresiliencia para consejo.
Errores frecuentes
1. Confiar solo en MFA cloud
El MFA es necesario, pero no compensa por sí solo una identidad on-premise débil. Si AD local está comprometido, el riesgo puede propagarse al entorno híbrido.
2. No tratar AD CS como Tier 0
Una CA o plantilla mal gobernada puede convertirse en una vía de escalada crítica.
3. Mantener cuentas de servicio sin owner
Sin responsable, no hay revisión, rotación ni control de privilegios.
4. Hacer contención parcial
Resetear contraseñas sin revisar certificados, sesiones, delegaciones, grupos, service principals o krbtgt puede dejar persistencia activa.
5. No probar runbooks
Un runbook que nunca se ha ensayado suele fallar cuando más se necesita.
6. Separar seguridad técnica y cumplimiento
Identidad, continuidad, gestión de incidentes y cumplimiento deben trabajar juntos. Esta separación es uno de los motivos por los que muchas organizaciones cumplen en papel, pero no contienen bien en crisis.
Sobre este punto, puedes leer también nuestro análisis sobre por qué separar ciberseguridad y compliance es un error.
Plan de 90 días para elevar la madurez
Días 0-30: visibilidad y riesgo inmediato
Objetivo: saber dónde está el riesgo.
Acciones:
- inventariar cuentas de servicio;
- identificar cuentas con SPN;
- clasificar privilegios efectivos;
- mapear activos Tier 0;
- revisar controladores de dominio, CA y bastiones;
- activar casos mínimos de detección para Kerberoasting;
- revisar plantillas AD CS de mayor riesgo;
- validar fuentes de logging;
- identificar rutas críticas de escalada.
Resultado esperado: mapa inicial de exposición de identidad.
Días 31-60: reducción de superficie
Objetivo: cerrar rutas explotables.
Acciones:
- rotar secretos de cuentas críticas;
- eliminar privilegios innecesarios;
- restringir delegaciones;
- endurecer plantillas AD CS;
- retirar configuraciones heredadas cuando sea viable;
- definir procedimiento de rotación krbtgt;
- segmentar administración Tier 0;
- revisar políticas de acceso híbrido;
- documentar owners y excepciones.
Resultado esperado: reducción medible de superficie de ataque.
Días 61-90: validación y resiliencia
Objetivo: comprobar que los controles funcionan.
Acciones:
- ejecutar simulación controlada de cadena de abuso;
- validar detecciones con SOC;
- ajustar reglas para reducir falsos positivos;
- probar runbooks de contención;
- realizar ejercicios de mesa con negocio e infraestructura;
- medir MTTD y MTTC;
- cerrar gaps prioritarios;
- preparar roadmap trimestral.
Resultado esperado: capacidad validada de detección y contención.
Para organizaciones que quieren validar rutas reales de ataque, puede tener sentido realizar ejercicios de Red Team o simulaciones de adversario controladas. También puedes leer esta guía sobre cuándo tiene sentido un Red Team en empresas medianas.
Checklist técnico de contención
Un runbook serio de contención de identidad híbrida debería incluir:
- criterios de activación por severidad;
- matriz de aislamiento de host, cuenta y segmento;
- responsables técnicos por plano: AD, Entra ID, SOC, endpoint, red y negocio;
- procedimiento de preservación de evidencias;
- flujo de bloqueo de cuentas;
- revocación de sesiones y tokens;
- revisión de grupos privilegiados;
- revisión de delegaciones;
- revisión de plantillas AD CS;
- revocación de certificados sospechosos;
- rotación de cuentas de servicio;
- procedimiento krbtgt;
- validación de replicación;
- validaciones post-contención;
- criterios de reapertura;
- informe técnico y ejecutivo.
Este runbook debe estar probado, no solo escrito.
Relación con NIS2, DORA, ENS e ISO 27001
La defensa de identidad híbrida no es solo un problema técnico. También conecta con resiliencia, continuidad, gestión de incidentes y cumplimiento normativo.
En marcos como NIS2, DORA, ENS e ISO 27001, la organización debe demostrar capacidad de gestión de riesgos, control de accesos, monitorización, respuesta a incidentes y mejora continua.
Un incidente de identidad que afecte a Active Directory, Entra ID o Microsoft 365 puede impactar directamente en:
- continuidad de negocio;
- disponibilidad de servicios críticos;
- trazabilidad de accesos;
- segregación de privilegios;
- gestión de incidentes;
- evidencias de auditoría;
- reporting a dirección;
- obligaciones regulatorias.
Si tu organización está trabajando en estos marcos, puedes consultar nuestras páginas de NIS2, DORA, ENS e ISO 27001.