Cómo detectar un ransomware en Linux antes de que cifre tu servidor usando Wazuh
Si llevas algunos años administrando servidores Linux, seguramente has escuchado alguna variante de esta frase:
“Linux no necesita antivirus.”
La versión premium es todavía mejor.
“En Linux no existen los ransomware.”
Cada vez que escucho eso me imagino a un administrador apagando el monitor, cruzando los brazos y diciendo:
“Misión cumplida.”
Lamentablemente, Internet no funciona con optimismo.
Linux sigue siendo uno de los sistemas operativos más seguros disponibles.
Pero seguro no significa invulnerable.
Si un atacante obtiene acceso al servidor utilizando credenciales robadas, una vulnerabilidad sin corregir o una mala configuración, el problema deja de ser el sistema operativo.
El problema ahora eres tú.
O mejor dicho…
Todo lo que el atacante puede hacer utilizando tus propios permisos.
Y ahí es donde aparece otro mito bastante peligroso.
La mayoría imagina un ataque de ransomware de esta forma.
Un atacante compromete un servidor.
Cinco segundos después…
Todos los archivos cambian de nombre.
Las aplicaciones dejan de funcionar.
Aparece una nota de rescate.
Y recién ahí comienza el incidente.
No.
Cuando ves los archivos cifrados, el ataque prácticamente terminó.
Todo el trabajo difícil ocurrió mucho antes.
El atacante ya estudió tu infraestructura.
Ya encontró tus respaldos.
Ya obtuvo privilegios administrativos.
Ya sabe dónde están las bases de datos.
Ya conoce los servidores críticos.
Ya identificó las máquinas virtuales.
Incluso es posible que lleve varios días dentro de la red.
El cifrado es solamente el último paso.
Y aquí aparece la pregunta realmente importante.
¿Por qué nadie detectó todo lo anterior?
Porque la mayoría de las organizaciones sigue buscando malware.
Cuando en realidad debería estar buscando comportamientos.
La diferencia entre detectar malware y detectar un ataque
Imagina que alguien entra a tu casa.
No roba nada.
Solo recorre todas las habitaciones.
Fotografía cada ventana.
Anota dónde está la caja fuerte.
Desconecta la alarma.
Copia las llaves.
Y se va.
Técnicamente todavía no ocurrió un robo.
Pero cualquiera entendería que algo muy malo está por pasar.
Con un ransomware ocurre exactamente lo mismo.
Antes de cifrar un solo archivo, el atacante necesita realizar una enorme cantidad de acciones.
Todas dejan evidencia.
Procesos.
Conexiones.
Cambios en archivos.
Usuarios nuevos.
Servicios detenidos.
Permisos modificados.
Comandos ejecutados.
Nada de eso es un ransomware.
Pero todo junto cuenta una historia.
Y esa historia suele comenzar varias horas antes del desastre.
Ahí es donde Wazuh marca la diferencia
Existe una idea equivocada bastante común.
Instalar Wazuh no significa que tu empresa ahora tenga un SOC.
Tampoco significa que estés protegido contra ransomware.
Ni mucho menos que puedas olvidarte de la seguridad.
Wazuh no reemplaza:
- Hardening.
- Gestión de vulnerabilidades.
- MFA.
- Backups.
- Segmentación de red.
- Actualizaciones.
- Políticas de acceso.
Lo que hace es algo mucho más interesante.
Te muestra comportamientos que normalmente pasarían completamente desapercibidos.
Y mientras antes aparezcan esas alertas…
Más posibilidades tienes de detener el ataque.
Porque restaurar un backup siempre será más barato que negociar con un delincuente.
Aunque todavía me sigue sorprendiendo la cantidad de empresas que prefieren gastar millones en infraestructura…
…pero consideran un gasto innecesario revisar las alertas de seguridad.
Es parecido a instalar cámaras en toda la empresa y después guardar el monitor en una bodega.
Las cámaras funcionan perfectamente.
Nadie las mira.
El problema nunca fueron las cámaras.
El objetivo de este artículo
Este no es un tutorial para instalar Wazuh.
Tampoco vamos a revisar cada opción del dashboard.
La documentación oficial ya hace un excelente trabajo en eso.
La idea aquí es distinta.
Vamos a recorrer paso a paso cómo trabaja realmente un atacante.
Qué hace primero.
Qué hace después.
Qué evidencia deja.
Cómo detectarla utilizando Wazuh.
Y por qué, en muchos casos, es perfectamente posible detener un ransomware horas antes de que empiece a cifrar archivos.
Porque los ransomware cambian constantemente.
El comportamiento de un atacante…
Ese casi nunca cambia.
03:12 AM - El ataque acaba de comenzar (y nadie lo sabe)
Son las 03:12 de la madrugada.
No hay nadie trabajando.
No hay ventanas de mantenimiento.
No hay despliegues programados.
El servidor lleva semanas funcionando sin problemas.
De pronto aparece un inicio de sesión SSH.
Nada explota.
No aumenta el uso de CPU.
No aparecen mensajes de error.
La aplicación sigue funcionando normalmente.
Si revisaras solamente el dashboard de infraestructura probablemente dirías:
Todo está bien.
Pero no.
Acaba de comenzar el incidente.
Y todavía faltan varias horas para que aparezca el primer archivo cifrado.
Así trabajan la mayoría de los ransomware modernos
Hollywood nos hizo creer que un ransomware entra y comienza a cifrar archivos inmediatamente.
Eso funciona muy bien para una película.
Pero es una pésima estrategia para un atacante.
¿Por qué avisar que estás dentro antes de saber qué vale la pena robar?
Hoy la mayoría de las bandas de ransomware siguen una metodología bastante ordenada.
flowchart LR
A[Acceso inicial]
--> B[Escalada de privilegios]
B --> C[Persistencia]
C --> D[Reconocimiento]
D --> E[Movimiento lateral]
E --> F[Desactivar defensas]
F --> G[Eliminar respaldos]
G --> H[Cifrado]
H --> I[Extorsión]
Lo interesante es que cada etapa deja evidencia.
Y esa evidencia normalmente aparece mucho antes del cifrado.
Ese es exactamente el momento donde Wazuh puede darte una ventaja.
No porque conozca el nombre del ransomware.
Sino porque reconoce comportamientos que simplemente no deberían ocurrir.
Primera etapa: conseguir acceso
La realidad suele ser mucho menos espectacular de lo que imaginamos.
No aparecen hackers con capucha escribiendo código verde sobre una pantalla negra.
Generalmente ocurre algo mucho más aburrido.
Una contraseña filtrada.
Una VPN comprometida.
Una llave SSH robada.
Un servicio sin actualizar.
Una aplicación vulnerable.
Una credencial olvidada hace cinco años.
Y listo.
El atacante entra exactamente igual que cualquier administrador.
No rompe nada.
No instala malware.
No modifica archivos.
Solo inicia sesión.
Por eso muchas veces el primer indicador del ataque ya estaba registrado en los logs.
Nadie lo revisó.
¿Qué puede detectar Wazuh?
Por ejemplo, eventos como estos.
Failed password for root
Invalid user backup
Invalid user oracle
Failed password for admin
Hasta aquí todavía no significa que exista un ataque.
Internet está lleno de bots probando contraseñas.
Eso ocurre todos los días.
Lo realmente interesante aparece cuando alguno de esos intentos finalmente tiene éxito.
Accepted password for admin
o
Accepted publickey for root
¿Eso significa compromiso?
Tampoco.
Depende completamente del contexto.
Porque seguridad nunca se trata solamente del evento.
Se trata del contexto.
No es lo mismo que el administrador inicie sesión desde la oficina un lunes a las diez de la mañana.
Que un usuario llamado “backup” aparezca autenticándose desde otro continente un domingo a las tres de la madrugada.
El log puede ser prácticamente idéntico.
La historia que cuentan es completamente distinta.
Segunda etapa: ahora necesita ser root
Entrar al servidor no sirve de mucho.
Con permisos limitados es difícil desactivar servicios, modificar configuraciones o cifrar archivos del sistema.
Así que el siguiente objetivo suele ser bastante predecible.
Convertirse en root.
Aquí empiezan a aparecer comandos conocidos por cualquier administrador Linux.
sudo -i
sudo su -
su -
pkexec
Ninguno de ellos es malicioso.
Tú probablemente los ejecutas todos los días.
Lo importante es quién los ejecuta.
Y qué ocurrió antes.
Y qué ocurrió después.
Supongamos 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 normal?
Probablemente no.
Ahora empiezan a aparecer patrones.
Y los patrones son muchísimo más interesantes que los eventos individuales.
El archivo más pequeño puede contar una historia enorme
Hay cuatro archivos que prácticamente todos los atacantes terminan tocando.
/etc/passwd
/etc/shadow
/etc/group
/etc/sudoers
No porque sean especiales.
Sino porque controlan la identidad y los privilegios del sistema.
Modificar cualquiera de ellos no implica automáticamente un ataque.
Pero sí merece una pregunta.
¿Quién hizo el cambio?
Si la respuesta es:
“Felipe estaba creando un usuario nuevo durante una ventana de mantenimiento.”
Perfecto.
Caso cerrado.
Si la respuesta es:
“No tenemos idea.”
Entonces ya tienes un problema bastante más serio que una alerta en Wazuh.
Tercera etapa: asegurarse un camino de regreso
Los atacantes rara vez quieren entrar una sola vez.
Quieren poder volver cuando quieran.
Aunque cierres la vulnerabilidad original.
Aunque cambies la contraseña.
Aunque reinicies el servidor.
Por eso aparece la persistencia.
Las técnicas pueden variar, pero el objetivo siempre es el mismo.
Volver sin hacer ruido.
Por ejemplo.
Crear un usuario aparentemente inofensivo.
useradd support
O algo todavía más creativo.
useradd backup
Porque si alguien revisa rápidamente la lista de usuarios probablemente asumirá que siempre estuvo ahí.
También es frecuente encontrar modificaciones en:
~/.ssh/authorized_keys
o nuevas tareas programadas.
/etc/crontab
/var/spool/cron
o servicios de systemd.
/etc/systemd/system
Todo eso puede ser completamente legítimo.
O puede ser el comienzo de un incidente.
Nuevamente…
El contexto manda.
No el comando.
¿Y si todo esto ocurre en menos de cinco minutos?
Aquí empieza la verdadera gracia de un SIEM.
Cada uno de estos eventos por separado podría clasificarse como una alerta de severidad media.
Pero cuando aparecen juntos…
La historia cambia completamente.
Ya no estás viendo un inicio de sesión.
Estás viendo una cadena de ataque.
Y eso cambia la prioridad de la investigación.
Porque un atacante rara vez hace una sola cosa.
Siempre hace varias.
Y casi siempre las hace en el mismo orden.
03:27 AM - El atacante deja de esconderse
Hasta este momento el atacante ha sido bastante cuidadoso.
Entró.
Obtuvo privilegios.
Creó persistencia.
Reconoció el servidor.
Todo con un impacto prácticamente invisible para el usuario.
Pero llega un momento en que ya no puede seguir siendo discreto.
Necesita comenzar a preparar el cifrado.
Y aquí es donde empiezan a aparecer comportamientos extremadamente difíciles de ocultar.
File Integrity Monitoring: probablemente la mejor herramienta contra ransomware
Si tuviera que elegir una sola característica de Wazuh para detectar ransomware, elegiría File Integrity Monitoring.
Sin dudarlo.
Y curiosamente es una de las funciones que más veo deshabilitada.
Generalmente por dos motivos.
“Genera muchas alertas.”
o
“Consume recursos.”
Es curioso.
Es exactamente el mismo argumento que escucho cuando alguien desactiva SELinux, auditd o el firewall.
Todo molesta…
…hasta el día que realmente se necesita.
File Integrity Monitoring no intenta descubrir un ransomware.
Hace algo mucho más simple.
Observa continuamente qué archivos cambian.
Y esa diferencia es enorme.
No importa qué ransomware sea
Todos los ransomware cambian.
Cambian de nombre.
Cambian de algoritmo.
Cambian de extensión.
Cambian de infraestructura.
Pero hay algo que jamás pueden evitar.
Necesitan modificar archivos.
Miles.
Decenas de miles.
A veces cientos de miles.
Y eso deja una huella gigantesca.
No importa si mañana aparece un ransomware completamente nuevo.
Va a tener que hacer exactamente lo mismo.
Leer.
Modificar.
Renombrar.
Guardar.
Repetir.
Miles de veces.
Eso es justamente lo que monitorea FIM.
No monitorees todo
Uno de los errores más comunes es habilitar FIM sobre todo el sistema operativo.
Después llegan cientos de miles de eventos.
El disco comienza a llenarse.
El administrador se molesta.
Y finalmente termina deshabilitando la función.
La solución no es dejar de monitorear.
La solución es monitorear con criterio.
Pregúntate una sola cosa.
¿Qué directorios me dejarían sin trabajo si desaparecen?
Normalmente la lista es bastante pequeña.
Por ejemplo.
/etc
/home
/var/www
/srv
/opt
/backup
/var/lib/mysql
/var/lib/postgresql
/vm
No necesitas observar veinte millones de archivos.
Necesitas observar los importantes.
El error de mirar un solo árbol
Imagina que aparece esta alerta.
Archivo modificado:
/var/www/html/index.php
¿Es un ataque?
Probablemente no.
Tal vez el desarrollador publicó una nueva versión.
Ahora cambia el escenario.
En menos de noventa segundos aparecen.
- 18.000 archivos modificados.
- 9.000 archivos renombrados.
- 11.000 permisos modificados.
- 4.500 archivos eliminados.
Eso ya no parece un despliegue.
Eso parece alguien destruyendo información.
El problema de muchos sistemas de monitoreo es que analizan eventos individuales.
Los atacantes trabajan con secuencias.
Y las secuencias cuentan historias mucho más interesantes.
Los permisos también hablan
Muchos ransomware ni siquiera comienzan cifrando.
Antes necesitan asegurarse de que podrán acceder a todo.
Por eso aparecen comandos como.
chmod -R
chown -R
chgrp -R
chattr -i
No porque quieran modificar permisos.
Lo hacen porque esos permisos son un obstáculo para el siguiente paso.
Cuando ves cambios masivos sobre permisos en directorios críticos, alguien está preparando el terreno.
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 backups.
Porque destruyen completamente el negocio.
No importa cuánto cifren.
Si puedes restaurar rápidamente, el chantaje pierde valor.
Por eso los respaldos casi nunca son el último objetivo.
Generalmente son uno de los primeros.
Empiezan buscando directorios conocidos.
/backup
/snapshots
/repository
/mnt
/data
Después aparecen comandos bastante familiares.
rm -rf /backup
o
find /backup -delete
o
rsync --delete
En servidores con LVM podrías encontrar.
lvremove
lvchange
En ZFS.
zfs destroy
En Btrfs.
btrfs subvolume delete
Y en plataformas de virtualización probablemente aparezcan operaciones sobre snapshots.
Aquí ocurre algo interesante.
Todavía no se ha cifrado absolutamente nada.
Pero el atacante ya está eliminando tu capacidad de recuperación.
Ese momento es muchísimo más importante que el propio cifrado.
Porque todavía estás a tiempo de reaccionar.
“Nosotros tenemos snapshots”
Perfecto.
Ahora pregúntate otra cosa.
¿Quién puede eliminarlos?
Porque si el atacante consiguió permisos administrativos…
Los snapshots también son simplemente archivos.
Muchas empresas descubren este pequeño detalle cuando intentan volver atrás…
…y descubren que ya no existe ningún punto de restauración.
Borrar evidencia también forma parte del ataque
Los delincuentes saben perfectamente que cada acción queda registrada.
Y también saben que esos registros pueden terminar frente a un perito.
Así que intentan desaparecer.
Aparecen comandos como.
history -c
o
rm -rf /var/log/*
o
journalctl --vacuum-time=1s
Incluso cosas tan simples como.
echo "" > /var/log/secure
Ningún administrador borra los logs completos de un servidor en producción porque sí.
Si alguien lo hace…
Vale la pena averiguar el motivo.
Urgentemente.
El siguiente objetivo será dejarte ciego
Hay un patrón que prácticamente se repite en todos los incidentes.
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 luego elimina respaldos…
No hace falta esperar el archivo cifrado para entender cómo terminará la historia.
El ataque ya está en marcha.
Y probablemente llevas varios minutos de retraso.
Aquí es donde Wazuh deja de ser un visor de logs
Mucha gente cree que Wazuh sirve para juntar eventos.
Eso sería desperdiciar completamente la plataforma.
Su verdadero valor aparece cuando empiezas a unir las piezas.
Una alerta aislada rara vez dice mucho.
Diez alertas consecutivas pueden contar exactamente lo que está ocurriendo.
Y eso veremos en la siguiente sección.
Porque el atacante todavía no comienza a cifrar archivos.
Pero Wazuh ya tiene suficiente información para levantar una alerta crítica mucho antes de que aparezca la primera nota de rescate.
El problema no son las alertas
Hay una frase que escucho bastante seguido.
“Wazuh genera demasiadas alertas.”
La mayoría de las veces no es cierto.
Lo que realmente ocurre es otra cosa.
El administrador está mirando cada alerta como si fuera un evento independiente.
Y los ataques no funcionan así.
Los ataques cuentan historias.
Supongamos este escenario.
03:12
Inicio de sesión SSH exitoso.
03:14
Uso de sudo.
03:15
Creación de un 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 evento por separado probablemente todos tengan severidad media.
Incluso algunos podrían clasificarse como informativos.
Ahora míralos como una secuencia.
¿Todavía parecen ocho eventos independientes?
No.
Ahora parecen un ransomware preparándose para trabajar.
Y ahí está la verdadera diferencia entre juntar logs y hacer detección.
Deja de buscar malware
Durante años la industria intentó resolver el mismo problema.
Buscar una firma.
Buscar un hash.
Buscar un nombre.
Buscar un IOC.
Todo eso sigue siendo útil.
Pero tiene una limitación enorme.
Funciona únicamente cuando alguien ya descubrió el malware.
¿Y si mañana aparece uno completamente nuevo?
No tendrá firma.
No tendrá reputación.
No aparecerá en VirusTotal.
No existirá ninguna regla específica.
Sin embargo…
Necesitará exactamente los mismos permisos.
Exactamente los mismos archivos.
Exactamente los mismos procesos.
Exactamente los mismos respaldos.
Exactamente la misma secuencia de acciones.
Los atacantes cambian.
El comportamiento casi nunca cambia.
Por eso hoy el comportamiento vale muchísimo más que la firma.
OpenSSL no es un ransomware
Este es uno de mis ejemplos favoritos.
Cada cierto tiempo veo reglas que generan alertas simplemente porque alguien ejecutó OpenSSL.
Mala idea.
OpenSSL es probablemente una de las herramientas más utilizadas en cualquier servidor Linux.
Renovar certificados.
Crear llaves.
Verificar conexiones.
Firmar archivos.
Todo eso utiliza OpenSSL.
Entonces…
¿Por qué aparece tanto en incidentes de ransomware?
Porque también sirve para cifrar.
El problema nunca fue OpenSSL.
El problema es el contexto.
No es lo mismo.
root
renovando un certificado TLS.
Que.
www-data
ejecutando OpenSSL sobre cuarenta mil archivos del sitio web.
El comando es idéntico.
La historia es completamente distinta.
Lo mismo ocurre con estas herramientas
Tampoco tendría sentido generar una alerta solamente porque aparece alguno de estos procesos.
openssl
gpg
tar
zip
7z
xz
rsync
Todos son completamente legítimos.
Lo interesante es responder preguntas como estas.
¿Por qué se ejecutó?
¿Quién lo ejecutó?
¿Desde dónde?
¿Sobre qué archivos?
¿Después de qué otros eventos?
¿Antes ocurrió una escalada de privilegios?
¿El usuario existía ayer?
Cuando empiezas a responder esas preguntas…
Ya no estás viendo procesos.
Estás viendo comportamiento.
El contexto siempre gana
Imagina dos servidores.
Servidor A.
03:15
Felipe inicia sesión.
Renueva certificados.
Reinicia Apache.
Actualiza la aplicación.
Todo perfectamente documentado.
Servidor B.
03:15
Un usuario llamado backup inicia sesión desde otro país.
Cinco minutos después obtiene root.
Detiene auditd.
Desactiva SELinux.
Elimina snapshots.
Comienza a modificar miles de archivos.
Ambos servidores ejecutaron exactamente los mismos comandos.
Pero solamente uno está siendo administrado.
El otro está siendo comprometido.
Eso es contexto.
Y el contexto vale muchísimo más que cualquier firma.
La mejor alerta es la que nunca necesitó una firma
Una de las ventajas más interesantes de trabajar con comportamiento es que puedes detectar amenazas completamente nuevas.
Supongamos que mañana aparece un ransomware llamado…
MegaUltraCryptoDestroyer 9000.
Sí.
El nombre probablemente sea igual de ridículo.
Nadie lo conoce.
No existe documentación.
No hay reglas.
No hay indicadores.
No hay firmas.
Pero para funcionar necesita hacer lo mismo que todos los anteriores.
Entrar.
Escalar privilegios.
Buscar respaldos.
Eliminar respaldos.
Detener servicios.
Modificar archivos.
Eso significa que el nombre del malware prácticamente deja de importar.
Lo único importante es la secuencia.
Ahí es donde empieza a trabajar un SOC
Existe una diferencia enorme entre revisar alertas y analizar incidentes.
Revisar alertas es leer eventos.
Analizar incidentes es reconstruir una historia.
Un buen analista no pregunta.
¿Qué alerta apareció?
Pregunta.
¿Qué estaba intentando hacer el atacante?
Cuando empiezas a responder esa segunda pregunta…
La investigación cambia completamente.
Y también cambia la velocidad con la que puedes contener un ataque.
Porque ya no estás reaccionando al ransomware.
Estás reaccionando a las acciones que inevitablemente necesita realizar antes de cifrar un solo archivo.
Y eso puede darte minutos.
A veces horas.
En seguridad esos minutos valen oro.
Entonces…
¿Puede Wazuh detener un ransomware?
La respuesta corta es no.
Y cualquier fabricante que diga lo contrario probablemente está vendiendo marketing.
Wazuh no impide que alguien escriba malware.
No evita que un administrador reutilice contraseñas.
No corrige una vulnerabilidad.
No instala parches.
No reemplaza los respaldos.
Lo que sí hace es darte visibilidad.
Y esa visibilidad puede marcar la diferencia entre descubrir un ataque cuando alguien acaba de iniciar sesión…
…o descubrirlo cuando toda la empresa está mirando una nota de rescate.
Créeme.
La segunda opción suele ser bastante más cara.
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.
Nunca.
Porque el día que realmente la necesites será demasiado tarde para descubrir que estaba mal configurada.
Lo mismo ocurre con los respaldos.
Todo el mundo dice que tiene backups.
Muy pocos saben si realmente pueden restaurarlos.
Con Wazuh pasa exactamente igual.
Instalar el agente no significa que estés protegido.
Las reglas pueden estar mal.
Los directorios pueden no estar siendo monitoreados.
Las alertas pueden llegar tarde.
O simplemente nadie las está mirando.
Por eso recomiendo hacer pequeños laboratorios de forma periódica.
No necesitas descargar un ransomware.
No necesitas malware.
No necesitas poner en riesgo un servidor.
Basta con simular el comportamiento.
Y eso es muchísimo más seguro.
Laboratorio 1: modificaciones masivas de archivos
Crea 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 deberías comenzar a recibir eventos por modificaciones masivas.
No porque exista un ransomware.
Sino porque alguien acaba de modificar cientos de archivos en pocos segundos.
Y eso merece atención.
Laboratorio 2: renombrado masivo
Muchos ransomware cambian la extensión de todos los archivos.
Puedes simular ese comportamiento.
for i in /tmp/ransomware-test/*
do
mv "$i" "$i.encrypted"
done
No has cifrado absolutamente nada.
Pero acabas de reproducir uno de los patrones más comunes de un ransomware.
Laboratorio 3: cambios de permisos
Simular modificaciones masivas de permisos también resulta útil.
Por ejemplo.
chmod -R 640 /tmp/ransomware-test
Después.
chmod -R 600 /tmp/ransomware-test
Y nuevamente.
chmod -R 640 /tmp/ransomware-test
Lo interesante no es el permiso.
Lo interesante es la cantidad de cambios realizados en muy poco tiempo.
Laboratorio 4: borrado masivo
Elimina todo el contenido.
rm -rf /tmp/ransomware-test
Si ese directorio está siendo monitoreado, Wazuh debería registrar la eliminación.
Otra vez.
No estás simulando malware.
Estás simulando comportamiento.
Y eso es justamente lo importante.
Laboratorio 5: el atacante intenta desaparecer
Limpia el historial de comandos.
history -c
Vacía un archivo de log de pruebas.
truncate -s 0 /tmp/log-prueba.log
No vas a engañar a un perito.
Pero sí puedes comprobar si tus reglas detectan intentos de borrar evidencia.
¿Qué deberías observar?
Durante estos laboratorios no te preocupes solamente por recibir una alerta.
Eso es apenas el comienzo.
Hazte preguntas.
- ¿Cuánto tardó en aparecer?
- ¿Llegó al dashboard?
- ¿Se generó una notificación?
- ¿El nivel de severidad fue correcto?
- ¿Se registró el usuario?
- ¿Se registró el proceso?
- ¿Se registró la hora?
- ¿La información es suficiente para investigar?
Si alguna respuesta es “no”…
Acabas de descubrir una oportunidad de mejora.
Y eso es muchísimo mejor que descubrirla durante un incidente real.
Active Response: automatiza con cabeza
Cada vez que doy una charla sobre Wazuh aparece la misma pregunta.
“¿Puedo hacer que Wazuh bloquee automáticamente cualquier ataque?”
Sí.
La pregunta correcta es otra.
¿Deberías hacerlo?
No siempre.
Automatizar respuestas sin entender el impacto puede generar más problemas que el propio ataque.
Imagina que una regla mal ajustada bloquea la IP de tu equipo de respaldo.
O del balanceador.
O del clúster Kubernetes.
El incidente ahora tiene dos responsables.
El atacante.
Y tú.
Mi recomendación es bastante simple.
Automatiza primero las acciones de bajo riesgo.
Por ejemplo.
- Bloquear temporalmente una IP que realiza fuerza bruta.
- Enviar una alerta crítica a Teams o Slack.
- Abrir automáticamente un ticket.
- Ejecutar un script que recopile evidencia.
- Notificar al equipo de seguridad.
Y deja las acciones destructivas para cuando realmente tengas la certeza de lo que está ocurriendo.
La automatización debe ayudarte.
No convertirse en otro incidente.
Lo que realmente protege un servidor Linux
Si alguien llegó hasta aquí esperando encontrar un botón mágico llamado “Protección contra ransomware”…
Lamento decepcionarlo.
Ese botón no existe.
La seguridad siempre es una suma de capas.
Hardening.
Actualizaciones.
Contraseñas robustas.
MFA.
Segmentación de red.
Backups probados.
Monitoreo.
Auditoría.
Y personas que realmente revisen las alertas.
Wazuh es una pieza muy importante.
Pero sigue siendo una pieza.
No el rompecabezas completo.
Conclusión
Los ransomware seguirán cambiando.
Cambiarán de nombre.
De algoritmo.
De infraestructura.
Incluso de sistema operativo.
Lo que difícilmente cambiará es el comportamiento de quien los ejecuta.
Necesitará entrar.
Necesitará privilegios.
Necesitará conocer tu infraestructura.
Necesitará encontrar tus respaldos.
Necesitará modificar miles de archivos.
Y todo eso deja rastros.
La gran pregunta no es si Wazuh puede detectar un ransomware.
La verdadera pregunta es mucho más incómoda.
¿Estás mirando las señales antes de que sea demasiado tarde?
Porque cuando aparece la nota de rescate…
Hace bastante rato que el atacante terminó su trabajo.
¿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.
Nuestro 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, FIM, Active Response o la 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.