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?
17 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.
Yo suelo añadir un bloque de “golden images / rebuild” y otro de verificación forense de persistencia antes de levantar nada: cuentas ocultas, GPOs raras, tareas programadas, servicios y RDP/PSRemoting expuestos, porque Akira suele dejar más puerta trasera que ruido. Y para el cierre, una lección aprendida útil en auditoría es ligar cada acción correctora a un control ISO 27001/27002 y a una evidencia de prueba real de restore, no solo al ticket.
Nosotros estamos usando un cierre de post-mortem en dos capas: una técnica con timeline, IOC, persistencia, cuentas privilegiadas y validación de exfiltración, y otra de gobierno con acciones priorizadas, owner, fecha y evidencia de restauración; así luego encaja muy bien en auditoría y dirección. Si el entorno es salud, yo metería además una revisión específica de ENS y RGPD arts. 33/34 antes de volver a producción, porque la combinación de notificación, impacto asistencial y tiempos de recuperación suele ser donde más se atasca el caso.
Sí, y si buscáis algo operativo yo lo estructuraría como un post-mortem de 72 horas: alcance real, vector inicial, persistencia, lateral movement, impacto en backups y decisión de rebuild, con evidencia de cada punto y cierre de remediación priorizada. En salud me está funcionando añadir una columna de “riesgo residual aceptado” y otra de “control compensatorio” para que dirección entienda qué se puede levantar ya y qué no, y dejar el ejercicio de restauración aislada como prueba recurrente, no como hito único.
Totalmente de acuerdo con el enfoque de 72h; yo además lo cerraría con un “lessons learned” de IAM muy específico: hardening de Tier 0, separación física/lógica del backup y revisión de cuentas de servicio con rotación obligatoria, porque en Akira el error típico es asumir que el restore es el final y no el siguiente punto de entrada. Si queréis una referencia más “auditable”, lo alineo con ISO 27001/27002 en control de copias de seguridad, gestión de privilegios y continuidad, y con ENS para dejar la segregación y la recuperación probadas con evidencia de restore aislado.
En mi experiencia, el checklist falla si no incluye criterios explícitos de go/no-go: IOC y persistencia descartados, Tier 0 reconstruido, credenciales rotadas, restore aislado verificado y monitorización reforzada durante al menos 72 horas. Añadiría una prueba de restauración trimestral con backups inmutables y evidencias firmadas, alineada con ISO 27001 y ENS, incluyendo la recuperación de aplicaciones clínicas prioritarias y no solo de la infraestructura.
Sumado a todo lo dicho, para clientes de salud yo añadiría una verificación de la integridad del software médico específico, que suele ser el gran olvidado en el rebuild y donde Akira a veces deja persistencia en bases de datos SQL. Es fundamental que el post-mortem documente la transición a un esquema de backups inmutables air-gapped lógicamente, alineándolo con el Art. 21 de NIS2 para justificar ante una posible inspección que se han tomado medidas de resiliencia proporcionales al riesgo.
Añadiría al cierre un tabletop con dirección clínica, TI, DPO y proveedor del HIS, validando RTO/RPO reales y el procedimiento de comunicación durante la indisponibilidad; en salud, el impacto asistencial debe gobernar el go/no-go, no solo la ausencia de IOCs. Además, dejaría trazabilidad de la evaluación y notificaciones RGPD de los arts. 33/34 y de los controles de continuidad exigibles bajo ENS/NIS2, con evidencias reutilizables en auditoría.
Inicia sesión para responder y votar.