AD híbrido cambiar la contraseña no basta para detener a los atacantes así se cierra la ventana de exposición

Cuando se detecta una intrusión, el reinicio de contraseñas suele ser el gesto reflexivo y correcto: rápido, visible y con la promesa de cortar el acceso del atacante. Sin embargo, en entornos Windows/Active Directory híbridos esa acción no siempre elimina instantáneamente todos los caminos de autenticación, y ese retardo puede ser suficiente para que un adversario mantenga o restaure su presencia.

El problema tiene varias caras: Windows conserva hashes en caché para permitir inicios de sesión sin conexión, la sincronización de hashes hacia Entra ID (Azure AD) no siempre es inmediata y Kerberos usa tickets que permanecen válidos hasta su expiración. Es decir, tras un cambio de contraseña pueden coexistir simultáneamente el hash anterior en máquinas desconectadas, tickets Kerberos activos y, en híbridos, un hash antiguo aún no replicado a la nube.

Desde la perspectiva de respuesta a incidentes esto tiene implicaciones prácticas: un atacante que ya capturó un hash puede emplear técnicas de tipo pass-the-hash, seguir usando credenciales en endpoints desconectados o mantener sesiones válidas mediante tickets. Las variantes más graves, como los tickets forjados (los llamados Golden o Silver Tickets), directamente invalidan la efectividad de un simple cambio de contraseña hasta que se aborden esos componentes críticos.

La buena noticia es que muchos de estos vectores se mitigan con medidas concretas y ordenadas: primero, aislar y forzar la desautenticación de los dispositivos comprometidos —desconectar de red, forzar cierre de sesión o reinicio y, cuando sea posible, purgar tickets Kerberos activos en los equipos afectados—; segundo, rotar credenciales críticas, incluyendo las de cuentas de servicio con privilegios; y tercero, realizar una revisión exhaustiva del directorio para detectar permisos o ACLs añadidas indebidamente, cuentas nuevas, SPNs sospechosos o modificaciones a AdminSDHolder.

Hay mecanismos técnicos que ayudan a cerrar la ventana de exposición: forzar la sincronización de contraseña hacia Entra ID (Azure AD Connect) o activar las notificaciones de cambio en AD reduce el lapso en entornos híbridos; y purgar tickets locales con utilidades nativas puede cortar sesiones que seguirían activas tras la rotación de credenciales. Microsoft documenta cómo funciona la sincronización de hash y cómo forzar sincronías en entornos híbridos, información útil para los equipos de operaciones: https://learn.microsoft.com/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization.

Para incidentes de mayor gravedad donde se sospeche que se han forjado tickets, la acción más disruptiva pero necesaria suele ser el reinicio controlado de la cuenta KRBTGT del dominio (habitualmente en dos pasos) para invalidar TGTs maliciosos. Esto requiere planificación y pruebas en entornos de ensayo, y Microsoft ofrece guías técnicas sobre el procedimiento y sus riesgos: https://learn.microsoft.com/troubleshoot/windows-server/identity/reset-krbtgt-password.

No hay que olvidar que la recuperación no es sólo técnica: hay que buscar caminos alternativos que permitan la reentrada sin contraseña, como delegaciones que permitan restablecer contraseñas, permisos persistentes en ACLs o cuentas con derechos elevados que no fueron tocadas. Auditar cambios recientes en miembros de grupos privilegiados, roles o delegaciones es tan crítico como rotar claves.

En paralelo conviene endurecer la superficie para que futuros resets sean más eficaces: imponer MFA obligatoria en accesos remotos y para administradores, reducir la base de cuentas con privilegios permanentes, aplicar el principio de privilegio mínimo, y emplear soluciones que gestionen y roten contraseñas de cuentas de servicio y credenciales locales (por ejemplo, LAPS u otros gestores de secretos). La detección importa tanto como la contención: basar la respuesta en logs de autenticación, alertas de detección de lateralidad y telemetría EDR/SIEM acelera la identificación de persistencias.

Para equipos de operaciones que quieran acciones prácticas y ordenadas, recomiendo primero ejecutar un plan de contención inmediato: aislar sistemas afectados, forzar cierre de sesiones y reinicios, rotar credenciales humanas y de servicio críticas, y lanzar una sincronización dirigida en entornos híbridos. A continuación, realizar una auditoría detallada de AD en busca de cambios de ACL, nuevas cuentas con privilegios o modificaciones a AdminSDHolder, y documentar cada paso para la cadena de custodia y lecciones aprendidas.

Finalmente, no subestime la importancia de la prevención y del ejercicio: pruebas regulares de respuesta a incidentes, simulaciones de compromiso de cuentas privilegiadas y el despliegue de controles como MFA en todas las rutas críticas reducen drásticamente la dependencia de resetear contraseñas como única defensa. Para entender mejor técnicas que abusan de hashes y tickets, un buen resumen del componente ofensivo está disponible en la base de conocimientos de ATT&CK: https://attack.mitre.org/techniques/T1550/002/.

En pocas palabras, un cambio de contraseña es necesario pero rara vez suficiente. La remediación efectiva combina aislamiento, rotación de las credenciales correctas, invalidación de sesiones y tickets, auditoría de permisos y medidas preventivas que reduzcan las ventanas de oportunidad en el futuro.