LunexStealer infecta 100+ sitios con verificación falsa de Cloudflare: UAC-0277

Qué acaba de pasar y por qué te interesa aunque no uses Windows

El 7 de octubre de 2026, CERT-UA publicó el aviso #6319983 describiendo una campaña de alcance industrial: más de 100 sitios web legítimos fueron comprometidos e infectados con un fragmento de JavaScript malicioso que muestra a sus visitantes una página falsa de verificación de Cloudflare. Si la víctima cae en el engaño y ejecuta el comando que la página le pide, termina descargando e instalando LunexStealer, un infostealer con capacidad de ejecución remota, registrado por CERT-UA bajo el identificador UAC-0277.

Esto importa a un sysadmin Linux por tres razones que la mayoría de las notas en inglés pasan por alto:

• Los 100+ sitios comprometidos son, en su mayoría, servidores Linux con CMS desactualizado, plugins sin parche o credenciales filtradas. Si tú corres un wordpress, un Joomla, un Magento o un Drupal expuesto, puedes estar en esa lista sin saberlo.
• El script de inyección usa smart contracts de Polygon y Ethereum como C2: los atacantes cambian el dominio de la página falsa o apagan la campaña sin tocar los sitios comprometidos. Eso complica la limpieza tradicional basada en listas de dominios estáticas.
• El vector ClickFix es transversal a la plataforma: aunque el payload final apunta a Windows, el truco funciona porque cualquiera, en cualquier SO, puede copiar y pegar un comando en una terminal. Si tu navegador está en Linux pero la víctima de tu sitio corre Windows, el problema vuelve a tu casa.

En este artículo te llevo por la cadena completa: anatomía del ataque, las tres variantes de MSI, los indicadores de compromiso publicados por CERT-UA y, lo más útil, qué hacer hoy si sospechas que uno de tus servidores está entre los comprometidos.

Anatomía del ClickFix disfrazado de Cloudflare

El ClickFix no es nuevo — lleva más de un año activo en campañas de soporte técnico falso y verificación de captchas — pero UAC-0277 lo subió de nivel al combinarlo con dos elementos que no se habían visto juntos a esta escala: un panel falso de Cloudflare y un canal de mando basado en blockchain.

Cuando un usuario entra al sitio comprometido desde un buscador (Google, Bing, DuckDuckGo), el script inyectado detecta el referer y, si el User-Agent sugiere Windows, muestra la página falsa. La página tiene tres modos de operación configurables por el atacante desde el smart contract:

• Off: no muestra nada, simplemente rastrea al visitante.
• Silent visitor tracking: registra IP, User-Agent y huella del navegador sin levantar sospecha.
• Full fake verification: muestra la página de “verificación humana” que pide abrir el menú Ejecutar de Windows (Win+R), pegar un comando y presionar Enter. El comando descarga un MSI desde un servidor remoto y lo instala silenciosamente.

La página no se muestra más de dos veces en 12 horas al mismo visitante, lo cual es una salvaguarda para no delatar el compromiso. También filtra por referer de buscador: un visitante que llega directo desde un marcador, un enlace en un correo o un foro nunca ve la página. Esta segmentación explica por qué los administradores de los sitios comprometidos, al revisar sus logs manualmente, no encuentran el patrón: el tráfico “sospechoso” siempre parece tráfico legítimo de Google.

El detalle técnico clave es que el dominio del panel falso y los parámetros del script no viven en los sitios comprometidos, sino en un smart contract desplegado en Polygon o Ethereum. Cada vez que la página se carga, el JavaScript consulta el contrato, lee la configuración actual y la usa. Si CERT-UA o un proveedor de hosting bloquea un dominio, los atacantes solo publican un nuevo valor en el contrato y al instante los 100+ sitios empiezan a usar el nuevo dominio, sin necesidad de re-infectar nada.

Las tres variantes de MSI: tres caminos al mismo ladrón

CERT-UA analizó tres variantes distintas del instalador que el comando de ClickFix descarga. Las tres terminan desplegando LunexStealer, pero la ruta técnica varía, y cada una exige una contramedida distinta.

La primera variante es la más simple: el MSI instala directamente el binario del stealer. La segunda es la más agresiva: intenta evadir Windows Defender creando exclusiones y luego despliega un driver vulnerable de AMD (PDFWKRNL.sys) usando la técnica BYOVD (Bring Your Own Vulnerable Driver). El driver explota la CVE-2023-20598, una falla de elevación de privilegios que existía en versiones antiguas del driver y que ya está parcheada, pero que los atacantes incluyen firmada con un certificado que Windows todavía respeta si no está revocado. Una vez que el driver está cargado en modo kernel, el stealer se ejecuta con privilegios de sistema.

La tercera variante abandona el BYOVD y usa DLL side-loading: el MSI instala un ejecutable legítimo (FnHotkeyUtility.exe, el panel de teclas rápidas de Fn de ciertos fabricantes de portátiles) junto a una DLL maliciosa (spkvol.dll) en la misma carpeta. Cuando el sistema o el usuario inicia el ejecutable legítimo, Windows carga la DLL maliciosa que está al lado, porque la resolución de DLL en Windows prioriza el directorio actual. La DLL descifra y lanza el stealer. Esta técnica es muy efectiva contra antivirus porque el binario “malo” es uno que ya está firmado por un fabricante conocido y suele estar en la lista blanca de EDRs.

LunexStealer: mucho más que un ladrón de contraseñas

El payload final, LunexStealer (también conocido como Psychedelic Stealer), está lejos de ser un ladrón de cookies genérico. CERT-UA lo describe como un infostealer con tres componentes modulares que se activan según la configuración que el C2 le entregue:

• LunexStealer core: roba credenciales almacenadas en navegadores (Chrome, Edge, Firefox, Brave, Opera), cookies activas, historiales de navegación, autocompletados, monederos de criptomonedas y tokens de sesión. Es la fase de reconocimiento y exfiltración inicial.
• LUNARAXE: una extensión maliciosa para Chrome/Edge que se instala bajo el nombre Microsoft Office Word Editor (no es el nombre real, pero la cadena está diseñada para pasar desapercibida en la lista de extensiones). La extensión roba cookies, historial y todo lo que se escribe en formularios web, y otorga al atacante control remoto en vivo del navegador: puede abrir pestañas, hacer clic en botones, capturar pantalla, descargar archivos desde la víctima.
• NAIVEMESS: un componente en PowerShell que se registra como host de mensajería nativo entre el navegador y el sistema operativo. Esto le da a la extensión LUNARAXE acceso de lectura, escritura y ejecución sobre el sistema de archivos, esencialmente creando un canal lateral que muchos EDRs no inspeccionan porque asume que la comunicación navegador-a-sistema es legítima.

El binario principal además incluye un módulo de ejecución remota que acepta comandos directos del C2: descargar y lanzar EXE, MSI, scripts PowerShell y comandos crudos. En la práctica, LunexStealer no es solo un infostealer, es un punto de entrada persistente con el que el atacante puede pivotar a otras máquinas, instalar ransomware o plantar keyloggers de segunda etapa.

Indicadores de compromiso publicados por CERT-UA

Si administras un sitio público o quieres cazar intentos en tu red, esta tabla resume los IoC más relevantes del aviso. Copialos a tu SIEM o a tu solución de detección de endpoints.

Tipo	Indicador	Descripción
IPv4	107.175.82.242	Infraestructura de la campaña, aloja wilow/psychedeliclove.exe
IPv4	193.178.158.61	Infraestructura C2 secundaria
IPv4	193.178.159.128	Endpoints HTTP de extensión remota
IPv4	109.238.86.112	Infraestructura con endpoint HTTP listado
IPv4	109.238.86.113	Infraestructura con endpoint HTTP listado
IPv4	176.53.159.40	Infraestructura de la campaña
IPv4	159.69.234.218	Infraestructura de la campaña
URL	http://107.175.82.242:9000/wilow/psychedeliclove.exe	Descarga del ejecutable
Dominio	uasputnik[.]com	Aloja los MSI elit.msi, elita.msi, elite.msi, omen.msi
Dominio	ahahahahadebili[.]help	Aloja think.msi
Dominio	sputnk[.]com	Aloja think.msi
Dominio	uasputn[.]com	Aloja esptnk.msi
Dominio	ukrainerada[.]top	Endpoint /tds/tds.php del script de la campaña
Dominio	spectre.pp[.]ua	Aloja spectre.msi
Dominio	ilovecutecatetetes[.]click	URL adicional listada por CERT-UA
Archivo	PDFWKRNL.sys	Driver AMD vulnerable (CVE-2023-20598) usado en BYOVD
Archivo	FnHotkeyUtility.exe + spkvol.dll	Par legítimo + DLL maliciosa para side-loading
Extensión	Microsoft Office Word Editor	Nombre de camuflaje de LUNARAXE
Hash	38e90affe37342ee36917cdc535fe9bf04589afa8430eb8d1ba1016adcfc1878	elita.exe (SHA-256)
Hash	bf14cd6c3328ebd08e940478b5d1da04e9e5aa576d045d41950bf4f1e2456dd8	psychedelic.exe
Hash	6e8b49cf70bf854e8c59c7d27cefa89406caf8978461190dabb86dafcd8554e1	embedded_driver.sys (driver BYOVD)

La lista completa de hashes SHA-256 está en el aviso original de CERT-UA. Si tu WAF o tu CDN puede bloquear por IP o dominio, hazlo de inmediato: aunque los atacantes roten infraestructura, los rangos reportados suelen mantenerse activos durante semanas.

Defensa para sysadmins Linux: lo que puedes hacer hoy

Aunque el payload final apunta a Windows, la primera línea de defensa está en tu servidor Linux. Estos controles se implementan en menos de una hora y reducen la superficie de compromiso de tu sitio.

El primer paso es auditar tu servidor web en busca de inyecciones de JavaScript no autorizadas. Este comando busca archivos sospechosos en las rutas típicas de inyección (cabeza de archivos .php, .html, .js):

# Buscar inyecciones JS en archivos PHP, HTML, JS
find /var/www -type f ( -name "*.php" -o -name "*.html" -o -name "*.js" ) 
  -not -path "*/cache/*" -not -path "*/node_modules/*" 
  -mtime -90 -print0 | xargs -0 grep -lE 'eval(atob|document.write(atob|new Function(atob|cloudflare-verification|cdn-cgi/challenge' 2>/dev/null
# Verificar las primeras 30 líneas de cada coincidencia
find /var/www -type f ( -name "*.php" -o -name "*.html" -o -name "*.js" ) 
  -not -path "*/cache/*" -mtime -90 -print0 | xargs -0 grep -lE 'eval(atob|document.write(atob|cloudflare-verification' 2>/dev/null 
  | while read f; do echo "== $f =="; head -30 "$f"; done

Si encontras coincidencias, no borres el archivo a ciegas: captura el fragmento inyectado como evidencia y revisa el resto del archivo. En sitios WordPress la inyección suele estar en wp-includes/, wp-content/themes/<tema>/functions.php o en un plugin abandonado. En Magento y Drupal tiende a aparecer en app/design/frontend/ o en archivos .tpl modificados recientemente.

El segundo control es monitorear conexiones salientes hacia los dominios e IPs de la tabla anterior. Este comando lista las conexiones activas y los procesos que las originan, ideal para correr como parte de un cron cada cinco minutos:

#!/bin/bash
# Bloquear dominios e IPs de UAC-0277 detectados por CERT-UA
IOC_DOMAINS=(
  "uasputnik.com" "ahahahahadebili.help" "sputnk.com"
  "uasputn.com" "ukrainerada.top" "spectre.pp.ua"
  "ilovecutecatetetes.click" "ilovecutecatics.com"
)
IOC_IPS=(
  "107.175.82.242" "193.178.158.61" "193.178.159.128"
  "109.238.86.112" "109.238.86.113" "176.53.159.40"
  "159.69.234.218"
)
# Bloquear con iptables
for ip in "${IOC_IPS[@]}"; do
  iptables -I OUTPUT -d "$ip" -j DROP -m comment --comment "UAC-0277 IOC"
done
# Bloquear con DNS (responder 0.0.0.0 para los dominios)
for d in "${IOC_DOMAINS[@]}"; do
  echo "0.0.0.0 $d" >> /etc/hosts.blocklist
done
sort -u /etc/hosts.blocklist > /etc/hosts

El tercer control es auditar las credenciales y la higiene de acceso. La inyección de JavaScript requiere en la mayoría de los casos una de tres condiciones: una vulnerabilidad explotable en el CMS, un plugin con credenciales filtradas o un secreto de SFTP/SSH en un equipo del administrador que ya está comprometido. verifica las tres:

# Revisar últimos 50 accesos SSH exitosos
last -i -n 50 | head -50
# Buscar usuarios con login por password (debería ser solo key-based)
awk -F: '$3 >= 1000 {print $1}' /etc/passwd | while read u; do
  sudo -l -U "$u" 2>/dev/null | grep -q "NOPASSWD" || echo "User $u puede escalar con password"
done
# Verificar plugins CMS con vulnerabilidades conocidas (ejemplo WordPress)
sudo -u www-data wp plugin list --allow-root --format=csv --path=/var/www/html 
  | awk -F, 'NR>1 && $7 != "active" {print $1, $7}'
# Revisar archivos modificados en los últimos 30 días en directorios de web
find /var/www -type f -mtime -30 -not -path "*/cache/*" -not -path "*/uploads/*" 
  -printf "%T@ %TY-%Tm-%Td %TH:%TM %pn" | sort -rn | head -30

Si tu servidor comparte base de datos o red con máquinas Windows, recuerda que la víctima del ClickFix es la máquina Windows, no el servidor Linux. Pero el servidor Linux fue el punto de entrada. Notificá a tu equipo de endpoints para que revise los hosts que accedieron a tu sitio en los últimos 60 días: el script de inyección puede haber estado activo durante semanas antes de que CERT-UA lo detectara.

El truco del smart contract: por qué esta campaña es más dura de tumbar

El detalle que más me llamó la atención de la campaña UAC-0277 no es técnico, es operativo. Los atacantes aprendieron que los takedowns centralizados (registrar dominios maliciosos, bloquear IPs, retirar certificados) son la principal causa de muerte de sus operaciones, así que descentralizaron el control. El dominio del panel falso y los parámetros del script viven en un smart contract, lo que les da tres ventajas:

• Resiliencia: un smart contract en Polygon o Ethereum no se puede tumbar con una orden judicial a un registrador. Está replicado en miles de nodos y solo se modifica con una transacción firmada por la clave del atacante.
• Rotación instantánea: si bloquean el dominio actual, los atacantes publican un nuevo valor en el contrato y al instante los 100+ sitios comprometidos empiezan a usar el nuevo dominio. No necesitan re-infectar nada.
• Apagado selectivo: el smart contract puede activar o desactivar la campaña a voluntad, lo que les permite operar solo durante ciertos horarios o geografías, evadiendo investigadores y fuerzas de seguridad.

La contramedida real no es bloquear dominios, es limpiar los sitios comprometidos. Mientras existan servidores infectados con el JavaScript de UAC-0277, los atacantes pueden activar la campaña cuando quieran. La lista de los 100+ sitios no la tiene CERT-UA publicada, pero puedes sospechar si tu sitio aparece en alguna de estas condiciones: tiene un CMS sin actualizar, los logs muestran picos anómalos de tráfico referido desde Google que no convierten, o tus usuarios reportan haber visto una página sospechosa al llegar desde buscador.

Una auditoría profunda de un sitio WordPress sospechoso tarda menos de una hora. Empieza por estos archivos:

# Archivos WordPress modificados fuera del flujo legítimo
find /var/www/html -type f -name "*.php" -mtime -30 
  -not -path "*/wp-content/cache/*" -not -path "*/wp-content/uploads/*" 
  -not -path "*/wp-content/upgrade/*" 
  -printf "%T@ %TY-%Tm-%Td %pn" | sort -rn | head -20
# Comparar contra el core oficial de WordPress (descargado a /tmp/wp-clean)
diff -rq /var/www/html/wp-admin /tmp/wp-clean/wp-admin 2>/dev/null | grep -v "^Only in /tmp"
diff -rq /var/www/html/wp-includes /tmp/wp-clean/wp-includes 2>/dev/null | grep -v "^Only in /tmp"
# Buscar funciones de ofuscación comunes en PHP
grep -rnE 'base64_decode|eval(|gzinflate|str_rot13|gzuncompress' /var/www/html/wp-content/ 
  --include="*.php" | head -20

El último comando es el que más falsos positivos da, pero si el archivo no es un plugin conocido y aparece en un tema, es casi seguro compromiso. base64_decode combinado con eval() en el mismo archivo es la firma clásica de inyecciones de PHP-shell.

Vale la pena seguir el caso? Sí, pero sin paranoia

Si tu sitio no es un objetivo interesante (tienda online, servicio de salud, institución educativa) y mantienes el CMS actualizado con autenticación de dos factores, la probabilidad de que estés entre los 100+ comprometidos es baja. Pero si el aviso te deja con la duda, los controles de la sección anterior son una tarde de trabajo y te dejan con un baseline de seguridad mejor que el que tenías ayer.

Lo que sí recomiendo sin dudar es agregar *.cloudflare-verification y las IPs de la tabla a tu WAF o a tu lista de bloqueo corporativo. Aunque esta campaña desaparezca, la técnica del panel falso de Cloudflare ya fue copiada por otros grupos y la vamos a ver repetida en los próximos meses. Tener los controles listos antes de la siguiente campaña es la diferencia entre detectarla en horas y enterarte cuando ya se filtraron credenciales.

Si administras endpoints Windows en tu entorno, el consejo de CERT-UA sigue siendo el más práctico: una verificación de seguridad real nunca te va a pedir abrir Ejecutar, Símbolo del sistema o PowerShell para pegar un comando. Si un sitio te pide eso, aunque sea legítimo, cierra la pestaña y avisa al administrador del sitio. Es un patrón que ya vimos en soporte técnico falso, en captchas falsos y ahora en paneles de Cloudflare falsos. La educación del usuario final es la única defensa que escala cuando el vector cambia de disfraz cada trimestre.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
• Guía Definitiva para Sysadmins: Configuración de Bonding de Interfaces de Red en Linux