Un ransomware o una brecha no avisa. Lo que decides en las primeras horas -- antes de que llegue cualquier consultor externo -- determina si el incidente termina siendo un evento contenido de un día o una crisis de semanas. Esta es la secuencia real que sigue un equipo de respuesta, explicada para quien tiene que decidir, no solo para quien ejecuta los comandos.
Fase 1: Confirmar antes de reaccionar
El primer error común es actuar sobre una sospecha sin confirmarla. Antes de aislar servidores o apagar sistemas, alguien técnico necesita verificar señales reales: archivos con extensiones nuevas, notas de rescate, procesos que no deberían existir, alertas del antivirus/EDR que coinciden en el tiempo. En paralelo se empieza a preservar evidencia -- memoria RAM y conexiones de red activas se pierden apenas se reinicia un equipo, así que ese orden importa: primero capturar, después limpiar.
Fase 2: Contener sin apagar todo
Contener significa cortar la propagación, no apagar el sistema. Aislar de la red (sacar el cable, bloquear el puerto, sacar la VM del balanceador) preserva evidencia que un apagado destruye. Esta fase también incluye decisiones que solo el negocio puede tomar: qué cuentas deshabilitar, qué sistemas se pueden aislar sin frenar operaciones críticas, y desde cuándo cada minuto de contención retrasada es un minuto más de exposición.
Fase 3: Erradicar con evidencia ya resguardada
Recién con la evidencia preservada tiene sentido eliminar el malware, cerrar los puntos de persistencia y cambiar credenciales. Para un ransomware con cifrado avanzado, la recomendación técnica suele ser reconstruir el sistema desde una imagen limpia en vez de "limpiarlo" -- confiar en que quedó sano es la forma más común de tener una reinfección semanas después.
Fase 4: Recuperar y vigilar 30 días
La restauración desde respaldo tiene un orden: primero la infraestructura crítica (directorio activo, autenticación), después los sistemas de negocio, al final las estaciones de trabajo. Ningún respaldo se restaura sin antes verificar que no esté comprometido también. Y la vigilancia no termina cuando todo vuelve a funcionar -- el período de mayor riesgo de reinfección son las semanas siguientes, mientras el atacante todavía puede tener otro punto de entrada sin detectar.
Fase 5: La reunión que casi nadie hace bien
Después de resuelto el incidente, la pregunta que importa no es "qué pasó" sino "por qué fue posible" -- un análisis de causa raíz real, no una lista de síntomas. Si el vector de entrada fue un RDP expuesto con una contraseña débil, la lección no es "cambiar esa contraseña": es preguntarse qué otro proceso permitió que existiera un acceso administrativo expuesto a internet sin MFA durante meses. Esa pregunta es, en el fondo, la misma que responde un pentest hecho antes del incidente.
Comunicación: la parte que decide cómo se recuerda el incidente
Un cliente o directorio no necesita jerga técnica en medio de una crisis -- necesita saber qué se sabe con certeza (no hipótesis), qué se hizo con hora exacta, y qué decisión se les pide a ellos. Actualizar cada 2-4 horas durante la fase activa, aunque el avance sea parcial, evita el peor escenario de comunicación: que el cliente se entere de algo grave por otro canal antes que por el equipo que está respondiendo.
La forma más barata de vivir esto es no vivirlo por primera vez en medio de una crisis real. Un pentest o una evaluación de exposición antes del incidente encuentra el mismo tipo de puerta de entrada que un atacante real explota, con la diferencia de que todavía hay tiempo de cerrarla.