Ataque de Malspam en Agosto: Cómo los Sysadmins Linux Pueden Proteger su Correo

El ataque de malspam que volvió a poner en alerta a los gateways Linux

A finales de agosto de 2026, un mensaje de malspam con un archivo adjunto malicioso terminó en la cuarentena de un gateway de correo operado por uno de los clientes de Jan Kopriva, analista del SANS Internet Storm Center. El email simulaba ser una solicitud de cotización para un sistema de fibra óptica, con un remitente que se hacía pasar por un empleado de una empresa legítima. El gateway lo bloqueó por el contenido malicioso del adjunto, y aunque no lo hubiera hecho, los chequeos SPF y DMARC ya habían fallado, así que no habría llegado muy lejos.

El caso es relevante para sysadmins Linux porque detrás del adjunto había una cadena de infección de varias etapas: un JavaScript ofuscado que descarga ejecutables .NET a través de imágenes PNG con esteganografía, evade AMSI, y se persiste vía tareas programadas. Vamos a desarmar el ataque, ver qué lo hizo pasar, y armar un pipeline defensivo en Linux con herramientas abiertas.

Por qué este tipo de malspam sigue funcionando

El vector inicial es el clásico: un email de spearphishing con un archivo adjunto que parece un documento legítimo. Lo que cambió en 2026 es la profundidad de la cadena de infección. Según el análisis publicado en el diario del SANS ISC (LausivLoader analysis), el adjunto era un archivo .r01 que contenía un JavaScript de 613 KB bautizado PO.4843293191 For Supply Chain - Imports HM..js. En el momento del análisis, el archivo tenía una tasa de detección de 28/55 en VirusTotal, con varios motores identificándolo como parte de la familia LausivLoader.

Lo más interesante del payload es cómo pasa datos entre etapas. El JavaScript crea dos archivos en %TEMP%, guarda rutas a esos archivos en variables de entorno del proceso (Kv7408 y Kv562), y luego invoca conhost.exe --headless que hereda esas variables hacia powershell.exe. El PowerShell lee los archivos, los combina, decodifica Base64, y aplica AES-128-CBC para obtener un ejecutable .NET de 315 KB. Ese .NET carga otro loader, parchea AMSI, y descarga la siguiente etapa desde una URL escondida en un chunk iTXt de un PNG.

Para un sysadmin Linux esto importa por tres razones. Primero, el gateway de correo sigue siendo la primera línea de defensa y los adjuntos maliciosos Windows siguen llegando a usuarios Linux. Segundo, si administras un gateway Linux (Postfix + Rspamd + ClamAV), necesitas entender qué patrones bloquear más allá del hash. Tercero, si haces análisis forense, el truco de pasar datos vía variables de entorno es un patrón que aparece cada vez más en malware moderno y vale la pena reconocerlo.

Anatomía técnica de la cadena de infección

La cadena de LausivLoader tiene seis etapas claramente diferenciadas. Cada una pasa información a la siguiente por un canal diferente: variables de entorno, archivos temporales, lectura de payloads desde imágenes, e inyección en memoria. Vamos etapa por etapa.

Etapa 1: el JavaScript ofuscado

El archivo inicial tenía 450 líneas de comentarios con palabras aleatorias en inglés para inflar el peso y dificultar el análisis estático. Quitados los comentarios, quedaban 205 KB de código que construía strings largas con String.fromCharCode y luego las concatenaba para formar una llamada a WScript.Shell.Run. El truco para analizarlo es empezar por el final del archivo: ahí está la línea Run(v6177, 0, false), donde v6177 es la concatenación de todos los strings decodificados.

Etapa 2: el paso de datos por variables de entorno

Aquí viene lo elegante. En lugar de escribir el payload completo en un solo archivo, el JavaScript creaba dos archivos en un directorio con nombre aleatorio dentro de %TEMP%:

var v4825=(Math.floor(Math.random()*89999)+10000).toString(36)
            +(+new Date()).toString(36);
var v368=v8593.ExpandEnvironmentStrings("%TEMP%")+""+v4825;
if(!v9719.FolderExists(v368))v9719.CreateFolder(v368);
var v9296=v368+""+v4825+"a";
var v9227=v368+""+v4825+"b";
// escribe v3663 en v9296, v9870 en v9227
v2491("Kv7408")=v9296;
v2491("Kv562")=v9227;

Luego el JavaScript invoca conhost.exe --headless que ejecuta PowerShell. Por la herencia normal de variables de entorno, los valores Kv7408 y Kv562 llegan al PowerShell. El PowerShell lee los dos archivos, los combina, los borra inmediatamente. Por eso ningún análisis estático del comando PowerShell descodificado puede reconstruir el payload completo.

Etapa 3: descifrado AES-128-CBC y carga reflectiva

El PowerShell aplica AES-128-CBC con PKCS#7 padding, descomprime con GZip, y obtiene un .NET de 64 bits de 315.904 bytes. La clave y el IV están hardcodeados en el código, lo cual hace el descifro trivial offline. El script no escribe el ejecutable a disco: lo carga directamente en memoria con Assembly.Load(byte[]) e invoca el entry point via reflection.

Etapa 4: parcheo de AMSI

El .NET de primera etapa resuelve APIs de Windows dinámente y modifica el código de AmsiScanBuffer y AmsiScanString antes de cargar el siguiente assembly. Es un intento clásico de bypass de AMSI. Si usas Windows Defender o una solución EDR con AMSI activo, este parcheo reduce dramáticamente la visibilidad del ataque.

Etapa 5: otro .NET con extracción esteganográfica

El siguiente .NET, de 59.904 bytes, descarga un PNG desde hxxps://yapw[.]life/phpt/stego_zrgaixkku8.png. Recorre la estructura del PNG buscando un chunk iTXt, busca el marcador FF 89 AD 4A, aplica XOR, descomprime con DEFLATE, y obtiene un PE final. Si es .NET lo carga por reflection, si es nativo usa process hollowing.

Etapa 6: persistencia

Antes de toda la cadena, el JavaScript inicial se copia a %LOCALAPPDATA%MicrosoftPhotoEnginePhotoStudio.js y registra una tarea programada llamada MicrosoftEdgeUpdateTaskCore con trigger de logon. El nombre imita una tarea legítima de Edge Update, un patrón de masquerading listado en MITRE ATT&CK como T1036.004.

Pipeline defensivo para gateways Linux en 2026

El ataque falló en dos puntos antes de llegar al usuario. El primero fue el filtro antimalware del gateway, que detectó contenido malicioso en el adjunto. El segundo fueron los chequeos SPF y DMARC. Vamos a configurar un gateway Postfix en Debian que replique esas defensas y agregue más.

Componentes del stack

El stack mínimo que vamos a usar tiene cuatro piezas: Postfix como MTA, Rspamd como motor de filtrado (spam + antivirus), ClamAV como motor antivirus, y Redis como backend de cache y aprendizaje bayesiano. En Debian 13 (trixie) los paquetes ya están todos en los repos oficiales.

Componente	Rol	Puerto / Socket	Notas 2026
Postfix	MTA (Mail Transfer Agent)	25/TCP, 587/TCP submission	Versión 3.8+ en Debian 13, soporte OAuth2 via postscreen
Rspamd	Filtro spam + antivirus + DKIM	11333/TCP control, 11334/TCP worker	Bayesiano en Redis, UI web opcional
ClamAV	Motor antivirus open source	3310/TCP clamd, /var/run/clamav/clamav-milter.ctl Unix	Firmas oficiales + Sanesecurity + Yara-Rules
Redis	Backend bayesiano + cache	6379/TCP localhost	Solo escucha en loopback, no exponer
clamav-milter	Integración ClamAV ↔ Postfix	Socket Unix	Permisos para usuario rspamd en grupo clamav

Instalación de Rspamd y ClamAV

Lo primero es instalar las dependencias y luego configurar el filtro clamav-milter para que ClamAV escanee adjuntos directamente:

sudo apt update
sudo apt install -y postfix rspamd redis-server 
  clamav-daemon clamav-freshclam clamav-unofficial-sigs

El paquete clamav-unofficial-sigs descarga bases adicionales de firmas mantenidas por Sanesecurity, Yara-Rules, y otros proyectos que cubren phishing, malware polimórfico y malware .NET que las firmas oficiales de ClamAV tardan más en detectar. Estas firmas son clave para detectar familias como LausivLoader que combinan ofuscación pesada con carga reflectiva.

Antes de seguir configurando, verifica que freshclam descargó las firmas base. Si tu servidor no tiene acceso directo a internet, configura el proxy en /etc/clamav/freshclam.conf.

Configuración del socket clamav-milter

Para que Rspamd pueda invocar ClamAV via milter, necesitamos el socket Unix expuesto por clamav-milter. La configuración en /etc/clamav/clamav-milter.conf debe tener:

# /etc/clamav/clamav-milter.conf
MilterSocket /var/run/clamav/clamav-milter.ctl
MilterSocketMode 0660
MilterUser rspamd
MilterGroup clamav

El punto crítico es que el usuario rspamd pertenezca al grupo clamav, sino el milter rechaza las conexiones. Después de editar, agrega el usuario y reinicia:

sudo usermod -aG clamav rspamd
sudo systemctl restart clamav-daemon clamav-freshclam clamav-milter

Conectar Rspamd a Postfix

Rspamd corre por defecto en 11333 (control) y 11334 (worker). El módulo antivirus de Rspamd se configura en /etc/rspamd/local.d/antivirus.conf:

# /etc/rspamd/local.d/antivirus.conf
clamav {
  symbol = "CLAM_VIRUS";
  type = "clamav";
  servers = "/var/run/clamav/clamav-milter.ctl";
  action = "reject";
  patterns {
    "email" = ".eml$";
    "mail" = ".mail$";
  }
}

El parámetro action = "reject" rechaza el email sin entregarlo al destinatario cuando ClamAV detecta virus. Para casos donde quieres cuarentena en lugar de rechazo, cambiá a action = "quarantine". Después de editar, reiniciá Rspamd y validá que el módulo antivirus cargó:

sudo systemctl restart rspamd
rspamc stat  # muestra módulos cargados, debe aparecer CLAM_VIRUS

Validar SPF y DMARC en el gateway

El ataque original también falló SPF y DMARC. Si tu gateway no valida esos registros, el malspam se entrega igual. Rspamd tiene módulos separados para SPF (spf) y DMARC (dmarc) que se activan al primer reinicio si los DNS están configurados correctamente. Para verificar manualmente que tu servidor puede resolver los registros TXT:

dig +short TXT _dmarc.example.com
dig +short TXT 2026._domainkey.example.com

Si los registros están publicados, Rspamd los aplica automáticamente. Si no, no hay mucho que el gateway pueda hacer: SPF y DMARC dependen de que el dominio del remitente los publique. Lo que sí puedes hacer es configurar el módulo whitelist de Rspamd con sobreescrituras para dominios críticos, y bloquear por IP las fuentes que aparecen en listas como Spamhaus DBL.

Análisis estático del adjunto en Linux

Si el adjunto igual llega a la cuarentena de tu gateway, puedes analizarlo desde Linux sin necesidad de Windows. Hay tres herramientas abiertas que cubren los casos más comunes.

Extraer metadata del email con Python

El módulo email de la stdlib de Python parsea archivos .eml directamente. Para extraer los adjuntos:

python3 -c "
import email
from email import policy
with open('sample.eml', 'rb') as f:
    msg = email.message_from_binary_file(f, policy=policy.default)
for part in msg.walk():
    if part.get_filename():
        print(part.get_filename(), part.get_content_type(),
              len(part.get_payload(decode=True)))
"

El output te da el nombre del archivo, el MIME type reportado, y el tamaño real. Si el MIME type dice application/octet-stream y la extensión del archivo dice .pdf o .docx, eso es una primera señal de alerta.

Detectar macros y objetos OLE con oletools

oletools es una colección de scripts Python para analizar archivos OLE2 de Microsoft Office. En Kali viene preinstalado. En Debian o Ubuntu lo instalas con pip:

python3 -m pip install --user oletools
~/.local/bin/olevba suspicious.doc

El comando olevba extrae y deobfusca macros VBA, busca DDE exploits, objetos embebidos, y conexiones externas. Para el caso de LausivLoader (que es JS, no OLE), olevba no aplica, pero es la primera línea de defensa para adjuntos Office.

Verificar el hash contra VirusTotal

Antes de abrir cualquier adjunto sospechoso, calculá el hash y comparalo contra bases públicas:

sha256sum suspicious_attachment.js
# pegá el hash en https://www.virustotal.com/gui/file/<hash>

LausivLoader tenía 28/55 detecciones en el momento del análisis. Si ves menos 5 detecciones, eso no significa que el archivo esté limpio: los loaders polimórficos evaden la mayoría de detecciones hasta que las firmas específicas salen.

Troubleshooting común del pipeline

Estos son los problemas que más aparecen cuando se monta este stack por primera vez, y cómo resolverlos.

ClamAV no detecta nada pero el archivo tiene virus

Si ClamAV devuelve OK para un archivo que claramente tiene malware, el problema casi siempre es que clamav-freshclam no actualizó las firmas. verifica la última actualización:

sudo freshclam -v
ls -la /var/lib/clamav/daily.cld

Si la base tiene más de 48 horas, forzá una actualización manual. Si clamav-unofficial-sigs no está corriendo, también te faltan las firmas de Sanesecurity que cubren phish y malware reciente.

Rspamd dice “clamav not available” en los logs

El problema típico es de permisos sobre el socket Unix. verifica:

ls -la /var/run/clamav/clamav-milter.ctl
# debe ser srw-rw---- clamav clamav
sudo -u rspamd test -r /var/run/clamav/clamav-milter.ctl 
  && echo "OK" || echo "permisos rotos"

Si el test dice “permisos rotos”, agregá el usuario rspamd al grupo clamav con usermod -aG clamav rspamd y reiniciá clamav-milter.

Falsos positivos masivos en adjuntos grandes

Si ves que ClamAV marca adjuntos ZIP o PDFs legítimos como virus, probablemente está corriendo el módulo Heuristics.enhanced con umbral muy bajo. Para ajustar:

# /etc/clamav/clamd.conf
HeuristicScanMode yes
HeuristicAlerts no  # reduce falsos positivos
StructuredDataDetection yes
StructuredMinCreditCardCount 5
StructuredMinSSNCount 5

Reiniciá clamd después de cambiar. Si sigues viendo falsos positivos, ajustá el umbral bayesiano de Rspamd en /etc/rspamd/local.d/classifier-bayes.conf subiendo el min_prob_strength de 0.05 a 0.1.

Lo que NO hacer

Antes de cerrar, tres patrones que veo seguido y que empeoran la situación. Primero, no confíes solo en el hash: las familias de loader como LausivLoader cambian el hash de cada campaña. Bloquear por hash sirve para una variante específica, no para la familia. Segundo, no desactives ClamAV porque “come CPU”: el costo de un análisis ClamAV en adjuntos es marginal comparado con el costo de un endpoint comprometido. Tercero, no expongas el panel web de Rspamd a internet sin autenticación: el puerto 11334 con la interfaz web es cómodo para debugging pero es un vector de ataque si queda accesible.

El malspam de agosto de 2026 no fue particularmente sofisticado en su vector inicial — fue un email de spearphishing con un adjunto. Lo sofisticado fue la cadena post-explotación: paso de datos por variables de entorno, descifrado AES en memoria, parcheo de AMSI, descarga esteganográfica. Eso es lo que hace que estas campañas duren semanas sin ser detectadas. Un gateway Linux bien configurado las corta en el adjunto, antes de que toda la cadena se monte.

Resumen

El caso de LausivLoader muestra tres cosas. Primero, los gateways de correo Linux siguen siendo la primera línea de defensa contra malspam, y un stack Postfix + Rspamd + ClamAV con firmas actualizadas bloquea estos ataques antes de que lleguen al usuario. Segundo, el análisis de adjuntos en Linux es viable con herramientas abiertas como oletools, el módulo email de Python, y la verificación contra VirusTotal. Tercero, los loaders modernos usan técnicas de paso de datos no estándar (variables de entorno, esteganografía en PNG, AES en memoria) que requieren análisis dinámico o instrumentado, no solo análisis estático del adjunto inicial.

Si administras un gateway Linux, los próximos pasos concretos son auditar tu configuración SPF/DMARC, validar que ClamAV esté actualizando firmas (incluyendo las de Sanesecurity vía clamav-unofficial-sigs), y verificar que el módulo antivirus de Rspamd esté rechazando, no solo marcando. Si recibiste algún adjunto sospechoso en los últimos 30 días, vale la pena correr oletools o rspamc learn_spam sobre la cuarentena antes de purgarla.

Preguntas frecuentes

Lee también

• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Creando tu Home Lab para Agentes IA: Ollama + Proxmox en 2026
• Contribuciones a Debian: Trabajos patrocinados por Freexian y opciones de apoyo
• Nextcloud 35 en Linux: guía completa 2026 para sysadmins
• Montaje de un Servidor de Correo con Postfix: Guía Definitiva para Sysadmins Linux