Respuesta ante incidentes: qué hacer (y qué no) cuando te hackean

Introducción al Problema#

"Nos hackearon" es una frase que paraliza. Y en esa parálisis, o en la reacción improvisada que le sigue, muchas empresas cometen los errores que transforman un incidente recuperable en una catástrofe total.

La realidad es que un incidente de seguridad — ya sea un ransomware, una filtración de datos, o un acceso no autorizado — no se diferencia tanto de otros tipos de emergencia empresarial. Un incendio, una inundación, un corte de suministro. La diferencia es que tenemos protocolos claros para esos casos (plan de evacuación, seguro, proveedores de respaldo) y casi nunca tenemos un plan equivalente para los incidentes digitales.

El NIST SP 800-61 (el estándar del Instituto Nacional de Estándares y Tecnología de EE.UU. para respuesta a incidentes) establece un proceso en 6 fases que, seguido correctamente, permite a las empresas contener el daño, preservar la evidencia, recuperarse, y aprender para no volver a pasar por lo mismo. No requiere un equipo de seguridad de 20 personas: requiere un plan conocido y ensayado.

En este artículo recorremos cada fase con ejemplos concretos de qué hacer, qué no hacer, y las decisiones que marcan la diferencia entre recuperarse en días o en semanas.

Caso Real o Ejemplo Cotidiano#

Era un lunes a las 7:30 de la mañana. El gerente de sistemas de una empresa logística llegó a la oficina y encontró todos los monitores mostrando el mismo mensaje: "Tus archivos fueron cifrados. Pagá 5 BTC para recuperarlos." Era ransomware.

Su primera reacción, comprensible pero catastrófica, fue apagar todo inmediatamente. Todos los servidores, todos los equipos, todo. "Necesitamos detenerlo antes de que se siga expandiendo", pensó.

El problema fue múltiple:

Primero, el ransomware ya había terminado su trabajo — apagar los equipos no detuvo nada porque el cifrado ya estaba completo. Segundo, al apagar los servidores sin preservar la memoria RAM (donde viven los procesos activos, las conexiones de red activas, y a veces hasta las claves de cifrado usadas por el ransomware), destruyeron la evidencia forense más valiosa. Tercero, al apagar sin un procedimiento de shutdown correcto, corrompieron algunos archivos de sistema que después dificultaron la recuperación.

Y el cuarto error, el peor: dos servidores de backup estaban conectados en red y también fueron cifrados por el ransomware durante los días previos, antes de que nadie se diera cuenta del ataque. Al apagar todo en pánico, nadie verificó qué backups estaban limpios antes de que el equipo de recuperación llegara.

El resultado: 3 semanas para recuperar el 70% de los datos. Un 30% perdido para siempre. Costo total: USD 340.000 entre recuperación, pérdida de negocio, y asesoramiento forense para el juicio que siguió.

Riesgos para la Empresa#

Reaccionar sin plan ante un incidente multiplica el daño:

Explicación Técnica Sencilla#

El proceso de respuesta a incidentes según NIST SP 800-61 tiene 6 fases. Cada una tiene un objetivo específico y decisiones concretas:

Fase 1 — Preparación (antes del incidente)#

Esta es la fase más importante porque ocurre antes de que pase algo. Es como tener el plan de evacuación ensayado antes del incendio.

• Documentar qué sistemas son críticos y en qué orden recuperarlos
• Tener contactos de emergencia definidos (proveedor de IT, abogado, seguro cibernético)
• Asegurarse de que los backups están probados, offline, y listos para restaurar
• Asignar roles: ¿quién toma decisiones técnicas? ¿quién comunica con clientes y proveedores?

Fase 2 — Identificación#

¿Qué está pasando? ¿Es un verdadero incidente o una falsa alarma?

Señales de alerta comunes:

• Archivos con extensiones raras o mensajes de rescate
• Sistema extremadamente lento sin razón aparente
• Alertas del antivirus que normalmente no aparecen
• Empleados que no pueden acceder a sus archivos
• Tráfico de red inusual a horas raras

La pregunta clave en esta fase: ¿el ataque está activo ahora o ya terminó? Esto define si hay que actuar en segundos o si hay tiempo para analizar con calma.

Fase 3 — Contención#

El objetivo es detener que el problema se expanda, sin destruir la evidencia.

Contención a corto plazo (primeros 30 minutos):

• Desconectar de la red los equipos afectados (cable de red físico, no apagar)
• NO apagar los equipos si es posible — preservar la memoria RAM
• Si hay que apagar, documentar el estado antes (screenshot de procesos, conexiones activas)
• Verificar que los backups offline estén desconectados y no cifrados

Contención a largo plazo:

• Redes de cuarentena para sistemas comprometidos
• Restablecimiento de servicios críticos desde copias limpias mientras se investiga

Fase 4 — Erradicación#

Eliminar la causa raíz. No solo el malware visible, sino el vector de entrada que permitió el ataque.

Si solo eliminás el ransomware pero no cerrás la vulnerabilidad o la cuenta comprometida que usaron para entrar, el atacante puede volver a entrar en días.

Acciones típicas:

• Identificar el vector de entrada (credencial comprometida, software sin parchear, phishing)
• Cerrar el vector (cambiar contraseñas, parchear la vulnerabilidad, revocar cuentas)
• Escanear todos los sistemas en busca de presencia persistente del atacante

Fase 5 — Recuperación#

Restaurar los sistemas y volver a la operación normal, de forma controlada y verificada.

Orden recomendado de recuperación:
1. Sistemas de autenticación (Active Directory, VPN)
2. Backups verificados como limpios
3. Sistemas críticos de negocio (ERP, facturación)
4. Comunicaciones (correo)
5. Resto de sistemas
6. Monitoreo reforzado por 30 días post-incidente

Fase 6 — Lecciones Aprendidas#

La fase que casi nadie hace y que es la más valiosa para el futuro: 2-4 semanas después del incidente, el equipo se reúne para responder:

• ¿Cómo entró el atacante?
• ¿Qué controles fallaron?
• ¿Qué tardamos demasiado en detectar?
• ¿Qué parte del plan funcionó bien?
• ¿Qué cambios implementamos para que no se repita?

Cómo Prevenirlo#

1. Escribí un plan de respuesta básico antes de necesitarlo: No tiene que ser un documento de 100 páginas. Con una hoja A4 que diga quién llama a quién, qué se apaga y en qué orden, y dónde están los backups offline, ya tenés infinitamente más que el 90% de las PyMEs argentinas.

2. Ensayá el plan al menos una vez al año: Un plan que nunca se practicó es un plan que falla bajo presión. Un ejercicio de simulacro de 2 horas donde el equipo recorre mentalmente los pasos puede salvar semanas de caos en el momento real.

3. Separé los backups de la red durante el incidente: Los backups conectados permanentemente a la red son tan vulnerables al ransomware como los datos originales. Al menos una copia debe estar offline (disco externo desconectado, cinta, nube con retención inmutable).

4. Documentá antes de actuar: Cuando detectás un incidente, los primeros instintos (apagar todo, borrar el virus, formatear) suelen destruir la evidencia que necesitás para entender qué pasó. Tomá screenshots, guardá logs, documentá el estado antes de tocar nada.

5. Tenés derecho a no pagar: Pagar el rescate no garantiza recuperación, financia a grupos criminales, puede violar sanciones internacionales, y coloca a tu empresa como objetivo conocido para futuros ataques. Siempre consultá con un especialista antes de decidir.

6. Evaluá tu obligación legal de notificación: En Argentina, la Ley 25.326 de Protección de Datos Personales puede requerir notificación a la autoridad competente en casos de brecha de datos. En sectores regulados (finanzas, salud), los plazos son aún más estrictos. Tenerlo claro antes del incidente evita problemas legales post-incidente.

Herramientas Recomendadas#

Open source — TheHive (thehive.project): Plataforma de respuesta a incidentes open source que permite coordinar el trabajo del equipo durante un incidente: asignar tareas, documentar hallazgos, registrar la línea de tiempo de eventos. Diseñado para que varias personas trabajen en paralelo sobre el mismo caso sin perder información. Se integra con MISP para compartir inteligencia de amenazas.

Open source — MISP (misp-project.org): Plataforma de inteligencia de amenazas open source que permite compartir y correlacionar indicadores de compromiso (IoC — como IPs maliciosas, hashes de archivos, dominios usados por atacantes). Útil tanto para investigar un incidente activo como para prevenir futuros al conocer las tácticas usadas por grupos de amenaza conocidos.

Estándar gratuito — NIST SP 800-61 Rev. 3: La guía completa del NIST para respuesta a incidentes es gratuita y descargable desde el sitio del NIST. Está en inglés pero es el estándar de referencia mundial. Para PyMEs, las secciones 2 (ciclo de vida) y 3 (coordinación) son las más accionables. Tenerla descargada offline es especialmente valioso durante un incidente cuando quizás no tenés acceso a internet.

Checklist Final#

• Existe un plan de respuesta a incidentes documentado, aunque sea básico
• Están definidos los roles: quién toma decisiones técnicas, quién comunica externamente
• Los contactos de emergencia (IT, abogado, seguro cibernético) están disponibles offline
• Al menos una copia de backup está offline y desconectada de la red
• Los backups fueron probados (restauración real verificada) en los últimos 3 meses
• El equipo sabe que NO debe apagar los servidores como primera reacción
• Están documentados los sistemas críticos y el orden de recuperación prioritario
• Sabemos cuáles son nuestras obligaciones legales de notificación en caso de brecha
• Hicimos al menos un ejercicio de simulacro del plan en los últimos 12 meses
• Los logs de sistemas críticos están activos y se retienen al menos 90 días
• Existe un proceso para aislar equipos de la red sin apagarlos
• Después del último incidente (o del simulacro) se hizo una reunión de lecciones aprendidas

CVE / Vulnerabilidades Relacionadas#

CVE-2025-30406 — Gladinet CentreStack & Triofox (CVSS 9.0 — Crítico)#

Esta vulnerabilidad ilustra perfectamente por qué la fase de erradicación es crítica. CVE-2025-30406 permite ejecución remota de código en servidores de archivos corporativos sin autenticación — y fue explotada activamente como zero-day antes de que existiera un parche.

El escenario de pesadilla para la respuesta a incidentes: una empresa descubre ransomware, lo elimina, restaura desde backups, vuelve a la operación normal... y una semana después vuelve a estar cifrada. ¿Por qué? Porque el vector de entrada (la vulnerabilidad en el servidor de archivos) nunca fue identificado ni cerrado durante la fase de erradicación. El atacante simplemente volvió a entrar por la misma puerta.

Sin una fase de erradicación correcta que identifique y cierre el vector de entrada, la recuperación es temporal. La empresa vuelve a ser vulnerable desde el momento en que vuelve a estar online.

Podés leer más sobre esta vulnerabilidad en nuestra ficha CVE-2025-30406.

Conclusión y CTA#

Nadie quiere pensar que le va a pasar. Pero las estadísticas son claras: no es cuestión de si una empresa mediana va a sufrir un incidente de seguridad, sino de cuándo. La diferencia entre una empresa que lo supera en 48 horas y una que tarda 3 semanas y pierde datos irreemplazables no es el tamaño del ataque — es si tenían un plan o no.

Un plan de respuesta básico, backups offline probados, y el equipo que sabe qué hacer en los primeros 30 minutos: eso vale más que el firewall más caro del mercado cuando el momento llega.

¿Querés evaluar cuán preparada está tu empresa para responder a un incidente? Pedí nuestro diagnóstico gratuito o volvé al artículo anterior: Firewalls empresariales: más allá del "está activado".