Nuevo malware GlassWorm, BlackMamba y la nueva ola de ciberamenazas

El panorama del nuevo malware que circula por el ecosistema de desarrolladores y empresas tecnológicas está cambiando a una velocidad brutal. No hablamos solo de troyanos “clásicos”, sino de campañas como GlassWorm, pruebas de concepto como BlackMamba y familias de malware que se apoyan en técnicas fileless, cifrado avanzado, inteligencia artificial y canales de mando y control poco habituales como la blockchain de Solana o aplicaciones de colaboración corporativa.

En este contexto, términos como GlassWorm, malware polimórfico, keyloggers generados por IA o extensiones maliciosas de VS Code han dejado de ser curiosidades técnicas para convertirse en un problema muy real para desarrolladores, organizaciones y hasta gobiernos. A continuación desgranamos con detalle qué está pasando, cómo funcionan estas amenazas y por qué exigen un cambio de mentalidad en la forma de proteger la cadena de suministro de software.

GlassWorm: el gusano invisible que se cuela en extensiones y repositorios

GlassWorm se ha consolidado como uno de los primeros gusanos centrados específicamente en el ecosistema de desarrolladores, con una especial fijación en extensiones de VS Code, repositorios GitHub y registros como npm u OpenVSX. Su rasgo distintivo inicial fue el uso de caracteres Unicode invisibles para ocultar código malicioso dentro de ficheros JavaScript y TypeScript sin que nada “raro” se apreciara a simple vista en el editor.

El truco consiste en aprovechar caracteres de zonas de uso privado de Unicode (PUA) y modificadores de variación que los editores representan como espacios en blanco, pero que en realidad codifican bytes. Un pequeño decodificador recorre el contenido de una cadena que parece estar vacía, convierte esos puntos de código en valores numéricos válidos, los junta en un búfer y finalmente llama a eval() para ejecutar el payload ya decodificado.

Desde el punto de vista del desarrollador, el fragmento sospechoso suele estar camuflado entre cambios aparentemente inocuos: refactorizaciones menores, pequeños ajustes de documentación o bumps de versión. El commit no “canta” nada especialmente extraño, y la propia inyección suele quedar camuflada dentro de un fichero de utilidad o un helper compartido, lo que facilita que pase desapercibida en revisiones de código manuales.

Las primeras oleadas de esta campaña, rastreadas por distintas empresas de seguridad, demostraron que la técnica de Unicode invisible era suficiente para burlar revisiones, linters y muchas herramientas automatizadas. El resultado: repositorios populares comprometidos, extensiones infectadas y una superficie de ataque perfecta para propagar malware a cualquiera que instalara o clonara esos proyectos.

En paralelo, se observó cómo el actor de amenazas detrás de GlassWorm iba moviéndose entre ecosistemas: primero OpenVSX y VS Code, después GitHub, luego npm y de nuevo vuelta a los marketplaces de extensiones, siguiendo un patrón muy claro de ataques en oleadas, cada una más sofisticada que la anterior.

Campañas encadenadas: de Unicode invisible a binarios Rust y payloads cifrados

Conforme los analistas publicaban informes técnicos detallando los métodos de GlassWorm, el atacante respondía modificando las TTPs (tácticas, técnicas y procedimientos) en cuestión de semanas. Esa evolución se ha ido organizando en varias “olas” o waves, cada una con matices propios pero con una infraestructura y objetivos claramente compartidos.

En las primeras oleadas, el protagonismo absoluto era de los payloads ocultos en caracteres Unicode invisibles integrados en extensiones de VS Code y OpenVSX. El código malicioso, una vez decodificado, solía descargar un segundo script empleando la blockchain de Solana como canal de distribución, con capacidad de robo de credenciales, secretos de desarrollador y datos de monederos de criptomonedas.

Posteriormente, el actor dio un salto hacia binarios compilados en Rust, dejando atrás la parte más evidente del truco Unicode. Estos binarios incorporaban lógica más compleja, incluyendo capacidades de robo de datos, creación de proxies SOCKS y canales de acceso remoto mediante VNC, todo ello lanzado desde el entorno del desarrollador que instalaba una extensión aparentemente legítima.

En una cuarta oleada, el enfoque cambió de nuevo: el payload comenzó a llegar como código JavaScript con contenido cifrado mediante AES-256-CBC, incrustado en ficheros compilados de extensiones de OpenVSX. La clave y el vector de inicialización (IV) estaban codificados en el propio código, compartidos entre varias extensiones, lo que apuntaba a un único operador detrás de la campaña.

Para rematar, el atacante incluyó una táctica muy concreta para evadir sandboxes: un retraso de unos 900.000 milisegundos (unos 15 minutos) antes de ejecutar cualquier acción maliciosa. Muchos entornos de análisis automatizado cortan la ejecución a los pocos minutos, así que la extensión parecía inocua durante el tiempo que duraba la observación, pasando los filtros sin levantar sospechas.

Salto a macOS: GlassWorm va donde están los desarrolladores

Una de las evoluciones más preocupantes de GlassWorm ha sido el cambio de foco desde sistemas Windows a un objetivo prácticamente exclusivo en macOS, especialmente en campañas recientes. Tiene todo el sentido: gran parte de los desarrolladores, en particular en entornos de criptomonedas, web3 y startups, utilizan Mac como estación principal de trabajo.

En lugar de PowerShell o de jugar con el Registro de Windows, las nuevas variantes de GlassWorm emplean AppleScript para ejecutar acciones de forma sigilosa y usan LaunchAgents como mecanismo de persistencia, garantizando que la carga maliciosa se ejecute en cada inicio de sesión del usuario comprometido.

El malware se centra en robar información extremadamente sensible de macOS: bases de datos del llavero (login.keychain-db), contraseñas almacenadas, notas de Apple Notes, cookies de Safari, datos de navegadores basados en Chromium y Firefox, documentos del sistema de ficheros con apariencia de contener secretos de desarrollo y más.

Además, el payload recopila credenciales de desarrollador y datos de proyectos, incluyendo tokens de GitHub, credenciales almacenadas en caches de git, tokens de npm desde el fichero .npmrc, claves SSH del directorio ~/.ssh y configuraciones de VPN. Todo ello se empaqueta en una carpeta temporal, se comprime y se exfiltra a servidores controlados por el atacante.

La infraestructura de mando y control (C2) mantiene un patrón consistente: uso de la blockchain de Solana para publicar notas o memos con URLs codificadas en base64 que apuntan a los servidores actuales. Los endpoints pueden cambiar cuantas veces quiera el atacante; basta con publicar un nuevo memo en la blockchain. Como el registro en Solana es inmutable y descentralizado, es prácticamente imposible “tumbanarlo” del mismo modo que se haría con un dominio clásico.

Troyanización de monederos hardware: el siguiente nivel

Uno de los avances más serios de las últimas oleadas de GlassWorm es la capacidad para reemplazar aplicaciones de monederos hardware por versiones troyanizadas. El código malicioso busca específicamente instaladores o ejecutables de aplicaciones como Ledger Live y Trezor Suite en el sistema del usuario.

Si los encuentra, el malware intenta descargar una versión maliciosa de esas aplicaciones desde los servidores del atacante, elimina la aplicación legítima y deja instalada la variante manipulada. Para evitar que una descarga incompleta delate la intrusión, el código incluye comprobaciones de tamaño mínimo (por ejemplo, archivos por debajo de cierto umbral no se instalan), lo que revela un grado de cuidado notable por parte del actor.

Este enfoque abre la puerta a ataques muy sofisticados contra el ecosistema cripto: una aplicación de monedero alterada podría mostrar direcciones de recepción falsas, modificar los detalles de las transacciones antes de que el usuario firme en el dispositivo físico, capturar frases semilla durante procesos de “recuperación” o interceptar la comunicación entre el dispositivo hardware y el software.

En el momento de algunos análisis, los servidores C2 devolvían archivos vacíos para las supuestas aplicaciones troyanizadas, lo que sugería que el atacante estaba aún preparando las cargas útiles o migrando la infraestructura. Sin embargo, el resto de funcionalidades -robo de credenciales, exfiltración de información, persistencia en macOS- estaban plenamente operativas.

Más allá de los monederos hardware, el malware sigue extendiendo su alcance sobre docenas de monederos de navegador y de escritorio: MetaMask, Phantom, Coinbase Wallet, Exodus, Keplr, Solflare, Trust Wallet, Rabby, Electrum, Coinomi, Atomic, clientes de Bitcoin Core, Monero y otros. La intención es clara: comprometer el máximo de fondos posible en cada equipo infectado.

Robo masivo de credenciales y expansión como gusano

GlassWorm no se limita a robar credenciales; también las utiliza activamente para seguir propagándose. En incidentes documentados, los operadores aprovecharon cuentas legítimas de desarrolladores -por ejemplo, en OpenVSX o en GitHub- para subir versiones adulteradas de extensiones o para empujar commits maliciosos a proyectos de código abierto.

En uno de los casos, la cuenta de un desarrollador con varias extensiones populares fue comprometida y empleada para distribuir actualizaciones maliciosas que incluían el payload de GlassWorm. Estas extensiones llevaban años siendo totalmente inocuas, lo que reforzaba la confianza de los usuarios a la hora de actualizar sin miramientos.

Los commits usados para introducir el código malicioso daban el pego: sumaban cambios de estilo, pequeños arreglos y mensajes de commit coherentes con el historial del proyecto. Todo apunta a que el atacante utiliza herramientas de generación de código asistidas por IA, o incluso plantillas de commits generados automáticamente, para que cada modificación encaje con el estilo del repositorio comprometido.

A medida que este gusano avanza, se han documentado víctimas en múltiples regiones, incluidas organizaciones de alto perfil. Entre los datos sustraídos en uno de los servidores de mando y control se encontró un listado parcial de víctimas de América, Europa, Asia e incluso una entidad gubernamental de Oriente Medio. Junto a esta información, aparecían también trazas del propio operador: datos de keyloggers, indicios de idioma ruso, uso de frameworks de C2 como RedExt y cuentas en exchanges de criptomonedas y plataformas de mensajería.

Todo ello apunta a un actor altamente profesional, con motivación económica clara y con una capacidad de iteración técnica nada desdeñable. Además, da una pista de por qué las campañas siguen activas incluso tras informes públicos y mitigaciones: mientras el modelo de negocio sea rentable y la infraestructura no sea completamente desmantelada, las oleadas seguirán llegando.

BlackMamba y la amenaza del malware generado por IA

Paralelamente al caso GlassWorm, se han desarrollado pruebas de concepto que exploran cómo los modelos de lenguaje y la IA generativa pueden dar forma a un nuevo tipo de malware. Una de las más conocidas es BlackMamba, diseñada para demostrar el potencial de los grandes modelos de lenguaje a la hora de crear keyloggers polimórficos bajo demanda.

BlackMamba parte de un ejecutable benigno que, en tiempo de ejecución, realiza peticiones a una API de alta reputación (como la de OpenAI) para solicitar código Python capaz de registrar pulsaciones de teclado. Ese código se genera dinámicamente en cada ejecución, de modo que nunca es exactamente el mismo, y se ejecuta en memoria mediante la función exec() de Python, sin necesidad de escribir el payload en disco.

Esto provoca que la parte verdaderamente maliciosa del programa sea polimórfica y fileless, ya que reside solo en memoria y cambia continuamente. En pruebas realizadas contra soluciones EDR del mercado, este enfoque llegó a pasar completamente inadvertido, sin generar alertas ni detecciones, a pesar de que el comportamiento (keylogging y exfiltración de datos) era claramente dañino.

Para sacar los datos del dispositivo infectado, la PoC utilizó un canal que muchos considerarían inocuo: Microsoft Teams, mediante webhooks hacia un canal controlado por el atacante. De este modo, nombres de usuario, contraseñas, números de tarjeta y cualquier texto tecleado podían enviarse a través de una plataforma de comunicaciones corporativa legítima, mimetizándose con el resto del tráfico.

El empaquetado final del malware se llevó a cabo con herramientas como auto-py-to-exe, que permiten convertir scripts de Python en ejecutables autónomos para Windows, macOS o Linux. Así, el usuario objetivo recibe un archivo que puede ejecutar sin necesidad de tener Python instalado, lo que facilita su distribución mediante técnicas tradicionales como correos de phishing, enlaces en chats o ingeniería social clásica.

¿Hasta dónde llega el riesgo del malware generado por IA?

La existencia de PoCs como BlackMamba no significa que de repente el mundo esté indefenso, pero sí deja claro que los atacantes pueden apoyarse en modelos de IA para combinar comportamientos maliciosos de manera poco habitual, explotando lagunas de los sistemas de detección basados en patrones históricos.

La IA permite, por ejemplo, generar variaciones casi infinitas de un mismo payload, ajustar el código para evadir heurísticas concretas, o incluso producir commits con mensajes y cambios aparentemente razonables para enmascarar actividades de intrusión en repositorios de código. Combinada con canales de exfiltración “respetables” -como Teams, servicios cloud públicos o APIs de proveedores de confianza-, la línea entre tráfico legítimo y tráfico malicioso se difumina aún más.

Ahora bien, también es cierto que el uso de memoria como único lugar de residencia del malware, el polimorfismo y el abuso de canales legítimos son retos que la industria de la ciberseguridad lleva tiempo enfrentando. El salto cualitativo de la IA no es tanto la aparición de técnicas totalmente nuevas, sino la facilidad con la que cualquier atacante puede automatizar y orquestar esas técnicas a gran escala.

Las soluciones de seguridad modernas, especialmente las que combinan EDR/XDR con modelos de IA propios y análisis de comportamiento, ya trabajan monitorizando patrones de ejecución, accesos a APIs sensibles, anomalías de red y correlaciones temporales entre eventos, en lugar de depender solo de firmas estáticas. Aun así, la presión sobre los sistemas defensivos aumenta, y las organizaciones que no hayan dado el salto a este tipo de enfoque corren un riesgo mayor frente a amenazas como las mostradas por BlackMamba.

En este escenario se hace evidente que la inteligencia humana sigue siendo crucial: analistas capaces de interpretar señales sutiles, de entender el contexto de un incidente y de ajustar las defensas de forma creativa. La colaboración entre fabricantes de seguridad, investigadores, clientes y fuerzas de seguridad se vuelve indispensable para compartir indicadores de compromiso (IOCs), patrones de ataque y mejores prácticas de respuesta.

Defensa de la cadena de suministro: más allá de los antivirus tradicionales

Todo lo anterior apunta a una conclusión clara: las organizaciones ya no pueden confiar únicamente en revisiones visuales de código, antivirus clásicos o escaneos estáticos de paquetes para proteger su cadena de suministro de software. Cuando el código malicioso puede ser literalmente invisible en el editor, ejecutarse solo en memoria o llegar cifrado y con retardo, hace falta un enfoque integral.

Varias plataformas especializadas han empezado a incorporar motores de detección específicos para patrones como el uso de caracteres Unicode invisibles, payloads cifrados y comportamientos anómalos en extensiones y paquetes. Estos motores analizan tanto los repositorios como los artefactos que los equipos instalan (extensiones, dependencias, imágenes de contenedor, etc.), buscando secuencias de instrucciones sospechosas, llamadas a APIs inusuales y patrones de ofuscación.

Otra línea de defensa es el uso de herramientas que envuelven los gestores de paquetes (npm, npx, yarn, pnpm y similares) con capas de seguridad adicionales, interceptando instalaciones potencialmente peligrosas y cotejándolas frente a bases de datos de malware y modelos de riesgo. Algunas soluciones incluso combinan IA con analistas humanos para validar rápidamente paquetes sospechosos, bloqueando su entrada en los entornos de desarrollo.

Para los equipos de desarrollo, también es crítico mantener una buena higiene de credenciales: rotar tokens, usar autenticación multifactor, limitar el alcance de los accesos y monitorizar cambios inusuales en repositorios y extensiones asociadas a sus cuentas. Si un atacante se apropia de la identidad de un mantenedor de confianza, el impacto sobre toda la comunidad de usuarios de ese paquete o extensión puede ser enorme.

En última instancia, protegerse frente a campañas como GlassWorm o frente a malware polimórfico generado por IA requiere combinar controles técnicos avanzados, procesos maduros de gestión de dependencias y una cultura de desconfianza sana hacia cualquier componente que no haya sido verificado a fondo. No se trata de dejar de usar software de terceros, sino de asumir que cualquier eslabón de la cadena puede ser un vector de ataque y actuar en consecuencia.

El nuevo malware que está emergiendo -desde gusanos invisibles en extensiones de VS Code hasta keyloggers polimórficos servidos por modelos de lenguaje- demuestra que los atacantes se están sofisticando tan rápido como la propia tecnología que usamos para defendernos. Quien quiera seguir el ritmo tendrá que abrazar soluciones basadas en comportamiento, reforzar la seguridad de la cadena de suministro y, sobre todo, dejar de dar por sentado que lo que no se ve en el editor o en el escritorio no existe.