CASO DE ESTUDIO: Cuando el ransomware llegó a las 4:00 AM

Caso real: cronología de una crisis de ransomware y las decisiones que siguieron.

La llamada llegó a las 4:00 de la mañana. No era del NOC, ni de un sistema de alertas automatizado. Eran los guardias de seguridad física del edificio. Las cámaras no mostraban imagen.

El servidor Dahua había dejado de recibir respuesta del DNS, del NTP y de otros servicios de red. Sin sincronización de tiempo, sin resolución de nombres, el sistema simplemente se detuvo. Y con él, todas las cámaras. A eso de las 4:00 AM, cuando el único equipo en alerta era el de seguridad física, esa pérdida de imagen fue la primera señal visible de algo que llevaba horas ocurriendo en silencio.

Lo que nadie sabía todavía era que un ransomware había comprometido aproximadamente el 65% de los servidores de la organización. Y que su primer objetivo —antes que cualquier sistema de producción— había sido el sistema de respaldo.

---

4:00 AM — el vector de alerta que nadie anticipó

Entré al servidor Dahua mientras mi jefe empezaba a revisar los demás servicios. Lo que encontramos en las siguientes dos horas no era un fallo de hardware, ni un problema de conectividad puntual. Era un entorno completamente silenciado: servidores que no respondían ping, servicios caídos sin log de error claro, y la red comportándose de forma errática en segmentos que deberían haber sido independientes.

A las 5:50 AM teníamos la confirmación. Ransomware. Activo. Extendido por una porción significativa de la infraestructura.

El dato que más me impactó en ese momento no fue el número de servidores afectados. Fue la fuente de la alerta: no fue el firewall perimetral, no fue el SIEM, no fue ningún sistema de detección de intrusiones. Fueron los guardias de seguridad, llamando porque no podían ver las cámaras. En entornos donde Fortinet y Cisco están presentes, la expectativa es que la alerta temprana venga de la infraestructura. Esa noche vino del personal de turno.

Lección #1: Los sistemas de detección automatizada fallan justo cuando más se necesitan. Si el adversario sabe cómo desactivar o evadir las herramientas de monitoreo, el primer aviso puede venir de cualquier parte. El plan de respuesta a incidentes tiene que contemplar alertas no convencionales, y tiene que haber alguien que conteste a las 4:00 AM.

La respuesta física: desconectar para sobrevivir

Con el diagnóstico confirmado, la decisión fue inmediata y brutal en su simplicidad: la mitad del equipo fue directo al data center y empezó a desconectar cables de red. Casi todos. No hubo tiempo para análisis elegante ni para runbooks perfectos. La prioridad era contener la propagación antes de que alcanzara lo que todavía no estaba comprometido.

Es una imagen que no se olvida: el data center iluminado a las 6 de la mañana, el equipo agachado detrás de los racks, desconectando patch cords uno por uno mientras alguien en el otro extremo de la sala intentaba identificar qué segmentos podían mantenerse en línea sin riesgo. Fue respuesta de crisis pura, sin automatización, sin playbooks ejecutándose solos.

Esa imagen también es la respuesta más honesta a la pregunta de qué tan preparada estaba la organización para un incidente de esta magnitud. La segmentación de red, con Cisco gestionando bordes internos y WatchGuard en el perímetro, había limitado algo la propagación. Pero no lo suficiente. El movimiento lateral ya había ocurrido antes de que pudiéramos intervenir.

Lección #2: La contención manual tiene un costo altísimo en tiempo y en errores. La segmentación de red no es un proyecto de optimización —es el único mecanismo que puede limitar el radio de daño cuando el perímetro ya fue superado. En arquitecturas WatchGuard/Cisco, las políticas de microsegmentación y de segregación deben estar definidas y probadas antes del incidente, no diseñadas durante él.

El primer objetivo del ataque: el sistema de respaldo

Esto fue lo más revelador de todo el análisis post-incidente. El primer sistema que el ransomware atacó (antes que los servidores de producción, antes que los sistemas de negocio) fue VEEAM. El sistema de backups quedó paralizado desde el inicio, lo que significó que durante toda la crisis, los respaldos más recientes estaban potencialmente comprometidos sin que pudiéramos saberlo con certeza.

No es un detalle técnico menor. Es una decisión estratégica del atacante: si eliminas la capacidad de recuperación antes de activar el cifrado, maximizas el impacto y la presión sobre la organización. No se puede recuperar rápido si los backups están comprometidos. Y si no puedes recuperarte rápido, la presión hacia el pago aumenta.

La decisión que tomamos fue no confiar en los respaldos de VEEAM recientes; optamos por versiones anteriores (más antiguas, con pérdida de datos garantizada) porque esas sí podíamos verificar que no habían estado en la línea de fuego. Algunos servidores tuvieron que formatearse por completo: la data estaba cifrada o potencialmente manipulada sin posibilidad de certificar su integridad.

Lección #3: VEEAM, o cualquier solución de backup accesible desde la red de producción, es un objetivo de alta prioridad para el atacante. Los respaldos aislados, inmutables, y fuera de la red principal no son un lujo. Son el único mecanismo de recuperación que sobrevive a un ataque bien ejecutado. La regla 3-2-1-1 (tres copias, dos medios distintos, una offsite, una offline/inmutable) no es paranoia. Es el estándar mínimo después de ver esto en producción.

La recuperación: semanas de trabajo, decisiones permanentes

La recuperación completa tomó varias semanas, no fue un proceso lineal. Hubo servicios que volvieron rápido porque había backups limpios y procedimientos claros. Otros se recuperaron de forma improvisada: algunos procesos pasaron temporalmente a manual, otros se migraron de emergencia a la nube, otros se reformularon desde cero porque el sistema original ya no justificaba ser restaurado tal como estaba.

Esa etapa (la de las decisiones de emergencia) terminó siendo más valiosa de lo que parecía en el momento. Porque obligó a la organización a hacer algo que en condiciones normales es difícil de ejecutar: cuestionar qué sistemas realmente importaban, cuáles justificaban la inversión de recuperación, y cuáles podían simplificarse o eliminarse.

Al finalizar, la arquitectura no era la misma de antes del incidente, era mejor. No porque el ransomware fuera una buena noticia, claramente no lo fue. Sino porque la crisis generó el contexto para tomar decisiones de rediseño que en circunstancias normales habrían tardado años en aprobarse.

Lección #4: El plan de recuperación tiene que estar definido antes del incidente, con roles claros y decisiones pre-autorizadas. En la crisis, cada hora de deliberación es una hora de operación perdida. El directorio que no ha aprobado previamente un plan de recuperación de desastres va a tomar decisiones de emergencia bajo presión, y esas decisiones raramente son las mejores. Esto implico en el rediseño total tanto fisica como lógica de toda la plataforma de red y de sistemas, como tambien del equipo de trabajo, el cual hablaremos en otra entrega en detalle.

---

Lo que este caso le dice al CIO

El ransomware no llegó por una vulnerabilidad exótica ni por un vector sofisticado, Llegó porque había brechas en la arquitectura de segmentación, porque los respaldos estaban accesibles desde la red de producción, y porque no había un mecanismo de detección que funcionara en las horas críticas de la madrugada.Y sobre todo por tener un grupo muy reducido para realizar las labores de administracion, monitoreo y reaccion ante las eventualidades, apenas una (1) persona para rede, una (1) para servidores y 1 para base de datos.

Tres preguntas que todo CIO debería hacerse hoy, antes de que las haga la crisis:

• ¿Están mis backups aislados de la red de producción, con copias inmutables verificadas regularmente?
• ¿Qué tan rápido puede el equipo detectar un incidente fuera del horario laboral, sin depender de alertas automatizadas?
• ¿Cuánto puede propagarse un ataque interno antes de que la segmentación de red lo detenga?

Si alguna de esas respuestas genera incomodidad, ese es exactamente el punto de partida del trabajo.

¿Tu organización está preparada para las 4:00 AM?

Suscríbete al newsletter Cybersecurity Insights en LinkedIn para recibir análisis como este cada semana. Casos reales, decisiones reales, sin tecnicismo innecesario.

#Ciberseguridad #Ransomware #IncidentResponse #CIO #ITManager #Fortinet #Cisco #pfSense #VEEAM #BackupStrategy #ISO27001 #NISTCSF #GestiónDeRiesgos #CasoDeEstudio #Chile