Anatomía de un ransomware en una empresa mexicana: qué pasó, qué se aprendió
La mejor forma de entender qué hace caer a una empresa frente a un ransomware no es leer un white paper de un proveedor. Es reconstruir un caso real. En este artículo desmenuzamos un incidente que ocurrió en una empresa manufacturera mediana del Bajío durante la primera mitad de 2025. Los detalles están anonimizados (sector, geografía y orden de magnitud son reales, los nombres y cifras exactas no), pero la cronología, los vectores y las decisiones son fieles a lo que pasó.
El objetivo no es asustar. Es mostrar, con detalle, dónde se pierde una empresa cuando lo pierde, y dónde se gana cuando se gana.
El contexto
La empresa: manufactura de componentes industriales, 280 empleados, dos plantas en Guanajuato y Querétaro, ingresos cercanos a USD 40 millones anuales. Stack típico: ERP on-premise, M365 con licencias Business Standard, AD on-premise, VPN para conexiones remotas, antivirus tradicional en endpoints, backups en NAS local.
Sin CISO. Sin SOC. Un equipo de TI de cuatro personas que se ocupaba de todo.
Día 0: el vector inicial
El ataque empezó con un correo de phishing dirigido al área de finanzas. El correo simulaba ser del director general pidiendo revisar un comprobante adjunto. El adjunto era un PDF con un enlace a una página falsa de M365.
La gerente de finanzas hizo clic, vio la pantalla familiar de Microsoft pidiendo contraseña, la introdujo y autorizó la solicitud de MFA por push (MFA fatigue: el atacante envió varios prompts hasta que ella autorizó por error pensando que era un sync legítimo).
A partir de ese momento, el atacante tuvo control de la cuenta de finanzas. Importante: la cuenta tenía MFA, pero la modalidad de push sin contexto la hizo vulnerable a fatiga. Los atacantes saben esto y lo explotan sistemáticamente.
Días 1-7: reconocimiento silencioso
Durante una semana el atacante no hizo nada visible. Lo que sí hizo:
- Leyó correos de la víctima para entender la estructura organizacional.
- Identificó al director de TI, al CEO y al CFO.
- Encontró credenciales de servicios internos compartidas por correo (mala práctica común).
- Usó OneDrive de la víctima para mapear documentos relevantes (planos, contratos, nóminas).
- Probó accesos a apps SaaS conectadas a la cuenta comprometida.
Ninguno de estos movimientos disparó alertas porque el antivirus tradicional no monitorea actividad en M365 ni el equipo de TI tenía visibilidad fuera de los endpoints.
Día 8: escalamiento de privilegios
El atacante encontró, en un correo viejo, una contraseña que el director de TI había compartido años antes. Probó esa contraseña contra el VPN. Funcionó. El director nunca la había rotado.
A partir del VPN, el atacante hizo movimiento lateral en la red interna usando técnicas conocidas (pass-the-hash, kerberoasting). En 48 horas tenía control de un servidor con privilegios de administrador de dominio.
Días 10-12: exfiltración
Antes de cifrar, el atacante exfiltró datos. Aproximadamente 400 GB que incluían:
- Estados financieros de los últimos cinco años.
- Información de clientes y proveedores.
- Datos personales de empleados (nóminas, INE, expedientes).
- Planos y diseños propietarios.
- Correos sensibles del comité ejecutivo.
La exfiltración se hizo en horario laboral, mezclada con tráfico legítimo, hacia servidores en una infraestructura de nube comprometida. El monitoreo de red de la empresa no detectó nada anómalo.
Día 13: el cifrado
Un sábado a las 3 a.m., el atacante ejecutó el ransomware. En menos de 6 horas cifró:
- ERP entero (servidor de aplicaciones y base de datos).
- Servidor de archivos compartido.
- NAS de backups (este fue el golpe más duro: los backups estaban accesibles desde la red).
- Estaciones de trabajo de aproximadamente 60 usuarios que estaban encendidas.
El lunes en la mañana el equipo encontró pantallas con la nota de rescate. USD 1.2 millones en Bitcoin a cambio de la clave de descifrado y la promesa de no publicar los datos exfiltrados.
La decisión: no pagar
Después de 36 horas de evaluación con asesores legales y técnicos, la dirección decidió no pagar. Tres razones:
- No hay garantía de que la clave funcione ni de que los datos no se publiquen.
- Pagar marca a la empresa como blanco para futuros ataques.
- Implicaciones legales: pagar a grupos en listas de sanciones internacionales tiene consecuencias.
La decisión fue correcta, pero el costo de no pagar fue alto.
La recuperación
Tomó 9 días restablecer operaciones mínimas y casi 6 semanas llegar a operación plena. Lo que se hizo:
- Reconstrucción del AD desde cero con servidores limpios.
- Restauración del ERP desde backups offline en cinta que se habían hecho una vez al mes (afortunadamente esos no estaban accesibles desde la red).
- Reinstalación de todas las estaciones de trabajo con imagen limpia.
- Reset masivo de credenciales y rotación de todos los secretos.
- Notificación a clientes y autoridades por la posible exposición de datos personales.
Costo total estimado, incluyendo:
- Pérdida de operación (9 días sin facturar).
- Honorarios de respuesta a incidentes (firma especializada).
- Reposición de hardware.
- Multas por LFPDPPP (en proceso).
- Pérdida de dos clientes que cancelaron contratos por desconfianza.
Aproximadamente USD 4.5 millones, casi cuatro veces el rescate solicitado. Sin contar el costo reputacional difícil de cuantificar.
Qué se hizo bien
Antes de pasar a las lecciones, vale reconocer qué funcionó:
- Backups offline mensuales en cinta. Anticuado, sí. Pero salvó a la empresa.
- Decisión rápida y disciplinada de no pagar. Sin titubeos públicos.
- Comunicación clara con empleados y clientes. Sin maquillar.
- Contratación inmediata de equipo de respuesta. No intentaron resolverlo solos.
Lecciones que aplican a casi cualquier empresa
Este caso es ordinario. Cientos de empresas mexicanas pasan por algo parecido cada año. Las lecciones se repiten:
1. MFA por push sin contexto no basta
Para cuentas críticas, hardware keys (YubiKey, Titan) o al menos number matching en authenticator apps. La fatiga de MFA es el vector más explotado de 2024-2025.
2. Rotación obligatoria de credenciales
Sobre todo de cuentas privilegiadas. Cada 90 días, sin excepciones. Y nunca compartirlas por correo o chat.
3. Backups inmutables y desconectados
La regla 3-2-1: tres copias, dos medios distintos, una offline o inmutable. Si tu NAS de backups vive en la misma red que el ERP, no es backup, es tarea pendiente.
4. Segmentación de red en serio
VLANs separadas, acceso entre segmentos solo con justificación. Una red plana es una invitación al movimiento lateral.
5. EDR, no antivirus tradicional
Un antivirus de firmas no detecta técnicas modernas. Microsoft Defender for Business, CrowdStrike o SentinelOne son lo mínimo.
6. Visibilidad sobre M365 y SaaS
El ataque empezó en M365 y nadie vio nada por días. Una herramienta de monitoreo de identidad (incluida en M365 E5 o servicios como Vectra, Push Security) habría detectado el comportamiento anómalo.
7. Plan de respuesta a incidentes ensayado
No basta con tener el plan en un PDF. Hay que simularlo al menos una vez al año con todo el comité. La primera vez que se ejecuta no debería ser durante un incidente real.
Cierre
La pregunta no es si tu empresa va a sufrir un intento de ataque. Es si vas a estar preparado cuando ocurra. La diferencia entre las empresas que se recuperan en una semana y las que no se recuperan está en decisiones tomadas en frío, meses antes del incidente. Hoy es ese momento, no después.
En ALCA hacemos assessments de exposición a ransomware con simulación de escenarios reales y plan accionable. ¿Quieres un assessment de exposición a ransomware? Te lo damos en 1 semana. Agenda una llamada de 30 minutos.
