Cómo se investiga realmente un incidente de ransomware (paso a paso)

El pánico es el primer enemigo de una buena respuesta

Cuando se detectan los primeros indicios de un ataque de ransomware —archivos cifrados, extensiones extrañas, una nota de rescate en el escritorio—, la reacción instintiva es entrar en pánico y empezar a tomar decisiones apresuradas: desconectar equipos al azar, apagar servidores sin criterio, o intentar restaurar copias de seguridad sin haber contenido primero el ataque. Cada una de estas reacciones instintivas puede empeorar la situación o destruir evidencia necesaria para entender qué ha ocurrido.

La secuencia real de una investigación bien gestionada

1. Detección y confirmación inicial

Verificar que efectivamente se trata de un incidente de ransomware, identificando el alcance aparente inicial: qué sistemas muestran signos de cifrado, desde cuándo.

2. Activación del plan de respuesta a incidentes

Convocar al equipo de respuesta definido de antemano, no improvisado en el momento, y establecer un canal de comunicación que no dependa de los sistemas potencialmente comprometidos (el correo corporativo puede estar comprometido).

3. Contención

Aislar los sistemas afectados de la red, sin apagarlos de forma abrupta si es posible evitarlo, dado que apagar un sistema puede destruir evidencia volátil en memoria útil para la investigación posterior.

4. Preservación de evidencia

Antes de cualquier acción de limpieza o restauración, capturar evidencia forense de los sistemas afectados: imágenes de disco, volcados de memoria, registros de red, que permitirán entender el vector de entrada y el alcance real del compromiso.

5. Investigación del alcance y el vector de entrada

Determinar cómo entró el atacante, qué sistemas ha tocado, si ha exfiltrado datos antes de cifrar (habitual en la mayoría de campañas actuales) y desde cuándo tenía acceso a la red, que puede ser semanas antes del momento del cifrado visible.

6. Erradicación

Eliminar la presencia del atacante de todos los sistemas afectados, no solo de los que muestran síntomas visibles, incluyendo cualquier mecanismo de persistencia que pueda haber dejado.

7. Recuperación

Restaurar sistemas desde copias de seguridad verificadas como limpias, con una vigilancia reforzada durante el proceso para detectar cualquier señal de que el atacante conserva acceso.

8. Análisis post-incidente y lecciones aprendidas

Documentar qué ocurrió, qué funcionó bien, qué no, y qué medidas se implementarán para reducir el riesgo de que se repita.

Decisiones que no se pueden improvisar en el momento

• Si se notifica o no a las autoridades (AEPD si hay datos personales afectados, CCN-CERT si aplica el ENS), y en qué plazo, es una decisión que debe estar clara de antemano, no improvisada bajo presión.
• Si se contrata apoyo forense externo especializado, especialmente si el equipo interno no tiene experiencia previa gestionando este tipo de incidentes.
• Si se paga o no el rescate, una decisión con implicaciones legales, éticas y prácticas que idealmente debería tener una postura definida de antemano por parte de la dirección, no decidida en caliente durante la crisis.

La diferencia entre un incidente grave y uno catastrófico

Rara vez es el ataque en sí lo que determina si un incidente se convierte en catastrófico para la organización: es la calidad de la respuesta durante las primeras horas y días. Un plan de respuesta a incidentes ensayado previamente, con roles claros y decisiones ya tomadas de antemano sobre los aspectos más críticos, es lo que separa una crisis gestionada de una crisis que se descontrola.