NotPetya: cuando «malware» se comportó como un mazo

NotPetya en una página: qué hizo y por qué importó

NotPetya fue ampliamente informado como ransomware. Operativamente, trátalo como un wiper con excelente distribución.
Usó múltiples métodos de propagación, capturó credenciales, se ejecutó mediante herramientas administrativas estándar de Windows y
luego saboteó el arranque del sistema sobrescribiendo partes del proceso de arranque del disco y cifrando estructuras necesarias para montar el sistema de archivos.

La implicación práctica: pagar no recuperaría confiablemente nada porque el flujo de «rescate» estaba funcionalmente roto.
El daño no fue «archivos bloqueados»; fue «máquinas que no arrancan, y la recuperación es reinstalar + restaurar».
Si tu modelo de recuperación asumía «limpiaremos los endpoints», NotPetya lo convirtió en «necesitamos reimaginar flotas y reconstituir la identidad».

NotPetya también expuso una verdad silenciosa: muchas empresas funcionan como un piso compartido con una llave maestra. El movimiento lateral
se vuelve trivial cuando las contraseñas de administrador local se reutilizan, los administradores de dominio inician sesión en escritorios al azar y la ejecución remota queda totalmente abierta.

Un máximo de ingeniería sigue aplicando, y es la cita que vale la pena mantener en tu pared:
La esperanza no es una estrategia. —idea parafraseada atribuida al General Gordon R. Sullivan

Broma #1: NotPetya era «ransomware» como una excavadora es «paisajismo». Puedes pagar; el jardín ya no existe.

Hechos y contexto que realmente deberías recordar

Esto no es trivia; son las palancas que explican por qué el incidente se propagó como lo hizo.

• Llegó en junio de 2017, propagándose rápido por redes corporativas y causando interrupciones globales.
• Entró comúnmente vía un mecanismo de actualización de software comprometido (compromiso clásico de la cadena de suministro), no solo phishing aleatorio.
• Abusó de herramientas administrativas de Windows como PSExec y WMIC—herramientas que tus administradores ya usaban diariamente.
• Usó robo de credenciales (escaneo de memoria / volcado de credenciales) para moverse lateralmente donde el parcheo no era suficiente.
• También se propagó vía SMB usando múltiples técnicas, incluyendo explotar hosts sin parchear y aprovechando credenciales válidas.
• Daño a la capacidad de arranque al manipular registros de arranque y cifrar estructuras clave del disco; la recuperación a menudo significó reimaginar.
• El canal de pago del rescate era efectivamente no funcional, lo que significa que incluso un «pago exitoso» no resultaba en una desencriptación organizada.
• Se etiquetó erróneamente al inicio como «Petya ransomware», lo que enturbió los playbooks de respuesta diseñados para ransomware con motivación económica.
• Resaltó los riesgos de redes planas: una vez dentro, buscó rutas de administración compartida como el agua busca grietas.

Si recuerdas solo una cosa: el vector de compromiso inicial importa menos que los controles internos que te faltaban.
NotPetya no fue un truco mágico; fue una auditoría de atajos cotidianos.

Cómo funcionó NotPetya: la mecánica de un “destructor” disfrazado de ransomware

1) Entrada: la cadena de suministro vence al teatro del perímetro

Organizaciones que «no eran objetivo» igual fueron afectadas porque el punto de entrada no fue en muchos casos un spearphishing personalizado.
Un mecanismo de actualización comprometido da al atacante un binario que parece firmado con un canal de distribución que ya permites.
Por eso «bloqueamos ejecutables en email» es necesario pero no suficiente; también es por lo que el filtrado de egress y el allowlisting de aplicaciones
se convierten en controles de seguridad reales, no en teatro de cumplimiento.

2) Propagación: exploit + credenciales + herramientas de administración

NotPetya no apostó por una sola técnica. Combinó múltiples maneras de moverse:

• Propagación tipo exploit contra implementaciones SMB vulnerables en sistemas Windows sin parchear.
• Propagación basada en credenciales una vez que obtuvo contraseñas/hashes, convirtiendo tus propios derechos de administrador en su transporte.
• Ejecución remota vía PSExec/WMIC, que a menudo pasaba porque «es interno» y «los admins lo necesitan».

Ese enfoque multifacético importa operativamente. La gestión de parches por sí sola no te salva si tu higiene de credenciales es mala.
A la inversa, contraseñas perfectas no te salvan si dejaste cajas heredadas sin parchear en el mismo dominio de broadcast que todo lo demás.
La defensa debe ser por capas porque el atacante ya lo está.

3) Payload: rompe la cadena de arranque, no solo los archivos

La familia «tipo Petya» es notoria por alterar el proceso de arranque. NotPetya atacó estructuras de disco de bajo nivel.
Esta es la parte que transforma un incidente de malware en un incidente logístico: canalizaciones de imagenado, fiabilidad de arranque por PXE desde USB,
paquetes de drivers, claves de recuperación de BitLocker y deriva de imágenes doradas de repente importan.

También aprendes rápidamente qué «copias de seguridad» eran solo instantáneas de datos ya cifrados y cuáles eran realmente inmutables,
offline y restaurables bajo presión.

4) Timing y comportamiento de reinicio: por qué se sintió como que el piso desapareció

NotPetya comúnmente forzaba un reinicio para ejecutar su sabotaje a nivel de arranque. Esto es psicológicamente importante: un usuario ve un reinicio,
encoge de hombros, toma café y vuelve a una pantalla con calaveras. Entonces el help desk llama a IT. Luego IT llama a todos.
Mientras tanto, el movimiento lateral ya ocurrió.

Por eso «lo apagaremos cuando lo veamos» suele llegar demasiado tarde. Si tu detección depende de que los usuarios finales estén atentos,
estás construyendo un sistema de seguridad con esperanza y cafeína.

5) El impacto real: identidad, DNS y servicios compartidos

NotPetya no solo mató escritorios. Rompió las cosas que esos escritorios usaban: controladores de dominio, servidores de archivos, servidores de despliegue,
puntos de distribución de software, colectores de monitorización. Cuando esos fallan, la empresa descubre que ni siquiera puede coordinar la recuperación.

Si tu plan de respuesta requiere «empujar un agente a todos los hosts» y tu distribución de software está caída, felicitaciones:
tu plan es un documento, no una capacidad.

Dónde fallaron las organizaciones: los puntos débiles previsibles

Redes planas: la arquitectura por defecto del arrepentimiento

Muchas LAN empresariales aún se comportan como un vecindario amistoso donde cada casa comparte el mismo pasillo.
Cuando NotPetya cae en un endpoint, puede ver recursos compartidos, puertos de gestión y rutas de ejecución remota por todas partes.
La segmentación no es glamorosa. También es la forma más barata de convertir una «caída global» en un «incidente local».

Expansión de credenciales: un administrador de dominio en una estación es una pistola cargada

NotPetya amaba las credenciales porque las credenciales son universales. Los exploits son exigentes; las contraseñas no.
Si administradores de dominio o cuentas de servicio de alto privilegio inician sesión en endpoints, esos secretos terminan en memoria, y la memoria es un buffet.
La corrección es aburrida y estricta: modelo de administración en niveles, estaciones de trabajo para acceso privilegiado, LAPS/Windows LAPS y remover privilegios de administrador a usuarios.

Ejecución remota abierta: PSExec no es el villano, tus controles lo son

PSExec y WMIC son comunes porque funcionan. NotPetya los usó porque se los permitiste por todas partes.
Puedes mantener gestión remota y aun así reducir el radio de impacto: restringe quién puede invocarlo, desde dónde puede invocarse,
regístralo y aísla las herramientas administrativas en subredes de gestión.

Copias de seguridad que no eran recuperables a escala

«Tenemos backups» es una frase que no significa nada a menos que puedas responder: recuperar qué, qué tan rápido, en qué orden,
y sin AD.
NotPetya obligó a las empresas a descubrir que su proceso de restauración dependía del AD de producción, DNS de producción y shares de archivos de producción.
Cuando esos están caídos, el runbook de restauración se vuelve danza interpretativa.

Monitorización que se quedó en silencio con la red

Logging y monitorización centralizada son geniales—hasta que están en la misma red que acaba de quedar inutilizable.
Necesitas al menos una vista fuera de banda: un tap, una red de gestión separada o telemetría basada en la nube que sobreviva al caos interno.
Si no puedes ver, no puedes diagnosticar y no puedes demostrar contención.

Guía de diagnóstico rápido: qué comprobar primero/segundo/tercero para encontrar el cuello de botella rápidamente

Esto es para la primera hora, cuando todos gritan y tu trabajo es convertir el pánico en una cola.
El objetivo es identificar: (1) ¿seguimos propagando?, (2) ¿qué servicio compartido es el cuello de botella?, (3) ¿qué podemos restaurar primero?

Primero: detener la hemorragia (propagación)

1. Confirma movimiento lateral activo observando picos en tráfico SMB/RPC, tormentas de autenticación y creación de servicios remotos.
2. Tira de los frenos de la red estratégicamente: bloquea SMB (445) entre segmentos; restringe protocolos administrativos a subredes de gestión.
3. Deshabilita rutas de herramientas abusadas conocidas temporalmente: creación de servicios PSExec, WMI remoto y shares administrativos entre VLANs de usuarios.

Segundo: proteger y validar servicios de identidad

1. Revisa controladores de dominio: ¿son accesibles, saludables, con hora sincronizada y no reiniciándose en cosas raras?
2. Congela cuentas privilegiadas: deshabilita o resetea cuentas de alto riesgo, rota credenciales de servicio donde sea factible.
3. Confirma integridad de DNS y DHCP: si la resolución de nombres está envenenada o caída, las herramientas de recuperación fallarán de formas extrañas.

Tercero: decide la estrategia de recuperación (reconstruir vs restaurar)

1. Elige una “isla dorada”: un segmento de red limpio con estaciones de administración limpias y herramientas limpias.
2. Prioriza servicios de negocio: ERP, envíos, manufactura, identidad, correo—lo que mantenga la operación crítica.
3. Valida copias de seguridad restaurando un sistema representativo en la isla dorada. No debatas; restaura.

Tu victoria más rápida suele ser restaurar capacidad (identidad + apps mínimas) en lugar de perseguir la forense perfecta.
La forense importa. También la nómina del viernes.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas prácticas que puedes ejecutar durante un incidente estilo NotPetya o en ejercicios de endurecimiento. Las salidas son ejemplos.
El punto no es memorizarlas; es generar memoria muscular sobre qué significa la salida y qué hacer después.

Tarea 1: Identificar tormentas súbitas de conexiones SMB en un gateway Linux

cr0x@server:~$ sudo ss -tnp '( sport = :445 or dport = :445 )' | head
ESTAB 0 0 10.10.20.5:51234 10.10.30.12:445 users:(("smbd",pid=2140,fd=45))
SYN-SENT 0 1 10.10.20.5:51301 10.10.30.19:445 users:(("smbclient",pid=9921,fd=3))
ESTAB 0 0 10.10.20.8:49822 10.10.30.12:445 users:(("smbd",pid=2140,fd=52))
...

Qué significa: Un estallido de intentos nuevos de SMB (SYN-SENT) junto con muchas sesiones establecidas puede indicar escaneo tipo gusano o acceso masivo a shares.

Decisión: Si esto es anormal, bloquea 445 entre VLANs de usuarios inmediatamente y restringe SMB solo a subredes de servidores de archivos.

Tarea 2: Ver los mayores emisores hacia el puerto 445 en un router/firewall

cr0x@server:~$ sudo conntrack -L | grep dport=445 | awk '{print $5}' | cut -d= -f2 | sort | uniq -c | sort -nr | head
  482 src=10.10.20.5
  219 src=10.10.20.8
   77 src=10.10.21.33
...

Qué significa: Un pequeño conjunto de fuentes generando cientos de flujos SMB es sospechoso en redes de oficina.

Decisión: Aísla a los emisores principales a nivel de puerto de switch o VLAN. No esperes a que las herramientas de endpoint cooperen.

Tarea 3: Comprobar salud de replicación de dominio Windows desde un host de gestión (vía WinRM)

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"repadmin /replsummary\""
Replication Summary Start Time: 1/22/2026 02:14:50

Source DSA          largest delta    fails/total %%   error
DC1                 00:01:12         0 / 20    0
DC2                 00:00:58         0 / 20    0

Destination DSA     largest delta    fails/total %%   error
DC1                 00:01:12         0 / 20    0
DC2                 00:00:58         0 / 20    0

Qué significa: Una replicación saludable sugiere que AD no se está colapsando actualmente. Durante un wiper, la estabilidad de AD es oxígeno.

Decisión: Si fallan las replicaciones o los deltas crecen, prioriza el aislamiento y recuperación de DCs sobre los servidores de apps. Todo lo demás depende de ello.

Tarea 4: Detectar creación inesperada de servicios remotos (común con PSExec)

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045; StartTime=(Get-Date).AddHours(-2)} | Select-Object -First 5 | Format-List\""
ProviderName : Service Control Manager
Id           : 7045
Message      : A service was installed in the system. Service Name: PSEXESVC Display Name: PSEXESVC
...

Qué significa: El evento ID 7045 con PSEXESVC indica ejecución remota al estilo PSExec.

Decisión: Si es inesperado, bloquea shares administrativos entrantes y llamadas remotas al SCM entre segmentos de estaciones; investiga las hosts origen de inmediato.

Tarea 5: Buscar trazas de ejecución remota WMIC

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-2)} | Where-Object { $_.Message -match 'wmic.exe' } | Select-Object -First 3 | Format-Table -Auto\""
TimeCreated           Id Message
-----------           -- -------
1/22/2026 01:42:10 4688 A new process has been created... New Process Name: C:\Windows\System32\wbem\WMIC.exe ...

Qué significa: Eventos de creación de proceso que hacen referencia a WMIC pueden indicar ejecución remota o herramientas de inventario. El contexto importa.

Decisión: Si aparece en endpoints de usuarios o desde procesos padre inusuales, trátalo como compromiso activo y aísla el host.

Tarea 6: Confirmar si SMBv1 sigue habilitado en hosts Windows

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol\""
FeatureName      : SMB1Protocol
State            : Enabled

Qué significa: SMBv1 habilitado es un amplificador persistente de riesgo; no es «la causa», pero aumenta la velocidad de los malos días.

Decisión: Deshabilita SMBv1 ampliamente, pero planifícalo: identifica dependencias legacy primero y luego aíslas esas excepciones. No permitas que una copiadora antigua dicte la seguridad de la red.

Tarea 7: Ver qué hosts exponen shares administrativos desde una caja scanner Linux

cr0x@server:~$ for ip in 10.10.20.{1..20}; do timeout 1 bash -c "echo >/dev/tcp/$ip/445" 2>/dev/null && echo "$ip:445 open"; done
10.10.20.5:445 open
10.10.20.8:445 open
10.10.20.12:445 open

Qué significa: Mucha exposición de 445 entre estaciones de trabajo facilita el movimiento lateral.

Decisión: Implementa reglas de firewall de host o ACLs de red para que las estaciones no acepten SMB desde pares.

Tarea 8: Identificar máquinas que se reinician inesperadamente (perspectiva de host de virtualización Linux)

cr0x@server:~$ sudo journalctl -u libvirtd --since "2 hours ago" | grep -E "shutdown|reboot|destroy" | head
Jan 22 01:31:02 hv01 libvirtd[1120]: Domain win-app-03 destroyed
Jan 22 01:31:18 hv01 libvirtd[1120]: Domain win-app-03 started
...

Qué significa: Patrones de reinicio súbitos en VMs Windows pueden alinearse con malware que provoca reinicios para ejecutar cambios a nivel de arranque.

Decisión: Pausa reinicios automáticos; haz snapshots de discos forenses cuando corresponda; aísla la conectividad de red de VMs sospechosas.

Tarea 9: Comprobar visibilidad de MBR/tabla de particiones desde un entorno de rescate Linux

cr0x@server:~$ sudo fdisk -l /dev/sda | head -n 15
Disk /dev/sda: 240 GiB, 257698037760 bytes, 503316480 sectors
Disk model: SSD 860 EVO
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1  *     2048 503316479 503314432   240G  7 HPFS/NTFS/exFAT

Qué significa: Si fdisk muestra basura, label desconocida o particiones faltantes, probablemente hubo manipulación del registro de arranque.

Decisión: No intentes «arreglos rápidos» en discos de producción. Preserva imágenes para investigación; procede con reconstrucción + restauración salvo que tengas un plan de recuperación probado.

Tarea 10: Validar inmutabilidad/suposiciones de air-gap de backups (ejemplo en object storage vía s3cmd)

cr0x@server:~$ s3cmd info s3://corp-backups/windows/DC1-2026-01-22.vhdx
File size: 68719476736
Last mod: Tue, 22 Jan 2026 01:10:02 GMT
MIME type: application/octet-stream
MD5 sum: 1b2c3d4e5f...
Server side encryption: AES256

Qué significa: El backup existe y los metadatos son coherentes. Esto no prueba que esté sin modificar o que sea restaurable, pero es la primera puerta.

Decisión: Intenta una restauración inmediata en una red aislada. Si la restauración no se completa en una prueba controlada, trata los backups como no confiables.

Tarea 11: Comprobar si hay deriva de “todos son admin local” en Windows

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-LocalGroupMember -Group 'Administrators' | Select-Object Name\""
Name
----
BUILTIN\Administrator
CORP\Domain Admins
CORP\Helpdesk
CORP\someuser

Qué significa: Grupos de dominio y usuarios aleatorios en Administradores locales hacen que el volcado de credenciales sea mucho más valioso.

Decisión: Elimina grupos amplios del admin local; adopta LAPS; aplica acceso privilegiado mediante cuentas y dispositivos dedicados.

Tarea 12: Confirmar si las políticas de caché de credenciales son demasiado permisivas

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"reg query 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' /v CachedLogonsCount\""
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    CachedLogonsCount    REG_SZ    10

Qué significa: Los inicios de sesión en caché ayudan a laptops a funcionar offline, pero también implican más material de credenciales en endpoints.

Decisión: Ajusta la caché de inicios de sesión según necesidad de negocio. Para segmentos de alto riesgo (finanzas, admins), reduce el cacheo y exige MFA + estaciones privilegiadas.

Tarea 13: Encontrar tormentas de autenticación Kerberos que insinúen abuso de credenciales

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddMinutes(-30)} | Measure-Object\""
Count    : 18423
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

Qué significa: Un pico súbito en eventos de emisión de tickets puede correlacionar con intentos de autenticación masivos y movimiento lateral.

Decisión: Limita y aísla subredes sospechosas; investiga los hosts que más solicitan; considera restablecimientos de contraseña de emergencia para cuentas de servicio expuestas.

Tarea 14: Verificar que tu “imagen dorada” sea realmente recuperable y esté actualizada

cr0x@server:~$ ls -lh /srv/images/windows-2019-golden.wim
-rw-r--r-- 1 root root 5.3G Jan 10 03:12 /srv/images/windows-2019-golden.wim

Qué significa: Tienes un archivo de imagen. La marca de tiempo sugiere que puede estar desactualizada respecto al ritmo de parches.

Decisión: Si la imagen está vieja, reconstruyela ahora en tiempo de paz. Durante un brote, imágenes obsoletas crean un segundo incidente: desplegar masivamente con vulnerabilidades conocidas.

Broma #2: Tu runbook de incidente que depende de «conectarse al host infectado y ejecutar la herramienta» es adorable.
Es como planear apagar un incendio enviando un email al humo.

Tres mini-historias corporativas del radio de impacto

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa manufacturera mediana tenía un entorno Windows mixto: una red de oficina moderna más máquinas heredadas cercanas a OT
que «no podían tocarse» porque controlaban líneas de empaquetado. El equipo de seguridad supuso que las máquinas OT estaban aisladas
porque estaban en un rango IP diferente. No estaban aisladas. Simplemente tenían numeración distinta.

Cuando la infección inicial apareció en contabilidad, la primera respuesta fue clásica: bloquear adjuntos de email, bloquear algunos hashes
y decir a los usuarios que dejaran de clicar cosas. El equipo creyó que la amenaza se quedaría donde empezó, porque «es ransomware».
En una hora, los tickets del help desk se dispararon: shares de archivos indisponibles, inicios de sesión con timeout, reinicios aleatorios.

La suposición equivocada se mostró en el firewall: casi no existían reglas internas este-oeste. SMB, RPC y shares administrativos fluían libremente.
El «rango OT» era plenamente accesible desde escritorios de oficina porque alguien había necesitado empujar una actualización y nunca quitó la regla.
Esa regla vieja ahora era una autopista.

La recuperación fue brutal pero clarificadora. Tuvieron que reconstruir endpoints a escala, luego reconstruir la confianza: estratificación de AD, LAPS, segmentación por función
y la regla explícita de «no SMB entre estaciones». La lección dolorosa no fue que el malware sea ingenioso. La lección fue que las redes son honestas:
si es enrutable, es accesible.

Mini-historia 2: La optimización que salió mal

Una compañía minorista había optimizado su administración de Windows por velocidad. El equipo de gestión de endpoints usaba una única cuenta de servicio altamente privilegiada
para desplegar software mediante ejecución remota en miles de máquinas. Era eficiente, consistente y querida.
«Una cuenta para gobernarlos a todos», decían en reuniones, con exactamente la cantidad equivocada de confianza.

Durante el brote, el volcado de credenciales convirtió esa optimización en un multiplicador de catástrofes.
Una vez que el material de la credencial de la cuenta de servicio se cosechó en una sola máquina, se volvió una llave maestra para la flota.
El malware no necesitó forzar contraseñas. Simplemente se hizo pasar por exactamente lo que la empresa usaba para control.

El equipo intentó contener apagando la plataforma de gestión, pero la plataforma no era el único problema—la credencial lo era.
Deshabilitar la cuenta frenó algo de propagación, pero también rompió flujos legítimos de recuperación remota.
Habían diseñado accidentalmente un entorno donde el mismo mecanismo que facilitaba operaciones también aceleraba al atacante.

La solución no fue «nunca centralizar». Fue centralizar con límites: cuentas de despliegue por segmento,
delegación restringida, administración con lo justo y separación fuerte entre planos de gestión y endpoints de usuario.
Hoy aún despliegan rápido. Solo que ya no lo hacen con una contraseña maestra que pueda ser raspada de la RAM.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una firma de servicios profesionales tenía una costumbre de la que nadie se jactaba: simulacros trimestrales de restauración que asumían que AD no estaba disponible.
No era un ejercicio de mesa. Era práctico, con una red limpia, orden de operaciones documentado
y una insistencia irritante en anotar qué se rompió.

Cuando se presentó comportamiento estilo NotPetya (entrada por cadena de suministro, movimiento lateral rápido, fallos de arranque), su monitorización se iluminó
y hicieron algo poco sexy de inmediato: detuvieron SMB este-oeste en el núcleo y luego crearon una subred de gestión limpia.
Aceptaron que algunos hosts estaban perdidos y pasaron directamente a la reconstrucción.

Los simulacros de restauración rindieron frutos de forma muy específica: tenían copias offline del material de recuperación de AD y sabían cómo levantar
un servicio de identidad mínimo sin depender del dominio infectado. También sabían qué backups eran «agradables de tener» y cuáles
eran esenciales para facturación y entregas a clientes.

Aún tuvieron una semana mala. Pero fue una semana, no un mes. La «salsa secreta» no fue un producto.
Fue la disciplina de probar las partes aburridas: restauraciones, acceso privilegiado y reglas de segmentación que hacen bostezar a los arquitectos.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: «Aislamos la primera laptop infectada, pero más máquinas siguen muriendo.»

Causa raíz: El movimiento lateral ya ocurrió vía credenciales y herramientas administrativas; el host inicial no fue el único propagador.

Solución: Bloquea SMB y protocolos administrativos remotos entre segmentos de estaciones; rota credenciales de alto valor; busca actividad PSExec/WMIC a escala.

2) Síntoma: «El parcheo no ayudó; estábamos parcheados y aún nos afectó.»

Causa raíz: El estado de parches reduce explotabilidad pero no previene la propagación basada en credenciales ni la entrada por cadena de suministro.

Solución: Aplica principio de menor privilegio, LAPS, administración por niveles y segmentación de red. Trata la higiene de credenciales como un control primario, no para después.

3) Síntoma: «Existen backups, pero restaurar es imposible ahora mismo.»

Causa raíz: El proceso de restauración depende del AD/DNS/shares de producción, que están caídos o no son confiables.

Solución: Construye un entorno de restauración en sala limpia; mantiene credenciales/llaves offline; ensaya restauraciones con AD caído; conserva copias inmutables/offline.

4) Síntoma: «No podemos iniciar sesión en ningún lado; la autenticación falla por completo.»

Causa raíz: Controladores de dominio afectados, desincronización de hora, problemas de DNS o restablecimientos masivos de contraseñas hechos sin secuencia.

Solución: Estabiliza DCs primero; verifica sincronización de hora; valida DNS; realiza rotación controlada de credenciales empezando por cuentas tier-0.

5) Síntoma: «Las herramientas de endpoint muestran todo en verde, pero los usuarios reportan bucles de reinicio y fallos de arranque.»

Causa raíz: Manipulación del registro de arranque y daño a nivel de disco; los agentes no pueden reportar si el OS no carga.

Solución: Pasa a un flujo de imagenado/reconstrucción; preserva imágenes forenses de discos; no pierdas horas intentando ‘limpiar’ sistemas que no inician.

6) Síntoma: «La contención falló porque no pudimos aplicar reglas de firewall lo suficientemente rápido.»

Causa raíz: Dependencia excesiva en gestión centralizada que comparte el destino con la red infectada.

Solución: Prepara playbooks de ACL en switches/firewalls core; mantén acceso fuera de banda; prueba rutas de cambio de emergencia.

7) Síntoma: «Solo una oficina subsidiaria recibió la actualización, pero la central también cayó.»

Causa raíz: Conectividad hub-and-spoke con confianza amplia; credenciales de administración compartidas o servicios compartidos entre redes.

Solución: Segmenta por límites de confianza; restringe uso de credenciales administrativas entre sitios; usa dominios de gestión separados o jump hosts PAM.

Listas de verificación / plan paso a paso

Fase 0 (ahora, antes del próximo brote): reducir el radio de impacto

1. Segmenta la red: bloquea SMB/RPC entre estaciones por defecto. Permite solo a servidores necesarios.
2. Deshabilita SMBv1 ampliamente; aísla excepciones detrás de ACLs estrictas.
3. Despliega LAPS/Windows LAPS para que las contraseñas de admin local sean únicas y rotadas.
4. Clasifica tus cuentas administrativas: no inicios de sesión de admin de dominio en estaciones; usa estaciones para acceso privilegiado.
5. Bloquea PSExec/WMIC: restringe quién puede ejecutar remotamente; monitoriza creación de servicios y llamadas WMI sospechosas.
6. Haz los backups resistentes: copias inmutables, offline/air-gapped cuando sea posible, y simulacros de restauración que asuman AD caído.
7. Prepara una isla dorada: hosts de salto limpios, herramientas limpias y una subred de gestión que funcione durante un incidente.
8. Instrumenta el tráfico este-oeste: si no puedes ver el movimiento lateral, no puedes contenerlo.

Fase 1 (primera hora): contener

1. Declara el incidente temprano y congela cambios riesgosos. Necesitas un comandante técnico, no un comité.
2. Bloquea SMB (445) y administración remota (p. ej. RPC/shares) entre VLANs de estaciones en el core.
3. Aísla a los emisores principales identificados vía telemetría de red (tormentas SMB, tormentas de autenticación).
4. Protege DCs: aíslalos lógicamente; asegura que solo subredes de gestión puedan alcanzar los puertos admin.
5. Deshabilita o resetea cuentas de alto valor si se sospecha compromiso (admins de dominio, cuentas de despliegue).

Fase 2 (día 1–3): recuperar capacidad, luego confianza

1. Levanta un entorno de gestión limpio (jump host, imageado, logging) separado de segmentos infectados.
2. Reconstruye desde imágenes conocidas buenas en lugar de “limpiar” endpoints. Los wipers castigan el optimismo.
3. Restaura servicios prioritarios en orden de dependencia: identidad/DNS/DHCP → apps centrales → servicios de archivos → endpoints.
4. Rota credenciales sistemáticamente empezando por tier-0. Documenta qué se rotó y cuándo.
5. Prueba la contención con evidencia de red y logs antes de reconectar segmentos.

Fase 3 (semana 2+): no desperdicies el dolor

1. Escribe la línea temporal mientras las memorias están frescas: acceso inicial, propagación, detección, contención, recuperación.
2. Mide MTTR honestamente: no cuando los servidores arrancaron, sino cuando el negocio se reanudó.
3. Convierte hallazgos en controles: reglas de segmentación, estratificación de cuentas, simulacros de backup y monitorización que sobreviva caídas.

Preguntas frecuentes

¿NotPetya es ransomware o un wiper?

Trátalo operativamente como un wiper. Presentó una nota de rescate, pero la recuperación mediante pago no era confiable.
El efecto fue destructivo y sistémico.

¿Por qué se propagó tan rápido dentro de las compañías?

Porque combinó múltiples métodos: explotación SMB, robo de credenciales y ejecución remota mediante herramientas administrativas estándar.
Redes planas y credenciales compartidas hicieron que el entorno interno se comportara como una gran zona de confianza.

¿Deshabilitar SMBv1 lo hubiese prevenido?

Habría reducido una vía de propagación de alto riesgo, pero no habría eliminado la propagación basada en credenciales ni el abuso de herramientas administrativas.
Necesitas segmentación, mínimo privilegio e higiene de credenciales además de parcheo y endurecimiento de protocolos.

¿Cuál es la medida de contención más importante?

Detener el movimiento este-oeste: bloquear SMB y protocolos administrativos remotos entre segmentos de estaciones a nivel de red.
El aislamiento de endpoints es genial cuando funciona; los controles de red funcionan cuando los endpoints ya están incendiándose.

¿Debemos apagar máquinas infectadas?

A veces. Si tienes evidencia de propagación activa desde un host, retirarlo de la red ayuda.
Pero no pierdas tiempo jugando a buscar y destruir; enfócate en contención de red y rotación de credenciales. También preserva evidencia forense si es necesario.

¿Cómo fallan los backups en eventos como este?

Comúnmente por dependencia: restauraciones requieren AD/DNS de producción, el catálogo de backups está en un share infectado o las copias no son inmutables y también se borran.
La cura son los simulacros de restauración en sala limpia y al menos una copia offline/inmutable.

¿Qué debemos monitorizar para detectar movimiento lateral tipo NotPetya?

Picos de conexiones SMB, logs de eventos de creación de servicios remotos (p. ej. PSEXESVC), ejecución WMI inusual, tormentas de autenticación (Kerberos/NTLM)
y reinicios súbitos en muchos hosts.

¿Ayuda el allowlisting de aplicaciones?

Sí, especialmente contra binarios inesperados y ejecuciones sospechosas desde rutas escribibles por usuarios.
Pero el allowlisting no te salvará si el atacante ejecuta herramientas legítimas con credenciales robadas. Úsalo como una capa, no como un talismán.

¿Cómo recuperamos Active Directory de forma segura si los DCs fueron afectados?

Con un plan documentado y ensayado: aislar DCs sospechosos, validar replicación/salud, decidir si restaurar desde backups confiables
y rotar credenciales privilegiadas tras restablecer la confianza. Si nunca has practicado recuperación de AD, no improvises durante la crisis.

¿Cuál es la mejor defensa a largo plazo contra una entrada por cadena de suministro?

No puedes «firewallear» salir de la confianza en proveedores. Reduce el impacto con segmentación, mínimo privilegio y monitorización fuerte.
Además endurece flujos de actualización: verifica cadenas de firma, restringe dónde pueden ejecutarse sistemas de actualización y aísla esos sistemas de endpoints de usuario.

Próximos pasos prácticos

NotPetya no fue impresionante porque fuera novedoso. Fue impresionante porque era compatible con cómo las empresas realmente operan:
credenciales compartidas, amplia alcanzabilidad de red y una confianza excesiva en que «interno» equivale a «seguro».

Si administras sistemas de producción, haz tres cosas este trimestre:

1. Implementa segmentación que bloquee SMB/RPC entre estaciones y pruébala con tests.
2. Arregla la higiene de credenciales: LAPS, estratificación de admins y sin sesiones de admin de dominio en endpoints.
3. Realiza un simulacro de restauración asumiendo AD caído, usando una red limpia y un objetivo temporizado.

No necesitas predecir el próximo NotPetya. Necesitas hacer tu entorno aburrido para destruir: lento para propagarse, difícil para saltar con credenciales
y fácil de reconstruir desde partes limpias. Eso es resiliencia cuando el «malware» llega con un mazo.