El mito del ‘mejor antivirus’: lo que realmente previene el ransomware

El mito: “Mejor antivirus” como estrategia de seguridad

El antivirus (AV) e incluso las herramientas modernas de endpoint no son inútiles. Simplemente no son un control principal contra el ransomware. Tratarlos como “la cosa que detiene el ransomware” es como tratar los cinturones de seguridad como un plan para evitar choques de coche. Bien tenerlos, pero no evitan los accidentes.

Los operadores de ransomware ya no apuestan la empresa a malware de estantería. Ejecutan guiones operativos. Compran acceso. Explotan la identidad. Viven off the land. Usan herramientas firmadas, gestión remota, utilidades administrativas legítimas y credenciales robadas. Se toman su tiempo. Desactivan lo que compraste para protegerte o lo sortean.

El modo de fallo central detrás del mito del “mejor AV” es un error de categoría: el AV es una detección/control en endpoints. El ransomware es una falla operacional que abarca identidad, red, backup, almacenamiento y respuesta. Los controles en endpoints son una capa, pero necesitas defensa que sobreviva a un atacante con privilegios de administrador.

Realidad seca: si un adversario se convierte en administrador de dominio y puede alcanzar tu sistema de backups, tu puntuación de “mejor AV” no va a importar mucho.

Una cita que deberías grapar en la pared: “La esperanza no es una estrategia.” — Vince Lombardi

Broma #1 (corta, relevante): El antivirus es como el desodorante: ayuda, pero no reemplaza el baño.

Hechos e historia: cómo llegamos aquí (y por qué importa)

El ransomware parece moderno, pero ha ido iterando durante décadas. Algunos puntos concretos que explican por qué las defensas de hoy deben ser operacionales, no solo software:

• 1989: El troyano AIDS se cita a menudo como un precursor temprano del ransomware: distribuido en disquetes, usando cifrado rudimentario y pago por correo. El modelo funcionó incluso cuando la criptografía no lo hacía.
• Mediados de los 2000: El “scareware” y los falsos antivirus monetizaron el miedo. Enseñaron a los criminales que el comportamiento de los usuarios y los flujos de pago importan más que la elegancia técnica.
• 2013–2016: CryptoLocker y sus sucesores industrializaron el cifrado fuerte a escala. Comienza la era de “cifrar todo rápido”.
• 2017: WannaCry y NotPetya se propagaron usando vulnerabilidades tipo worm y mala higiene de parches. NotPetya fue destructivo disfrazado de ransomware: los seguros y los planes de respuesta tuvieron que adaptarse.
• 2019–2021: El “big game hunting” cambió el foco a empresas: intrusión manual, escalado de privilegios y impacto a medida. El cifrado era solo el acto final.
• Extorsión doble: Los atacantes empezaron a robar datos antes de cifrarlos, convirtiendo “restaurar desde backup” en solo la mitad de la solución.
• Ransomware como servicio: Afiliados comercializaron las intrusiones. La habilidad se distribuye; el volumen aumenta; las tácticas se estandarizan.
• Guerras EDR: Los operadores prueban y ajustan explícitamente cargas contra las pilas EDR populares. El endpoint se convierte en un espacio disputado, no seguro.
• Giro en la era cloud: El abuso de identidad y API puede borrar el almacenamiento de objetos o cifrar datos SaaS. Tu “AV de endpoint” es irrelevante frente a un token OAuth robado.

Esto no es trivia. Explican la regla moderna: no puedes confiar en un único producto preventivo, porque la capacidad central del atacante es adaptarse a los productos.

Lo que el ransomware realmente hace en tu entorno

La mayoría de los incidentes de ransomware en entornos corporativos siguen una secuencia bastante aburrida. “Aburrido” no es tranquilizador. Significa que ocurre mucho.

Fase 1: Acceso inicial

Puntos de entrada comunes: credenciales VPN comprometidas sin MFA, RDP expuesto, phishing que captura tokens, appliances perimetrales sin parchear o herramientas remotas de terceros. El atacante quiere un punto de apoyo que parezca trabajo remoto normal.

Fase 2: Robo de credenciales y escalado de privilegios

Volcado de credenciales, robo de tokens, abuso de Kerberos, password spraying, reutilización de administradores locales. Si tus administradores inician sesión en estaciones con cuentas de administrador de dominio, la tarea del atacante se vuelve mucho más sencilla.

Fase 3: Descubrimiento y movimiento lateral

Enumeran shares de archivos, servidores de backup, hypervisors, controladores de dominio y sistemas de monitorización. Buscan tus joyas de la corona y los sistemas que podrían ayudarte a recuperar. Si pueden romper la recuperación, el rescate sube.

Fase 4: Robo de datos (opcional, cada vez más común)

Preparan y exfiltran datos sensibles. Aquí es donde los gráficos de ancho de banda y las conexiones salientes inesperadas importan. Si no tienes monitorización de egress, lo descubres cuando llega la nota de rescate.

Fase 5: Impacto

Cifrado de endpoints y servidores, eliminación de shadow copies/snapshots, desactivación de servicios, cambios masivos de GPO y—si tienes mala suerte—destrucción de backups. Este es el momento de “todo está en llamas”, pero empezó horas o días antes.

Controles que realmente previenen el ransomware (y por qué)

Nótese la palabra “prevenir”. No “detectar cuando ya está por todas partes”. La prevención real significa detener al atacante antes de que pueda cifrar masivamente o antes de que pueda destruir tu capacidad de restaurar.

1) Endurecimiento de identidad supera las heroicidades en endpoints

Si no puedes proteger identidades, no puedes proteger nada. A los operadores de ransomware les encantan los entornos donde las credenciales son de larga duración, con privilegios excesivos y reutilizadas de modo casual.

• MFA en todas partes (VPN, correo, portales administrativos, consolas cloud). Preferir MFA resistente al phishing para roles administrativos.
• Cuentas administrativas separadas (usuario diario vs privilegiado). Ningún administrador de dominio navegando por la web.
• Workstations de acceso privilegiado (PAWs) o hosts jump endurecidos para acciones administrativas.
• Modelo de niveles (los Controladores de Dominio son Nivel 0; mantener credenciales Nivel 0 fuera de niveles inferiores).
• Reducir privilegios permanentes con elevaciones just-in-time cuando sea posible.

2) Backups: la única “cura”, pero solo si no pueden borrarse

Los backups no son una casilla para marcar. Son un sistema con adversarios. Si el atacante puede usar tus propias herramientas administrativas para borrar backups, no tienes backups. Tienes una ilusión cara.

Cómo se ve “bien”:

• 3-2-1: tres copias, dos tipos de medios, una fuera de sitio/aislada. Sigue siendo una base sólida.
• Inmutabilidad: snapshots/object lock o políticas tipo WORM que tus administradores habituales no puedan anular rápidamente.
• Copia offline/air-gapped (lógica o física). No todo necesita estar offline, pero algo sí.
• Pruebas de restauración: programadas, medidas y aburridas. El objetivo no es un backup exitoso; es una restauración exitosa.
• RPO/RTO diseñados: cuánto puedes perder (RPO) y cuán rápido puedes volver (RTO). Si nunca has cronometrado una restauración, tu RTO es un deseo.

3) Segmentación de red: hacer el movimiento lateral caro

Las redes planas aceleran el ransomware. La segmentación es cómo conviertes “un portátil comprometido” en “un portátil comprometido”, en lugar de “toda la empresa”.

• Aislar backups de la red general de servidores. Limitar puertos de gestión a hosts jump.
• Separar subredes de usuarios de subredes de servidores; separar subredes de servidores por función.
• Restringir tráfico este-oeste. Hacer SMB y WinRM aburridamente difíciles de alcanzar.
• Controlar el egress. La mayoría de entornos monitorizan el inbound; a los atacantes les encanta el outbound.

4) Registro y monitorización que sobreviva al ataque

Los atacantes desactivan lo que pueden ver. Si tus logs viven en el mismo dominio y mismo almacenamiento que se cifra, harás forense con intuiciones.

• Centralizar logs en un sistema con acceso endurecido.
• Alertar sobre eventos de identidad: nuevas cuentas administrativas, nuevos service principals, cambios de membresía de grupos.
• Alertar sobre manipulación de backups: eliminaciones de jobs, cambios de retención, borrado de snapshots.
• Alertar sobre patrones masivos de renombrado/escritura de archivos y altas tasas de escritura SMB.

5) Gestión de parches: no perfecta, aún esencial

La higiene de parches no detendrá el robo de credenciales, pero evitará una porción del acceso inicial y del escalado de privilegios. Prioriza dispositivos de borde, appliances VPN, herramientas RMM, hypervisors y controladores de dominio. Si tu cadencia de parches es “cuando tenemos tiempo”, el ransomware programará tiempo por ti.

6) EDR y AV: útiles, pero no el jefe del plan

Usa soluciones modernas de detección/respuesta en endpoints para visibilidad, aislamiento y contención. Pero asume que al menos un endpoint será pasado por alto o podrá ejecutar algo de todos modos. Tus otras capas deben aguantar.

7) Ingeniería de almacenamiento: snapshots, inmutabilidad y control del radio de explosión

Como persona de almacenamiento, aquí va la verdad incómoda: el ransomware es una carga de trabajo de almacenamiento. Es una tormenta de escrituras amplificadas, trituración de metadatos y muchas escrituras pequeñas con mala intención. Verás picos de IOPS, aumentos de latencia y pools que de repente parecen “ocupados” aunque el tráfico de negocio sea normal.

Controles de almacenamiento que importan:

• Snapshots inmutables (donde se soporten) o políticas de snapshot protegidas de credenciales administrativas rutinarias.
• Almacenamiento de backup separado del primario. Credenciales diferentes, red diferente, dominio de fallo diferente.
• Monitorizar tasas de borrado y tormentas de renombrado en sistemas de archivos.
• Conocer tus rutas de restauración: restauraciones al nivel VM, a nivel archivo, bare metal. Cronometrarlas.

Tareas prácticas: 12+ comprobaciones concretas con comandos y decisiones

Estas son tareas prácticas que puedes ejecutar hoy. Cada una incluye un comando, salida de ejemplo, lo que significa y la decisión que tomas. Asume servidores Linux para el host de comandos a menos que se indique; adáptalo a tu entorno.

Tarea 1: Comprobar actividad sospechosa en shares SMB (servidor Samba en Linux)

cr0x@server:~$ sudo smbstatus -b
Samba version 4.15.13-Ubuntu
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
-----------------------------------------------------------------------------------------------------------------------------
2314    jdoe         domain users  10.20.5.44 (ipv4:10.20.5.44:49832)       SMB3_11           -                    partial
2488    svc_backup   domain users  10.20.9.12 (ipv4:10.20.9.12:52110)       SMB3_11           -                    partial

Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
finance      2314    10.20.5.44    Tue Feb  5 10:12:44 2026 UTC     -            partial
profiles     2488    10.20.9.12    Tue Feb  5 09:55:03 2026 UTC     -            partial

Qué significa: Sesiones SMB activas y qué shares están tocando. Una sola estación martillando un share sensible fuera del horario laboral es sospechosa.

Decisión: Si un host inesperado está conectado a muchos shares o aparecen muchas sesiones rápidamente, aislar ese endpoint y empezar auditoría de archivos.

Tarea 2: Detectar una tormenta de renombrado/escritura en un sistema de archivos (Linux)

cr0x@server:~$ sudo iostat -xz 1 3
Linux 6.5.0-15-generic (fs01)  02/05/2026  _x86_64_ (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.12    0.00    6.44   31.88    0.00   52.56

Device            r/s     rkB/s   rrqm/s  %rrqm   r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm   w_await wareq-sz  aqu-sz  %util
nvme0n1          4.12    211.4     0.00   0.00    2.41    51.30   812.3  18244.0   120.1  12.88   38.22    22.45   31.2   99.1

Qué significa: Altas operaciones de escritura, alto iowait, alta utilización. El ransomware suele presentarse como presión sostenida de escritura con muchas escrituras pequeñas.

Decisión: Si esto es anormal para el host, trátalo como incidente. Correlaciona con IO a nivel de proceso y eventos recientes de autenticación.

Tarea 3: Identificar procesos con mayor IO (Linux)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ:         0.00 B/s | Total DISK WRITE:      65.12 M/s
TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
8123 be/4  root        0.00 B/s   18.22 M/s  0.00 % 98.00 %  python3 /opt/agent/tmp/enc.py
3911 be/4  nobody      0.00 B/s   12.05 M/s  0.00 % 87.00 %  smbd: notifyd

Qué significa: Un solo proceso realizando escrituras sostenidas es una señal de alarma—especialmente desde rutas extrañas como /opt/agent/tmp.

Decisión: Matar/aislar el host, preservar evidencia y comprobar si este proceso existe en otros sistemas.

Tarea 4: Buscar ejecutables modificados recientemente en directorios sospechosos (Linux)

cr0x@server:~$ sudo find /tmp /var/tmp /dev/shm -type f -mtime -1 -maxdepth 2 -ls | head
131099  120 -rwxr-xr-x   1 root root   122880 Feb  5 09:58 /tmp/.cache/agent
131104   44 -rwxr-xr-x   1 root root    45056 Feb  5 10:01 /dev/shm/.x

Qué significa: Ejecutables recientes en ubicaciones temporales son comunes en cadenas de intrusión.

Decisión: Si ves artefactos ejecutables nuevos, poner en cuarentena el sistema y hashear/colectarlos para análisis.

Tarea 5: Verificar controles de inmutabilidad del repositorio de backups (ejemplo: snapshots ZFS)

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation tank/backups | tail -5
tank/backups@auto-2026-02-05_0100  Tue Feb  5 01:00 2026
tank/backups@auto-2026-02-05_0200  Tue Feb  5 02:00 2026
tank/backups@auto-2026-02-05_0300  Tue Feb  5 03:00 2026
tank/backups@auto-2026-02-05_0400  Tue Feb  5 04:00 2026
tank/backups@auto-2026-02-05_0500  Tue Feb  5 05:00 2026

Qué significa: Los snapshots existen y se crean según lo programado. Eso es necesario, pero no suficiente.

Decisión: Confirma quién puede destruir estos snapshots. Si “domain admins pueden SSHear y ejecutar zfs destroy”, no tienes inmutabilidad; tienes una lista de tareas.

Tarea 6: Comprobar si los snapshots están protegidos por delegación (ejemplo ZFS)

cr0x@server:~$ sudo zfs allow tank/backups
---- Permissions on tank/backups --------------------------------------------
Local+Descendent permissions:
user backupsvc create,mount,receive,rollback,snapshot
user root create,destroy,mount,receive,rename,rollback,snapshot

Qué significa: Solo root puede destruir snapshots/datasets; la cuenta del servicio de backup puede crear/recibir/snapshot pero no destruir.

Decisión: Este es un patrón bueno. Si tu servicio de backup puede destruir o renombrar, arréglalo. Si demasiadas personas pueden volverse root fácilmente, arréglalo también.

Tarea 7: Validar que puedes restaurar (no solo respaldar) un archivo rápidamente (ejemplo clon ZFS)

cr0x@server:~$ sudo zfs clone tank/backups@auto-2026-02-05_0500 tank/restore-test
cr0x@server:~$ ls -lah /tank/restore-test/finance/ | head
total 64K
drwxr-xr-x  2 root root 4.0K Feb  5 05:00 .
drwxr-xr-x  8 root root 4.0K Feb  5 05:00 ..
-rw-r--r--  1 root root  18K Feb  5 04:59 invoice-2026-02.csv

Qué significa: Puedes montar una vista puntual sin tocar datos de producción. Así es como se ve la “preparación para restaurar”.

Decisión: Cronometrar esta operación y registrarla. Si toma demasiado, tus supuestos de RTO están equivocados.

Tarea 8: Comprobar cambios masivos de archivos usando logs de auditoría (ejemplo auditd en Linux)

cr0x@server:~$ sudo ausearch -ts today -k finance-share | tail -5
time->Tue Feb  5 10:03:41 2026
type=SYSCALL msg=audit(1738759421.211:1293): arch=c000003e syscall=82 success=yes exit=0 a0=ffffff9c a1=7f2a2c001b40 a2=241 a3=1b6 items=2 ppid=8123 pid=8123 auid=1002 uid=0 gid=0 exe="/usr/bin/python3" comm="python3"
type=PATH msg=audit(1738759421.211:1293): item=1 name="/srv/samba/finance/Q1/budget.xlsx.locked" inode=901232 dev=fd:00 mode=0100644 ouid=1002 ogid=1002 rdev=00:00 nametype=CREATE

Qué significa: Un proceso está creando archivos con una nueva extensión en el share de finanzas. Eso es comportamiento clásico de cifrado.

Decisión: Contener inmediatamente: aislar host/usuario, deshabilitar credenciales, bloquear SMB desde esa fuente, preservar el snapshot.

Tarea 9: Comprobar conexiones salientes por transferencias grandes inesperadas (Linux)

cr0x@server:~$ sudo ss -tpn | head -8
State Recv-Q Send-Q Local Address:Port  Peer Address:Port  Process
ESTAB 0      131072 10.20.9.22:443      185.199.110.153:52344 users:(("rclone",pid=9011,fd=7))
ESTAB 0      0      10.20.9.22:22       10.20.1.10:49822   users:(("sshd",pid=1881,fd=3))

Qué significa: Herramientas como rclone se abusan con frecuencia para exfiltración porque parecen sincronización normal en la nube.

Decisión: Si no ejecutas rclone en producción, trata esto como incidente. Matar el proceso, capturar línea de comandos/historial y revisar logs de egress para ver qué salió.

Tarea 10: Verificar salud de replicación del controlador de dominio (Windows desde un host de gestión usando WinRM es común; aquí un chequeo desde Linux vía samba-tool)

cr0x@server:~$ samba-tool drs showrepl dc01.corp.example
DSA Options: 0x00000001
DSA object GUID: 2b6b0f4b-3a2b-4d2a-9f2a-3b5a9c9aa2ad
==== INBOUND NEIGHBORS ====
DC=corp,DC=example
    dc02.corp.example via RPC
        DSA object GUID: 9d7b1c2a-1c11-4a72-ae9e-2d0b2a6a0c17
        Last attempt @ Tue Feb  5 09:55:12 2026 UTC was successful

Qué significa: Si la replicación está rota, no puedes confiar en cambios de membresía de grupos, restablecimientos de contraseña o el estado de GPO durante la respuesta al incidente.

Decisión: Si la replicación falla, estabiliza AD primero. Muchas recuperaciones mueren porque la identidad es inconsistente.

Tarea 11: Buscar nuevas adiciones de administradores locales (ejemplo Linux vía sudoers y archivos de grupos)

cr0x@server:~$ sudo grep -R "ALL=(ALL)" -n /etc/sudoers /etc/sudoers.d | head
/etc/sudoers:27:%sudo   ALL=(ALL:ALL) ALL
/etc/sudoers.d/90-cloud-init-users:1:deploy ALL=(ALL) NOPASSWD:ALL

Qué significa: Sudo sin contraseña para una cuenta general es un regalo para atacantes que aterrizan en ese host.

Decisión: Eliminar NOPASSWD donde no sea estrictamente necesario y restringir comandos. Si es necesario, colócalo detrás de autenticación fuerte y registro en un host jump.

Tarea 12: Confirmar que los backups se completan y no fallan silenciosamente (genérico: comprobar systemd timers + logs)

cr0x@server:~$ systemctl list-timers --all | grep -E "backup|restic|borg"
Tue 2026-02-05 01:00:00 UTC  4h 59min left Tue 2026-02-04 01:00:03 UTC 19h ago  restic-backup.timer  restic-backup.service
cr0x@server:~$ sudo journalctl -u restic-backup.service -n 8 --no-pager
Feb 04 01:00:03 backup01 restic[2201]: repository 1a2b3c4d opened successfully
Feb 04 01:12:44 backup01 restic[2201]: processed 412563 files, 1.8 TiB in 12m41s
Feb 04 01:12:44 backup01 restic[2201]: snapshot 9f8e7d6c saved
Feb 04 01:12:44 backup01 systemd[1]: restic-backup.service: Succeeded.

Qué significa: Los backups se ejecutaron, completaron y guardaron un snapshot. También conoces rendimiento y escala, lo cual importa para restauraciones.

Decisión: Si los backups fallan, arréglalo antes de hacer cualquier cosa “avanzada”. Si son lentos, planifica mejoras de capacidad para restauración.

Tarea 13: Probar integridad de la restauración con comparación de checksum (ejemplo)

cr0x@server:~$ sha256sum /srv/data/finance/invoice-2026-02.csv
c8b1d7a2b2a5ef3fdddbf0d66a52f3f3d8b2d1e2f30d7c2f2e0b7b2b3a1f0a9e  /srv/data/finance/invoice-2026-02.csv
cr0x@server:~$ sha256sum /tank/restore-test/finance/invoice-2026-02.csv
c8b1d7a2b2a5ef3fdddbf0d66a52f3f3d8b2d1e2f30d7c2f2e0b7b2b3a1f0a9e  /tank/restore-test/finance/invoice-2026-02.csv

Qué significa: Tu copia restaurada coincide con producción. Así demuestras que los backups no solo existen, sino que son correctos.

Decisión: Si los checksums no coinciden, trátalo como corrupción de datos o backup incompleto e investiga antes de que un incidente te obligue a actuar.

Tarea 14: Encontrar rápidamente procesos con persistencia sospechosa (Linux)

cr0x@server:~$ systemctl list-unit-files --type=service | grep -E "agent|update|backup" | head
agent-updater.service                      enabled
backup-sync.service                        enabled
system-update.service                      enabled
cr0x@server:~$ systemctl status agent-updater.service --no-pager | sed -n '1,12p'
● agent-updater.service - Agent Updater
     Loaded: loaded (/etc/systemd/system/agent-updater.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-02-05 09:58:11 UTC; 7min ago
   Main PID: 8123 (python3)
     CGroup: /system.slice/agent-updater.service
             └─8123 /usr/bin/python3 /opt/agent/tmp/enc.py

Qué significa: Persistencia vía systemd es común. Un servicio que ejecuta un script desde una ruta tipo temporal es extremadamente sospechoso.

Decisión: Detener el servicio, aislar el host, capturar el unit file y el script para análisis, y buscar en la flota la misma unidad.

Guía rápida de diagnóstico

Esta es la lista de “entrar a la sala de crisis y ser útil en cinco minutos”. El objetivo es encontrar el cuello de botella: ¿es un brote de endpoints, una compromisión de identidad, un evento de saturación de almacenamiento o un intento de destrucción de backups?

Primero: confirmar alcance y detener la hemorragia

1. Identificar al paciente cero: ¿qué host/usuario reportó primero archivos cifrados? Correlaciona timestamps con logs de autenticación.
2. Aislar las fuentes probables: poner endpoints en cuarentena a nivel de red cuando sea posible; no confíes en que el endpoint cooperará.
3. Congelar backups/snapshots: preservar puntos de restauración inmediatamente. Si tienes snapshots inmutables, verifica que sigan existiendo y sean accesibles.

Segundo: averiguar si la identidad está comprometida

1. Comprobar cambios en cuentas privilegiadas: nuevos administradores, cambios en membresía de grupos, inicios de sesión sospechosos desde hosts inusuales.
2. Comprobar reinicios masivos de contraseñas o MFA deshabilitado. A veces los atacantes “preparan” cortando a los defensores.
3. Confirmar salud de los DC: si AD es inestable, tus acciones de remediación pueden no propagarse correctamente.

Tercero: determinar si es cifrado, exfiltración o ambos

1. Telemetría de almacenamiento: picos de iowait, ráfagas de escritura SMB, elevado número de operaciones de metadatos. El cifrado es ruidoso a nivel de almacenamiento.
2. Telemetría de egress: conexiones salientes inusuales, herramientas como rclone, grandes transferencias a IPs desconocidas.
3. Indicadores de archivos: nuevas extensiones, notas de rescate, patrones consistentes de renombrado.

Cuarto: elegir una vía de recuperación

• Si los backups están intactos: priorizar contención y planificación de restauración. No apresures restauraciones dentro de un dominio aún comprometido.
• Si los backups están amenazados: protegerlos inmediatamente (cambios de credenciales, aislamiento de red, revocar accesos). El tiempo importa más que la elegancia.
• Si la exfiltración está confirmada: involucrar legal/cumplimiento temprano; la restauración no borra las obligaciones de divulgación.

Tres mini-historias corporativas desde el frente

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

Estaban orgullosos de su suite de endpoints. Un proveedor conocido, marketing agresivo, un panel lleno de círculos verdes tranqulizadores. El responsable de seguridad podía señalar informes mensuales que mostraban malware bloqueado. La dirección lo adoraba porque parecía progreso.

La suposición equivocada fue sencilla: “Si tenemos EDR, el ransomware no puede propagarse.” Lo que en realidad tenían era EDR desplegado en la mayoría de endpoints, con exclusiones de rendimiento en un conjunto de servidores de archivos que “no podían permitirse sobrecarga”. Esos servidores eran donde los empleados guardaban todo lo importante. Los servidores también permitían configuraciones SMB antiguas para una app heredada que nadie quería tocar.

Un atacante entró por una cuenta de VPN de un contratista sin MFA. La cuenta había sido “temporal” durante seis meses. Se movieron lateralmente, encontraron los servidores de archivos desprotegidos y ejecutaron cifrado directamente en ellos. Sin agente en los servidores, no hubo acción de aislamiento. Para cuando el helpdesk vio el primer ticket, el almacenamiento ya estaba saturado de escrituras y el share era un cementerio de archivos renombrados.

En el postmortem, la realización incómoda fue clara: su “mejor AV” no falló. Hizo lo que pudo en los endpoints donde estaba. Su estrategia falló porque construyeron un sistema donde los activos más importantes eran los menos protegidos, y donde un control faltante se convirtió en una crisis de toda la empresa.

La solución no fue “comprar un producto mejor”. Fue un proyecto de segmentación, aplicación de MFA, eliminación de accesos permanentes y rediseño del repositorio de backups para que una cuenta de contratista ni siquiera pudiera alcanzarlo.

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

Otra empresa tenía un sistema de backups que funcionaba. Las restauraciones eran lentas, pero funcionaban. Alguien notó la factura mensual de almacenamiento y decidió “optimizar”. Reducieron la frecuencia de snapshots, acortaron retenciones y consolidaron credenciales de backup para que el equipo de ops pudiera “moverse más rápido”. También abrieron reglas de firewall para que el servidor de backup pudiera alcanzar todo sin tickets.

El cambio parecía eficiente. Menos snapshots. Menos almacenamiento. Menos fricción. Las métricas mejoraron. El riesgo no apareció en los dashboards, porque el riesgo rara vez lo hace.

Cuando llegó el ransomware, el atacante encontró rápidamente el servidor de backup. Tenía amplio alcance en la red y una credencial con demasiado poder porque “los backups necesitan acceso”. Usaron la misma ruta administrativa que ops usaba: borrar puntos de restauración antiguos, luego los recientes, luego borrar las definiciones de trabajo para que tardara más en notarse. El entorno no solo perdió datos de producción; perdió tiempo, porque nadie pudo decir qué backups eran confiables.

La recuperación se convirtió en arqueología. Tuvieron que buscar una copia fuera de sitio más antigua que no estuviera totalmente sincronizada. Se restauró, pero era lo suficientemente antigua como para causar una interrupción seria. La “optimización” había cambiado efectivamente un coste de almacenamiento predecible por un coste existencial impredecible.

La lección que adoptaron fue estricta: trata los sistemas de backup como territorio hostil. Reduce la conveniencia. Añade fricción donde protege eliminaciones y manipulaciones. Y nunca optimices retenciones sin probar primero los requisitos de restauración.

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

Esta no es cinematográfica. Es por qué funcionó.

Una firma mediana tenía un ritual trimestral molesto: una prueba de restauración. No una mesa de ejercicio. Una restauración real. Escogían una VM de aplicación al azar, la restauraban en una red aislada, verificaban que el servicio arrancara y medían el tiempo. Molestaba a todos porque consumía almacenamiento y mano de obra y producía un informe que nadie leía hasta que algo salía mal.

También mantenían una cuenta administrativa de backups separada, almacenada offline, con MFA. El almacenamiento de backups vivía en un segmento de red distinto. La eliminación de snapshots requería una vía de aprobación y credenciales separadas que no eran las mismas que las de administrador de dominio.

Cuando llegó el ransomware a través de un buzón de correo comprometido y se propagó a unos pocos servidores, causó daño real. Pero no pudo alcanzar el repositorio de backups. No pudo borrar snapshots. El equipo aisló hosts afectados, verificó los snapshots conocidos como buenos y restauró sistemas en un orden controlado. Los runbooks de la prueba de restauración significaron que no hubo debate sobre “cómo” restaurar—solo “qué primero”.

Todavía tuvieron una semana difícil, porque los incidentes son así. Pero no tuvieron un trimestre catastrófico. La práctica aburrida—la prueba repetida de que las restauraciones funcionan—convirtió el pánico en una secuencia de pasos.

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

Esta es la parte en la que dejo de ser diplomático. Estos son patrones que siguen apareciendo en entornos reales.

1) “Nuestros backups estaban bien” (hasta que no lo estaban)

• Síntomas: Los trabajos de backup muestran “exitoso”, pero las restauraciones fallan o tardan días; consistencia de aplicación ausente; archivos corruptos; nadie conoce claves/contraseñas.
• Causa raíz: Éxito de backup medido por finalización de job, no por validación de restauración; sin simulacros de restauración; credenciales almacenadas en sistemas comprometidos.
• Solución: Programar pruebas de restauración con RTO medido; almacenar credenciales de admin de backup offline; implementar inmutabilidad; documentar orden de restauración por dependencias.

2) El cifrado se propaga “instantáneamente” por la organización

• Síntomas: Muchos shares y servidores afectados en minutos; picos de latencia en almacenamiento; tasas de escritura SMB verticales.
• Causa raíz: Red plana + permisos amplios en shares + credenciales admin reutilizadas + sin controles este-oeste.
• Solución: Segmentar; restringir SMB/WinRM; eliminar la reutilización de administradores locales; implementar modelo de admins por niveles; limitar permisos de escritura en shares.

3) El equipo de seguridad no puede ver nada durante el incidente

• Síntomas: SIEM silencioso; agentes offline; servidores de logs cifrados; sin línea temporal.
• Causa raíz: La monitorización depende del mismo plano de identidad/almacenamiento que fue comprometido; sin pipeline de logs endurecido.
• Solución: Centralizar logs en infraestructura endurecida; separar autenticación; usar controles de retención de solo escritura o restringidos; probar “logging durante outage”.

4) Las restauraciones reinfectan el entorno

• Síntomas: Los sistemas se vuelven a cifrar tras la restauración; el atacante sigue presente; aparecen nuevas cuentas admin otra vez.
• Causa raíz: Restaurar en un dominio todavía comprometido; persistencia no eliminada; credenciales no rotadas.
• Solución: Contener primero; rotar credenciales privilegiadas; reconstruir la confianza del dominio cuidadosamente; restaurar en red aislada y validar antes de volver a unir.

5) “Teníamos MFA” pero los atacantes aún entraron

• Síntomas: Compromiso a través de SSO; concesiones OAuth sospechosas; tokens de sesión abusados; engaño al helpdesk.
• Causa raíz: MFA no aplicado en todos los caminos; métodos susceptibles al phishing; robo de tokens; verificación débil del helpdesk.
• Solución: Aplicar MFA en todas partes; usar MFA resistente al phishing para admins; alertar sobre nuevos consentimientos de aplicaciones; endurecer procedimientos del helpdesk.

6) Los backups existen pero igual son borrados

• Síntomas: Snapshots faltantes; retención cambiada; jobs de backup eliminados; buckets de object storage vaciados.
• Causa raíz: Admins de backup comparten el mismo plano de identidad que los atacantes; sin inmutabilidad; sin separación de funciones; sin alertas sobre acciones destructivas.
• Solución: Implementar retención inmutable; separar credenciales; requerir cuentas break-glass para eliminaciones; alertar de inmediato sobre cambios de retención y eliminaciones.

Listas de verificación / plan paso a paso

Checkpoint 0: Decidir qué significa “bien” para tu negocio

• Definir RPO por sistema (cuánto dato puedes perder).
• Definir RTO por sistema (cuánto tiempo puedes estar caído).
• Clasificar datos: regulados, confidenciales, internos, públicos.
• Identificar los 5 servicios principales que deben volver primero (identidad, DNS, apps núcleo, shares de archivos, ERP, etc.).

Semana 1: Detener las victorias fáciles para los atacantes

1. Aplicar MFA en VPN, correo y accesos privilegiados.
2. Inventariar cuentas privilegiadas y separar cuentas administrativas de las de uso diario.
3. Eliminar bombas de privilegio obvias: sudo NOPASSWD, credenciales admin compartidas, cuentas de contratistas obsoletas.
4. Baselinar egress: saber cómo es el tráfico saliente “normal” desde servidores.

Semana 2: Hacer los backups resistentes a la compromisión administrativa

1. Implementar inmutabilidad para al menos una copia de backup (snapshots/object lock/retención tipo WORM).
2. Segregar redes de backup: restringir acceso a la infraestructura de backup desde un host jump únicamente.
3. Separar credenciales: las cuentas admin de backup no deberían ser admins de dominio; almacenar credenciales break-glass offline.
4. Alertar acciones destructivas: eliminaciones de snapshots, cambios de retención, eliminación de jobs de backup.

Semana 3: Reducir el radio de explosión con segmentación y permisos

1. Segmentar acceso usuario→servidor: solo puertos necesarios, solo subredes necesarias.
2. Endurecer permisos de shares: eliminar “Everyone write”; aplicar mínimo privilegio por grupos.
3. Bloquear protocolos de movimiento lateral donde sea posible: SMB entre estaciones, WinRM, WMI entre subredes.
4. Endurecer flujos administrativos: PAW o host jump, sin administración directa desde estaciones de trabajo.

Semana 4: Probar que puedes recuperar

1. Ejecutar una prueba de restauración en una red aislada; validar función de la app, no solo el arranque.
2. Cronometrarla y comparar con RTO; actualizar planes o comprar capacidad.
3. Escribir runbooks para orden de restauración y puntos de decisión.
4. Ensayar la primera hora: contención, rotación de credenciales, preservación de snapshots, plan de comunicaciones.

Broma #2 (corta, relevante): Si tu plan de recuperación ante desastres es un PDF que nadie puede encontrar, felicidades—has inventado un almacenamiento de documentación compatible con ransomware.

Preguntas frecuentes

¿Importa el antivirus en absoluto?

Sí. Reduce infecciones de commodity y puede ayudar con la contención. Pero no es un control principal porque los operadores de ransomware a menudo usan herramientas legítimas y credenciales robadas.

¿Cuál es el control más importante contra el ransomware?

Backups que puedas restaurar, protegidos por inmutabilidad y separación de privilegios. Si los atacantes pueden borrar tus backups, el incidente se vuelve existencial.

¿Son suficientes los backups inmutables?

No. Abordan el impacto del cifrado, no el robo de datos, la compromisión de identidad o la reinfección. Aún necesitas endurecimiento de identidad, segmentación y monitorización.

¿Con qué frecuencia deberíamos probar las restauraciones?

Como mínimo trimestral para sistemas críticos, y tras cambios importantes (nueva herramienta de backup, migración de almacenamiento, cambios de identidad). Para sistemas de primer nivel, mensual no es excesivo.

¿Qué deberíamos monitorizar para detectar ransomware temprano?

Cambios de identidad (nuevos admins, nuevos tokens, cambios de MFA), patrones inusuales de escritura SMB, picos en renombrado de archivos, cambios en retención/jobs de backup y transferencias salientes anormales.

¿Deberíamos pagar el rescate?

Es una decisión de negocio/legales, no técnica, y depende de la jurisdicción, el seguro y el impacto. Operacionalmente: construye para no tener que hacerlo. También asume que las herramientas de descifrado pueden ser lentas, poco fiables o incompletas.

Somos mayormente SaaS. ¿Estamos seguros?

No. La compromisión de identidad puede cifrar o borrar datos en la nube, y los atacantes pueden abusar de concesiones OAuth y consolas administrativas. Aún necesitas backups/exports, registro y controles fuertes de identidad.

¿Cuál es la diferencia entre EDR y AV en este contexto?

El AV es típicamente prevención basada en firmas/comportamiento en endpoints. EDR añade telemetría, hunting y acciones de respuesta (como aislar un host). Ambos ayudan, ninguno sustituye la resiliencia de backups y los controles de identidad.

¿Cómo evitamos restaurar malware junto con los datos?

Restaurar en una red aislada, escanear y validar, rotar credenciales y asegurar que la vía de intrusión original esté cerrada antes de reconectar. Trata las restauraciones como una reconstrucción controlada, no como un botón de retroceso.

¿Cuentan los snapshots en almacenamiento primario como backups?

Son una herramienta de recuperación, no una estrategia completa de backups. Si el atacante compromete el plano admin de almacenamiento, los snapshots pueden ser destruidos. Usa snapshots como una capa más, además de copias de backup separadas.

Próximos pasos que puedes ejecutar esta semana

Si quieres prevención de ransomware, deja de buscar el “mejor antivirus” y empieza a ejecutar un programa de fiabilidad para resultados de seguridad.

1. Elige un servicio crítico y mide el tiempo de restauración de extremo a extremo. Pon el número por escrito.
2. Protege una copia de backup con inmutabilidad y demuestra que los admins rutinarios no pueden borrarla rápidamente.
3. Aplica MFA para todo acceso remoto, luego audita excepciones hasta que no queden válidas.
4. Segmenta redes de backup y gestión para que una estación comprometida ni siquiera pueda verlas.
5. Configura tres alertas a las que realmente responderás: cambios en grupos privilegiados, cambios en retención de backups y transferencias salientes anormales.
6. Escribe un runbook de la primera hora en una página y ejecútalo una vez. El objetivo es eliminar el debate, no impresionar a nadie.

El ransomware es un problema de sistemas. Trátalo como ingeniería de producción: reduce el radio de explosión, aplica mínimo privilegio, diseña para la recuperación y ensaya. El antivirus puede acompañar el viaje.