Post-mortem: ransomware contenido en cuatro segundos.

Hay incidentes que se cuentan por horas y otros por segundos. Este es de los segundos. Lo escribimos como recordatorio interno y como ejemplo público — anonimizado — de qué pinta tiene una contención automatizada cuando todas las piezas están en su sitio. Se quedaron fuera detalles sensibles del cliente; lo importante de la reconstrucción está.

Resumen ejecutivo en una frase

Ransomware comercial llegó vía macro-Excel, lanzó vssadmin delete shadows a los 2 segundos, fue aislado a los 4, y nunca llegó a cifrar un solo fichero más allá de los del propio host.

Lo que sigue es la reconstrucción. La cuenta atrás empieza con T+0s en el momento en que el usuario hace doble-click sobre el adjunto.

T+0s · El vector

Email externo, dirigido a una cuenta de finanzas, con un Excel adjunto que se hacía pasar por una factura pendiente. SPF, DKIM y DMARC: todos pasan, porque el dominio remitente había sido comprometido — un proveedor real del cliente. Esto importa: los filtros perimetrales no fallaron, simplemente no había nada perimetral que fallara.

El usuario, formado, abrió el adjunto y le dio a Habilitar contenido porque el correo encajaba perfectamente con un proceso interno conocido. Aquí, el reflejo de muchos blue teams es echar la culpa al usuario; no nos parece útil. La culpa la tiene el modelo de defensa que asume que el humano va a leer 200 emails al día y nunca dudar.

T+1s · La detonación

La macro lanzó un cmd.exe que invocó powershell.exe con argumentos codificados en base64. Comportamiento clásico de stage-1. Tres procesos en cadena: EXCEL.EXE → cmd.exe → powershell.exe. La regla de detección por comportamiento del EDR del cliente — desplegada por Cibrax tres semanas antes — se disparó en T+1s. La regla, en pseudo-código:

process_create where
    parent_image == "EXCEL.EXE"
    AND grandchild_image in ("powershell.exe", "wscript.exe", "mshta.exe")
    AND command_line contains_any ("-Enc", "-EncodedCommand", "FromBase64String")

No es complicada. Es una de las primeras reglas que escribimos en cualquier despliegue. Lo importante no es la regla; es lo que sucede cuando se dispara.

T+2s · El daño que sí ocurrió

Antes del aislamiento, el stage-1 ya había hecho dos cosas. La primera: vssadmin.exe delete shadows /all /quiet. Esto destruye copias de sombra locales — un clásico previo al cifrado. La segunda: una conexión saliente al C2 para descargar el stage-2 (el binario de cifrado real). El primer comando se ejecutó. El segundo no llegó a completarse.

T+3s · La decisión automática

La regla del paso anterior tiene un response action asociado: si el host es de tipo "endpoint usuario" y la cadena de procesos coincide, aislar el host de la red inmediatamente (excepto para el agente del propio EDR, que mantiene comunicación con la consola). Sin ticket. Sin esperar a un analista. Sin "vamos a verificar primero".

Aquí es donde mucha gente se pone nerviosa: ¿y si es falso positivo? Es legítimo preocuparse, pero en este caso concreto la regla tiene un falso positivo histórico de cero en 14.000 endpoints durante un año. Algunas reglas se ganan el derecho a actuar solas; otras no. La diferencia la hace el tuning, no la categoría.

T+4s · Contención y trazabilidad

El host estaba aislado. La consola del EDR había levantado un caso, capturado el árbol de procesos completo, congelado los binarios involucrados, y notificado al canal del cliente con un mensaje claro: «FIN-WS-04 aislado · stage-1 ransomware · acción automática». El analista de guardia recibió la notificación y, en lugar de tener que correr a contener, llegó al teclado para investigar. Esa es la diferencia que importa.

Las primeras 24 horas: persecución

Una vez contenido el host, empezó la parte que Cibrax llama caza forense: asumir que el atacante puede haber tocado más de lo que vimos y comprobarlo activamente.

• Buzones: rastreo del email original a otros destinatarios internos. Cuatro más lo recibieron, ninguno abrió el adjunto.
• Identidad: revisión de logons del usuario. La cuenta no había sido usada para autenticar en otros hosts, lo que confirmaba que el ataque no había escalado.
• Red: tráfico saliente del host previo al aislamiento. Tres intentos de conexión al C2, todos fallidos por el aislamiento.
• Endpoint: el host se reimaginó desde cero. No se "limpió". Los hosts comprometidos no se limpian.

Lo que cambió después del incidente

Un buen post-mortem deja tras de sí no solo aprendizajes, sino cambios concretos. En este caso:

1. Tres reglas nuevas en el SIEM, derivadas de TTPs específicos del actor. Cubren vssadmin delete, descarga de PowerShell desde dominios recién registrados y uso de regsvr32 con URL como argumento.
2. Política de macros de Office endurecida: bloqueo total de macros desde Internet, incluyendo documentos descargados de SharePoint del cliente que provengan de invitados externos.
3. Incorporación del proveedor comprometido al programa de third-party threat intel. Pequeño, pero importante.

Lo que NO funcionó (y por qué lo cuento)

El antivirus tradicional, instalado en paralelo al EDR, no detectó nada. Ni el adjunto, ni la macro, ni el stage-1. Lo cuento porque sigue habiendo organizaciones que confían en AV de firma como capa de detección. El AV de firma sigue teniendo sitio (cumplimiento, capa básica), pero no como detección primaria. Si tu plan de respuesta empieza por «esperamos que el AV vea esto», tu plan ya falló antes de empezar.