AD: evaluación, copia de seguridad y recuperación del bosque

Los controles de hardening se degradan sin hacer ruido. Una configuración de directiva de grupo se desvía, una cuenta de servicio acabó en Domain Admins durante un incidente y nadie lo revirtió, una nueva confianza llegó con un proyecto de migración y nunca se revisó. La evaluación, las copias de seguridad y los ensayos de recuperación son la capa de gobierno que detecta esa deriva y garantiza que cuando algo salga mal (no si sale mal) tenga a la vez la evidencia para saber que ocurrió y un camino probado de vuelta a un bosque limpio.

Este artículo trata la ejecución e interpretación de evaluaciones de postura, la comparación de la configuración con el Security Compliance Toolkit de Microsoft y los CIS Benchmarks, el tratamiento de LAPS y del modelo de niveles como comprobaciones recurrentes en lugar de proyectos puntuales, la protección de las copias de seguridad de Tier 0 y el ensayo de una recuperación completa del bosque.

Herramientas de evaluación de la postura

Tres herramientas cubren la mayor parte de lo que necesita, y son complementarias, no redundantes:

Ejecute PingCastle (o Purple Knight) como tarea programada, no de forma puntual:

# PingCastle, modo healthcheck, programado mediante el Programador de tareas
PingCastle.exe --healthcheck --server dc01.domain.com --level Full

Cómo leer la puntuación: no persiga el 100/100; algunos hallazgos son falsos positivos en su entorno o riesgos aceptados (documentados, por ejemplo, una aplicación heredada que requiere un protocolo antiguo). Lo que importa es:

1. Que los hallazgos críticos disminuyan de una ejecución a otra, nunca que aumenten.
2. Que cualquier hallazgo nuevo en Trusts o Privileged Accounts se clasifique en cuestión de días, no en el siguiente ciclo trimestral: estas categorías son las que cambian más rápido y las que con más frecuencia interesan a un atacante.
3. Que los hallazgos estén vinculados a un ticket y a un responsable, en lugar de revisarse y aceptarse de nuevo indefinidamente.

Comparación con líneas de base: Microsoft SCT y CIS Benchmarks

Los analizadores de postura le informan del riesgo a nivel de objetos de AD (cuentas obsoletas, confianzas mal configuradas, delegación). Por lo general no sustituyen por completo a una comparación con una línea de base de directiva de grupo, que le dice si sus GPO reales se ajustan a una línea de base de seguridad contrastada.

• Microsoft Security Compliance Toolkit (SCT): incluye copias de seguridad de GPO de línea de base para cada versión compatible de Windows Server, además de Policy Analyzer, una herramienta gráfica y de línea de comandos que compara sus GPO de producción con la línea de base y señala cada configuración que difiere.
• CIS Benchmarks para Windows Server / Active Directory: una línea de base mantenida de forma independiente y más prescriptiva; muchos entornos regulados exigen específicamente el cumplimiento de CIS en lugar de (o además de) la línea de base de Microsoft.

Flujo de trabajo:

# Exportar las GPO actuales para la comparación
Get-GPO -All | ForEach-Object { Backup-GPO -Guid $_.Id -Path "C:\GPOBackups" }

A continuación, cargue en Policy Analyzer tanto las copias de seguridad exportadas como las copias de seguridad de las GPO de línea de base de SCT/CIS y genere un informe de diferencias. Registre las excepciones (las configuraciones de las que se aparta deliberadamente) en un documento con una justificación y un responsable: los auditores y usted mismo en el futuro lo agradecerán.

Repita esta comparación cada vez que Microsoft publique una nueva línea de base de SCT (normalmente alineada con cada actualización de características de Windows Server) y, en cualquier caso, al menos dos veces al año.

LAPS y el modelo de niveles como comprobaciones recurrentes, no proyectos puntuales

Tanto LAPS (Local Administrator Password Solution / Windows LAPS) como el modelo de niveles administrativos (Tier 0 y acceso privilegiado) se deterioran si se tratan como un proyecto de implementación en lugar de como un control continuo:

# Verificar que LAPS rota realmente las contraseñas, no solo que está instalado
# Windows LAPS (atributos msLAPS-*)
Get-ADComputer -Filter * -Properties msLAPS-PasswordExpirationTime |
  Where-Object { $_.'msLAPS-PasswordExpirationTime' -lt (Get-Date).AddDays(-35).ToFileTime() } |
  Select-Object Name
# Microsoft LAPS heredado, solo si su extensión de esquema (ms-Mcs-AdmPwd*) está instalada
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwdExpirationTime |
  Where-Object { $_.'ms-Mcs-AdmPwdExpirationTime' -lt (Get-Date).AddDays(-35).ToFileTime() } |
  Select-Object Name

# Verificar que no han aparecido cuentas inesperadas en los grupos de Tier 0
Get-ADGroupMember "Domain Admins" -Recursive | Select-Object Name, SamAccountName
Get-ADGroupMember "Enterprise Admins" -Recursive | Select-Object Name, SamAccountName

Programe ambas comprobaciones como mínimo cada semana. La deriva en la pertenencia a grupos (una cuenta de servicio agregada a Domain Admins durante un incidente y nunca retirada, un proveedor con acceso temporal que sobrevivió al encargo) es una de las formas más habituales en que el modelo de niveles falla sin hacer ruido, y es invisible a menos que la busque activamente. Correlaciónela con los eventos 4728/4732/4756 para saber cuándo y quién provocó la deriva, no solo que existe.

Proteger las copias de seguridad de Tier 0

La copia de seguridad del estado del sistema de un controlador de dominio es, a efectos prácticos, una copia de todas las credenciales del dominio: la base de datos NTDS con todos los hashes de contraseñas y la clave de krbtgt que firma cada ticket Kerberos. Protéjala en consecuencia:

• Haga copias de seguridad del estado del sistema, no solo copias a nivel de archivo o instantáneas de VM, para que tanto la restauración autoritativa como la no autoritativa funcionen correctamente:

wbadmin start systemstatebackup -backupTarget:E: -quiet

• Almacene las copias de seguridad sin conexión, de forma inmutable o aisladas de producción. Si una credencial equivalente a Domain Admin (o un ransomware que la haya obtenido) puede llegar a su almacén de copias de seguridad y borrarlo, no es una copia de seguridad: es una segunda copia del mismo activo que el atacante ya controla. El almacenamiento de objetos inmutable (escritura única, con bloqueo de retención) o los soportes realmente sin conexión o aislados son aceptables; un recurso compartido de copias de seguridad unido al mismo dominio y al alcance de las mismas cuentas privilegiadas no lo es.
• Restrinja los derechos de operador de copia de seguridad: Backup Operators puede leer toda la base de datos NTDS mediante una copia de seguridad del estado del sistema, lo que convierte a ese grupo, a efectos de confidencialidad, en el equivalente a Domain Admin. Audite su pertenencia con el mismo rigor que la de Domain Admins.
• Pruebe que las copias se pueden restaurar, no solo que terminan. Un trabajo de copia de seguridad que informa de éxito le dice que escribió datos; no le dice que esos datos se puedan restaurar.

Ensayar la recuperación del bosque

Microsoft publica una detallada AD Forest Recovery Guide que describe el orden exacto de las operaciones para recuperarse de un escenario en el que no se puede confiar en el bosque (ransomware, un cambio malicioso del esquema o la pérdida de suficientes DC como para romper la replicación o el quórum). No la lea por primera vez durante un incidente real.

Orden general de las operaciones (consulte la guía de Microsoft para el procedimiento completo):

1. Identifique la última copia de seguridad del estado del sistema válida conocida y libre de malware de un DC por dominio, dando prioridad a un servidor de catálogo global del dominio raíz del bosque.
2. Aísle el entorno (desconéctelo de la red o pause la replicación) antes de restaurar, para que un adversario todavía activo o un asociado de replicación dañado no puedan volver a infectar el DC restaurado.
3. Restaure el primer DC de cada dominio (primero la raíz del bosque) en el Modo de restauración de servicios de directorio (DSRM) como una restauración no autoritativa de AD DS con una restauración autoritativa de SYSVOL (wbadmin start systemstaterecovery ... -authsysvol, o establezca msDFSR-Options en 1 en la suscripción SYSVOL del DC para DFSR). Todos los demás DC se reconstruirán, así que no hay ningún asociado de replicación cuyos cambios haya que sobrescribir.
4. Restablezca la contraseña de krbtgt dos veces en cada dominio como parte de la recuperación, respetando la convergencia de la replicación entre ambos restablecimientos: esto invalida todos los tickets Kerberos emitidos antes de la recuperación, incluidos los que haya falsificado un atacante.
5. Limpie los metadatos de los DC que no se vayan a recuperar con ntdsutil, para que los objetos de DC obsoletos no provoquen problemas de replicación o de DNS:

ntdsutil
metadata cleanup
connections
connect to server <survivingDC>
quit
select operation target
list domains
select domain <n>
list sites
select site <n>
list servers in site
select server <n>
quit
remove selected server
quit
quit

6. Reconstruya y vuelva a promover los DC restantes desde medios limpios una vez verificados el primer DC y la limpieza de metadatos.
7. Vuelva a habilitar la conectividad de red y la replicación de forma progresiva, vigilando las señales de reinfección antes de volver a conectar todo el entorno.

Ensaye esto en un laboratorio aislado al menos una vez al año. Las guías de recuperación se leen de una forma y se ejecutan de otra: los problemas con la contraseña de DSRM, una ubicación inesperada de los roles FSMO o la falta de familiaridad con la sintaxis de ntdsutil bajo presión son exactamente el tipo de fricción que quiere descubrir durante un simulacro, no durante un incidente de ransomware a las dos de la madrugada.

Qué se rompe

Nada directamente: se trata de trabajo de gobierno y de recuperación ante desastres, no de un control que afecte a producción. El coste es tiempo y disciplina de procesos: ejecuciones de evaluación programadas, presupuesto de almacenamiento para la retención inmutable o sin conexión y simulacros periódicos de recuperación que consumen infraestructura de laboratorio y horas de personal. Nada de ello cambia el comportamiento diario de autenticación o de acceso de los usuarios.

Combínelo con el hardening de Kerberos para la cadencia de rotación de krbtgt fuera de los escenarios de recuperación, y con Auditoría, registro y detección para que, cuando la evaluación de la postura señale un hallazgo, disponga también de los registros para determinar si se llegó a explotar.