Introducción
Los equipos de seguridad que confían en que su EDR sigue operativo porque el proceso aparece activo en el Task Manager están operando bajo una premisa que Lunex Stealer ya rompió. Ontinue documentó una cadena de ataque de cuatro etapas que, antes de desplegar el payload de robo de información, carga un driver AMD legítimo pero vulnerable para reemplazar con ceros los callbacks de kernel que alimentan la telemetría de seguridad. El resultado es un endpoint donde CrowdStrike, SentinelOne o Defender siguen corriendo en modo usuario, pero el kernel ya no les entrega eventos. No se trata de un kill directo: el EDR está vivo y ciego. Para un equipo de SRE o infraestructura que monitorea dashboards de alertas, el silencio es indistinguible de «todo está bien».
Qué ocurrió
La campaña identificada como Psychedelic Stealer (el nombre del binario en el endpoint) forma parte de Lunex, una plataforma Malware-as-a-Service operada por un equipo de habla rusa que ya cuenta con 28 paneles de comando y control distribuidos en 13 países: Rusia, EE.UU., Reino Unido, Países Bajos, Francia, Alemania, Turquía y Bangladesh. En junio de 2026, BlueTeamCoolTeam había detectado apenas 6 paneles; el crecimiento a 28 en pocos meses indica que la plataforma se vende activamente a múltiples grupos criminales, no que un único actor haya escalado.
El vector inicial son sitios web legítimos comprometidos —una clínica de tratamiento capilar, un fabricante de maquetas, una librería especializada, una herramienta de retail automotor— a los que se inyecta un iframe que renderiza una página falsa de verificación Cloudflare estilo ClickFix. El usuario, creyendo resolver un CAPTCHA, ejecuta un MSI fraudulento que dispara la cadena completa. El C2 principal observado opera sobre HTTP en 193.178.159[.]128.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto directo para un equipo de infraestructura es la pérdida de visibilidad en endpoints comprometidos. Si tu stack de observabilidad de seguridad depende de agentes EDR que se alimentan de callbacks de kernel (minifilters, ETW providers, callbacks de ObRegisterCallbacks), un endpoint con estos callbacks anulados no genera alertas de ejecución de procesos sospechosos, escritura de archivos en rutas sensibles ni conexiones de red anómalas desde el kernel.
Para entornos cloud donde se gestionan endpoints virtuales (VDI, Azure Virtual Desktop, AWS WorkSpaces), el riesgo se multiplica: un solo usuario con credenciales robadas puede moverse lateralmente por un tenant completo. Lunex extrae credenciales de siete navegadores Chromium-based (Chrome, Edge, Brave, Vivaldi, Opera, Yandex, Samsung Internet), cookies de sesión activas, datos de autofill y wallets de criptomonedas. Con una sesión de Microsoft 365 o AWS Console robada, el atacante no necesita crackear una contraseña: hereda la autenticación vigente.
La persistencia viaja un paso más allá del binario. Lunex instala un Native Messaging Host en PowerShell dentro del contexto del proceso de Chrome, respaldado por un script de 13.200 bytes incrustado en la sección .rdata del ejecutable. Este host sobrevive a la eliminación del stealer, a reboots del sistema y a cierres del navegador, y expone seis operaciones de sistema de archivos sobre stdin/stdout del protocolo Chrome Native Messaging.
Detalles técnicos
El componente crítico es CVE-2023-20598, una vulnerabilidad en el driver kernel-mode PDFWKRNL.sys incluido en AMD Radeon Software. LunexLoader descarga este driver y lo carga en kernel para ejecutar una técnica de PDB-guided kernel callback zeroing: en lugar de matar procesos de seguridad (lo que dispara alertas de EDR), localiza en memoria las estructuras de callbacks registradas por los minifiltros de protección y las reemplaza con ceros. Los procesos siguen corriendo, los handles siguen válidos, pero el kernel deja de notificarles eventos.
Ontinue validó en laboratorio que ni HVCI (Hypervisor-Protected Code Integrity) ni la Microsoft Vulnerable Driver Blocklist actual impiden la carga de esta variante específica de PDFWKRNL.sys. El hash del driver figura en el proyecto LOLDrivers desde marzo de 2026, pero la lista de bloqueo de Microsoft no lo incluye en su variante exacta. Esto convierte al driver en un «living-off-the-land» legítimo con firma digital válida que evade los controles de integridad del kernel.
La escalada de privilegios previa al BYOVD usa el objeto COM CMSTPLUA (part of the Windows Connection Manager) para evadir UAC sin prompt visible. Una vez en SYSTEM, la carga del driver kernel es trivial.
La inyección en Chrome manipula el archivo Secure Preferences para declarar permisos extensos sobre cookies, history, bookmarks, tabs, storage, proxy, scripting, declarativeNetRequest y acceso a todas las URLs HTTP/HTTPS. El stealer también se comunica con el panel Lunex para recibir tareas de phishing con dominios de marca suplantada; uno de los paneles en Turquía resuelve cinco dominios de phishing activos.
Qué deberían hacer los administradores y equipos técnicos
Bloquear el driver a nivel endpoint. Agregá el hash SHA-256 de PDFWKRNL.sys (variante utilizada en esta cadena, catalogada en LOLDrivers desde marzo 2026) a la lista de drivers bloqueados por WDAC o AppLocker. En Windows 10/11, podés usar PowerShell:
# Generar política WDAC que bloquee el driver específico
New-CIPolicy -Level PcaCertificate -FilePath .\BlockAMD.sys -UserPEs
Add-CIPolicyIdInfo -FilePath .\BlockAMD.sys -PolicyID «Block-PDFWKRNL»
Set-RuleOption -FilePath .\BlockAMD.sys -Option 5 # Enforce mode
Verificá que tu Microsoft Vulnerable Driver Blocklist esté actualizada a la última versión (KB5028185+). Si el hash específico no aparece, reportalo y aplicá una regla WDAC manual por nombre de archivo y hash.
Monitorear el Native Messaging Host de Chrome. Revisá las rutas HKCU\Software\Google\Chrome\NativeMessagingHosts\ y HKLM\Software\Google\Chrome\NativeMessagingHosts\ en todos los endpoints gestionados. Cualquier entrada que apunte a un script PowerShell o a un binario fuera de C:\Program Files\ es un indicador de compromiso. Podés auditar con:
Get-ChildItem «HKCU:\Software\Google\Chrome\NativeMessagingHosts\» -Recurse |
ForEach-Object { Get-ItemProperty $_.PSPath } |
Where-Object { $_.'(default)’ -notlike «*Program Files*» }
Revisar Secure Preferences en Chrome/Edge. Desplegá una GPO o script que compare el archivo Secure Preferences contra una baseline conocida. Los permisos declarativeNetRequest y scripting con acceso a
Reforzar el vector ClickFix. Implementá DNS filtering (Zscaler, Umbrella, o reglas en el firewall perimetral) para bloquear dominios de verificación falsos. Capacitá a los usuarios: una página de Cloudflare Turnstile auténtica nunca pide ejecutar comandos ni instalar MSI. En entornos con endpoint protection, habilitá la detección de ejecuciones de MSI desde navegadores.
Auditar el C2 conocido. Bloqueá a nivel de firewall/proxy las IPs 193.178.159[.]128 y los cinco dominios de phishing asociados al panel turco. Revisá logs de red de los últimos 90 días para identificar conexiones HTTP a estos indicadores.
Conclusión
Lunex no es un stealer genérico más en el catálogo de MaaS. Su decisión de usar BYOVD con callback zeroing en lugar de termination de procesos marca un cambio de paradigma en la evasión de EDR: el objetivo ya no es apagar la protección, sino hacer que funcione en un kernel que dejó de hablarle. Para los equipos de infraestructura, la lección operativa es concreta: un dashboard de seguridad sin alertas no significa ausencia de amenaza, puede significar que el kernel dejó de informar. Los controles de integridad del kernel (WDAC, HVCI, blocklists de drivers) dejan de ser un nice-to-have y pasan a ser el último anillo de defensa cuando la visibilidad del EDR ya está comprometida.
Fuentes
- https://thehackernews.com/2026/09/lunex-stealer-abuses-amd-driver-to.html