NotPetya: el ciberataque más caro de la historia

25 de febrero de 2026 • 12 min read

A finales de junio de 2017, en Ucrania empieza algo que, a primera vista, parece “ransomware de siempre”: equipos que reinician, archivos que dejan de estar disponibles y, en pantalla, aparece una petición de rescate.

Unas horas después, ya está claro: no es un incidente local. Es un incendio.

El nombre que se quedó grabado es NotPetya. Hasta hoy, representa cómo una supuesta “ola de malware” puede convertirse en un evento que paraliza empresas en todo el mundo y provoca daños de miles de millones.

En este artículo quiero unir dos cosas:

La historia detrás de NotPetya: qué pasó entonces y por qué fue tan caro.
La perspectiva práctica: qué significa esto para empresas “normales” hoy, no solo para gigantes Fortune 500.

Lo incómodo de NotPetya no es que fuera “demasiado complejo”. Lo incómodo es: es aterradoramente realista.

¿Por qué escribo esto en 2026? Porque hoy podemos hablar de ataques de phishing con deepfakes impulsados por IA, pero cuando hay una crisis seguimos fallando en las mismas cosas básicas que en 2017: falta de segmentación y backups conectados al mismo “suero” que la producción.

NotPetya en 5 minutos: ¿qué pasó?

Para situarnos, hay que ordenar los hechos.

El 27 de junio de 2017, NotPetya apareció primero en Ucrania y se expandió globalmente a gran velocidad. Un factor clave fue una actualización comprometida de un software de contabilidad muy usado en Ucrania (M.E.Doc). El malware no entró por “un clic tonto”, sino por un mecanismo que las empresas usan a diario: las actualizaciones.

Y esto es algo que mucha gente subestima a posteriori: en esencia fue un ataque a la cadena de suministro (supply chain). M.E.Doc no fue un objetivo aleatorio: fue el palanca perfecta porque las actualizaciones se confían por diseño.

La lección para hoy es incómoda, pero importante: puedes hacer muchas cosas bien internamente; si el software de tu asesoría, un proveedor, un conector de ERP o una herramienta de un tercero se corrompe, igualmente estás en el radio de impacto. El riesgo de supply chain no es “un problema de la nube”: es, muy concretamente, un problema de actualizaciones.

Una vez dentro de la red, NotPetya dejó de ser “un par de PCs” y pasó a ser Lateral Movement (movimiento lateral):

A través de SMB y vulnerabilidades conocidas (incluida EternalBlue / MS17-010, un exploit filtrado del toolkit de la NSA), NotPetya podía propagarse a otros sistemas Windows sin interacción del usuario.
En paralelo, utilizó dumping de credenciales (Mimikatz/LSASS) para extraer contraseñas/hashes desde la RAM y moverse con credenciales reales de administrador.
Para la ejecución remota, usó herramientas “normales” de administración (p. ej., PsExec/WMI). Esa combinación es peligrosa porque, en los logs, al principio puede parecer “operación normal”.

Ese fue el “ingrediente secreto”: un exploit para saltar rápido a nuevos sistemas, credenciales sacadas de memoria para tener privilegios reales y, después, escalar usando herramientas del sistema.

Lo importante: parchear no habría sido suficiente. Incluso si un sistema estaba parcheado contra EternalBlue, podía caer igualmente en cuanto el malware conseguía credenciales/hashes válidos de administrador en alguna parte de la red.

NotPetya también jugó con el tiempo: incorporó un retraso y no forzó el “gran golpe” (reinicio/wipe) de inmediato, sino tras un rato. Eso complica la detección y, de paso, es un patrón clásico contra sandboxes: el malware no “explota” enseguida mientras, por detrás, ya está escalando.

El resultado es el que siempre se ve en estos casos:

Primero, algunos sistemas se comportan “raro”.
Luego, de repente, cae un sitio entero.
Y si no reaccionas muy rápido (cortar red, bloquear cuentas, cerrar fronteras de segmentación), el incidente puede saltar entre sedes.

Por qué “ransomware” era solo camuflaje

NotPetya se percibió como ransomware porque mostraba una petición de rescate. Pero técnicamente y en la práctica era otra cosa.

El punto clave: NotPetya era, en realidad, un wiper. Malware cuyo objetivo no es “ganar dinero”, sino destruir sistemas y frenar la operación.

Esto puede sonar a semántica, pero en un incidente marca una diferencia enorme:

Con ransomware clásico, a veces existe una posibilidad de recuperar datos con claves o negociación.
Con un wiper, el objetivo es “roto”. Pagar en Bitcoin no te salva.

En NotPetya hay un detalle técnico que subraya aún más el carácter de wiper: sobrescribía el MBR (Master Boot Record) y cifraba la MFT (Master File Table). Además, incluso la parte “ransomware” estaba implementada de forma defectuosa: el ID de instalación mostrado se generaba al azar y no estaba correctamente vinculado a una clave de descifrado utilizable. En otras palabras: prácticamente no había vuelta atrás.

Por eso NotPetya fue tan perverso: empujó a muchas empresas al playbook equivocado al principio. Piensas “playbook de ransomware”, pero lo que necesitas es “playbook de disaster recovery”.

Que el ataque fuera más de destrucción que de dinero también encaja con la atribución posterior: varios gobiernos atribuyeron públicamente NotPetya a actores estatales rusos.

10.000 millones de dólares: ¿por qué fue tan caro?

Si solo te quedas con la etiqueta “ransomware”, el daño cuesta de entender. “¿No restauras el backup y ya?”

En la práctica, NotPetya fue tan caro sobre todo porque golpeó donde muchos presupuestos no invierten lo suficiente: la disponibilidad.

El mayor coste no fue el malware, sino el paro.

Líneas de producción paradas.
Logística volviendo al papel.
Identidades y dominios reconstruidos desde cero.
Aplicaciones, integraciones y dependencias cayendo en cadena.
Y todo eso no en un sistema, sino en muchos a la vez.

Por eso NotPetya se describe a menudo como “el ciberataque más caro de la historia”. En informes se estiman los daños totales en torno a 10.000 millones de dólares.

También se ve en cifras concretas: Merck, FedEx (incluyendo TNT Express) y Mondelez describieron en sus informes que no fue “un tema de IT”, sino un tema de negocio con impacto real en ingresos, costes y capacidad de entrega.

NotPetya también tuvo un enorme después legal: empresas se pelearon con sus aseguradoras. Algunas aseguradoras intentaron no pagar clasificándolo como “acto de guerra” (“Act of War”, es decir, un ataque dirigido por un estado). Un caso muy conocido es la disputa de Mondelez con su aseguradora. Para las empresas, la lección sigue siendo durísima: ¿mi seguro ciber cubre ataques estatales o, cuando importa, entra una exclusión de guerra?

Actualización para lectores pro: el caso de Mondelez se resolvió en 2023. Desde entonces (y, en general, tras NotPetya), el mercado ha endurecido el lenguaje en muchos sitios: en muchas pólizas, los ataques “motivados por estados” se definen de forma más estrecha o se excluyen explícitamente. Eso convierte el seguro ciber en un riesgo financiero real si no entiendes de verdad las cláusulas.

Y ojo: incluso si “solo” restauras sistemas, en la vida real peleas contra dependencias.

Un ejemplo que aparece en muchos retrospectives es Maersk: no fue “unos archivos cifrados”, sino reconstruir sistemas core, identidades y la IT operativa para que puertos y logística pudieran volver a arrancar.

La historia es legendaria porque muestra lo frágiles que pueden ser identidades y backups: Maersk perdió prácticamente todo su Active Directory, salvo un único Domain Controller en Ghana que, por un corte de luz, estaba offline en el momento del ataque. Ese “Lucky Punch” fue un backup offline accidental: con ese único servidor físico pudieron reconstruir su AD global y acelerar la recuperación.

Al final, esto no golpea solo a “IT”, sino directamente al negocio:

En alimentación: producción, planificación y cadena de suministro se paran.
En navieras: los contenedores se quedan quietos.
En farma: fabricación, procesos de calidad y capacidad de entrega quedan bajo presión.

Por eso la cifra es tan alta: la pantalla del rescate es el síntoma. El daño real es el paro.

Caso práctico: el incidente que esperaría en una empresa “normal”

Quiero describir a propósito un caso que no suena a Hollywood. No “State Actor vs. Big Tech”, sino un escenario plausible para una empresa mediana.

Imagina una empresa mediana:

Una sede principal y una segunda pequeña.
Un setup Windows clásico: AD, file servers, algunas VMs, un ERP.
Más algunos sistemas que casi nadie toca por buenas razones: controladores de máquinas, software legacy, un “Windows Server 2008 lo-que-sea” porque el proveedor nunca actualizó.
Hay backups: diario a un NAS, semanal además a otro sistema.

Y aquí viene el punto que muchos subestiman:

Esta empresa no tiene “poca seguridad” porque todos sean incompetentes. Es porque operación y tiempo siempre ganan.

Se posponen parches porque la planificación de producción aprieta. La segmentación se deja para “más adelante” porque VLANs son trabajo. Las contraseñas de admin local se han heredado históricamente. Y el NAS, claro, está online porque restaurar “si no” es un suplicio.

La línea temporal (realista, no dramática)

Un martes por la mañana entra una actualización. Puede ser de un proveedor, una herramienta de un tercero, un conector… cualquier cosa que se actualiza sola. O un sistema comprometido de un partner con acceso por VPN.

08:10: los primeros clientes se vuelven inestables. Un reinicio aquí, un error raro allá.
08:25: el primer file server se pone lento. Suben los tickets al helpdesk.
08:40: de repente, “el dominio está raro”. El login tarda, las GPO fallan.
09:00: un admin inicia sesión “para mirar rápido”. Muchas veces ahí el movimiento lateral se dispara.
09:20: una sede entera está, en la práctica, fuera de servicio.

Y ahora viene la parte que solo se entiende del todo a posteriori:

Si en ese momento no cortas “a lo bruto”, el daño no escala linealmente: escala de forma exponencial.

Y, por supuesto, llega la pregunta de siempre:

“¿Pagamos?”

En NotPetya, la respuesta amarga era: incluso si quisieras, probablemente no habría servido. Psicológicamente, eso cambia el incidente, porque tienes que pensar en “reconstrucción”, no en “descifrado”.

Cuanto más esperas, más sistemas hay que rehacer. Cuantos más sistemas hay que rehacer, más tiempo estás en modo emergencia. Y cuanto más estás en modo emergencia, más caro sale.

Lo que de verdad duele

Tras unas horas queda claro: esto no es “restauramos un par de archivos”. Esto es “reconstruimos Active Directory y sistemas core”.

Y entonces descubres:

Tus backups estaban online y también cayeron.
Tu documentación no está al día.
No tienes suficientes “golden images” para reimaging rápido.
Las credenciales de admin estaban por todas partes.
Nadie ha practicado cómo segmentar una sede limpia en 30 minutos.

Ahí es cuando un incidente de IT se convierte en una crisis de empresa.

Qué hace distinto un SOC hoy (y qué tiene que ver la IA)

En un Security Operations Center (SOC) grande entran cada día miles de millones de eventos de muchísimas fuentes. Ya no es “un admin mirando el log del firewall”, sino un proceso industrializado de sensórica, correlación, automatización y análisis humano.

Lo interesante es el reparto de roles:

IA/automatización como primera línea: clasifica, correlaciona, detecta patrones y filtra lo obvio.
Humanos como segunda/tercera línea: cuando un caso es crítico o ambiguo, analistas toman decisiones y coordinan la respuesta.

Suena a “solo para grandes”, pero la idea también aplica a pequeñas empresas:

No tienes que montar tu propio SOC. Pero sí necesitas el mismo enfoque:

Recoge señales (EDR, firewall, logs de autenticación).
Define qué es “normal”.
Y ten un proceso que reaccione en minutos, no en días.

NotPetya ya era tan rápido en 2017 que ningún humano podía “reaccionar a tiempo” una vez iniciada la propagación. El punto de la IA es menos “aún más rápido” y más: ayudarte a encontrar antes la anomalía en el ruido (por ejemplo, si a las 03:00 de repente 500 equipos quieren hablar SMB entre sí). Esos minutos deciden: ver antes, contener antes, aislar antes.

Y luego está el mindset que cada vez veo más como estándar:

Assume breach.

Planifica como si el atacante ya estuviera dentro. No por paranoia, sino por pragmatismo.

Lo mínimo que quiero ver hoy (sin presupuesto enterprise)

Si te llevas algo de NotPetya, que sea esto:

NotPetya no fue “una vulnerabilidad”. Fue una cadena de debilidades que se amplificaban entre sí.

La buena noticia: precisamente por eso, unos básicos quitan muchísimo riesgo.

1) Gestión de parches y exposición (en serio)

Actualizaciones críticas de Windows (sobre todo en torno a SMB) no pueden quedar para “ya si eso”.
Todo lo expuesto hacia fuera tiene prioridad.
Y si hay legacy: al menos segmentado, con reglas claras.

2) Hacer incómodo el movimiento lateral

Separar cuentas admin (día a día vs. admin).
Contraseñas de admin local únicas por equipo (LAPS).
No dejar herramientas de admin remota (WMI, PsExec) abiertas en todas partes.
Restringir SMB donde no sea imprescindible.

3) Segmentación, pero pragmática

No tienes que hacer Zero Trust “perfecto” mañana. Pero:

Clientes, servidores, backups y OT/producción no deberían estar en una red plana.
Los Domain Controllers son tier 0 y hay que protegerlos como tal.
El tráfico este-oeste merece tanta atención como el tráfico a Internet.

4) Backups: offline, inmutables y probados

Lo digo como lo veo una y otra vez en proyectos:

Un backup que está siempre escribible y siempre conectado, en un incidente a menudo no es un backup.

3-2-1 es un buen inicio.
Almacenamiento inmutable (o medios offline) es un game changer.
Pruebas de restore son obligatorias. No “tenemos backups”, sino “hemos practicado restores”.

5) Runbooks de incidente y un “kill switch” por sede

No necesitas un manual de 80 páginas. Pero sí claridad:

¿Quién decide que se desconecta una sede?
¿Cómo bloqueas cuentas rápido?
¿Qué sistemas deben volver primero (AD, DNS, DHCP, VPN, ERP)?

Y sí: hay que practicarlo, o en un incidente no sirve.

Reality-check: en NotPetya, en muchos casos la medida más efectiva no fue “otra herramienta”, sino separación física. De Maersk hay relatos de gente corriendo por oficinas y desconectando cables de red/energía de switches para frenar la propagación. Suena básico, pero a veces es la mejor high-tech security cuando cuentan los segundos.

Conclusión

Para mí, NotPetya sigue siendo uno de los mejores ejemplos de por qué la seguridad no se resuelve con “tenemos antivirus”.

No fue devastador porque fuera magia. Fue devastador porque atacó puntos débiles muy normales:

confianza en actualizaciones
demasiado movimiento lateral
poca segmentación
backups demasiado pegados a producción

Y por eso es tan relevante para empresas “normales”.

Si inviertes hoy, no inviertas solo en herramientas: invierte en resiliencia (visibilidad, respuesta rápida y capacidad de restaurar sistemas de forma limpia). Esa es la diferencia entre “un día horrible” y “un trimestre que no recuperas”.

Fuentes y enlaces

Hasta la próxima, Joe