Redactar y ensayar un plan de recuperación del bosque de AD

La recuperación del bosque es el procedimiento que nadie quiere ejecutar, y por eso la mayoría de las organizaciones nunca lo han ejecutado. Es el último recurso cuando ya no se puede confiar en el propio Active Directory: DC cifrados por ransomware, un cambio destructivo en todo el bosque o un compromiso tan profundo que no se puede declarar limpio ningún DC. La Active Directory Forest Recovery Guide de Microsoft describe el procedimiento en detalle. Leerla durante un incidente, con el negocio parado y la dirección en la sala de crisis, es el peor momento para descubrir que sus contraseñas de DSRM están en un almacén que se autentica contra AD.

Esta guía convierte el procedimiento de Microsoft en un runbook propio, adaptado a su bosque, y en un programa de ensayos que demuestra que funciona. Da por hecho que existen las copias de seguridad descritas en la protección de las copias de seguridad de AD frente al ransomware, y profundiza más que la visión general del pilar de evaluación, copia de seguridad y recuperación.

Medir: lo que el plan debe saber

Un plan de recuperación es, sobre todo, inventario. Recopile y guarde sin conexión, en papel y en soportes cifrados fuera de AD:

• Topología del bosque: todos los dominios, sus DC, sus sitios, direcciones IP y versiones del sistema operativo, y qué DC tienen roles FSMO y el catálogo global.
• Mapa de copias de seguridad: para cada dominio, de qué DC se hace copia, en qué formato, dónde reside la copia inmutable y cómo llegar a ella sin AD.
• Credenciales: contraseñas de DSRM de los DC con copia de seguridad, cuentas de emergencia para los hipervisores, el almacenamiento y las consolas de copias de seguridad que no dependan de AD, y el procedimiento del almacén sin conexión.
• Dependencias: DNS, DHCP, AD CS, Entra Connect, AD FS, PAM y el orden en que deben volver las aplicaciones.
• Personas: responsables nominales de cada fase, con suplentes, y una comunicación fuera de banda que no dependa de Exchange ni de Teams con inicio de sesión a través del AD comprometido.

# Instantánea de la topología para imprimir y guardar junto al plan
Get-ADForest | Select-Object Name, ForestMode, SchemaMaster, DomainNamingMaster, Domains, GlobalCatalogs
Get-ADDomain | Select-Object DNSRoot, DomainMode, PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, OperatingSystem, IsGlobalCatalog, OperationMasterRoles
(Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties tombstoneLifetime).tombstoneLifetime

Un tombstoneLifetime vacío significa el antiguo valor predeterminado de 60 días de los bosques creados antes de Windows Server 2003 SP1. Los bosques creados después tienen un valor predeterminado de 180 días.

Decidir: ¿es esto una recuperación del bosque?

Incluya los criterios de decisión en el plan para que el responsable del incidente no tenga que improvisar:

Decida también qué copia de seguridad está limpia. Si el atacante ha permanecido mucho tiempo, la copia más reciente puede contener persistencia: administradores fraudulentos, AdminSDHolder modificado, historial de SID, GPO maliciosas, claves que permiten golden tickets. El plan debe indicar quién toma esa decisión y con qué evidencia, normalmente cronologías forenses procedentes de su canalización de reenvío de eventos.

El procedimiento de recuperación

El orden siguiente sigue la guía de Microsoft. Mantenga su runbook alineado con la versión vigente de esa guía, no con este resumen.

1. Construir la sala limpia

Construya una red aislada sin ruta hacia producción, con hipervisor o hardware limpios, medios de instalación limpios verificados por hash y estaciones de trabajo de administración creadas a partir de imágenes de confianza. Todo lo que sigue ocurre aquí. El bosque restaurado solo se une a producción cuando usted decide que está limpio.

2. Restaurar el primer DC grabable del dominio raíz del bosque

Restaure un DC grabable, preferiblemente uno que fuera catálogo global y servidor DNS, a partir de la copia de seguridad elegida. Si se puede reutilizar el servidor o la VM del DC original, arránquelo en DSRM y restaure el estado del sistema como se indica a continuación. Si ya no existe, haga primero una recuperación completa (bare-metal) desde una copia de seguridad completa del servidor en hardware aislado y continúe después desde DSRM.

# En el DC que se va a restaurar, reiniciar en DSRM
bcdedit /set safeboot dsrepair
shutdown /r /t 0

# Tras iniciar sesión con la cuenta de DSRM
wbadmin get versions -backupTarget:E:
wbadmin start systemstaterecovery -version:09/20/2026-02:00 -backupTarget:E: -authsysvol -quiet

Se trata de una restauración no autoritativa de AD DS con una restauración autoritativa de SYSVOL. El modificador -authsysvol marca el SYSVOL de este DC como la copia principal. Si el método de restauración no admite ese modificador, establezca msDFSR-Options en 1 en CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<DC>,OU=Domain Controllers,<domain DN> antes de reiniciar.

Antes de salir de DSRM, evite que el DC espere a asociados de replicación que ya no existen:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' `
  -Name 'Repl Perform Initial Synchronizations' -Value 0 -Type DWord
bcdedit /deletevalue safeboot

3. Tomar el control del dominio

Una vez que el DC esté en modo normal, con el DNS apuntando a sí mismo:

• Asuma a la fuerza todos los roles FSMO que tengan los DC que no se vayan a recuperar:

Move-ADDirectoryServerOperationMasterRole -Identity 'DC01' `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force

• Limpieza de metadatos de todos los demás DC del dominio. En las versiones actuales de Windows Server, eliminar el objeto de equipo del DC en Usuarios y equipos de Active Directory, o su objeto de servidor en Sitios y servicios de Active Directory, realiza la limpieza, con la limpieza de metadatos de ntdsutil como alternativa. Elimine también sus registros DNS y cualquier registro NS y delegación que apunte a ellos.
• Aumente el grupo de RID en 100 000 en el objeto RID Manager (rIDAvailablePool en CN=RID Manager$,CN=System) e invalide el grupo de RID actual en el DC restaurado. Ambos pasos evitan SID duplicados en los objetos creados después de la copia de seguridad.
• Restablezca la contraseña de la cuenta de equipo del DC restaurado y restablezca cada lado de cada confianza (netdom trust ... /resetOneSide) una vez recuperado el dominio asociado.

4. Restablecer las credenciales

• Restablezca la contraseña de krbtgt dos veces. Con un solo DC no hay replicación que esperar, pero deje que el primer restablecimiento termine antes del segundo. Esto invalida todos los tickets firmados con las claves antiguas. El mecanismo se explica en la rotación de la contraseña de krbtgt.
• Restablezca la contraseña del Administrator integrado y de todas las cuentas de Tier 0, y deshabilite cualquier cuenta de la que no pueda responder.
• Planifique el restablecimiento de todas las contraseñas de usuario, las contraseñas de las cuentas de servicio y las claves de las gMSA si la copia de seguridad pudo ser robada. La copia contiene todos los hashes tal como estaban en el momento de la copia.

5. Recuperar los demás dominios y reconstruir

Repita los pasos 2 a 4 con un DC grabable de cada dominio, de arriba abajo a partir de la raíz del bosque. Una vez operativa la raíz, los dominios pueden recuperarse en paralelo. Siga los pasos de la guía relativos al catálogo global para su topología, porque los usuarios no pueden iniciar sesión hasta que haya un GC disponible. Después, promueva DC nuevos desde medios limpios. No restaure más copias de seguridad. Vuelva a conectar los sitios y la replicación de forma gradual, vigilando una posible reinfección.

6. Limpiar antes de volver a conectar

Elimine la persistencia encontrada por el equipo forense, vuelva a ejecutar una evaluación con PingCastle y una revisión de ACL, y verifique la pertenencia a los grupos privilegiados antes de que cualquier tráfico de producción llegue al bosque recuperado.

Verificar

Cada punto de control de la recuperación necesita una prueba objetiva:

dcdiag /v /c /e /f:C:\Recovery\dcdiag.txt
repadmin /replsummary
repadmin /showrepl * /csv > C:\Recovery\showrepl.csv
Get-ADDomainController -Filter * | Select-Object HostName, OperationMasterRoles, IsGlobalCatalog

# SYSVOL: 4602 = SYSVOL autoritativo inicializado en el primer DC; 4604 = sincronización no autoritativa completada en los DC nuevos
Get-WinEvent -FilterHashtable @{ LogName = 'DFS Replication'; Id = 4602, 4604, 4614 } -MaxEvents 10
Get-SmbShare | Where-Object Name -in 'SYSVOL','NETLOGON'

Un DC con 4614 pero sin 4604 sigue esperando la replicación inicial de SYSVOL y no compartirá SYSVOL. Eso suele significar que el SYSVOL del primer DC nunca se marcó como autoritativo.

Ensayar

• Ejercicio de mesa, dos veces al año. Recorra el runbook con todos los responsables nominales. Compruebe que cada credencial y cada número de teléfono están donde el plan dice que están, y que ningún paso depende sin que nadie lo sepa de AD, del correo electrónico o del SSO.
• Simulacro técnico, cada año. Restaure copias de seguridad reales desde la copia inmutable en un laboratorio aislado y ejecute el runbook hasta obtener un bosque operativo con DC nuevos. Cronometre cada fase.
• Actualizar después de cada simulacro. Cada simulacro produce correcciones: controladores que faltan, contraseñas de DSRM incorrectas, ubicaciones de FSMO no documentadas, scripts que suponían una compilación concreta del sistema operativo. Las herramientas comerciales de recuperación del bosque (Semperis ADFR, Quest Recovery Manager for AD) pueden automatizar buena parte de esto, pero necesitan el mismo ensayo.

Qué se rompe

• Pérdida de datos hasta el punto de la copia. Todos los cambios posteriores a la copia elegida desaparecen: usuarios nuevos, cambios de contraseña, cambios de grupos, equipos unidos al dominio. Los equipos unidos o cuyas claves se renovaron desde entonces pueden perder su canal seguro y necesitar Test-ComputerSecureChannel -Repair o volver a unirse.
• Kerberos y sesiones. Restablecer krbtgt dos veces invalida todos los tickets. Todos los usuarios y servicios vuelven a autenticarse, y puede que haya que reiniciar los servicios de larga duración.
• Identidad híbrida. Entra Connect ve el directorio restaurado como un gran conjunto de cambios. Prepare el servidor de sincronización en modo de ensayo (staging), revise las exportaciones pendientes y vigile el umbral de eliminaciones accidentales.
• Riesgo de los simulacros. Un DC restaurado conectado por error a producción reintroduce contraseñas antiguas y objetos persistentes (lingering objects). Aísle el laboratorio física o lógicamente y compruébelo antes de cada simulacro.
• Tiempo. Una recuperación realista de un bosque con varios dominios lleva días, no horas. En su plan de continuidad de negocio deben figurar los tiempos de los simulacros, no RTO ilusorios.

Lecturas relacionadas: proteger las copias de seguridad de AD frente al ransomware garantiza que exista una copia limpia, definir Tier 0 enumera todo lo que debe volver con el bosque, y el área de evaluación, copia de seguridad y recuperación reúne toda la serie.