WannaCry: el ransomware que recordó a todos que existen los parches

Qué pasó realmente (y por qué funcionó)

WannaCry llegó en mayo de 2017 y hizo lo que todo SRE teme: transformó un problema interno de higiene en un desastre visible para clientes a velocidad de internet.
El núcleo del brote no fue un correo de phishing con ingeniería social impecable. Fue un exploit sobre SMB encadenado a un gusano.
Si un host Windows era vulnerable y accesible por TCP/445, podía ser atacado, cifrado y usado como plataforma de lanzamiento para atacar al siguiente.

Esto importa operacionalmente porque cambió la forma de responder incidentes. Con el ransomware típico buscas acceso inicial, credenciales robadas y movimiento lateral mediante herramientas administrativas.
Con WannaCry también tenías que tratar la red como una placa de Petri: cualquier endpoint vulnerable podía ser el paciente cero en su propia subred.
“Contener” no era solo deshabilitar cuentas y bloquear C2. Era detener un exploit auto-propagable antes de que convirtiera tu red plana en leña.

Aquí está la parte que la gente minimiza: Microsoft lanzó un parche para la vulnerabilidad SMB (MS17-010) antes del brote. La industria aun así fue arrasada.
No fue “porque parchear es difícil”. Fue porque muchas empresas habían construido procesos que hacían el parcheo opcional, lento o políticamente peligroso.
Sistemas que no podían reiniciarse. Aplicaciones “demasiado frágiles” para probar. Versiones legadas de Windows que nadie quería admitir que seguían ahí. Redes que asumían “interno = de confianza”.

WannaCry no ganó porque fuera brillante. Ganó porque encontró la fisura exacta entre “sabemos que deberíamos” y “lo haremos después”.

Datos rápidos y contexto histórico (las partes que la gente olvida)

• MS17-010 (marzo de 2017) abordó vulnerabilidades críticas en SMB explotadas luego por WannaCry; el parche existía antes del brote.
• EternalBlue fue el nombre del exploit ampliamente asociado a la vulnerabilidad SMB; formaba parte de un kit que se filtró públicamente.
• WannaCry incluía propagación tipo gusano, propagándose automáticamente vía SMB a otras máquinas vulnerables sin interacción del usuario.
• Un dominio interruptor incrustado en el malware redujo la propagación cuando se registró y fue accesible; muchas infecciones igual ocurrieron en entornos segmentados o con DNS bloqueado.
• SMBv1 fue un amplificador de riesgo; deshabilitar SMBv1 y endurecer SMB redujo la superficie de ataque y el radio de daño.
• Versiones legadas de Windows (notablemente lanzamientos antiguos sin soporte en ese momento) resultaron muy afectadas; luego se liberaron parches de emergencia para algunas.
• Servicios de salud y administraciones públicas se vieron especialmente interrumpidos; estos entornos suelen tener dispositivos de larga vida y ventanas de cambio limitadas.
• El pago del rescate no fue el coste principal; el tiempo de inactividad, la mano de obra de recuperación, la productividad perdida y el daño reputacional dominaron la factura.
• Redes internas planas convirtieron infecciones locales en caídas a nivel campus porque SMB era enrutable y ampliamente permitido.

Mecánica: EternalBlue, SMB y el comportamiento del gusano

Por qué SMB hizo esto tan explosivo

SMB es cómo Windows comparte archivos, impresoras y varios servicios de “conveniencia empresarial”. También es cómo el malware obtiene pase libre si permites que TCP/445 circule libremente.
En muchos entornos, SMB se permite en todas partes porque existen compartidos dondequiera y “siempre fue así”.
Esa suposición es un regalo para los atacantes: un host comprometido puede alcanzar a muchos otros con un protocolo que el sistema operativo trata como ciudadano de primer orden.

La propagación de WannaCry se apoyó en una falla en la implementación de SMB. El exploit tenía éxito, seguía ejecución de código, luego corría la carga útil de ransomware y el componente gusano seguía escaneando.
El resultado: velocidad. No paciencia de APT. Velocidad.

El interruptor de apagado: no es un escudo mágico

La comprobación de dominio incrustada funcionó como un pestillo de seguridad burdo: si el dominio resolvía y era accesible, el malware dejaba de ejecutarse.
Esto ralentizó dramáticamente el brote una vez que el dominio se registró y fue accesible para muchas víctimas.
Pero “accesible” implica muchas cosas.

Redes con DNS restringido, HTTP saliente bloqueado, sinkholes, o conectividad parcial aún podían ver infecciones.
Además, aparecieron variantes y copias rápidamente. Contar con un interruptor de apagado no es una estrategia; es una coincidencia que quizá no se repita.

Conclusión operativa: parchear es necesario pero no suficiente

Sí, parchear MS17-010 importa. Pero también necesitabas: inventario preciso, capacidad para aislar endpoints rápidamente, controles de movimiento lateral y copias de seguridad que no fueran modificables por las mismas máquinas que se cifraban.
WannaCry castigó los eslabones débiles en cada una de esas áreas.

Idea parafraseada de Werner Vogels (CTO de Amazon): “Todo falla, todo el tiempo—diseña para eso.”
WannaCry es lo que parece cuando diseñas como si parchear ocurriera eventualmente, y ese “eventualmente” nunca llega.

Los modos reales de fallo: parcheo, inventario y confianza

Modo de fallo 1: “Parcheamos… en su mayoría”

En la realidad empresarial, “parcheado” a menudo significa: un subconjunto de sistemas bajo gestión central, más un puñado de exclusiones, más una acumulación de servidores “especiales”, más portátiles que no conectaron VPN.
Al malware no le importa tu intención. Le importa la caja sin parche con TCP/445 abierto.

La solución no es “esforzarse más”. La solución es cumplimiento medible de parches con consecuencias: paneles, plazos y aplicación que trate las excepciones como ciudadanos de primera clase.

Modo de fallo 2: “No exponemos SMB a internet”

Bien. Internet no es el único modelo de amenaza. La propagación interna es lo que convirtió a WannaCry en un generador de caídas.
Una red plana con tráfico este-oeste permisivo hace que cada endpoint sea un atacante interno una vez comprometido.

Modo de fallo 3: “Tenemos copias de seguridad”

Muchas víctimas tenían backups. Algunos estaban online y escribibles, lo que significa que también fueron cifrados. Algunos estaban offline pero no probados, lo que significa que las restauraciones fallaron en el peor momento.
Si no puedes restaurar un servidor de archivos a un estado limpio en cronómetro, no tienes backups; tienes una historia reconfortante.

Modo de fallo 4: “Los sistemas legados son inevitables”

Algunos lo son. Eso no te da permiso para tenerlos desnudos en la LAN corporativa.
Si debes mantener un SO o dispositivo antiguo, envuélvelo: segmentalo, restringe su tráfico, controla el acceso administrativo y monitorízalo como si fuera radiactivo. Porque lo es.

Broma 1: “Nuestra política de parches era ‘si no está en llamas, no lo toques’. WannaCry trajo el fuego.”

Guion de diagnóstico rápido: qué comprobar primero/segundo/tercero

Este es el guion de “tienes 30 minutos antes de que el radio de daño se duplique”. Está sesgado hacia contención y triage sobre atribución perfecta.

Primero: detener la hemorragia (contención)

1. Identificar hosts infectados por síntomas: archivos de nota de rescate, extensiones de archivo súbitas, escaneo SMB elevado, alertas de endpoint.
2. Aislar máquinas sospechosas de la red (apagado de puerto de switch, VLAN de cuarentena NAC, aislamiento EDR). No “simplemente reinicies para ver”.
3. Bloquear movimiento lateral: restringir temporalmente TCP/445 entre subredes en firewalls núcleo. Si debes mantener SMB, solo permitir desde servidores de archivos conocidos hacia clientes conocidos.
4. Confirmar estado de parches en el resto de la flota, especialmente todo lo accesible en 445.

Segundo: determinar exposición (¿a dónde puede propagarse?)

1. Escanear internamente buscando oyentes en TCP/445 y mapearlos a propietarios/roles.
2. Verificar presencia y uso de SMBv1; planear deshabilitarlo ampliamente.
3. Encontrar sistemas sin parchear y priorizar los que tienen conectividad amplia (jump boxes, hosts de servicios compartidos, brokers VDI, servidores de archivos, sistemas adyacentes al dominio).

Tercero: decisiones de recuperación (restaurar vs reconstruir)

1. Decidir reconstruir vs restaurar: endpoints usualmente se reconstruyen; servidores dependen del rol y la madurez del backup.
2. Validar backups offline y asegurar que los objetivos de restauración estén limpios y parcheados.
3. Higiene de credenciales: asumir que credenciales de admin local y credenciales de dominio en caché pueden estar expuestas en endpoints infectados; rotar donde corresponda.

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

Estas tareas están escritas como si estuvieras en un host administrador Linux haciendo triage de red y consultando Windows mediante herramientas estándar cuando es posible.
En incidentes reales también usarás EDR/MDM, reenvío de eventos de Windows y tu CMDB. Pero los comandos no mienten, y son rápidos.

1) Descubrir exposición SMB interna rápidamente

cr0x@server:~$ nmap -n -Pn -p 445 --open 10.20.0.0/16 -oG smb-445.gnmap
Starting Nmap 7.94 ( https://nmap.org ) at 2026-01-22 10:17 UTC
Nmap scan report for 10.20.12.34
Host is up (0.0031s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
Nmap scan report for 10.20.55.10
Host is up (0.0020s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
Nmap done: 65536 IP addresses (4212 hosts up) scanned in 98.40 seconds

Qué significa: Estos hosts aceptan conexiones SMB. Son objetivos potenciales y posibles propagadores.
Decisión: Prioriza verificación de parches y reglas de segmentación para estas IPs primero. No empieces con las máquinas que “se sienten riesgosas”; empieza por las que son alcanzables.

2) Comprobar si SMBv1 está soportado por un objetivo (señal rápida)

cr0x@server:~$ smbclient -L //10.20.12.34 -N
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Qué significa: Esto puede indicar configuraciones SMB endurecidas, interferencia de firewall o que la negociación SMBv1 está bloqueada/deshabilitada.
Decisión: No asumas “bien”. Valida revisando la configuración del servidor de forma central. Si aún permites SMBv1 en otros sitios, sigue buscando.

3) Identificar versiones de Windows desde SMB (cuando está permitido)

cr0x@server:~$ crackmapexec smb 10.20.55.10
SMB         10.20.55.10     445    FS-LEGACY01       [*] Windows 7 Professional 7601 Service Pack 1 (name:FS-LEGACY01) (domain:WORKGROUP) (signing:False) (SMBv1:True)

Qué significa: Firma SMB apagada y SMBv1 habilitado son multiplicadores de riesgo; el SO es lo suficientemente viejo para merecer escrutinio extra.
Decisión: Si este sistema es crítico y no puede actualizarse rápido, aíslarlo en una VLAN estricta y restringir acceso SMB solo a lo necesario.

4) Detectar escaneo activo de SMB (comportamiento tipo gusano)

cr0x@server:~$ sudo tcpdump -ni eth0 'tcp dst port 445 and (tcp[tcpflags] & (tcp-syn) != 0)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:21:11.102938 IP 10.20.88.44.51532 > 10.20.12.34.445: Flags [S], seq 10293812, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10:21:11.103114 IP 10.20.88.44.51533 > 10.20.55.10.445: Flags [S], seq 7736123, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10:21:11.103290 IP 10.20.88.44.51534 > 10.20.101.9.445: Flags [S], seq 5512312, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10 packets captured

Qué significa: Un host está rociando SYNs a muchos objetivos SMB. Ese es comportamiento clásico de propagación de gusano.
Decisión: Aísla 10.20.88.44 inmediatamente. Luego busca otros escáneres; los gusanos rara vez viajan solos en una red grande.

5) Mapear el host escaneador a una MAC y puerto de switch (listo para contención)

cr0x@server:~$ arp -n | grep 10.20.88.44
10.20.88.44 ether 00:25:90:ab:12:ef C eth0

Qué significa: Tienes la dirección MAC del host sospechoso.
Decisión: Usa tu switch/controlador para cerrar el puerto o moverlo a una VLAN de cuarentena. No pierdas tiempo enviando correos al equipo de escritorios.

6) Comprobar si tus servidores de archivos Linux están siendo golpeados (conteo de conexiones SMB)

cr0x@server:~$ sudo ss -tn sport = :445 | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51533
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51534
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51535

Qué significa: Un único cliente está abriendo muchas conexiones SMB a tu servidor. Podría ser legítimo, un escaneo, software de backup o malware.
Decisión: Correlaciona con tcpdump y logs de Windows. Si el peer es sospechoso, bloquéalo en el firewall del host mientras la contención de red avanza.

7) Confirmar parche MS17-010 en Windows vía presencia de paquetes (comprobación de artefactos offline)

cr0x@server:~$ strings WS2012R2-C_drive/Windows/Logs/CBS/CBS.log | grep -E 'KB4012213|KB4012216|KB4012598' | tail -n 3
2017-04-02 08:14:09, Info                  CBS    Package: Package_for_KB4012213~31bf3856ad364e35~amd64~~6.3.1.0, state: Installed
2017-04-02 08:14:10, Info                  CBS    Mark store corruption flag because of package: Package_for_KB4012213~31bf3856ad364e35~amd64~~6.3.1.0
2017-04-02 08:14:15, Info                  CBS    Session: 30712533_1972450825 finalized. Reboot required: no

Qué significa: El host parece tener instalado un KB relevante (el KB exacto depende del SO).
Decisión: Trata esto como evidencia de apoyo, no como prueba. Aún valida el estado de SMBv1 y la postura de vulnerabilidad; los parches parciales y los rollback ocurren.

8) Verificar estado SMBv1 en un host Windows vía consulta remota (cuando tengas WinRM)

cr0x@server:~$ evil-winrm -i 10.20.55.10 -u 'ops' -p 'REDACTED' -s . -c "powershell -NoProfile -Command \"Get-SmbServerConfiguration | Select EnableSMB1Protocol,EnableSMB2Protocol\""
EnableSMB1Protocol EnableSMB2Protocol
------------------ ------------------
True               True

Qué significa: SMBv1 está habilitado. Eso es un problema que puedes arreglar hoy, no “en un programa”.
Decisión: Planifica un cambio de emergencia para deshabilitar SMBv1, empezando por endpoints y servidores no críticos, luego ampliando. Valida dependencias de aplicaciones en lugar de adivinar.

9) Comprobar si TCP/445 se permite este-oeste a través de un firewall (prueba rápida de realidad)

cr0x@server:~$ sudo traceroute -T -p 445 10.20.12.34
traceroute to 10.20.12.34 (10.20.12.34), 30 hops max, 60 byte packets
 1  10.20.88.1 (10.20.88.1)  0.421 ms  0.388 ms  0.361 ms
 2  10.20.0.1 (10.20.0.1)    0.910 ms  0.899 ms  0.885 ms
 3  10.20.12.34 (10.20.12.34)  1.914 ms  1.902 ms  1.890 ms

Qué significa: Nada está bloqueando el camino para TCP/445 entre redes; probablemente el tráfico fluye libremente.
Decisión: Implementa ACLs temporales en el núcleo para restringir 445. Un cambio a corto plazo que “rompa algunos flujos” es más barato que una outage de larga duración.

10) Buscar artefactos de nota de ransomware en un snapshot de compartido (triage sin tocar endpoints)

cr0x@server:~$ find /srv/samba/shares -maxdepth 4 -type f -iname '@Please_Read_Me@.txt' -o -iname '*WanaDecryptor*' | head
/srv/samba/shares/finance/@Please_Read_Me@.txt
/srv/samba/shares/hr/@Please_Read_Me@.txt

Qué significa: Probablemente hubo actividad de cifrado en estos directorios. Puedes acotar el impacto sin iniciar sesión en cajas Windows sospechosas.
Decisión: Congela el share (solo lectura) si es posible y preserva evidencia. Empieza la planificación de restauración desde el último snapshot o backup conocido bueno.

11) Validar que los backups no estén montados como escritura en producción (un clásico auto-boicot)

cr0x@server:~$ mount | grep -E 'backup|repo|vault'
backup01:/repo on /mnt/backup_repo type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.55.200,local_lock=none,addr=10.20.1.50)

Qué significa: Tu repositorio de backups está montado como lectura/escritura en un servidor de producción. Eso es una invitación a cifrar tu red de seguridad.
Decisión: Pasa a un modelo pull o monta solo lectura donde sea factible. Aplica inmutabilidad/WORM en objetivos de backup. Si no puedes, al menos aísla credenciales y rutas de red.

12) Comprobar disponibilidad de snapshots para restauración rápida (pregunta inicial del ingeniero de almacenamiento)

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/shares@2026-01-22_0000  Wed Jan 22 00:00 2026
tank/shares@2026-01-22_0100  Wed Jan 22 01:00 2026
tank/shares@2026-01-22_0200  Wed Jan 22 02:00 2026
tank/shares@2026-01-22_0300  Wed Jan 22 03:00 2026
tank/shares@2026-01-22_0400  Wed Jan 22 04:00 2026

Qué significa: Tienes snapshots frecuentes. Ese es tu mejor amigo durante eventos de ransomware porque es rápido y granular.
Decisión: Identifica el último snapshot limpio (antes del cifrado). Planea una estrategia de clon/rollback que evite sobrescribir evidencia y minimice el tiempo de inactividad.

13) Identificar qué cliente modificó archivos cifrados (logs de Samba)

cr0x@server:~$ sudo journalctl -u smbd --since "2026-01-22 03:00" | grep -E 'rename|unlink|pwrite' | head -n 6
Jan 22 03:07:12 fileserver smbd[1823]: [2026/01/22 03:07:12.221] rename finance/q1.xlsx -> finance/q1.xlsx.WNCRY
Jan 22 03:07:12 fileserver smbd[1823]: [2026/01/22 03:07:12.223] pwrite finance/q1.xlsx.WNCRY (client 10.20.88.44)
Jan 22 03:07:13 fileserver smbd[1823]: [2026/01/22 03:07:13.004] rename finance/payroll.csv -> finance/payroll.csv.WNCRY
Jan 22 03:07:13 fileserver smbd[1823]: [2026/01/22 03:07:13.009] pwrite finance/payroll.csv.WNCRY (client 10.20.88.44)

Qué significa: Has identificado la IP cliente que realiza escrituras destructivas.
Decisión: Esa IP es un objetivo inmediato de contención. Considera también revocar temporalmente el token de usuario/sesión si puedes mapearlo a identidad.

14) Verificar que tu DNS no esté haciendo algo “útil” que rompa el comportamiento del kill-switch

cr0x@server:~$ dig +short -t a example-killswitch-domain.invalid @10.20.0.53
10.20.0.10

Qué significa: Tu DNS interno está resolviendo NXDOMAIN a una IP local. Ese tipo de “utilidad” puede cambiar el comportamiento del malware de forma impredecible.
Decisión: Desactiva el wildcarding para dominios desconocidos en el DNS empresarial. Los controles de seguridad deben ser explícitos, no basados en sorpresas.

Broma 2: “Nada construye colaboración entre equipos como un ransomware. De repente todos saben dónde está el equipo de firewalls.”

Tres microhistorias corporativas desde las trincheras

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana operaba una mezcla de servidores Windows modernos y un conjunto obstinado de escritorios antiguos usados para supervisión de control industrial.
Todos “sabían” que esos escritorios estaban aislados. Estaban en una VLAN dedicada, después de todo. El diagrama de red lo decía, y el diagrama tenía un logo.

Durante una sesión de soporte remoto rutinaria, un técnico conectó uno de esos escritorios a una toma de pared conveniente en una zona de oficina general.
El puerto estaba configurado para la VLAN de usuario por defecto por culpa del “hoteling”. El escritorio obtuvo una IP normal, enrutamiento normal, todo normal. Podía ver compartidos, impresoras y otros escritorios.
Nadie lo notó, porque nada se rompió de inmediato.

Cuando apareció el escaneo SMB estilo WannaCry en el entorno (no necesariamente la cepa original de 2017—existen variantes y gusanos similares), ese escritorio era vulnerable y alcanzable.
Se convirtió en fuente de intentos de infección lateral, y además tenía credenciales en caché de trabajos administrativos previos.
El brote no se detuvo por “la VLAN” porque la VLAN era tan real como la configuración del puerto del switch en ese momento.

El postmortem fue contundente: la suposición equivocada fue “los dispositivos permanecen donde pensamos que están”.
Las correcciones fueron igual de contundentes: aplicación de NAC para clases de dispositivos, políticas de seguridad de puerto que coincidieran con el diagrama y una regla de que las cajas legadas vivan detrás de un firewall, no de buenas intenciones.

La lección: si tu contención depende de que humanos conecten cables correctamente para siempre, no tienes contención. Tienes un plan con forma de esperanza.

Microhistoria 2: La optimización que salió mal

Otra organización se enorgullecía de su postura TI austera. Habían reducido las “ventanas de mantenimiento desperdiciadas” estirando los ciclos de parcheo.
En vez de lotes pequeños y frecuentes, hacían grandes eventos trimestrales de parches. Menos reinicios, menos pruebas de apps, menos correos enfadados.
El panel se veía limpio. El registro de riesgos parecía teórico.

También optimizaron operaciones de red: conectividad este-oeste amplia, firewall interno mínimo, porque la segmentación interna era “compleja” y “difícil de depurar”.
Se dijeron que el antivirus en endpoints atraparía lo importante. Era una historia bonita hasta que no lo fue.

Cuando apareció el comportamiento de gusano SMB, el entorno se comportó exactamente como fue diseñado: como una red interna de entrega rápida.
La brecha de parches se medía en semanas a meses. La conectividad interna en “todo puede hablar con todo”.
Para cuando la gente entendió que aquello no era una alerta de malware normal, una parte de la flota de estaciones de trabajo ya era irrecuperable sin reconstrucción.

La optimización no fue solo la cadencia de parches; fue la creencia institucional de que “menos cambios = más estabilidad”.
En seguridad, menos cambio a menudo equivale a dolor demorado con intereses.
Pasaron a parches mensuales, aplicaron expiraciones forzadas a excepciones e introdujeron restricciones SMB entre redes de usuarios y redes de servidores.

La lección: optimizar para menos cambios está bien—hasta que el mundo cambia por ti. Los gusanos son muy pro-cambio.

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

Una tercera empresa tenía reputación de ser molesta por su disciplina. Realizaban revisiones de cumplimiento de parches semanales. No es emocionante.
Tenían una ventana de cambios fija. Tampoco emocionante.
Usaban administración en niveles: credenciales admin de estaciones no tocaban servidores, y credenciales admin de servidores no tocaban controladores de dominio salvo cuando era necesario. Muy poco emocionante.

También trataban los compartidos como sistemas de producción. Snapshots horarios para los conjuntos de datos más críticos, copias diarias fuera del sitio con controles de inmutabilidad y un simulacro de restauración trimestral.
El simulacro de restauración era impopular. Consumía fines de semana y generaba tickets por los que nadie obtiene ascensos.

Cuando el ransomware afectó a un segmento de usuarios, cifró contenido de unidades mapeadas de un puñado de clientes.
Pero el SMB hacia la red de servidores estaba restringido, así que no se propagó entre servidores.
Los endpoints infectados fueron aislados por EDR en minutos, y los compartidos se restauraron a un snapshot limpio con pérdida mínima de datos.

El incidente aún costó tiempo y estrés—no hay cuentos de hadas aquí—pero no se convirtió en una caída a nivel empresa.
Los controles “aburridos” convirtieron una crisis existencial en un miércoles desagradable.

La lección: las prácticas aburridas se acumulan. No son noticia. Hacen que la supervivencia sea normal.

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

1) “Parcheamos MS17-010, así que estamos a salvo”

Síntoma: Sigues viendo escaneo SMB e infecciones en algunos hosts.
Causa raíz: El cumplimiento de parches fue incompleto (portátiles que faltaron, subredes aisladas, servidores manuales, deriva de imágenes), o SMBv1 siguió habilitado y expuesto.
Solución: Mide cumplimiento mediante verificación activa (escaneos y comprobaciones de configuración), no solo por “WSUS dice aprobado.” Deshabilita SMBv1. Restringe TCP/445 este-oeste.

2) “Bloqueamos SMB en el perímetro, ¿por qué se propaga?”

Síntoma: El brote es totalmente interno y sigue expandiéndose.
Causa raíz: Red interna plana con TCP/445 sin restricciones; se ignoró el modelo de amenaza interno.
Solución: Segmentación: solo permitir SMB entre clientes y servidores de archivos designados. Bloquear SMB entre estaciones. Usa reglas de firewall que coincidan con flujos de negocio, no subredes como política.

3) “EDR dice contenido, pero los compartidos siguen cifrándose”

Síntoma: Las alertas de endpoint se detienen, pero los archivos siguen cambiando a extensiones cifradas o aparecen notas de rescate.
Causa raíz: Un host infectado pero no aislado aún tiene acceso a shares; o un segundo host está comprometido; o se abusa de una cuenta de servicio.
Solución: Usa logs de servidores de archivos para identificar IPs cliente que modifican contenido. Pone temporalmente shares en solo lectura. Revoca tokens deshabilitando cuentas si es necesario y rota credenciales.

4) “Las restauraciones fallan”

Síntoma: Existen jobs de backup, pero la restauración es lenta, incompleta o corrupta.
Causa raíz: Backups estuvieron online y se cifraron; nunca se probaron; el servidor de backup usaba credenciales de admin de dominio expuestas a endpoints.
Solución: Implementa backups inmutables y credenciales separadas. Ejecuta pruebas rutinarias de restauración. Mantén repositorios de backup fuera del mismo límite de confianza que los endpoints.

5) “No podemos deshabilitar SMBv1 porque algo podría romperse”

Síntoma: Excepciones y retrasos sin fin; SMBv1 permanece activo por defecto.
Causa raíz: Dependencias desconocidas y falta de propietarios para apps/dispositivos legados.
Solución: Inventaria el uso de SMBv1, nombra propietarios y fuerza plazos. Si un dispositivo requiere SMBv1, aíslalo y pon un plan de reemplazo con fecha.

6) “No podemos reiniciar servidores para parches”

Síntoma: Sistemas críticos acumulan meses sin actualizaciones.
Causa raíz: Servicios frágiles sin alta disponibilidad, sin ventana de mantenimiento, o temor al cambio por fallos pasados.
Solución: Construye HA o re-architectura para que los reinicios sean rutinarios. Si no puedes reiniciar un servidor Windows, no es “crítico”, es “un punto único de fallo que te niegas a admitir.”

Listas de verificación / plan paso a paso

1) Checklist de respuesta de emergencia (primeras 4 horas)

1. Contener: Aislar endpoints infectados; bloquear TCP/445 entre segmentos de usuarios inmediatamente.
2. Delimitar: Identificar shares tocados; identificar hosts escaneadores; listar todos los oyentes SMB internamente.
3. Estabilizar: Proteger backups: desmontar repositorios de backup escribibles de producción; asegurar que credenciales de backup no se usen en endpoints.
4. Verificar parches: Priorizar cobertura MS17-010 en hosts expuestos por SMB y todo lo que tenga alcance amplio.
5. Comunicar: Informar al negocio qué se interrumpirá (restricciones SMB, reinicios forzados) y por qué. La claridad vence al optimismo.
6. Preservar evidencia: Snapshots/exportes de logs de shares afectados; colectar artefactos de endpoints si tienes capacidad forense.

2) Checklist de endurecimiento (próximos 7 días)

1. Deshabilitar SMBv1 de forma amplia; rastrear y aislar excepciones.
2. Forzar firma SMB donde sea factible, especialmente en servidores.
3. Segmentar redes: bloquear SMB entre estaciones; permitir solo SMB cliente→servidor necesario.
4. Cumplimiento de parches: definir SLA (ej., críticos en días) y aplicar mediante reportes + automatización.
5. Administración con privilegios mínimos: cuentas admin por niveles; no usar admin de dominio en endpoints.
6. Endurecimiento de backups: copias inmutables, opción offline/air-gapped y pruebas de restauración.
7. Registro: centralizar logs de eventos de Windows y de auditoría de servidores de archivos para atribución rápida de clientes.

3) Checklist de ingeniería (próximos 30–90 días)

1. Reconstruir la canalización de parches como un sistema de producción: anillos, canarios, rollback, métricas.
2. Precisión del inventario de activos: conciliar DHCP, AD, EDR y escaneos de red; dispositivos desconocidos se vuelven incidentes.
3. Diseñar para reinicios: HA donde sea necesario; ventanas de mantenimiento reales; eliminar la mitología de “no reiniciar”.
4. Cuentas de servicio: rotar regularmente; restringir derechos de logon; monitorizar actividad SMB anormal y cambios masivos de archivos.
5. Ejercicios de mesa: ejecutar un simulacro de ransomware gusano, no una presentación. Validar aislamiento y tiempo de restauración.

Preguntas frecuentes

1) ¿Fue WannaCry principalmente un ataque de phishing?

La característica definitoria fue la propagación tipo gusano vía SMB explotando vulnerabilidades de la clase MS17-010. No se requirió interacción del usuario para la propagación entre hosts vulnerables.

2) Si parcheamos MS17-010 hoy, ¿estamos a salvo?

No. Parchea y luego restringe la exposición de SMB, deshabilita SMBv1 y endurece backups. Los brotes aprovechables por gusanos prosperan por la alcanzabilidad y la segmentación interna débil, no solo por KBs faltantes.

3) ¿Por qué SMBv1 sigue apareciendo en empresas?

Porque dispositivos y aplicaciones antiguas perduran, y la gente teme romperlas. El movimiento correcto es aislar dependencias SMBv1 fuertemente y reemplazarlas con una fecha límite.

4) ¿Debemos pagar el rescate?

Operacionalmente, pagar no garantiza recuperación y puede crear más problemas (incluyendo targeting repetido). Tu mejor inversión es la capacidad de restauración: snapshots, backups inmutables y recuperación practicada.

5) ¿Cuál es la acción de contención más rápida para un evento tipo WannaCry?

Bloquear TCP/445 este-oeste (especialmente entre estaciones) y aislar hosts escaneadores. Les estás cortando las patas al gusano.

6) ¿Cómo encontramos “la única caja sin parchear” rápido?

Empieza por la verdad de red: escanea oyentes TCP/445 y luego verifica estado de parche/configuración de esos hosts. Los CMDBs son útiles, pero el flujo de paquetes es la realidad.

7) ¿Pueden los backups también cifrarse?

Sí, si están montados como lectura/escritura, accesibles con credenciales comprometidas o almacenados en shares accesibles desde endpoints infectados. Backups inmutables y separación de límites de confianza son innegociables.

8) ¿Deshabilitar SMB rompe el uso compartido de archivos en Windows?

Deshabilitar SMB por completo lo haría, pero típicamente deshabilitas SMBv1 (viejo y riesgoso) y mantienes SMBv2/v3. Además restringes dónde se permite SMB en lugar de dejarlo libre.

9) ¿Por qué fallan las “ventanas de parcheo” en la práctica?

Porque el parcheo se trata como un proyecto, no como un bucle operativo. Las organizaciones exitosas lo ejecutan como despliegues: anillos, monitorización, rollback rápido y responsabilidad sobre excepciones.

Próximos pasos que puedes hacer esta semana

Si WannaCry enseñó algo a la industria, es que “teníamos la intención de parchear” no es un control de incidente. Es una confesión.
La meta no es ser perfecto. La meta es dejar de sorprenderte por algo que puedes medir.

1. Ejecuta un escaneo interno TCP/445 y entrega la lista a las personas que realmente pueden cambiar la política de firewall.
2. Fija una fecha para deshabilitar SMBv1 a nivel empresarial. Empieza con un anillo piloto y luego mueve rápido. Las excepciones van a VLANs de aislamiento con firma del propietario.
3. Mide el cumplimiento de parches desde el exterior (escaneos de red + comprobaciones de configuración), no solo desde la perspectiva de la herramienta de parches.
4. Arregla los backups como si te importara: copia inmutable, copia fuera del sitio y un simulacro de restauración que produzca un tiempo real de recuperación, no un PowerPoint.
5. Implementa un interruptor de contención: un conjunto de reglas de firewall de emergencia para restringir SMB este-oeste que puedas activar en minutos, no horas.

Haz eso, y la próxima ola de ransomware explotable seguirá siendo molesta. Simplemente no será existencial. Ese es el objetivo. Alcánzalo.