Si llevas algunos años administrando servidores Linux, seguramente has escuchado más de una vez:

- “Linux no necesita antivirus.”

O su versión más optimista:

- “En Linux no existen los ransomware.”

O peor aún, “En Linux no existen los virus”, como si todos los malware fueran virus, me dan ganas de agarrarlos a palos, pero esa es otra historia.

Linux sigue siendo uno de los sistemas operativos más seguros, pero que sea seguro no significa que sea invulnerable. Si un atacante obtiene acceso mediante credenciales robadas, una vulnerabilidad sin corregir o porque el servidor está mal instalado o tiene una mala configuración, el problema deja de ser el sistema operativo. A partir de ese momento, el riesgo está en todo lo que el atacante puede hacer utilizando tus propios permisos.

Aquí aparece uno de los mayores mitos sobre el ransomware. Muchas personas imaginan el ataque como una secuencia muy simple: alguien compromete un servidor, unos segundos después todos los archivos aparecen cifrados, las aplicaciones dejan de funcionar y finalmente aparece la nota de rescate.

La realidad suele ser bastante diferente.

Cuando ves los archivos cifrados, el ataque prácticamente terminó. Antes de llegar a ese punto, el atacante ya estudió la infraestructura, identificó los servidores críticos, localizó las bases de datos, encontró los respaldos de tu infraestructura y hasta esos videos… tú sabes cuáles (bueno, para eso se inventó el internet. ¿no?), obtuvo privilegios administrativos y, en muchos casos, lleva varios días dentro de la red sin levantar sospechas.

El cifrado es únicamente la última etapa de una cadena de acciones mucho más larga. Normalmente, cuando te hackea alguien “peligroso” no te das cuenta, el atacante no quiere que sepas que está ahí, quiere usar tus recursos, usarte como un zombie para hacer ataques DDOS, usarte para enviar spam con tu IP, usar tu poder de computo para minar bitcoins, o en este caso, usar tus datos valiosos para cobrar un rescate. Afortunadamente, todo deja rastros y podemos usarlos para detectar este tipo de ataques.

NOTA: Si te hackearon y pusieron en tu web un mensaje de “Hola mamá! Soy Jonny h4x0r! mira lo que pude hacer!!!”, Cágate de risa, saca una cerveza y disfruta que fue un niño jugando. Un ataque serio es mucho menos divertido.

Cuando hay un ataque de ransomware pregunta realmente importante es:

¿Por qué nadie detectó todo lo que ocurrió antes?

La respuesta suele ser sencilla: muchas organizaciones siguen concentrando sus esfuerzos en detectar malware, cuando en realidad deberían tratar de detectar comportamientos.

La diferencia entre detectar malware y detectar un ataque

Imagina que alguien entra a tu casa. No roba nada. Simplemente recorre las habitaciones, fotografía cada ventana, anota dónde está la caja fuerte, copia las llaves, desactiva la alarma y se va. Técnicamente todavía no ocurrió un robo. Pero, cualquiera entendería que algo muy grave está por pasar.

Con un ransomware pasa exactamente lo mismo.

Antes de cifrar un solo archivo, el atacante necesita iniciar sesión, elevar privilegios, crear persistencia, recorrer directorios, identificar respaldos, modificar configuraciones y preparar el entorno. Cada una de esas acciones deja evidencia en forma de procesos, conexiones, cambios de archivos, usuarios nuevos, servicios detenidos, permisos modificados y comandos ejecutados.

Ninguno de estos eventos, por sí solo, confirma un ransomware. Pero cuando se observan en conjunto, cuentan una historia. Y esa historia suele comenzar horas, días o incluso semanas antes del cifrado. Esa ventana de tiempo es la que aprovechan para moverse lateralmente, escalar privilegios y, lo más crítico, comprometer los respaldos. Por eso, cuando el ransomware finalmente se ejecuta, no es raro que los backups disponibles, incluso los de semanas atrás ya estén infectados o inaccesibles. He visto casos donde los respaldos rotaron y no quedaron versiones anteriores limpias. Y ahí, el desastre ya no es solo técnico.

Ahí es donde Wazuh marca la diferencia

Existe una idea equivocada bastante común: instalar Wazuh no significa que tu empresa tenga un SOC ni garantiza protección frente a un ransomware.

Tampoco reemplaza las prácticas fundamentales de seguridad, como el hardening, la gestión de vulnerabilidades, el uso de MFA, los respaldos, la segmentación de red, las actualizaciones o una política adecuada de control de accesos. Lo que sí hace es proporcionar visibilidad sobre comportamientos que normalmente pasarían desapercibidos. Esa capacidad puede darte minutos u horas de ventaja para contener un incidente antes de que el atacante alcance a hacer daño. Y esa diferencia suele ser enorme.

Restaurar un respaldo siempre será mucho más barato que negociar con un delincuente. Aun así, sigue sorprendiéndome la cantidad de organizaciones que invierten millones en infraestructura y, al mismo tiempo, consideran innecesario dedicar tiempo a revisar las alertas de seguridad.

Es como instalar cámaras de seguridad en toda la empresa y después guardar el monitor en una bodega.

Las cámaras funcionan perfectamente. El problema es que nadie las está mirando.

El objetivo de este artículo

Este no es un tutorial para instalar Wazuh ni un recorrido por todas sus opciones. La documentación oficial ya hace un excelente trabajo explicando esos aspectos.

La idea es otra.

Vamos a recorrer paso a paso cómo suele desarrollarse un ataque de ransomware sobre un servidor Linux, qué hace el atacante en cada etapa, qué evidencia deja y cómo Wazuh puede ayudarte a detectar esas señales antes de que comience el cifrado.

Los ransomware cambian constantemente. Cambian de nombre, de algoritmo, de infraestructura e incluso de sistema operativo. Sin embargo, el comportamiento de los atacantes cambia mucho menos de lo que podríamos pensar. Y precisamente ahí está la oportunidad para detectarlos antes de que sea demasiado tarde.

03:12 AM - El ataque acaba de comenzar (y nadie lo sabe)

• Son las 03:12 de la mañana. Un seminarista, un obrero. Con mil papeles de solvencia. (dijo Juan Luis)
• No hay nadie trabajando.
• No hay ventanas de mantenimiento.
• No hay despliegues programados.
• El servidor lleva miles de años funcionando con normalidad.
• De pronto aparece un inicio de sesión por SSH.
• No aumenta el uso de CPU.
• No aparecen errores.
• La aplicación sigue respondiendo sin problemas.

Si solo estuvieras mirando un dashboard de un monitoreo de infraestructura, probablemente pensarías que todo funciona perfecto.

Pero no.

El incidente acaba de comenzar y todavía falta mucho tiempo para que aparezca el primer archivo cifrado.

Así trabajan la mayoría de los ransomware modernos

Hollywood nos vendió la idea de que un hacker puede tomar el control de un servidor en 60 segundos, con una pistola en la cabeza, una rubia debajo del escritorio distrayéndolo y John Travolta haciendo bullying (qué gran película, tengo que volver a ver Swordfish). Pero la realidad, especialmente lo de la rubia, está muy lejos de eso. Un atacante real necesita tiempo. Mucho tiempo. Para estudiar la red, moverse lateralmente, recopilar información y preparar el terreno antes de que el ataque sea realmente efectivo. El cine dura dos horas; un ataque bien planeado puede durar semanas.

La mayoría de las bandas de ransomware sigue un proceso bastante metódico. Primero consiguen acceso, luego elevan privilegios, establecen mecanismos de persistencia, reconocen el entorno, realizan movimiento lateral, desactivan las defensas, eliminan los respaldos y, solo al final, comienzan el cifrado.

Lo interesante es que cada una de esas etapas deja evidencia, y esa evidencia aparece mucho antes del cifrado.

Ese es precisamente el momento en que Wazuh puede darte una ventaja. No porque conozca el nombre del ransomware, sino porque es capaz de identificar comportamientos que no deberían producirse en un servidor.

Primera etapa: conseguir acceso

La realidad suele ser mucho menos espectacular de lo que imaginamos.

No existen hackers con capucha escribiendo código verde sobre pantallas negras, ni complejos puzzles 3D que deben resolverse en 60 segundos antes de ser rastreados. Y, obviamente, mucho menos la rubia. Porque, seamos sinceros: a las minas no les atraen los hackers. Lo que realmente les vuelve locas es cuando uno les dice que eres un white hat especialista en Linux. No vuelvo a mencionarlo en el pub. Tuve que espantarlas con un palo.

En la mayoría de los casos, el acceso inicial llega por una vía mucho más simple: una contraseña filtrada, una VPN comprometida, una llave SSH robada, un servicio sin actualizar, una aplicación vulnerable o una credencial olvidada desde hace años, un script “mágico” que promete hacer maravillas con un solo comando, pero viene compilado u ofuscado para que nadie pueda ver realmente qué hace por dentro. Y ahí aparece la sorpresa: lo que parecía una herramienta milagrosa era flor de backdoor (por eso todos los script que les comparto están en bash).

Y eso basta.

El atacante entra exactamente igual que cualquier administrador legítimo.

• No rompe nada.
• No instala malware.
• No modifica archivos.

Simplemente inicia sesión.

Por eso, muchas veces el primer indicador del ataque ya estaba registrado en los logs. El problema es que nadie se dio cuenta.

¿Qué puede detectar Wazuh?

Los intentos de autenticación fallidos son un buen ejemplo.

Failed password for root

Invalid user backup

Invalid user oracle

Failed password for admin

Por sí solos no significan que exista un ataque. Internet está lleno de bots que prueban credenciales las veinticuatro horas del día. (Es normal encontrar cientos de miles de intentos diarios de conexión como root al SSH de un servidor. Aquí entra lo que ya hablamos del hardening de SSH y la protección contra ataques de fuerza bruta)

Lo realmente interesante ocurre cuando alguno de esos intentos finalmente tiene éxito.

Accepted password for admin

o

Accepted publickey for root

¿Eso confirma un compromiso?, ummm… no. Todo depende del contexto.

La seguridad rara vez consiste en analizar un único evento; consiste en entender la historia que construyen varios eventos relacionados.

No es lo mismo que el administrador inicie sesión desde la oficina un lunes a las diez de la mañana, a que un usuario llamado backup aparezca autenticándose desde otro continente un domingo a las tres de la madrugada.

El registro puede ser prácticamente idéntico.

La historia que cuenta es completamente diferente.

Segunda etapa: conseguir privilegios de administrador

Entrar al servidor suele ser solo el primer paso.

Con permisos limitados resulta difícil detener servicios, modificar configuraciones o cifrar información crítica (por eso jamás se debe permitir el acceso directo al usuario root), por lo que el siguiente objetivo suele ser bastante predecible: obtener privilegios de administrador.

En esta etapa comienzan a aparecer comandos que cualquier administrador Linux utiliza con frecuencia.

sudo -i

sudo su -

su -

pkexec

Ninguno de ellos es malicioso.

Lo importante no es el comando, sino quién lo ejecuta, desde dónde lo hace y qué ocurrió antes y después.

Imagina la siguiente secuencia.

03:12  Inicio de sesión SSH.

03:14  Uso de sudo.

03:15  Modificación de sudoers.

03:16  Creación de un nuevo usuario administrador.

¿Todavía parece una sesión de administración normal?

Probablemente no.

Cada uno de esos eventos podría tener una explicación perfectamente legítima. Sin embargo, cuando ocurren uno detrás de otro comienzan a formar un patrón, y los patrones son mucho más valiosos que los eventos aislados.

Un atacante casi nunca realiza una única acción.

Siempre ejecuta varias.

Y, por lo general, las realiza en el mismo orden.

Cuatro archivos que merecen toda tu atención

Hay algunos archivos que prácticamente todos los atacantes terminan modificando tarde o temprano.

/etc/passwd

/etc/shadow

/etc/group

/etc/sudoers

No porque tengan algo especial, sino porque controlan la identidad y los privilegios del sistema.

Modificar cualquiera de ellos no implica automáticamente un incidente de seguridad.

Lo que sí debería generar una pregunta inmediata es:

¿Quién realizó ese cambio?

Si la respuesta es:

Felipe estaba creando un usuario nuevo durante una ventana de mantenimiento o se instaló un paquete nuevo en la maquina y éste agrega un usuario de servicio a /etc/passwd

Perfecto.

No hay nada que investigar.

Pero si la respuesta es:

No tenemos idea.

Entonces el problema ya no es la alerta de Wazuh.

El problema es que alguien modificó archivos críticos del sistema y nadie sabe quién fue.

Tercera etapa: asegurar el acceso

Los atacantes rara vez quieren entrar una sola vez.

Su objetivo es poder volver cuando quieran, incluso si la vulnerabilidad original desaparece, cambias la contraseña o reinicias el servidor.

Para eso necesitan establecer algún mecanismo de persistencia.

Las técnicas pueden variar, pero el objetivo siempre es el mismo: mantener una puerta de entrada silenciosa.

Una posibilidad es crear un usuario aparentemente inofensivo.

useradd support

O elegir un nombre todavía más discreto, algo que parezca del sistema.

useradd rpcd

La mayoría de los administradores no se sorprendería al encontrar un usuario con ese nombre, y precisamente por eso resulta tan útil para un atacante.

También es habitual encontrar modificaciones en archivos como:

~/.ssh/authorized_keys

Nuevas tareas programadas en:

/etc/crontab

/var/spool/cron

O servicios adicionales en:

/etc/systemd/system

Todas esas acciones pueden formar parte de una administración completamente legítima.

O pueden ser el comienzo de un incidente.

Una vez más, el contexto es el que marca la diferencia.

Cuando los eventos empiezan a contar una historia

Hasta aquí, cada uno de los eventos que vimos podría clasificarse como una alerta de severidad media.

• Un inicio de sesión.
• Un uso de sudo.
• La modificación de un archivo sensible.
• La creación de un usuario.

Vistos de manera aislada, ninguno demuestra la existencia de un ataque.

Sin embargo, cuando aparecen juntos en pocos minutos, dejan de ser eventos independientes para transformarse en una cadena de ataque.

Ese es el verdadero valor de un SIEM.

No consiste únicamente en almacenar registros o generar alertas, sino en ayudarte a relacionar eventos que, observados por separado, parecerían completamente normales.

Y esa capacidad es la que permite detectar un ransomware mucho antes de que aparezca el primer archivo cifrado.

03:27 AM - El atacante deja de esconderse

Si si, hablamos de días, hasta semanas de duración del ataque, pero así no me va a alcanzar el tiempo para la película, y la rubia está esperando, así que sigan la corriente con los horarios

Hasta este momento el atacante ha sido bastante cuidadoso

Consiguió acceso, obtuvo privilegios, estableció mecanismos de persistencia (backdoor) y comenzó a conocer el entorno sin generar un impacto visible para los usuarios.

Pero llega un momento en que ya no puede seguir siendo discreto, Si quiere completar el ataque, necesita preparar el sistema para el cifrado Y es precisamente aquí donde comienzan a aparecer comportamientos mucho más difíciles de ocultar.

File Integrity Monitoring: una de las mejores defensas contra ransomware

Si tuviera que elegir una sola característica de Wazuh para detectar las primeras etapas de un ransomware, probablemente sería File Integrity Monitoring (FIM).

Y, curiosamente, también es una de las funciones que con más frecuencia encuentro deshabilitada.

Las razones suelen repetirse.

"Genera demasiadas alertas."

o

"Consume muchos recursos."

Es el mismo argumento que escucho cuando alguien decide desactivar SELinux, auditd o el firewall porque “molestan”.

Hasta el día en que realmente hacen falta. Es como usar un casco cuando andas en moto, es mejor usarlo siempre y no necesitarlo jamás, que necesitarlo una vez y no tenerlo.

File Integrity Monitoring no intenta identificar un ransomware por su nombre ni por su firma (además, los nombres y firmas cambian muy, MUY seguido). Su función es mucho más simple y, al mismo tiempo, mucho más útil: registrar qué archivos cambian, quién los modifica y cuándo ocurre.

Puede parecer una diferencia menor, pero cambia completamente la forma de detectar un ataque.

Detectar comportamiento es más importante que detectar un nombre

Los ransomware cambian constantemente.

• Cambian de nombre.
• Cambian de algoritmo.
• Cambian de extensión.
• Cambian de infraestructura.

Incluso aparecen nuevas familias cada pocos meses.

Sin embargo, todos tienen algo en común, Para cumplir su objetivo necesitan modificar archivos,

Miles de archivos, A veces decenas o cientos de miles.

No importa si mañana aparece una variante completamente nueva.

Tendrá que leer información, modificarla, renombrarla y volver a escribirla en el disco.

Y ese comportamiento deja una huella enorme.

Eso es exactamente lo que monitorea File Integrity Monitoring.

No monitorees todo el sistema

Uno de los errores más comunes al implementar FIM es intentar vigilar absolutamente todos los archivos del servidor.

El resultado suele ser predecible.

• Miles de eventos.
• Discos creciendo rápidamente.
• Administradores saturados de alertas, que terminan siendo como el cuento del lobo, nadie las toma en serio.

Y, finalmente, alguien termina deshabilitando la función.

La solución no es dejar de monitorear, La solución es monitorear con criterio.

Una buena pregunta para empezar es:

**¿Qué directorios me dejarían sin poder recuperar el servicio si desaparecieran?**

Normalmente la lista es bastante reducida.

/etc

/home

/var/www

/srv

/opt

/backup

/var/lib/mysql

/var/lib/postgresql

/vm

No necesitas supervisar millones de archivos.

Necesitas supervisar los que realmente importan para tu organización.

Un archivo modificado rara vez significa un ataque

Supongamos que Wazuh genera la siguiente alerta.

Archivo modificado:

/var/www/html/index.php

¿Es un incidente?

Probablemente no.

Tal vez un desarrollador publicó una nueva versión de la aplicación.

Ahora imagina un escenario diferente.

En menos de noventa segundos aparecen los siguientes eventos.

• 18.000 archivos modificados.
• 9.000 archivos renombrados.
• 11.000 permisos modificados.
• 4.500 archivos eliminados.

Eso ya no parece un despliegue.

Parece alguien destruyendo información.

Esta es una diferencia importante entre registrar eventos y detectar comportamientos.

Los eventos aislados aportan muy poco contexto.

Las secuencias muestran una historia completa.

Y esa historia suele ser mucho más útil para un analista de seguridad.

Los cambios de permisos también cuentan una historia

Muchos ransomware ni siquiera comienzan cifrando archivos.

Antes necesitan asegurarse de que podrán acceder a toda la información que quieren comprometer.

Por eso es común encontrar comandos como estos.

chmod -R

chown -R

chgrp -R

chattr -i

No buscan modificar permisos por casualidad.

Lo hacen porque esos permisos representan un obstáculo para la siguiente etapa del ataque.

Cuando ves cambios masivos sobre permisos en directorios críticos, alguien está preparando el entorno.

Y, normalmente, no es para instalar una actualización.

El atacante acaba de encontrar tus respaldos

Si existe algo que un ransomware odia son los respaldos.

Mientras puedas restaurar rápidamente, el chantaje pierde buena parte de su valor.

Por eso los backups generalmente son uno de los primeros objetivos.

El atacante comienza buscando directorios conocidos.

/backup

/snapshots

/repository

/mnt

/data

Después aparecen comandos bastante familiares.

rm -rf /backup

o

find / -type f -size +100M \( -name "*.zip" -o -name "*.tar" -o -name "*.gz" -o -name "*.bz2" -o -name "*.7z" -o -name "*.rar" -o -name "*.sql" -o -name "*.sql.gz" \) 2>/dev/null

o

find /backup -delete

o

rsync --delete

En servidores con LVM podrías encontrar operaciones como:

lvremove

lvchange

En ZFS:

zfs destroy

Y en Btrfs:

btrfs subvolume delete

En plataformas de virtualización también es frecuente ver operaciones sobre snapshots. Y lo interesante es que, en este punto, todavía no se ha cifrado absolutamente nada. Sin embargo, el atacante ya está eliminando tu capacidad de recuperación. Ese momento suele ser mucho más importante que el propio cifrado, porque todavía existe la posibilidad de reaccionar.

Otra opción, aún peor, es que no toquen los respaldos. Como ya mencioné, un ataque bien planificado toma tiempo, y un hacker suele ser una persona muy paciente. Podrían simplemente plantar backdoors, dejar todo el sistema de ransomware listo y configurar un timer, como una bomba de tiempo. ¿Para qué? Para que los respaldos se sigan generando con normalidad, pero ya contengan todo el malware instalado.

Si además logran ver los tiempos de rotación de los respaldos, pueden programar el ataque justo después de que el último respaldo “sano” haya sido borrado. En ese punto, todos los respaldos disponibles están comprometidos y la recuperación ya no es una opción.

“Nosotros tenemos snapshots”

Perfecto.

Ahora hazte otra pregunta.

¿Quién puede eliminarlos?

Si el atacante consiguió privilegios administrativos, los snapshots dejan de ser una garantía y pasan a ser otro recurso bajo su control.

Muchas organizaciones descubren este detalle demasiado tarde, cuando intentan volver atrás y descubren que ya no queda ningún punto de restauración disponible.

Borrar evidencia también forma parte del ataque

Los atacantes saben que cada acción deja rastros.

Y también saben que esos registros pueden convertirse en evidencia durante una investigación.

Por eso es habitual que intenten eliminarlos antes de iniciar el cifrado.

Algunos ejemplos son:

history -c

rm -rf /var/log/*

journalctl --vacuum-time=1s

O incluso algo tan simple como:

echo "" > /var/log/secure

Ningún administrador elimina todos los registros de un servidor en producción sin una razón muy específica.

Si alguien lo hace, merece la pena averiguar inmediatamente qué está ocurriendo.

NOTA: Ya vimos en las recomendaciones de hardening que los logs deben enviarse a un servidor remoto. Este es un ejemplo perfecto de por qué esa práctica no es opcional: cuando el atacante ya está dentro, lo primero que hace es borrar su rastro. Si los logs están solo en el servidor comprometido, esa evidencia desaparece con unos pocos comandos. En cambio, si están en un destino remoto, la historia del ataque queda intacta y el análisis forense sigue siendo posible.

El siguiente objetivo será dejarte sin visibilidad

Existe un patrón que se repite una y otra vez en los incidentes de ransomware.

Antes del cifrado, el atacante intenta desactivar todo aquello que pueda generar alertas.

Por ejemplo:

systemctl stop wazuh-agent

systemctl stop auditd

systemctl stop firewalld

systemctl disable auditd

setenforce 0

Si alguien detiene el agente de Wazuh, desactiva SELinux y, pocos minutos después, comienza a eliminar respaldos, no hace falta esperar a que aparezcan archivos cifrados para entender hacia dónde se dirige el incidente.

El ataque ya está en marcha.

Cuando Wazuh deja de ser un simple visor de logs

Mucha gente piensa que Wazuh sirve únicamente para centralizar registros.

Eso es solo una pequeña parte de su capacidad.

El verdadero valor aparece cuando empiezas a relacionar eventos que, observados por separado, parecerían completamente normales.

Una alerta aislada rara vez dice demasiado.

Diez alertas relacionadas pueden describir con bastante precisión lo que está ocurriendo en el servidor.

Y esa diferencia es la que convierte un conjunto de logs en información útil para detectar un incidente antes de que el atacante llegue a su objetivo.

El problema no son las alertas

Hay una frase que escucho siempre

“Wazuh genera demasiadas alertas.”

La mayoría de las veces el problema no es la cantidad de alertas, sino la forma en que se analizan.

Muchos administradores observan cada evento como si fuera completamente independiente del resto.

Pero los ataques no funcionan así.

Imagina la siguiente secuencia.

03:12  Inicio de sesión SSH exitoso.

03:14  Uso de sudo.

03:15  Creación de un nuevo usuario administrador.

03:17  Modificación de sudoers.

03:19  Desactivación de SELinux.

03:20  Detención del agente Wazuh.

03:22  Eliminación de respaldos.

03:24  Miles de archivos modificados.

Si analizamos cada uno de estos eventos por separado, probablemente la mayoría tendría una severidad media o incluso informativa.

Sin embargo, cuando aparecen juntos en pocos minutos dejan de ser ocho eventos independientes.

Ahora describen una cadena de ataque.

Y esa es la verdadera diferencia entre almacenar registros y hacer detección.

Deja de buscar malware

Durante muchos años la industria de la seguridad intentó resolver el mismo problema de la misma manera: buscar firmas, hashes, nombres de malware o indicadores de compromiso (IOC).

Todo eso sigue siendo útil, pero tiene una limitación evidente. Solo funciona cuando alguien ya descubrió la amenaza.

¿Y qué ocurre si mañana aparece un ransomware completamente nuevo?

• No tendrá firma.
• No tendrá reputación.
• No aparecerá en VirusTotal.
• No existirá ninguna regla específica para detectarlo.

Sin embargo, seguirá necesitando exactamente las mismas cosas que cualquier otro ransomware.

• Necesitará entrar al servidor.
• Obtener privilegios.
• Buscar respaldos.
• Eliminar respaldos.
• Modificar miles de archivos.
• Detener servicios de seguridad.

En otras palabras, cambiará el malware, pero No el comportamiento.

Por eso la detección basada en comportamiento resulta mucho más resistente al paso del tiempo que la detección basada únicamente en firmas. Más aun tratándose de Linux, donde muchas veces los ataques son hechos a mano y a medida, no usan un malware conocido.

OpenSSL no es un ransomware

Este es uno de mis ejemplos favoritos.

Cada cierto tiempo encuentro reglas que generan una alerta simplemente porque alguien ejecutó openssl.

Es una mala idea.

OpenSSL probablemente sea una de las herramientas más utilizadas en cualquier servidor Linux.

Se usa para renovar certificados, generar claves, verificar conexiones TLS y firmar información.

Entonces, ¿por qué aparece tantas veces durante un incidente de ransomware?

Porque también puede utilizarse para cifrar archivos.

El problema nunca fue la herramienta.

El problema es el contexto.

No es lo mismo que un administrador ejecute OpenSSL para renovar un certificado que un proceso perteneciente a www-data lo utilice para procesar cuarenta mil archivos dentro del sitio web.

Aunque el comando es exactamente el mismo.

Lo mismo ocurre con muchas otras herramientas

Tampoco tendría sentido generar una alerta simplemente porque aparece alguno de estos procesos.

openssl
gpg
tar
zip
7z
xz
rsync

Todas son herramientas completamente legítimas.

Las preguntas realmente importantes son otras.

• ¿Quién ejecutó el proceso?
• ¿Desde qué cuenta?
• ¿Sobre qué archivos?
• ¿Desde qué dirección IP?
• ¿Qué ocurrió inmediatamente antes?
• ¿Hubo una escalada de privilegios?
• ¿Ese usuario existía el día anterior?

Cuando empiezas a responder esas preguntas, dejas de analizar procesos individuales y comienzas a reconstruir el comportamiento del atacante.

El contexto siempre gana

Imagina dos servidores.

En el primero, un administrador inicia sesión durante una ventana de mantenimiento, renueva certificados, reinicia Apache y publica una nueva versión de la aplicación.

Todo está planificado y documentado.

En el segundo, un usuario llamado backup inicia sesión desde otro país a las tres de la madrugada. Cinco minutos después obtiene privilegios de administrador, desactiva auditd, cambia SELinux a modo permisivo, elimina snapshots y comienza a modificar miles de archivos.

Ambos servidores ejecutaron prácticamente los mismos comandos.

Sin embargo, solo uno está siendo administrado.

El otro está siendo atacado.

Eso es contexto.

Y el contexto suele aportar mucho más valor que cualquier firma.

Ahí es donde empieza a trabajar un SOC

Existe una diferencia enorme entre revisar alertas y analizar incidentes.

Revisar alertas consiste en leer eventos.

Analizar incidentes consiste en reconstruir una historia.

Un buen analista no pregunta:

¿Qué alerta apareció?

Pregunta:

¿Qué estaba intentando hacer el atacante?

Ese cambio de perspectiva transforma completamente una investigación.

Ya no estás reaccionando cuando aparecen archivos cifrados.

Estás reaccionando cuando el atacante todavía está preparando el entorno.

Y esos minutos de diferencia pueden marcar el éxito o el fracaso de una contención.

Entonces…

¿Puede Wazuh detener un ransomware?

La respuesta corta es no.

Y cualquiera que diga lo contrario probablemente está vendiendote algo.

• Wazuh no evita que alguien reutilice una contraseña.
• No corrige una vulnerabilidad.
• No instala parches.
• No reemplaza los respaldos.
• No impide que exista un nuevo ransomware.

Lo que sí hace es darte visibilidad.

Y esa visibilidad puede marcar la diferencia entre descubrir un ataque cuando un atacante acaba de entrar al servidor o descubrirlo cuando toda la empresa está leyendo una nota de rescate.

Créeme. La segunda opción siempre resulta mucho más cara, aunque no paguen el rescate, la perdida de datos, downtime de servicios críticos, siempre, siempre le pega fuerte a la billetera de la empresa.

Pruébalo tú mismo (sin infectar ningún servidor)

Si hay algo que he aprendido después de muchos años administrando infraestructura es esto:

Nunca des por hecho que una alerta funciona.

El peor momento para descubrir que una regla estaba mal configurada es durante un incidente real.

Con los respaldos ocurre exactamente lo mismo.

Todo el mundo afirma que tiene backups.

Muy pocos saben con certeza si podrán restaurarlos cuando llegue el momento.

Con Wazuh sucede algo parecido.

• Instalar el agente no significa que la detección esté funcionando correctamente.
• Las reglas pueden estar mal ajustadas.
• Los directorios importantes podrían no estar siendo monitoreados.
• Las alertas podrían llegar demasiado tarde, O simplemente, nadie podría estar revisándolas.

Por eso recomiendo realizar pequeños laboratorios de forma periódica.

No necesitas descargar un ransomware, no necesitas malware, no necesitas poner en riesgo un servidor.

Basta con reproducir algunos de los comportamientos que tendría un atacante.

Es mucho más seguro y, además, te permite validar que la detección realmente funciona.

Laboratorio 1: modificaciones masivas de archivos

Comienza creando un directorio de pruebas.

mkdir /tmp/ransomware-test

Genera algunos archivos.

for i in $(seq 1 500)
do
    echo "OrangeBox" > /tmp/ransomware-test/file-$i.txt
done

Ahora modifica todos los archivos.

for i in /tmp/ransomware-test/*
do
    echo "Archivo modificado" >> "$i"
done

Si File Integrity Monitoring está correctamente configurado, Wazuh debería comenzar a registrar una gran cantidad de modificaciones en pocos segundos.

No porque exista un ransomware.

Sino porque alguien acaba de alterar cientos de archivos de manera simultánea.

Y ese comportamiento merece atención.

Laboratorio 2: renombrado masivo

Muchos ransomware cambian la extensión de todos los archivos durante el proceso de cifrado.

Puedes simular ese comportamiento fácilmente.

for i in /tmp/ransomware-test/*
do
    mv "$i" "$i.encrypted"
done

No has cifrado absolutamente nada.

Sin embargo, acabas de reproducir uno de los patrones más habituales en este tipo de ataques.

Laboratorio 3: cambios masivos de permisos

También resulta útil comprobar cómo responde Wazuh frente a modificaciones repetitivas sobre los permisos.

Por ejemplo:

chmod -R 640 /tmp/ransomware-test

Después:

chmod -R 600 /tmp/ransomware-test

Y nuevamente:

chmod -R 640 /tmp/ransomware-test

El objetivo no es cambiar permisos.

Lo importante es verificar si Wazuh detecta una gran cantidad de modificaciones realizadas en muy poco tiempo.

Laboratorio 4: eliminación masiva de archivos

El siguiente paso consiste en borrar completamente el contenido del directorio de pruebas.

rm -rf /tmp/ransomware-test

Si ese directorio forma parte de File Integrity Monitoring, Wazuh debería registrar la eliminación de los archivos.

Una vez más, no estás simulando malware.

Estás simulando comportamiento.

Y eso es justamente lo que queremos validar.

Laboratorio 5: el atacante intenta borrar sus huellas

Una práctica bastante habitual consiste en eliminar la evidencia del ataque.

Puedes simular algunas de esas acciones.

Borra el historial de comandos.

history -c

Después vacía un archivo de log de pruebas.

truncate -s 0 /tmp/log-prueba.log

Evidentemente esto no eliminará todas las evidencias de un sistema comprometido.

El objetivo es comprobar si las reglas que diseñaste son capaces de detectar intentos de ocultar actividad.

¿Qué deberías revisar?

Durante estos laboratorios no te conformes con comprobar que aparece una alerta.

Eso es apenas el primer paso.

Hazte preguntas como estas:

• ¿Cuánto tardó en generarse la alerta?
• ¿Llegó correctamente al dashboard?
• ¿Se envió una notificación?
• ¿El nivel de severidad fue el esperado?
• ¿Se registró el usuario responsable?
• ¿Se identificó el proceso que realizó la acción?
• ¿La información disponible es suficiente para iniciar una investigación?

Si alguna de esas respuestas es no, acabas de encontrar una oportunidad de mejora.

Y descubrir ese problema durante un laboratorio siempre será mucho mejor que descubrirlo en medio de un incidente real.

Active Response: automatiza con criterio

Cada vez que recomiendo Wazuh aparece la misma pregunta.

"¿Puedo hacer que Wazuh bloquee automáticamente cualquier ataque?"

La respuesta es sencilla.

Sí.

La pregunta realmente importante es otra.

¿Deberías hacerlo?

No siempre.

Automatizar respuestas sin comprender el impacto puede provocar más problemas que el propio incidente.

Imagina que una regla mal ajustada bloquea la dirección IP de tu servidor de respaldos.

O del balanceador.

O de un nodo del clúster Kubernetes.

Ahora ya no tienes un único problema.

Tienes dos: El atacante Y una automatización mal diseñada.

Mi recomendación es empezar siempre por acciones de bajo riesgo.

Por ejemplo:

• Bloquear temporalmente una IP que realiza fuerza bruta.
• Enviar una alerta crítica al equipo de soporte
• Abrir automáticamente un ticket.
• Ejecutar un script que recopile evidencia.
• Notificar al equipo de seguridad.

Las acciones más agresivas, como bloquear servicios o aislar equipos automáticamente, deberían implementarse solo cuando tengas plena confianza en las reglas que disparan esa respuesta.

La automatización debe ayudar a responder más rápido, nunca convertirse en un incidente adicional.

Lo que realmente protege un servidor Linux

Si llegaste hasta aquí esperando encontrar un botón de “Protección contra ransomware”, tengo una mala noticia.

Ese botón no existe.

La seguridad siempre es el resultado de varias capas trabajando en conjunto.

• Hardening.
• Actualizaciones.
• Contraseñas robustas.
• MFA.
• Segmentación de red.
• Backups probados.
• Monitoreo.
• Auditoría.
• Personas que realmente revisen las alertas.

Wazuh es una pieza muy importante dentro de esa estrategia.

Pero sigue siendo una pieza.

No el rompecabezas completo.

Conclusión

Los ransomware seguirán evolucionando, cambiarán de nombre, de algoritmo, de infraestructura, incluso de sistema operativo. Pero lo que difícilmente cambiará será el comportamiento de quien los ejecuta.

Necesitará:

• Conseguir acceso.
• Elevar privilegios.
• Conocer tu infraestructura.
• Encontrar tus respaldos.
• Desactivar tus defensas.
• Modificar miles de archivos.

Y cada una de esas acciones dejará evidencia.

Por eso, la verdadera pregunta no es si algún software puede detener un ransomware mágicamente.

La pregunta es mucho más incómoda.

¿Estás observando las señales antes de que sea demasiado tarde?

Porque la nota de rescate aparece bastante tiempo después que el atacante terminó la parte más importante de su trabajo, ahora sólo está pasándote la cuenta.

¿Necesitas ayuda para implementar Wazuh?

En OrangeBox ayudamos a empresas a implementar plataformas de monitoreo y seguridad para servidores Linux, VMware y entornos críticos.

El objetivo no es llenar dashboards de colores.

Es ayudarte a detectar problemas antes de que se conviertan en incidentes.

Si ya utilizas Wazuh y quieres revisar la configuración de tus reglas, File Integrity Monitoring, Active Response o tu estrategia de monitoreo, conversemos.

A veces, una pequeña mejora en la detección puede ahorrarte muchas horas de recuperación.

Y unas cuantas canas también.