Recuperación de Active Directory: Rapid Recovery vs Validated Recovery

Problema

Los entornos que dependen de Active Directory (AD) suelen medir la recuperación con RTO (Recovery Time Objective): “tiempo hasta que AD vuelve a estar online”. En un escenario de fallo de infraestructura ese número es útil, pero cuando la causa es una intrusión, volver a levantar los controladores no garantiza que el dominio sea seguro. La diferencia entre “AD está arriba” y “el entorno está confiable” se vuelve crítica: persistencia no erradicada, credenciales comprometidas, tickets de servicio falsificados y relaciones de confianza rotas pueden volver a reactivar la amenaza minutos después de la restauración. El problema real es que muchas organizaciones todavía planifican solo la parte rápida (Rapid Recovery) y relegan la validación a un proceso posterior, lo que genera brechas de seguridad y prolonga el verdadero tiempo de recuperación.

Causa

1. Enfoque exclusivo en RTO – Los equipos de backup suelen medir su éxito con “controlador activo en 30 min”. No consideran que la restauración de objetos críticos (KRBTGT, cuentas de servicio) requiera pasos adicionales.
2. Falta de ownership claro – Cuando el equipo de backup y el de identidad no tienen responsabilidades bien definidas, la fase de validación se pierde o se delega a quien no tiene visibilidad completa.
3. Ausencia de pruebas integrales – Los ejercicios de tabletop rara vez incluyen la rotación de KRBTGT o la revocación de tickets de servicio. Sin pruebas reales, la lista de verificación nunca se valida.
4. Dependencias externas – VPNs, rutas de red, servidores de certificación y relaciones de confianza con dominios externos no se restauran automáticamente con los DCs. Un controlador puede estar online pero aislado.
5. Persistencia de malware – Herramientas como Mimikatz o DCSync pueden haber dejado puertas traseras en cuentas de administrador de dominio; la simple restauración no las elimina.

Solución

Adoptar un marco de “Validated Recovery” que combine la rapidez de la restauración con una fase obligatoria de validación antes de declarar el dominio como operativo. El proceso se divide en tres capas:

1. Preparación y definición de métricas

• RTO sigue siendo útil para la capa de infraestructura: tiempo máximo aceptable para que al menos un DC responda a solicitudes LDAP.
• Introducir TTTR (True Time To Recovery) como métrica de negocio: incluye todas las actividades de saneamiento y validación. Documentar ambos valores en el plan de continuidad.

2. Restauración rápida (Rapid Recovery)

1. Restaurar DCs críticos desde backup verificable (VSS, System State).
2. Re‑establecer la replicación usando repadmin /syncall.
3. Validar conectividad de red (puertos 88, 389, 636, 3268) y que los sitios y subredes estén correctos.

3. Validación y saneamiento (Validated Recovery)

Automatización parcial

Crear un script PowerShell que ejecute los pasos críticos y genere un informe. A continuación, un fragmento esencial:

# Rotar KRBTGT dos veces
Import-Module ActiveDirectory
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "TempPass123!" -Force)
Start-Sleep -Seconds 600
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "TempPass456!" -Force)

# Exportar lista de cuentas con privilegios elevados
Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, SamAccountName | Export-Csv -Path "C:\temp\DA_Members_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

4. Sign‑off y documentación

Una vez completados los pasos, el equipo de identidad firma el “Recovery Validation Report”. El equipo de backup solo firma la parte de infraestructura. Esta separación asegura que ambas áreas asuman la responsabilidad de sus dominios.

Cuándo aplicar esta solución

• Compromiso confirmado: detección de credenciales robadas, actividad de DCSync o indicadores de movimiento lateral.
• Fallo de datacenter con sospecha de intrusión: la restauración de DCs no es suficiente sin validar la cadena de confianza.
• Entornos con alta regulación (PCI‑DSS, HIPAA) donde la auditoría exige evidencia de saneamiento antes de volver a producción.

No es necesario aplicar todo el proceso si el incidente es puramente físico (p.ej., caída de energía sin indicios de ataque). En esos casos, la capa de Validated Recovery puede reducirse a pruebas de replicación y conectividad.

Verificación

1. Ping de controladores desde al menos dos subredes diferentes.
2. repadmin /replsummary – todos los DC deben mostrar “0 % failures”.
3. klist en una estación cliente: tickets deben tener tiempo de vida acorde a la nueva KRBTGT.
4. Revisión de logs de seguridad (Get-WinEvent -LogName Security) para confirmar que no aparecen eventos de autenticación fallida sospechosa después de la validación.
5. Prueba de aplicación crítica (por ejemplo, acceso a SharePoint) para asegurar que la cadena de confianza con servicios externos sigue intacta.

Si cualquiera de estos puntos falla, volver al paso correspondiente de Validated Recovery antes de declarar la recuperación completa.

Notas adicionales

• Minimal Viable Company (MVC): en un escenario de ransomware, considerar arrancar solo los servicios esenciales (DC, DNS, PKI) y dejar el resto fuera hasta que la validación esté completa.
• Tercer‑parte IR: si el equipo interno carece de experiencia en forense de AD, contratar un servicio especializado para la fase de saneamiento puede reducir el TTTR significativamente.
• Documentación viva: mantener la lista de cuentas con privilegios y la topología de trusts en un repositorio versionado; facilita la comparación post‑incidente.
• Backup immutable: usar almacenamiento inmutable (WORM) para los backups de System State garantiza que la restauración no incluya artefactos comprometidos.
• Comunicación: notificar al SOC y a la gerencia del cambio de estado en cada fase (Rapid, Validation, Sign‑off) evita malentendidos sobre el “estado operativo”.