🛡️ Guía independiente de formación en ciberseguridad · Certificaciones, itinerarios y cursos
Inicio › Cursos › Curso de Defensa y Bastionado de Active Directory
Módulo 13 de 13

Módulo 13: Copias de seguridad, recuperación y respuesta al compromiso del dominio

Módulo 13: Copias de seguridad, recuperación y respuesta al compromiso del dominio

Aviso ético: el contenido de este módulo se ofrece con fines exclusivamente educativos y de formación profesional en ciberseguridad defensiva y continuidad de negocio. Todos los comandos de copia de seguridad, restauración, ntdsutil y reseteo de krbtgt deben practicarse únicamente en laboratorios controlados (máquinas virtuales o entornos de pruebas aislados) sobre los que tengas autorización explícita. Ejecutar una restauración autoritativa, una limpieza de metadatos o un reseteo de krbtgt en un Active Directory de producción sin planificación, sin backup verificado y sin ventana de mantenimiento puede causar una pérdida de datos irreversible o dejar el dominio completamente inoperativo. Si tu organización sufre un incidente real de compromiso de Active Directory, sigue el plan de respuesta a incidentes aprobado, involucra a dirección/legal desde el minuto uno, y no experimentes directamente contra el entorno afectado.

Qué aprenderás

  • Por qué las copias de seguridad de AD son un control de supervivencia del negocio, no una casilla de cumplimiento, y qué hace que un backup sea realmente restaurable.
  • Cómo hacer copias de System State de al menos dos DC con wbadmin/Windows Server Backup, y por qué la regla 3-2-1(-1-0) offline/inmutable y fuera del dominio es innegociable frente a ransomware.
  • Qué es el DSRM (Directory Services Restore Mode), cómo se gestiona su contraseña, y cuándo lo necesitas.
  • La diferencia entre restauración no autoritativa y autoritativa con ntdsutil, y cuándo usar cada una.
  • La Papelera de reciclaje de AD (Recycle Bin) para recuperar objetos borrados sin DSRM, y sus límites (retención, atributos link-value).
  • El procedimiento oficial de Microsoft de Forest Recovery para reconstruir un bosque comprometido, con limpieza de metadatos y doble reseteo de krbtgt.
  • Un checklist de respuesta tras un compromiso de Domain Admin/Enterprise Admin: qué rotar, qué revisar, y por qué a menudo hay que reconstruir en vez de «limpiar».
  • Las obligaciones de notificación de brecha bajo RGPD/AEPD (72 horas) si el incidente afectó a datos personales.
  • Un laboratorio guiado para habilitar la Papelera de reciclaje y recuperar un objeto borrado.

1. Por qué este módulo es el más importante del curso

Todo lo aprendido en los módulos anteriores —Kerberoasting, delegación, modelo de niveles, PAW, SIEM— persigue un objetivo: evitar que alguien no autorizado controle tu Active Directory. Este módulo asume que, a pesar de todo eso, ha ocurrido: un ransomware ha cifrado tus DC, o un atacante ha confirmado tener Domain Admins/Enterprise Admins. La pregunta deja de ser «¿cómo lo prevengo?» y pasa a ser: ¿puedo recuperar el negocio, y puedo confiar en el AD que quede en pie?

En la inmensa mayoría de ransomware corporativo grave, AD no es víctima colateral: es el objetivo intermedio. El atacante lo compromete porque, con Domain Admins, puede desplegar el cifrador a todos los equipos simultáneamente vía GPO o PsExec. Esto implica dos cosas: (1) tus DC probablemente están entre los cifrados, y (2) no puedes confiar en restaurar el mismo AD que existía justo antes, porque es el AD que el atacante llevaba controlando, semanas o meses, antes del payload final. Microsoft lo resume así:

«Because Active Directory Domain Services (AD DS) is a distributed multi-master system, restoring a single domain controller from backup does not restore an entire AD forest to a known good state. […] A forest recovery is required when there’s been a catastrophic failure that leaves the forest unable to function correctly, or when the forest can no longer be trusted due to the nature of an attack or compromise.»

— Microsoft, «Active Directory Forest Recovery Guide», Microsoft Learn.

2. Fundamentos: qué hace que un backup de AD sea válido

2.1. System State: qué contiene y por qué es la unidad mínima de backup

No se hace «backup de AD» como una carpeta de ficheros: se hace backup del System State del DC, que Windows Server Backup trata como unidad atómica. Incluye la base de datos de AD (NTDS.dit) y su registro de transacciones, el volumen SYSVOL (GPO, scripts de inicio de sesión), el registro de Windows, la base de certificados si el DC también es CA, y los ficheros de arranque. Es consistente en el tiempo: todo se captura en el mismo instante vía Volume Shadow Copy Service (VSS), imprescindible porque restaurar NTDS.dit sin su SYSVOL (o viceversa) produce un DC inconsistente.

2.2. La regla de los «al menos dos DC»

AD es un sistema multi-maestro: cada DC escribible replica la base de datos con el resto. Esto implica que un solo DC de backup no basta: por redundancia física (si ese DC también fue cifrado, te quedas sin nada), y porque el Forest Recovery (sección 7) exige restaurar un DC por cada dominio del bosque desde un backup fiable. Recomendación mínima: System State de al menos dos DC por dominio, con frecuencia acorde a tu Recovery Point Objective (RPO) — diario como mínimo.

2.3. Comandos: Windows Server Backup y wbadmin

La herramienta nativa es Windows Server Backup y su CLI, wbadmin. Instalación y backup puntual a una unidad dedicada (nunca al mismo disco del sistema):

# Instalar la caracteristica Windows Server Backup (una vez, por servidor)
Install-WindowsFeature Windows-Server-Backup -IncludeAllSubFeature

# Backup puntual (una sola vez) del System State a una unidad externa E:
wbadmin start systemstatebackup -backupTarget:E: -quiet

# Ver el catalogo de backups de System State disponibles en este DC
wbadmin get versions

# Programar un backup diario de System State a las 22:00 sobre la unidad E:
wbadmin enable backup -addtarget:E: -schedule:22:00 -systemState -quiet

Nota sobre -backupTarget: si apunta a disco local/USB dedicado, Windows Server Backup lo reserva en exclusiva para el catálogo (deja de ser unidad normal), reduciendo el riesgo de que un ransomware que recorre unidades mapeadas cifre el propio backup. Un backup a ruta de red (útil para centralizar y copiar luego a offline) no se reserva en exclusiva, y pierde esa protección:

# Backup puntual de System State a una ruta de red (ej. NAS de backups)
wbadmin start systemstatebackup -backupTarget:\nas-backupsad-dc01 -quiet

2.4. La regla 3-2-1(-1-0) aplicada a Active Directory

La regla clásica —3 copias, en 2 soportes distintos, 1 offsite— se queda corta frente a ransomware que busca y cifra activamente los backups accesibles desde la red. La variante reforzada añade: 1 copia offline/inmutable (WORM, sin sobrescritura ni con credenciales de administrador durante un periodo), y 0 errores verificados (probada con restauración real, no solo «completada sin fallo»). Para AD, la regla crítica adicional es:

«Store the backup media in a location outside the domain and forest. […] If the backup media is accessible from the network, and an attacker has compromised the domain, the attacker might be able to access and compromise the backup as well.»

— Microsoft, «Active Directory Forest Recovery Guide», Microsoft Learn.

Tres requisitos auditados con frecuencia y cumplidos con poca: (1) la cuenta que gestiona el backup no debe tener privilegios en el propio AD; (2) el repositorio no debe ser accesible por autenticación de dominio del mismo bosque (NAS con credenciales locales, o cloud con MFA e identidad separada); y (3) al menos una copia debe estar verdaderamente offline (cinta extraída, o inmutable con retention lock) para que ni con credenciales robadas de Domain Admin se pueda alcanzar.

3. DSRM: Directory Services Restore Mode

El DSRM es un modo de arranque especial de un DC en el que AD DS está detenido y el DC se comporta como un servidor miembro con su propia SAM local. Imprescindible para operaciones que exigen NTDS.dit offline: restauraciones no autoritativas y autoritativas con ntdsutil, mantenimiento/compactación de la base de datos, y reparación tras corrupción.

3.1. La contraseña de DSRM: el secreto olvidado hasta que hace falta

Cada DC tiene su propia contraseña de DSRM, fijada en la promoción y almacenada localmente, sin replicarse con AD. El problema clásico: se define una vez y no se vuelve a tocar durante años, hasta el día en que se necesita en mitad de un incidente y nadie la recuerda.

# Resetear la contrasena de DSRM de un DC (ejecutar EN el propio DC, con AD arriba)
ntdsutil "set dsrm password" "reset password on server null" q q
# El comando pedira la nueva contrasena de forma interactiva (dos veces)

# Alternativa para automatizar/scripting (PowerShell, misma utilidad por detras)
$dsrmPass = Read-Host -AsSecureString "Nueva contrasena DSRM"
# ntdsutil no acepta SecureString directamente; usar el modo interactivo anterior
# en entornos donde se requiera automatizacion, custodiar el secreto en un vault
# (Azure Key Vault, HashiCorp Vault, CyberArk...) y aplicarlo de forma controlada.

Buenas prácticas: (1) distinta en cada DC; (2) en un vault corporativo, nunca en texto plano en el mismo dominio que protege; (3) resetearla periódicamente, porque nadie la usa y nadie notaría si quedó expuesta; y (4) tras un incidente con administrador local en un DC, tratarla como comprometida y resetearla sin excepción.

3.2. Arrancar un DC en DSRM

# Forzar el arranque en DSRM en el siguiente reinicio (metodo recomendado, sin tocar boot.ini/BCD)
bcdedit /set safeboot dsrepair
shutdown /r /t 0

# --- tras el reinicio, el DC arranca en Directory Services Restore Mode ---
# Iniciar sesion con la cuenta local ".Administrator" y la contrasena de DSRM

# IMPORTANTE: revertir el arranque especial tras terminar el mantenimiento,
# o el DC seguira arrancando en DSRM indefinidamente
bcdedit /deletevalue safeboot
shutdown /r /t 0

4. Tabla de referencia: escenario, técnica y herramienta

Escenario Técnica de recuperación Herramienta / comando ¿Requiere DSRM?
Objeto borrado accidentalmente (usuario, grupo, OU) hace <180 días (retención por defecto) Restaurar desde la Papelera de reciclaje de AD Get-ADObject -IncludeDeletedObjects + Restore-ADObject No
Atributo de un objeto sobrescrito por error (ej. una GPO cambió mal un atributo masivamente) Restauración autoritativa parcial de ese objeto/subárbol wbadmin (restaurar System State) + ntdsutil authoritative restore Sí
Un único DC caído por fallo de hardware/corrupción, resto del dominio sano Restauración no autoritativa de ese DC, o reinstalación + nueva promoción (reintroducción) wbadmin start systemstaterecovery, o ntdsutil metadata cleanup + dcpromo/Install-ADDSDomainController Sí (si se restaura) / No (si se reinstala desde cero)
Cambio de esquema o replicación masiva errónea detectada a tiempo, en varios DC Restauración autoritativa a nivel de dominio desde el DC más fiable ntdsutil authoritative restore (todo el dominio, USN incrementado) Sí
Bosque completo cifrado por ransomware, o atacante confirmado con Enterprise Admins Forest Recovery completo: aislar, restaurar un DC por dominio, limpieza de metadatos, reconstrucción, doble reseteo de krbtgt Guía oficial de Microsoft «AD Forest Recovery»; ntdsutil, wbadmin, scripts de reset de krbtgt Sí, en los DC restaurados
Confirmado que el atacante tuvo Domain Admin, pero los DC no fueron cifrados (persistencia, no destrucción) Respuesta a compromiso sin reconstrucción total: doble reset de krbtgt, reset masivo de credenciales, caza de persistencia Scripts de reset de krbtgt, auditoría de ACL/AdminSDHolder/GPO/delegación, EDR/SIEM No necesariamente, salvo hallazgos que lo requieran

5. La Papelera de reciclaje de Active Directory (AD Recycle Bin)

5.1. Qué resuelve y desde cuándo existe

Antes de 2008 R2, borrar un objeto lo convertía en un tombstone: se despojaba de casi todos sus atributos, se movía a CN=Deleted Objects, y tras el tombstone lifetime (180 días) se eliminaba en garbage collection. Recuperarlo exigía una restauración autoritativa completa — pesada, con downtime, para algo tan común como «he borrado una OU sin querer». Desde Windows Server 2008 R2 existe la AD Recycle Bin: el objeto borrado conserva todos sus atributos (incluidos los link-value, como pertenencia a grupos) durante la retención, y restaurarlo es una operación en caliente, sin backup ni downtime.

5.2. Habilitarla (operación irreversible de nivel funcional)

Se activa una sola vez por bosque y no se puede desactivar (eleva de forma permanente el esquema y el comportamiento de borrado en todo el bosque):

# Comprobar el estado actual de la caracteristica en el bosque
Get-ADOptionalFeature -Filter 'Name -like "Recycle Bin*"' |
    Select-Object Name, EnabledScopes

# Habilitar la Papelera de reciclaje de AD (requiere Enterprise Admins,
# y forest functional level 2008 R2 o superior en TODOS los dominios del bosque)
Enable-ADOptionalFeature "Recycle Bin Feature" `
    -Scope ForestOrConfigurationSet `
    -Target (Get-ADForest).Name `
    -Confirm:$false

5.3. Recuperar un objeto borrado

# Localizar el objeto borrado por nombre (busca en todo el arbol, incluidos borrados)
Get-ADObject -Filter 'isDeleted -eq $true -and Name -like "*jperez*"' `
    -IncludeDeletedObjects -Properties * |
    Select-Object Name, ObjectClass, LastKnownParent, whenChanged

# Restaurar el objeto a su ubicacion original (LastKnownParent)
Get-ADObject -Filter 'isDeleted -eq $true -and Name -like "*jperez*"' `
    -IncludeDeletedObjects |
    Restore-ADObject

# Restaurar a una OU distinta de la original (si esa OU tambien fue borrada o reorganizada)
Get-ADObject -Filter 'isDeleted -eq $true -and Name -like "*jperez*"' `
    -IncludeDeletedObjects |
    Restore-ADObject -TargetPath "OU=Usuarios,DC=empresa,DC=local"

Al restaurar un grupo borrado, la Papelera también restaura correctamente sus atributos link-value —la lista de miembros—, algo que la restauración autoritativa clásica no garantizaba igual de bien. Por eso, para «objeto borrado por error, bosque sano», la Papelera es siempre preferible a una restauración autoritativa completa.

5.4. Límites que hay que conocer

  • Retención finita. El objeto es recuperable durante el Deleted Object Lifetime (180 días por defecto); después pasa a recycled y se purga. Comprobar: Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=..." -Properties msDS-DeletedObjectLifetime.
  • No sustituye al backup. Ante corrupción de la base de datos o compromiso del bosque entero, sigue siendo función del mismo AD que puede estar comprometido o destruido. El backup offline es la única red de seguridad real.
  • Requiere forest functional level 2008 R2 mínimo en todo el bosque, obstáculo habitual en entornos legacy.

6. Restauración no autoritativa vs. autoritativa con ntdsutil

6.1. No autoritativa: «ponme al día con el resto»

Una restauración no autoritativa recupera el System State de un DC desde backup, y al arrancar de nuevo ese DC solicita al resto de DC los cambios posteriores (vía replicación normal, con USN — Update Sequence Numbers). Escenario: «este DC tuvo un fallo/corrupción, pero el resto del dominio está sano». Es la opción por defecto de wbadmin start systemstaterecovery.

# En el DC arrancado en DSRM, restaurar el System State desde el backup mas reciente
wbadmin get versions -backupTarget:E:

wbadmin start systemstaterecovery -version:07/01/2026-22:00 -backupTarget:E: -quiet
# Al reiniciar en modo normal, el DC replicara los cambios posteriores del resto de DC

6.2. Autoritativa: «esta es la verdad, que el resto se entere»

Una restauración autoritativa hace lo mismo pero además marca los objetos con un USN artificialmente incrementado vía ntdsutil, de modo que al replicar, su versión gana y se propaga sobrescribiendo el resto de DC. Imprescindible cuando «un cambio erróneo ya se replicó a todo el dominio y hay que revertirlo» — un borrado masivo de OU ya propagado, o (sin Papelera habilitada) recuperar objetos borrados.

# 1. El DC debe estar arrancado en DSRM (ver seccion 3.2)

# 2. Restaurar el System State desde backup (igual que la no autoritativa)
wbadmin start systemstaterecovery -version:07/01/2026-22:00 -backupTarget:E: -quiet

# 3. ANTES de reiniciar en modo normal, marcar como autoritativo el subarbol afectado
ntdsutil
  activate instance ntds
  authoritative restore
    restore subtree "OU=Ventas,DC=empresa,DC=local"
  quit
quit

# 4. Reiniciar en modo normal; este DC replicara SU version (con USN incrementado)
#    hacia el resto de DC, sobrescribiendo la version que tuvieran

Restaurar todo el dominio como autoritativo se hace con restore database en vez de restore subtree: una operación drástica, solo para cuando hay que revertir el dominio completo a un punto en el tiempo — de hecho, es uno de los pasos del propio Forest Recovery (sección 7).

ntdsutil
  activate instance ntds
  authoritative restore
    restore database
  quit
quit

6.3. Tabla comparativa rápida

No autoritativa Autoritativa
Qué resuelve Un DC concreto está corrupto/caído; el resto del dominio está bien Un cambio erróneo ya se replicó a todo el dominio y hay que revertirlo globalmente
Comportamiento tras restaurar El DC «se pone al día» recibiendo cambios posteriores del resto El DC «impone» su versión al resto vía USN incrementado artificialmente
Comando clave wbadmin start systemstaterecovery (sin pasos adicionales) wbadmin start systemstaterecovery + ntdsutil authoritative restore
Riesgo si se usa mal Bajo — es el comportamiento por defecto y esperado Alto — puede sobrescribir cambios legítimos posteriores al backup en todo el dominio

7. Forest Recovery: reconstruir un bosque comprometido desde cero

Cuando el ransomware ha cifrado los DC, o confirmas que un atacante tuvo Enterprise Admins/Domain Admins el tiempo suficiente como para no garantizar la integridad de ningún objeto del bosque, restaurar «un DC aquí y otro allá» no basta. Microsoft documenta un procedimiento formal para esto, la Active Directory Forest Recovery Guide. Idea central: reconstruyes a partir de un único punto de verdad por dominio (un backup restaurado), descartas todo lo demás, y reconstruyes el resto sobre esa base ya limpia.

7.1. Fase 0 — Aislamiento inmediato

  • Desconecta de la red todos los DC y, si es posible, toda la infraestructura del bosque, para detener el cifrado en curso y cualquier C2.
  • No apagues los DC que sigan funcionando sin necesidad — son evidencia forense y candidatos a base de restauración. Tampoco los reconectes a producción.
  • Activa el plan de respuesta a incidentes: notifica a dirección/legal y evalúa la notificación regulatoria (sección 9).
  • Preserva copias forenses de al menos un DC antes de tocar nada — necesarias para la contención y la notificación a la AEPD.

7.2. Fase 1 — Restaurar un DC por cada dominio del bosque

Para cada dominio se elige el backup de System State más reciente y fiable (idealmente de antes de la ventana estimada de compromiso — un backup posterior restaura también la persistencia del atacante), y se restaura en un entorno de red aislado (sin conectividad a producción ni a Internet).

# En cada DC seleccionado como "semilla" de su dominio, en RED AISLADA:
# 1. Arrancar en DSRM
bcdedit /set safeboot dsrepair
shutdown /r /t 0

# 2. Restaurar el System State del backup pre-compromiso
wbadmin start systemstaterecovery -version:<FECHA-PRE-COMPROMISO> -backupTarget:E: -quiet

# 3. Volver a arranque normal, TODAVIA sin red de produccion
bcdedit /deletevalue safeboot
shutdown /r /t 0

Este primer DC restaurado de cada dominio es el «DC ancla»: la única fuente de verdad para reconstruirlo. Se le aplican de inmediato los pasos de la fase 2 (metadatos, krbtgt) antes de reconectarlo a producción.

7.3. Fase 2 — Limpieza de metadatos de los DC no recuperados

El resto de DC del bosque quedan, para el ancla recién restaurado, como DC «fantasma»: existen en la base de datos pero no van a levantarse (cifrados, destruidos o de confianza dudosa). Hay que eliminar sus referencias con metadata cleanup para evitar errores de replicación y objetos NTDS Settings huérfanos:

ntdsutil
  metadata cleanup
    connections
      connect to server DC-ANCLA
      quit
    select operation target
      list domains
      select domain 0
      list sites
      select site 0
      list servers in site
      select server <NUMERO-DEL-DC-A-ELIMINAR>
      quit
    remove selected server
    quit
  quit

En versiones modernas también puede hacerse con Remove-ADDomainController -ForceRemoval más Remove-ADObject sobre el NTDS Settings residual, pero ntdsutil metadata cleanup sigue siendo el flujo de la guía oficial y el más compatible entre versiones.

7.4. Fase 3 — Doble reseteo de krbtgt (el paso que casi todos hacen mal)

La cuenta krbtgt firma y cifra todos los TGT Kerberos del dominio. Si un atacante alcanzó Domain Admins, asume que extrajo su hash, lo que permite forjar Golden Tickets válidos para cualquier cuenta y privilegio hasta que ese hash cambie. Resetear la contraseña los invalida. Matiz que se pasa por alto: cada cuenta krbtgt conserva las DOS últimas contraseñas (para no romper tickets emitidos justo antes de una rotación, en replicación no instantánea). Por eso un solo reset no basta: un Golden Ticket con el hash «N-1» sigue siendo válido, porque ahora es la «contraseña anterior» que el sistema todavía acepta.

«You must reset the krbtgt account password twice […] because the KDC maintains the last two passwords for the krbtgt account. If you only reset the password once, an attacker with the previous password hash could still forge valid Kerberos tickets using that old password.»

— Microsoft, «AD Forest Recovery – Resetting the krbtgt password», Microsoft Learn.

Microsoft publica un script de referencia (New-KrbtgtKeys.ps1) que automatiza el doble reseteo respetando el replication convergence time entre ambos resets — sin esperar a que el primer cambio se replique a todos los DC, se pueden causar fallos de autenticación generalizados:

# Concepto del doble reset (usar el script oficial New-KrbtgtKeys.ps1 de Microsoft
# para el calculo seguro de tiempos de espera entre resets en entornos multi-DC)

# Reset 1
Set-ADAccountPassword -Identity krbtgt -Reset `
    -NewPassword (ConvertTo-SecureString -AsPlainText "P@ssw0rd-Temporal-Larga-Aleatoria-1!" -Force)

# --- ESPERAR a que este cambio se replique a TODOS los DC del dominio ---
# Verificar convergencia de replicacion antes de continuar:
repadmin /replsummary
repadmin /showrepl * /csv

# Reset 2 (solo tras confirmar replicacion completa del reset 1)
Set-ADAccountPassword -Identity krbtgt -Reset `
    -NewPassword (ConvertTo-SecureString -AsPlainText "P@ssw0rd-Temporal-Larga-Aleatoria-2!" -Force)

# Repetir TODO el proceso para krbtgt_XXXXX de CADA dominio del bosque
# (el dominio raiz del bosque y cada dominio hijo tienen su propia cuenta krbtgt)

En un Forest Recovery completo, el doble reset se hace en el DC ancla, aislado, antes de reconectar nada a producción. En un «compromiso confirmado sin cifrado» (sección 8), se hace en caliente sobre el dominio en producción, con el mismo cuidado respecto a la convergencia de replicación.

7.5. Fase 4 — Reconstrucción del resto de la infraestructura

  1. Verificar el DC ancla: salud con dcdiag /v, integridad de la base de datos, roles FSMO disponibles (capturarlos con ntdsutil roles si el original no es el ancla).
  2. Promocionar nuevos DC limpios desde imágenes de SO nuevas (nunca discos/VM comprometidos).
  3. Reconstruir DNS si los DC alojaban zonas integradas en AD.
  4. Revisar y reconstruir trusts: las confianzas externas dependen de secretos compartidos, conviene resetearlos (netdom trust /resetkeydomain) para que el atacante no conserve vía de vuelta.
  5. Reconectar progresivamente a producción: primero servicios críticos, con monitorización reforzada.
  6. Reincorporar o reconstruir estaciones y servidores miembro: cada endpoint es sospechoso hasta reimaginarlo o verificarlo a fondo si hubo ransomware vía GPO.

8. Respuesta a un compromiso confirmado: checklist post-DA

Cuando confirmas que un atacante alcanzó Domain Admins/Enterprise Admins —incluso sin ransomware ni destrucción—, la premisa correcta es: asume que todo lo que ese privilegio podía tocar, lo tocó. La lista de verificación no es opcional ni parcial.

8.1. Checklist de contención y erradicación

  • Doble reset de krbtgt en cada dominio del bosque (sección 7.4), respetando la convergencia de replicación entre resets.
  • Reset de TODAS las contraseñas privilegiadas: Domain Admins, Enterprise Admins, Schema Admins, administradores locales críticos (rotación inmediata con LAPS), cuentas de servicio elevadas, y el administrador local de cada DC.
  • Revisión de Golden/Silver Ticket: logs Kerberos (Event ID 4768/4769 con TGT de vida anómala, RC4 sin motivo, cuenta inexistente).
  • Búsqueda de DCShadow: un equipo no autorizado registrado temporalmente como DC para inyectar replicación maliciosa. Revisa nTDSDSA en CN=Configuration contra el inventario real.
  • Auditoría de ACL, en especial AdminSDHolder y objetos de alto valor (GPO de raíz/OU de DC): busca ACE no reconocidas.
  • Revisión de delegación (unconstrained, constrained, resource-based) en busca de persistencia añadida.
  • Auditoría de GPO: compara cada GPO contra un inventario/backup previo, buscando scripts o tareas añadidas.
  • Cuentas ocultas o anómalas: userAccountControl manipulado, SIDHistory sospechoso, cuentas de equipo en grupos privilegiados.
  • Certificados de AD CS si hay CA integrada: plantillas que permitan autenticarse como cualquier usuario (ESC1-ESC8).
  • Reset de la contraseña de DSRM de cada DC alcanzable con privilegios locales.
  • Reset de trusts con otros dominios/bosques, como en la fase 4 del Forest Recovery.

8.2. El dilema: ¿limpiar o reconstruir?

La pregunta que toda dirección técnica se hace tras el checklist es: «¿ya está, podemos seguir operando este mismo AD?». La respuesta honesta es que la limpieza nunca puede demostrar un negativo: puedes confirmar que corregiste todo lo que buscaste, pero no que no queda nada que no se te ocurrió buscar. Un atacante con Domain Admin durante un periodo prolongado dispone de un catálogo enorme de mecanismos de persistencia, y basta con que se le escape uno para conservar el control.

Por eso la práctica estándar de respuesta a incidentes graves es: si el acceso fue Domain Admin/Enterprise Admin confirmado y prolongado (no un intento fallido contenido en minutos), la reconstrucción completa vía Forest Recovery es la única opción con garantías reales, aunque sea más costosa que «limpiar y seguir». La decisión es de negocio, sopesando coste/downtime frente al riesgo de un atacante con persistencia no detectada operando indefinidamente en la infraestructura de identidad. En la mayoría de compromisos confirmados de Domain Admin, ese cálculo se resuelve a favor de reconstruir.

8.3. El plan de recuperación: documentado y probado

Nada de lo anterior sirve si la primera vez que se ejecuta es en mitad de un incidente real. Un plan de recuperación de AD debe: (1) estar documentado paso a paso, con rutas de backup, credenciales (en vault, no en el documento) y contactos de escalado; (2) especificar RTO y RPO acordados con el negocio; y (3) probarse periódicamente con un simulacro completo en entorno aislado — restaurar de verdad, limpiar metadatos de verdad, medir cuánto se tarda. Un plan nunca probado tiene alta probabilidad de fallar justo en el paso que nadie ejecutó fuera de la teoría.

9. Aspectos legales: notificación de brecha (RGPD/AEPD)

Si el incidente implicó acceso no autorizado a datos personales (muy probable en un compromiso de AD, que almacena datos de empleados y da acceso indirecto a sistemas con datos de clientes), se activa el RGPD. El artículo 33 exige notificar a la autoridad de control (en España, la AEPD) sin dilación indebida y, de ser posible, en 72 horas desde que se tuvo constancia de la violación, salvo que sea improbable que entrañe riesgo para los afectados; si no se cumple el plazo, hay que justificar la dilación. El artículo 34 exige además comunicar la brecha a los interesados cuando sea probable un alto riesgo (credenciales, datos financieros, categorías especiales).

Implicaciones para el equipo técnico: (1) el reloj de 72 horas corre desde el conocimiento del incidente, no desde el fin de la investigación — la coordinación con legal/DPO empieza en paralelo a la contención técnica; (2) preservar evidencia forense (fase 0, 7.1) es también requisito para documentar ante la AEPD el alcance real; y (3) un compromiso con Domain Admin confirmado debe presumirse, salvo evidencia forense en contra, acceso potencial a cualquier dato alcanzable desde esas credenciales.

10. Laboratorio: habilitar la Papelera de reciclaje y recuperar un objeto borrado

Requisitos: un laboratorio aislado con un Domain Controller Windows Server (2019/2022), módulo ActiveDirectory de RSAT disponible, y permisos de Enterprise Admins en el bosque de laboratorio. No ejecutes este laboratorio contra un dominio de producción.

Paso 1 — Verificar el nivel funcional del bosque

Get-ADForest | Select-Object Name, ForestMode
# Debe ser "Windows2008R2Forest" o superior para poder habilitar la Papelera

Paso 2 — Habilitar la Papelera de reciclaje de AD

Enable-ADOptionalFeature "Recycle Bin Feature" `
    -Scope ForestOrConfigurationSet `
    -Target (Get-ADForest).Name `
    -Confirm:$false

# Confirmar que ha quedado habilitada
Get-ADOptionalFeature -Filter 'Name -like "Recycle Bin*"' | Select-Object Name, EnabledScopes

Paso 3 — Crear un usuario de prueba y un grupo con ese usuario como miembro

$domainDN = (Get-ADDomain).DistinguishedName

New-ADUser -Name "lab-recuperar" -SamAccountName "lab-recuperar" `
    -UserPrincipalName "lab-recuperar@$((Get-ADDomain).DNSRoot)" `
    -Path "CN=Users,$domainDN" -Enabled $true `
    -AccountPassword (Read-Host -AsSecureString "Contrasena temporal segura")

New-ADGroup -Name "Lab-GrupoPrueba" -GroupScope Global -GroupCategory Security -Path "CN=Users,$domainDN"
Add-ADGroupMember -Identity "Lab-GrupoPrueba" -Members "lab-recuperar"

Paso 4 — Borrar el usuario (simulando el error)

Remove-ADUser -Identity "lab-recuperar" -Confirm:$false

Paso 5 — Localizar y restaurar el objeto

# Localizar el objeto borrado
$deleted = Get-ADObject -Filter 'isDeleted -eq $true -and Name -like "lab-recuperar*"' `
    -IncludeDeletedObjects -Properties LastKnownParent
$deleted | Select-Object Name, ObjectClass, LastKnownParent

# Restaurar a su ubicacion original
$deleted | Restore-ADObject

# Verificar que el usuario ha vuelto y sigue perteneciendo al grupo (atributos link-value)
Get-ADUser -Identity "lab-recuperar" -Properties MemberOf | Select-Object Name, MemberOf

Si el paso 5 muestra correctamente Lab-GrupoPrueba dentro de MemberOf, la restauración ha recuperado tanto el objeto como su pertenencia al grupo, confirmando el comportamiento diferencial frente a una restauración autoritativa clásica pre-2008 R2.

11. Errores comunes

  • Guardar los backups de AD dentro del mismo dominio que protegen. El error más grave y frecuente: si la carpeta de backups es accesible con las mismas credenciales de dominio que el atacante ya controla, el ransomware la cifra también. El backup debe estar fuera del dominio, con identidad independiente y al menos una copia offline o inmutable.
  • Resetear krbtgt una sola vez. La cuenta conserva las dos últimas contraseñas; un solo reset deja vivo cualquier Golden Ticket forjado con el hash «anterior al reset».
  • No probar nunca la recuperación. Un backup «completado sin errores» no es lo mismo que un backup restaurable. Solo un simulacro real y periódico lo confirma.
  • Restaurar un backup posterior a la fecha en que el atacante ya tenía privilegios. Si el compromiso inicial fue, por ejemplo, tres semanas antes del cifrado, «el backup de ayer» reintroduce la persistencia junto con los datos.
  • Olvidar el segundo dominio en un bosque multi-dominio. El doble reset de krbtgt, la limpieza de metadatos y la verificación de trusts se repiten por cada dominio, no solo en el raíz.
  • No coordinar con legal/DPO desde el minuto uno. El plazo de 72 horas del RGPD corre desde que se tiene constancia del incidente, no desde que termina la investigación técnica.
  • Confiar en la Papelera de reciclaje como sustituto del backup. Protege borrados individuales, no corrupción, destrucción del bosque o compromiso total.
  • Reconectar sistemas a producción sin verificación intermedia. Reincorporar de golpe servidores y estaciones sin reimaginar/verificar los endpoints sospechosos es vía habitual de reinfección.

12. Ejercicio final integrador

En tu laboratorio de Active Directory (nunca en producción), documenta un escenario completo de principio a fin:

  1. Configura un backup diario de System State con wbadmin enable backup -systemState sobre al menos dos DC, apuntando a una unidad/ruta distinta en cada caso.
  2. Resetea y documenta de forma segura (gestor de contraseñas, no texto plano) la contraseña de DSRM de cada DC, verificando que son distintas.
  3. Simula el escenario de la sección 10 (Papelera de reciclaje) y, en un segundo objeto, una restauración autoritativa de un subárbol con ntdsutil tras restaurar desde backup (sección 6.2).
  4. Redacta, en no más de dos páginas, un plan de Forest Recovery para un bosque ficticio de dos dominios: qué DC sería la «semilla» de cada uno, orden de las fases 0-4 de la sección 7, y comandos concretos por fase.
  5. Ejecuta el doble reset de krbtgt (sección 7.4) en tu laboratorio, documentando el tiempo de espera real entre ambos resets con repadmin /replsummary antes del segundo.
  6. Redacta un checklist de respuesta post-DA (sección 8.1) para un entorno ficticio, y justifica en un párrafo si optarías por «limpiar» o por reconstruir vía Forest Recovery.

Preguntas frecuentes

¿Con la Papelera de reciclaje de AD habilitada, sigue siendo necesario hacer backups de System State?

Sí, sin excepción. La Papelera solo protege frente al borrado accidental de objetos individuales en un AD sano. No protege frente a corrupción, fallo catastrófico de hardware, ransomware que cifra los DC, o un compromiso que obliga a desconfiar de todo el bosque — ahí, el backup (y en el peor caso el Forest Recovery completo) sigue siendo la única vía.

¿Por qué no basta con reinstalar los controladores de dominio comprometidos y promocionarlos de nuevo, sin restaurar ningún backup?

Es válido para un DC sano en un dominio por lo demás intacto, pero no resuelve el bosque comprometido: un DC nuevo y limpio, al replicar con el resto (potencialmente comprometido), hereda los mismos objetos, ACL y persistencia del atacante. Reinstalar un DC solo «limpia» ese servidor, no el directorio que va a replicar hacia él.

¿Cuánto tiempo de espera es seguro entre el primer y el segundo reset de krbtgt?

No hay un número fijo: depende de la topología de replicación. La referencia de Microsoft es esperar a que el cambio converja en todos los DC del dominio, verificado con repadmin /showrepl * /csv o repadmin /replsummary sin errores pendientes, antes del segundo reset. En un único sitio puede ser cuestión de minutos; multi-sitio, horas. New-KrbtgtKeys.ps1 automatiza esa comprobación.

¿Es obligatorio notificar a la AEPD cualquier incidente de seguridad en Active Directory?

No cualquiera: el artículo 33 se activa cuando hay una violación de datos personales con riesgo no improbable para los afectados. Un compromiso con Domain Admin confirmado casi siempre cumple ese umbral. La decisión de notificar corresponde al DPO/legal, pero el equipo técnico debe aportar la valoración cuanto antes, dado el plazo de 72 horas.

¿Se puede automatizar por completo el procedimiento de Forest Recovery con un script?

Microsoft da scripts para partes específicas (como el reset de krbtgt), pero el procedimiento completo no es un único script desatendido: cada fase requiere verificación humana antes de continuar (¿el backup está sano?, ¿la limpieza de metadatos dejó el dominio consistente?, ¿convergió la replicación?). Automatizar pasos individuales reduce errores, pero exige puntos de control manuales entre fases.

«Recovering a forest is a significant undertaking […] This guide describes the recommended approach for recovering an AD DS forest that has become unusable because of a catastrophic failure or malicious compromise, including detailed procedures for restoring domain controllers, cleaning up metadata, and resetting the krbtgt account password twice for every domain in the forest.»

— Microsoft, «Active Directory Forest Recovery Guide», Microsoft Learn (learn.microsoft.com/windows-server/identity/ad-ds/manage/ad-forest-recovery-guide).