BookinglyTech News
Ciberseguridad

Lunex usa un driver vulnerable de AMD para cegar al EDR antes de robar credenciales

El stealer, vendido como plataforma de malware a varios grupos criminales, aprovecha CVE-2023-20598 para desactivar la monitorización de seguridad y extraer contraseñas, cookies y carteras de criptomonedas.

3 min de lecturaThe Hacker News0 vistas

Lunex es una plataforma de malware como servicio que se vende a distintos grupos criminales y que lleva meses en circulación. Su componente en la máquina de la víctima, Psychedelic Stealer, arranca con una página de CAPTCHA falsa y acaba con un agente de mando y control instalado en el navegador. Lo llamativo del caso es el camino: Ontinue ha documentado el uso de un driver vulnerable de AMD para dejar ciego al EDR antes de desplegar el robo de credenciales.

La cadena tiene cuatro etapas. El cebo es del estilo ClickFix: una verificación de Cloudflare falsa que empuja al usuario a ejecutar un instalador MSI fraudulento, servido desde sitios legítimos comprometidos y dirigido a público ucraniano. De ahí sale LunexLoader, un cargador que sortea el control de cuentas de usuario de Windows apoyándose en el objeto COM CMSTPLUA y que después recurre a la técnica bring your own vulnerable driver (BYOVD) para la evasión de defensas. El paso final es la descarga del stealer.

El driver en cuestión es PDFWKRNL.sys, el kernel-mode driver de AMD Radeon Software afectado por CVE-2023-20598. Con él, el malware escala privilegios y anula los callbacks del kernel en lugar de matar los procesos de seguridad: los productos siguen corriendo, pero no ven nada. Que un stealer use BYOVD como antesala es poco habitual, porque lo normal es encontrarlo delante de un ransomware y no de un ladrón de credenciales.

Ontinue explica en su informe técnico que la variante concreta de PDFWKRNL.sys carga incluso con HVCI activo y con la lista de drivers vulnerables bloqueados de Microsoft. Es decir, las dos mitigaciones que uno esperaría que cortaran esto por la mitad no lo cortan.

Qué se lleva y cómo se queda

Una vez dentro, LunexStealer habla por HTTP con el panel de Lunex y extrae credenciales de siete navegadores basados en Chromium: Chrome, Edge, Brave, Yandex Browser, Opera, Opera GX y Vivaldi. También enumera cinco carteras de escritorio (Bitcoin Core, Litecoin, Exodus, Atomic Wallet y Electrum) y cuatro de extensión (MetaMask, MetaMask Legacy, OKX Wallet y SafePal Wallet).

La persistencia es lo más incómodo de desmontar. El malware crea una clave Run en el registro, una tarea programada oculta llamada psychedelicloveUtils y un host de Native Messaging en Chrome respaldado por un script de PowerShell de 13.200 bytes embebido en la sección .rdata. Ese host vive dentro del contexto del proceso del navegador y sobrevive al borrado del binario del stealer, a los reinicios del sistema y a los del navegador. Ofrece seis acciones de sistema de ficheros: listar unidades de la C a la Z, listar directorios con tamaños, leer ficheros en bloques de 512 KB hasta 524 MB, escribir en cualquier ruta, descargar ficheros y ejecutar programas arbitrarios. Además inyecta una extensión maliciosa manipulando las Secure Preferences de Chrome, con permisos sobre cookies, historial, marcadores, pestañas, almacenamiento, proxy, scripting y declarativeNetRequest, y sobre todas las URL HTTP y HTTPS.

De seis paneles a 28

La primera referencia pública a Lunex es de junio de 2026, cuando Luke Wilkinson, de BlueTeamCoolTeam, localizó seis paneles de mando y control activos. El análisis de Ontinue eleva la cifra a 28 paneles repartidos por 13 países, alojados en Rusia, Estados Unidos, Reino Unido, Países Bajos, Francia, Alemania, Turquía y Bangladés. El rastro apunta a un desarrollador o equipo rusófono. Uno de los paneles turcos resuelve a cinco dominios de phishing, lo que indica que la plataforma no se limita al robo de credenciales: también sirve para suplantar marcas.

Para quien administra endpoints, el aviso es doble. Por un lado, el bloqueo de drivers vulnerables que viene por defecto no cubre esta variante, así que la detección tiene que mirar más allá del hash del fichero. Por otro, la persistencia vía Native Messaging en Chrome obliga a revisar el registro de hosts de mensajería nativa y las extensiones instaladas por preferencias manipuladas cuando se limpia una máquina infectada.