Las primeras cuatro horas de un incidente
El daño evitable en la mayoría de los incidentes no lo causa el atacante, sino la reacción improvisada de las primeras horas. Cinco errores que vemos repetirse y qué hacer en su lugar.
Cuando nos activan por un incidente, la primera pregunta que hacemos casi nunca es sobre el atacante. Es esta: ¿qué hicieron ustedes en las últimas horas?
La respuesta determina cuánto del caso todavía se puede reconstruir. En la mayoría de los incidentes que atendemos, el daño que resultó imposible de reparar no fue obra del adversario — fue consecuencia de decisiones bienintencionadas tomadas en las primeras cuatro horas, antes de que alguien con experiencia forense entrara a la conversación.
Estos son los cinco errores que más se repiten.
1. Apagar el servidor comprometido
Es el reflejo natural: hay algo malo corriendo, se corta la energía. El problema es que la memoria RAM contiene la mejor evidencia disponible — procesos en ejecución, conexiones activas, claves de cifrado, código inyectado que nunca tocó el disco — y desaparece por completo al apagar.
Buena parte del malware moderno opera enteramente en memoria precisamente por esto. Apagar el equipo no lo elimina si tiene persistencia; solo destruye la única copia de la evidencia que lo explicaba.
En su lugar: aísle el sistema de la red pero manténgalo encendido. Desconecte el cable de red, mueva el puerto a una VLAN aislada, o bloquéelo en el firewall. El adversario pierde el control; usted conserva la evidencia.
2. Rotar todas las credenciales de inmediato
Rotar credenciales es correcto. Rotarlas antes de conocer el alcance es contraproducente.
Si el adversario mantiene tres mecanismos de persistencia y usted rota las contraseñas que cubren dos de ellos, ha logrado exactamente dos cosas: le avisó que fue detectado, y no lo sacó. Un atacante que se sabe descubierto deja de ser sigiloso — acelera, destruye evidencia y, cada vez más, dispara el cifrado antes de perder el acceso.
En su lugar: determine el alcance primero, luego rote todo de una sola vez, de forma coordinada. Si la exposición es tan severa que hay que rotar ya, hágalo completo — incluidas cuentas de servicio, tokens de API, claves SSH y credenciales en el pipeline de despliegue.
3. Dejar que el antivirus “limpie” y seguir adelante
La consola muestra la amenaza en cuarentena, aparece el visto verde y la sensación es de caso cerrado. Pero la detección le dice qué encontró la herramienta, no cómo entró, desde cuándo estaba, ni qué más hizo mientras tanto.
El malware que se detecta suele ser la parte prescindible de la operación. La cuenta de servicio creada tres semanas antes, la tarea programada que se ejecuta cada domingo y la regla de reenvío en el buzón del director financiero siguen exactamente donde estaban.
En su lugar: preserve la muestra antes de eliminar nada y trate la detección como el inicio de la investigación, no como su conclusión.
4. Comunicarse por los canales comprometidos
Si el adversario tiene acceso a su entorno, es razonable asumir que lee el correo corporativo y el chat interno. Hemos visto operaciones donde el atacante siguió la respuesta en tiempo real desde el mismo hilo de Teams donde se coordinaba — y ajustó su comportamiento en consecuencia.
En su lugar: mueva la coordinación a un canal fuera de banda desde el primer minuto. Un grupo en teléfonos personales, una cuenta de correo en otro dominio, una llamada. Acuerde cuál es antes de necesitarlo; improvisarlo durante la crisis toma horas que no tiene.
5. Restaurar el respaldo sobre la misma vulnerabilidad
Restaurar es urgente y comprensible. Pero si el respaldo se restaura sobre la misma versión sin parchar del mismo servicio expuesto, la reinfección llega en días. Ya la vimos ocurrir dos veces en el mismo caso.
Además: si el respaldo se tomó después del acceso inicial, el respaldo también contiene la persistencia.
En su lugar: identifique el vector de entrada y la fecha del primer acceso antes de restaurar. Restaure a un entorno endurecido, con el vector cerrado y monitoreo reforzado sobre los sistemas afectados.
Lo que sí conviene hacer en la primera hora
- Aísle sin apagar los sistemas afectados.
- Preserve los registros ahora — muchos rotan en días y son irrecuperables después.
- Anote la línea de tiempo de lo que ya hizo su equipo. Cada acción de respuesta deja artefactos que un analista puede confundir con actividad del atacante.
- Abra un canal fuera de banda.
- Llame a quien vaya a responder. Una llamada de veinte minutos antes de tocar nada suele valer más que las siguientes ocho horas de trabajo.
El patrón de fondo
Ninguno de estos errores viene de negligencia. Vienen de que la respuesta a incidentes es contraintuitiva bajo presión: los instintos correctos para un problema operativo normal — restaurar el servicio, limpiar la infección, cambiar las claves — son casi todos incorrectos cuando hay un adversario activo.
Por eso el plan se escribe antes, y por eso se prueba en un ejercicio de mesa. No para tener el documento, sino para que las decisiones difíciles ya estén tomadas cuando el reloj corra.