Un ataque de ransomware paralizó toda la red de una universidad en 72 horas. Tenfold Security la restauró en 5 días, sin ninguna recurrencia en más de 3 años.

Sección 1

Acerca de la organización

Nuestro cliente es una universidad pública de tamaño mediano ubicada en el Medio Oeste de Estados Unidos, que atiende a miles de estudiantes en varios campus. Al igual que muchas instituciones de educación superior, opera en un entorno de TI complejo y extenso: una combinación de servidores locales, almacenamiento en la nube, proveedores externos para servicios de impresión y copias de seguridad fuera de las instalaciones, y una amplia base de usuarios con distintos niveles de conocimientos técnicos.

Las universidades son objetivos frecuentes de los grupos de ransomware. Almacenan datos confidenciales de estudiantes protegidos por FERPA, operan con presupuestos de seguridad de TI limitados en relación con la amplitud de su infraestructura y enfrentan una enorme presión para mantener las operaciones académicas funcionando de manera continua, lo que las convierte en objetivos atractivos y con mayor probabilidad de pagar rápidamente.

Sección 2

Desafío: Una Brecha Silenciosa Que Se Convirtió en un Apagón Total

El ataque no se anunció. Esperó.

Julio: El punto de entrada invisible

El proveedor externo de almacenamiento cloud de la universidad (responsable de almacenar los datos de las copias de seguridad de la organización) sufrió un ataque de ransomware. El proveedor no notificó a la universidad durante un mes entero. Durante ese período, los actores de amenazas mapearon silenciosamente la conexión entre el proveedor y la red interna de la universidad. Un jumpbox utilizado para conectar ambos entornos había sido comprometido y SentinelOne (la herramienta de detección de endpoints que se ejecutaba en ese nodo) fue deshabilitado silenciosamente.

Agosto: Comienza la cascada

Un viernes por la noche, el personal de TI de la universidad notó que las bases de datos se comportaban de manera extraña y que las copias de seguridad estaban fallando. Asumieron que se trataba de un problema técnico rutinario y comenzaron a investigar.

Para la mañana del lunes, la situación había empeorado drásticamente:

• Los servidores comenzaron a presentar lentitud en toda la red
• Los registros del firewall alcanzaron su capacidad máxima
• Las CPU de los servidores de archivos alcanzaron su capacidad máxima
• Las solicitudes al helpdesk comenzaron a llegar desde todo el campus

El martes llegóel primer correo electrónico con la demanda de pago para rescate, pero quedó enterrado en una bandeja de entrada saturada y no fue leído. El personal de TI aún consideraba que se trataba de un problema de rendimiento, no de un incidente de seguridad.

Para el miércoles, la realidad era inevitable:

• Todos los servidores estaban fuera de servicio y cifrados
• DHCP dejó de funcionar: toda la red quedó fuera de servicio
• Se recibió una segunda demanda de pago para rescate
• Se descubrió que las copias de seguridad offline de la universidad (almacenadas por el proveedor externo) habían desaparecido

Causas principales que hicieron esto posible

Este incidente no fue causado por una sola falla. Fue el resultado de la combinación de varias brechas de seguridad comunes y prevenibles:

• Implementación incompleta de MFA: Todas las cuentas, excepto dos, tenían habilitada la autenticación multifactor. Las dos excepciones (una cuenta de servicio de una impresora y una cuenta secundaria de administrador) fueron las cuentas explotadas. La cuenta de servicio de impresoras había sido convertida silenciosamente en una cuenta interactiva y se le habían otorgado privilegios de administrador.
• Puerto RDP abierto sin administrar: un proveedor de servicios de impresoras había solicitado a la universidad abrir un puerto RDP para dar mantenimiento a las impresoras. El trabajo se completó, pero el puerto nunca fue cerrado. Ya se habían realizado más de 300 conexiones externas a través de ese puerto abierto, antes de que fuera descubierto.
• Falta de administración de proveedores: la brecha del proveedor externo de copias de seguridad no fue reportada durante un mes. No existían requisitos de seguridad, mecanismos para verificar las notificaciones ni obligaciones contractuales de respuesta a incidentes.
• Copias de seguridad que no estaban realmente offline: el proveedor almacenaba lo que debían ser copias de seguridad offline; sin embargo, debido a que el proveedor sufrió una brecha y compartía una conexión directa con la universidad, todas las copias de seguridad se perdieron simultáneamente.
• Plan de respuesta a incidentes limitado: no existía un procedimiento documentado de respuesta a incidentes (IR), ningún plan de comunicación, ni un protocolo para incidentes relacionados con proveedores. Durante las primeras horas críticas, la información incorrecta se propagó libremente por toda la organización.

Sección 3

La solución: respuesta estructurada bajo presión

Tenfold Security fue contratado el miércoles, el día en que la red dejó de funcionar por completo. En cuestión de horas, nuestro equipo ya había establecido un plan de acción estructurado.

Día 1: Evaluación y contención

Nuestra primera prioridad fue comprender la situación. Creamos carriles “swim lanes” (un modelo de trabajo paralelo que permitió a diferentes equipos de respuesta trabajar simultáneamente en el análisis de la red, la evaluación de dispositivos, el análisis forense y la comunicación), en lugar de trabajar de forma secuencial durante la crisis.

Implementamos inmediatamente SentinelOne y Velociraptor en todos los dispositivos de la universidad. SentinelOne proporcionó detección y respuesta de endpoints en tiempo real; Velociraptor nos permitió realizar una rápida recopilación de evidencia forense y buscar mecanismos de persistencia (técnicas que los actores de amenazas utilizan para mantener un acceso continuo y a largo plazo) en todo el entorno, incluso con la red funcionando de manera limitada.

Días 2—4: Identificación y remediación

Con las herramientas implementadas en los endpoints, nuestro equipo trabajó para identificar cada dispositivo comprometido, aislar las amenazas activas y comenzar una restauración limpia. Nuestras acciones principales incluyeron:

• Identificar y cerrar el puerto RDP abierto y auditar todas las vías de acceso de proveedores
• Deshabilitar las cuentas comprometidas y restablecer todas las credenciales con MFA obligatorio
• Evaluar qué datos podían recuperarse y cuáles se habían perdido debido a la brecha del proveedor
• Coordinar con la aseguradora de riesgos cibernéticos para documentar el incidente y administrar las comunicaciones
• Establecer un protocolo de comunicación interno claro para detener la propagación de información incorrecta

Día 5: Restauración completa

Para el sábado (cinco días después de nuestra contratación), todos los dispositivos estaban limpios y la red había sido restaurada por completo. El proceso de inscripción de estudiantes de la universidad, un evento operativo crítico, se llevó a cabo sin interrupciones el lunes siguiente.

A diferencia de las empresas genéricas de respuesta a incidentes que utilizan procedimientos prediseñados, el enfoque de Tenfold Security fue metódico y específico para el entorno. Diseñamos la respuesta en función de la infraestructura real de la universidad, sus relaciones con proveedores y sus prioridades operativas, no a partir de una plantilla genérica.

Sección 4

Los Resultados

Tenfold Security restauró en cinco días una red universitaria completamente cifrada y fuera de servicio. Lo suficientemente rápido como para proteger uno de los eventos operativos más importantes del calendario académico: la inscripción de estudiantes.

Pero el resultado más significativo es lo que ha ocurrido desde entonces. En los 3.75 años posteriores al incidente, la universidad ha experimentado cero recurrencias de ransomware y cero brechas de seguridad. Este resultado no es accidental, sino el resultado directo de las mejoras sistemáticas de remediación y del programa de seguridad implementadas después de la respuesta al incidente.

Después del incidente, Tenfold Security trabajó con la universidad para abordar cada una de las causas principales identificadas:

• MFA implementado en el 100 % de las cuentas, incluidas las cuentas de servicio
• Se estableció un programa formal de gestión de proveedores con requisitos de seguridad y acuerdos de nivel de servicio (SLA) para la notificación de brechas
• Se rediseñó la infraestructura de copias de seguridad: copias verdaderamente offline y aisladas (air-gapped), con pruebas periódicas de restauración
• Se documentó el plan de respuesta a incidentes, se realizaron ejercicios de simulación y se estableció su actualización anual
• Se implementó un proceso de control de cambios del firewall con ciclos de revisión obligatorios
• Servicio continuo de Detección y Respuesta Administradas (MDR) con Tenfold Security

Sección 5

Lo que esto significa para tu organización

El ransomware no discrimina por tamaño ni sector. Si tu organización tiene vías de acceso abiertas para proveedores externos, una cobertura incompleta de MFA o procedimientos de copias de seguridad que no han sido probados, tú también compartes el mismo perfil de riesgo que tenía esta universidad antes del ataque.

La diferencia entre una recuperación de cinco días y una pesadilla de cinco meses depende de la preparación y del equipo al que llames desde el primer día.

Tenfold Security ofrece:

• Respuesta a Incidentes (IR): administración rápida, contención estructurada y restauración completa
• Detección y Respuesta Administradas (MDR): monitoreo 24/7 para detectar amenazas antes de que causen daños
• Pruebas de Penetración Activas: ponga a prueba la preparación de su equipo antes de que un atacante lo haga por usted

Preguntas frecuentes

Preguntas frecuentes: Respuesta a incidentes de ransomware para universidades