Cliente del sector salud, ransomware Akira, backups en el mismo dominio AD = también encriptados. Reconstrucción desde 0 con datos de hace 21 días. Lecciones: backups offline AHORA, segmentación AD, MFA en consolas. Pregunto: ¿alguien tiene checklist post-mortem que esté usando en producción?
10 respuestas
Te paso por DM nuestro runbook post-incidente. Lo importante: regla 3-2-1-1 (la cuarta es offline air-gapped). Y dominio AD aparte para tier 0.
Akira ataca también consolas Veeam. Si tenías Veeam en mismo dominio, mala suerte. Recomienda Veeam Hardened Linux Repository.
Pasamos por algo similar el año pasado. Mejor inversión post-incident: PAM + segmentación tier 0. Reduce blast radius en 80%.
Cierre del caso por si ayuda a alguien: recuperamos de la copia air-gapped semanal, perdimos 4 días de datos. Lección: la inmutabilidad no es opcional. Pasamos todo a repos inmutables con retención bloqueada.
Buen cierre. Añado: probad la restauración de verdad, no solo que el backup existe. El 90% descubre en el incidente que su restore tarda semanas.
Sí, y añadiría dos cosas al checklist: validación periódica de restores con RTO/RPO medidos de verdad, y revisión de cuentas de servicio/credenciales privilegiadas porque Akira suele pivotar por ahí más que por el propio backup. En salud, además, merece la pena documentar el post-mortem con evidencias para cumplimiento y notificación: RGPD arts. 33 y 34 si hay brecha de datos, y si aplica NIS2/DORA, dejar trazabilidad de medidas correctoras y pruebas de eficacia.
Nosotros estamos usando un post-mortem bastante “operativo”: timeline del compromiso, vector inicial, identidades/credenciales afectadas, alcance de cifrado, validación de exfiltración, y una matriz RTO/RPO real por servicio con evidencia de restore test. Si el cliente es salud, yo añadiría desde ya segregación de backup fuera del dominio, MFA en toda consola de administración y revisión de cuentas de servicio con privilegios, porque si no el siguiente Akira te repite el mismo patrón en 12 meses.
Coincido con lo de la matriz RTO/RPO, pero yo en el post-mortem meto también un apartado de “controles fallidos” mapeado a ISO 27001/27002 y a las causas raíz, porque ayuda mucho a justificar el plan de remediación ante dirección y auditoría. Si queréis algo práctico, lo que mejor me está funcionando es cerrar el informe con 10 acciones priorizadas, owner y fecha, y una prueba de restauración mensual de un sistema crítico aislado del AD para evitar que el backup “viva” del mismo fallo que el primario.
Muy buena la matriz de Jaime, pero no olvidéis que en salud el ENS suele marcar el paso: si es categoría Media o Alta, la segregación del backup no es solo recomendación, es exigencia normativa clara. Yo añadiría al post-mortem una auditoría profunda de GPOs y objetos del AD antes de reconectar el entorno, porque si no limpiáis bien la persistencia que deja Akira, os volverán a cifrar el restore en cuanto os deis la vuelta.
En post-mortem yo suelo cerrar con un bloque específico de “rebuild seguro” antes de volver a producción: limpieza de persistencia en AD, rotación completa de credenciales privilegiadas y de servicio, y validación de que el backup ya no comparte trust ni rutas de administración con el primario. En salud, además, dejaría trazado el análisis de exfiltración y la decisión de notificación bajo RGPD arts. 33/34, porque luego en dirección lo que más pesa es demostrar diligencia y que las medidas correctoras están fechadas y probadas.
Inicia sesión para responder y votar.