Dentro de FakeAgent: cómo una campaña de malvertising con Claude Desktop afectó a 29 organizaciones con SectopRAT

Actualización: Hemos actualizado la atribución de malware de este blog a SectopRAT debido a la presencia de HVNC en el payload .NET, tras una inspección más detallada de los servicios de Command and Control relacionados, revelados en las transacciones de Ethereum BSC.

Contexto

Entre el 21 y el 22 de julio de 2026, el Centro de operaciones de seguridad (SOC) de Huntress detectó una oleada de instalaciones de ejecutables inusuales, exclusiones de Defender y persistencia anómala en 29 organizaciones, todas provenientes de ClaudeDesktop.exe. Los ataques tenían un denominador común: las víctimas habían buscado la aplicación de escritorio de Claude y fueron dirigidas a un artefacto público malicioso de Claude en el dominio real de Claude AI, que parecía ser un enlace de descarga legítimo para la aplicación de escritorio.

Nuestra investigación más profunda de los ataques reveló una técnica frustrante de anti-análisis, datos de comando y control (C2) almacenados en la blockchain de Ethereum, y en su núcleo, SectopRAT, un troyano de acceso remoto (RAT) que sustrae datos de tarjetas de crédito, información personal, archivos y contraseñas de los usuarios. Hemos titulado esta campaña FakeAgent, por razones que creemos evidentes: el uso de Claude para alojar el cargador malicioso como un artefacto de Claude, y el uso del propio Claude Desktop como la aplicación de camuflaje.

Por nuestra parte, el análisis de este ataque fue parcialmente asistido por el propio Claude. Algunos detalles de reimplementación, específicamente sobre la emulación de AES y SM5, se obtuvieron mediante Claude Opus 4.8. Creemos que es importante divulgar estos detalles, tanto por transparencia como para dejar claro dónde las integraciones de LLM nos dan una ventaja como defensores cibernéticos.

Análisis

Acceso inicial

SEO poisoning y anuncios pagados maliciosos han sido una espina en el costado de los profesionales de ciberseguridad desde hace tiempo. Este ataque no es la excepción. El usuario realizó una búsqueda inocente en Bing de "CLAUDE DESKTOP APP". Como se muestra en la Figura 1, los resultados patrocinados estaban llenos de páginas falsas que pretendían ofrecer Claude Desktop. Sin embargo, entre esos resultados había un enlace patrocinado al dominio legítimo Claude.ai.

Una inspección más detallada de ese enlace patrocinado reveló algo más siniestro. En lugar de enviar al usuario a una página normal, el anuncio apuntaba al artefacto público alojado en Claude.ai. Los artefactos públicos son documentos o archivos que los usuarios o los modelos de lenguaje grande pueden crear, subir y compartir públicamente. Suelen usarse para mostrar contenido simple de prueba de concepto, como un sitio web de una sola página, un gráfico o una imagen.

Figura 1: Resultados de búsqueda en Bing con varios anuncios patrocinados maliciosos, incluido el Claude.ai artefacto público alojado.

En este caso, las víctimas son dirigidas desde Bing Search a un artefacto público alojado en claude[.]ai/public/artifacts/ca456f1f-44c0-42af-b329-4f1c7534a877. Claude indica en un descargo de responsabilidad en la Figura 2, que publica en todas sus páginas de artefactos: "El contenido es generado por el usuario y no verificado". Reportamos el artefacto para su eliminación y ayudar a interrumpir la distribución de este malware; desde entonces, Anthropic lo ha eliminado.

Sin embargo, antes de ser eliminado, el enlace del artefacto malicioso tuvo 7.100 visualizaciones de página.

Figura 2: Página de phishing de Claude Desktop/Cowork alojada como un artefacto de Claude.

Este artefacto generado por el usuario se hace pasar por una instalación legítima de Claude Desktop, pero redirige al usuario a un dominio externo al hacer clic en el botón "Download". Específicamente, son enviados a claude.ai.download-app[.]us (registrado el 9 de mayo de 2026) y posteriormente a downloading-api.it[.]com/html/claude/win.

En este punto, al usuario se le entrega un archivo malicioso ClaudeDesktop.exe, que descarga y ejecuta sin saberlo, con la confianza desarmada dado el dominio legítimo Claude.ai del que originalmente lo obtuvo.

Dentro del malware

ClaudeDesktop.exe y DockerDesktop.exe

Los ejecutables principales son ClaudeDesktop.exe y DockerDesktop.exe. Estos son idénticos: uno sirve para descargar y preparar el payload inicial (ClaudeDesktop.exe) y el otro (DockerDesktop.exe) se escribe en el disco como una tarea programada persistente para reinfectar repetidamente el equipo.

Figura 3: Detalles del proceso ClaudeDesktop.exe.

Vale la pena señalar que ClaudeDesktop.exe no es en realidad ClaudeDesktop.exe, sino un componente de jcef_helper.exe de JetBrains, una aplicación de Chromium Embedded Framework.

Esta aplicación es vulnerable a una técnica conocida como DLL sideloading.

Un breve paréntesis sobre el DLL sideloading

El DLL sideloading es una técnica mediante la cual una biblioteca de enlace dinámico (DLL) maliciosa y manipulada puede ubicarse dentro de la ruta de búsqueda de la aplicación. Estas DLL suelen contener código que el ejecutable principal importa y ejecuta. Al modificar maliciosamente esa función en la DLL, un atacante puede lograr ejecución en el contexto de un ejecutable confiable y firmado.

Con esto en mente, nuestro payload real se encuentra en la DLL ubicada junto a la aplicación maliciosa (libcef.dll). Esta es una DLL que se encuentra típicamente con el Chromium Embedded Framework (de ahí CEF) y, por sí sola, no es motivo de alarma.

Sin embargo, el hash de este archivo no coincide con los registros públicos, por lo que podemos concluir que un atacante probablemente lo ha manipulado.

Al examinar el binario libcef.dll, notamos algunas cosas particulares sobre nuestro malware:

• Ha sido empaquetado con VMProtect, una herramienta comercial de protección de software que los atacantes han abusado para hacer que su malware sea notoriamente difícil de revertir.

• Tiene referencias a un contrato de Ethereum (0xc1907d7be91f95903ad66d775c397302e7dd9228)

VMProtect es genuinamente problemático, ya que hace que el análisis de malware sea mucho más lento y más intensivo en recursos para los defensores, así que comenzamos explorando el contrato de Ethereum. En este caso, el contrato de Ethereum referenciado por el binario no tiene saldo, pero las llamadas a funciones pueden rastrearse hasta finalmente descargar y ejecutar un payload almacenado en cache.dat, que parece instalar posteriormente el componente secundario de este malware, el propio RAT.

Este acto de almacenar información de comando y control en la blockchain de Ethereum es una táctica conocida llamada "EtherHiding" que ha arrasado en el desarrollo de malware. Es esencialmente una dirección de comando y control resiliente: con solo publicar una nueva transacción en la dirección de Ethereum, un atacante puede rotar trivialmente sus servicios de comando y control de una manera difícil de derribar o interrumpir. El propósito de estos contratos de Ethereum no es contener ni mover fondos de criptomoneda, NFT ni representaciones de código de alguna transacción, sino brindar un medio resistente a la eliminación para que el malware cambie su servicio de comando y control.

Al llamar al contrato de Ethereum, recibimos una respuesta cifrada, sin una forma aparente de descifrarla. Al recorrer el binario, vemos que la aplicación entra en la sección VMProtect poco después, y nos quedamos en un callejón sin salida. ¿Cuál era el comando y control? ¿Qué detalles se obtenían del contrato de Ethereum? Ante la realidad de tener que trabajar con la ofuscación de VMProtect o con procedimientos de análisis dinámico complicados, pasamos al otro payload observado en el endpoint.

Desenmascarando al RAT

Se escribió un mecanismo de persistencia adicional en %APPDATA\Roaming\Microsoft\EdgeUpdate\Install\sslconf.exe, así que exploramos esto a continuación.

Sslconf.exe es, otra vez, una aplicación firmada; en este caso, un binario de IBM SPSS. IBM SPSS es una plataforma de análisis estadístico, así que otra aplicación legítima y poco llamativa, ampliamente usada en muchos sectores. 

Sin embargo, nuestro atacante es aficionado a los patrones. Tras investigar más, descubrimos que el actor volvió a usar carga lateral de DLL, esta vez a través del vector de carga lateral  tempdir.dll. Este archivo también fue modificado maliciosamente por el atacante, y esta vez no incluye VMProtect. 

Sin embargo, implementa varias protecciones que, en sí mismas, son increíblemente difíciles de superar. La principal es que tempdir.dll implementa una puerta anti-VM basada en GPU. Esta es una técnica anti-análisis en la que el malware revisa el hardware gráfico de un sistema antes de decidir si ejecuta realmente su payload malicioso. Al examinar los adaptadores de DirectX Graphics Interface (DXGI) en el endpoint y buscar valores como 0x1234 (QEMU), 0x15AD (VMWare), etc., el atacante logra vencer las plataformas de análisis comunes.

Los atacantes también buscan asignaciones limitadas de VRAM (Video RAM) (menos de 1 GB) y realizan una pequeña verificación de tiempo de un compute shader. Una asignación limitada de VRAM suele ser una señal confiable de que podrían estar ejecutándose dentro de una máquina virtual o sandbox en lugar de en la computadora física real de una víctima. Si esto termina excepcionalmente rápido, lo cual puede ocurrir en emulación, el malware no logra ejecutarse. 

Esta no es la única interacción gráfica con este malware. De hecho, todo el payload se almacenaba en el disco como appcfg.dat. Tradicionalmente, tomaríamos la rutina de descifrado del malware y la ejecutaríamos sobre el payload, pero nuestro atacante se adelantó. 

La rutina de descifrado del malware no es una rutina de descifrado típica basada en CPU: en cambio, es un shader de DirectX compilado que se ejecuta sobre el payload, delegando el descifrado del payload a la interfaz gráfica de DirectX (comúnmente una tarjeta gráfica). 

Mientras que las rutinas de descifrado basadas en CPU normalmente llaman a API de criptografía o algoritmos personalizados para descifrar en memoria —algo que los defensores detectan fácilmente al interceptar llamadas a API de criptografía y escanear la memoria del proceso en busca de código desempaquetado sospechoso—, el cifrado basado en GPU/shader no usa el conjunto de instrucciones típico, y los kits de ingeniería inversa estándar no manejan bien la descompilación de esta base de código. Esto queda esencialmente abstraído para nosotros, de forma muy similar al payload de VMProtect. El malware hace algo de magia de caja negra, y las credenciales se exfiltran.

Ahora nos enfrentamos a una bifurcación en el camino: 

• Revertir el código protegido con VMProtect

• Recurrir a plataformas de emulación para intentar lograr la desofuscación

• Implementar nuestro propio intérprete de bytecode SM5 y emular la función de shader en bruto

Ninguna opción resulta particularmente atractiva, pero optamos por la ruta de nuestro propio intérprete SM5, con la ayuda de nuestras integraciones de confianza con Claude.

Usando Claude para análisis asistido por IA

Pusimos a Claude manos a la obra, y de inmediato comenzó extrayendo el archivo DirectX Binary Container (DXBC). El archivo era notablemente grande: 26.536 bytes para un esquema de descifrado simple. Esto significa que había embebido más que solo el algoritmo criptográfico.

Al desglosarlo un poco, recuperamos la S-box de Rijndael almacenada dentro del shader, además de los materiales de clave. Al recorrer el binario, no pudimos identificar ningún algoritmo criptográfico conocido. Inicialmente exploramos ChaCha20 como caso probable, pero esto se descartó rápidamente por las tablas incorporadas, que nos llevaron a AES-256-CTR. 

Recuperamos la S-box directa de AES y la secuencia Rcon de AES para la expansión de claves, y nos pusimos a reimplementar esencialmente AES para descifrar esto sin ayuda de una GPU. Al montar un oráculo, o una pieza de descifrado contra la cual probar repetidamente, pudimos validar una y otra vez nuestras suposiciones de una clave 'correcta' contra el oráculo y lograr el descifrado. 

Con algo de guía, llevamos a Claude a derivar con éxito la clave AES-256 y el nonce, además de todo el material criptográfico relevante. Y le pedimos amablemente que los usara para descifrar el payload. Probó con OpenSSL y… falló. Los LLM suelen introducir errores o problemas en el código, y la criptografía es bastante delicada, así que no es descabellado que el análisis asistido por IA haya cometido un error en algún punto del proceso.

Figura 4: Autodocumentación de Claude para la emulación SM5 de tempdir.dll; valida la comprensión correcta de las modificaciones de AES-256-CTR contra el oráculo de AES para recuperar el material criptográfico de AES.

Sin embargo, la verificación manual cruzada y la reimplementación de las partes particularmente opacas que derivan rasgos clave del shader de GPU todavía resultaron en un fallo al descifrar el payload. El descifrado SM5 solo había analizado varias partes de la aplicación; necesitábamos una implementación más realista. Claude se pone manos a la obra otra vez para lograr resultados.

Figura 5: Claude se está dando por vencido con nosotros.

Claude volvió y entregó la noticia sin rodeos: llegamos al límite de lo que se puede lograr aquí. Reimplementamos un intérprete de bytecode SM5 más robusto, e incluso descubrimos por qué el descifrado no funcionaba del todo; el shader usa una función MixColumns no estándar, así que una emulación SM5 más completa dio frutos, pero en última instancia no resultó en el descifrado. 

Nos quitamos el sombrero de analistas y nos ponemos el de ingenieros. Cuando algo no funciona y ya revisaste todo lo relevante, en su lugar examina tus suposiciones. Creamos nosotros mismos un shader de DirectX para probar nuestra aplicación, y pasa la prueba: nuestra implementación SM5 es correcta. Algo en nuestras suposiciones previas está equivocado.

La respuesta es dolorosamente simple con algo de análisis manual. Transcribimos mal la clave AES. Dentro de la clave, un solo byte se copió incorrectamente como 0x68 en lugar de 0x6b. Este error de un solo byte provocó nuestra incapacidad para descifrar, incluso con la operación corregida de la Fila 3 derivada de la emulación de bytecode. Si alguna vez lo dudaste, esta es la importancia del factor humano en la ecuación.

Figura 6: Claude celebró, nosotros celebramos, y creo que escuché aplausos desde los parlantes de mi MacBook.

Con esto, podemos descifrar appcfg.dat de forma estática en el disco (sin usar el shader directamente) simplemente reimplementando el algoritmo AES-256-CTR específico con la ligera modificación de la función MixColumns de la fila 3.

Descifrando el huevo

Antes de entrar en esta sección, quiero recordarle al lector el matiz aquí: todavía no tenemos el comando y control del binario. Ni siquiera sabemos qué hace más allá de lo que hemos afirmado aquí. 

Con esto en mente, nos pusimos a examinar appcfg.dat, recién descifrado por Claude. Dentro del sinsentido logramos extraer tanto un archivo PE estándar como un ensamblado .NET. Con algunas hipótesis sobre lo que esto significa, el ensamblado .NET contiene el grueso de nuestro botín. 

Al abrir ILSpy, un descompilador de .NET común, de inmediato nos encontramos inundados con un payload de .NET fuertemente ofuscado. Las cadenas en texto plano incluyen referencias a inicios de sesión de navegadores, cookies, autocompletados, tarjetas de crédito, robo de claves de chromium, FTP, Discord, clientes de mensajería, etc.

Sin embargo, el servicio de comando y control todavía está ofuscado, así que aún no estamos fuera de peligro, aunque ya tenemos una buena idea de qué es este malware: SectopRAT. Podemos triangular esto a partir de las cadenas expuestas, los datos objetivo y los comportamientos. Si no es una implementación directa del SectopRAT de uso común, es una variante poco notable de la familia SectopRAT.

Sin el comando y control, sin embargo, estamos atascados. VMProtect todavía guarda las claves de nuestro comando y control si volvemos a nuestro análisis anterior, y el payload de .NET también está fuertemente ofuscado. Sin embargo, .NET es mucho más fácil de trabajar, así que planteamos la hipótesis: "Si el adversario usó Etherhiding una vez, ¿podría volver a usarlo?" Y comenzamos a buscar características de Etherhiding en el payload de .NET.

Encontramos oro.

Ardiendo por ambos extremos

De inmediato ubicamos el comportamiento de HttpClient dentro del binario descompilado, lamentablemente ofuscado, pero discernible; con algunas referencias de variables que nos permitieron subir para ver la estructura de configuración. 

Figura 7: Empleando la habilidad críticamente útil de usar Ctrl+F para nombres de funciones comunes.

Pusimos a Claude a descifrar y desofuscar todas las cadenas relevantes, y en general a rastrear el flujo de control con nuestro HttpClient identificado como ancla, logrando una representación fiel del código. Es importante señalar que esto no es una desofuscación "convencional"; en cambio, el LLM creó su propia interpretación de cómo lucía la función, basada en su comprensión del cifrado/ofuscación. Esto no es muy distinto de los lenguajes intermedios que utilizan plataformas de ingeniería inversa como BinaryNinja.

Figura 8: Representación desofuscada por el LLM del código .NET integrado. 

Con esto en mano, por fin tenemos nuestro botín, el contrato de Ethereum, y los medios para descifrarlo; y obtenemos la dirección activa del comando y control (C2): 2.24.131[.]246, y hemos superado el anidamiento de malware tipo Matryoshka presente en esta campaña.

Seguridad operativa fallida

Dentro de nuestro análisis, exploramos varios campos usando una combinación de registros WHOIS públicos y la plataforma de inteligencia Validin. Logramos identificar la dirección de correo electrónico usada para registrar el dominio malicioso download-app[.]us antes de que el proveedor de hosting ocultara los datos personales del usuario.

Figura 9: Resultados de Validin que indexan la dirección de correo electrónico del individuo en varios sitios de phishing y distribución de malware.

Validin indexó exitosamente 10 dominios distintos registrados con esta misma dirección de correo electrónico, que se remontan hasta diciembre de 2025. Además, notamos que al menos un sitio alojado con esta dirección de correo electrónico fue incautado por Microsoft como parte de Operation Endgame, un esfuerzo internacional conjunto para interrumpir la distribución de malware y los servicios de comando y control. Específicamente, el dominio polse[.]us fue identificado por Microsoft como alojamiento del malware stealer StealC.

Los analistas de Huntress triangulan a este usuario con una campaña que rastreamos internamente en abril de 2026, donde el mismo individuo usó Docker Hub para distribuir una instalación falsa de Docker Desktop con tácticas similares, utilizando la carga lateral de libcef.dll para distribuir malware bajo la apariencia de una instalación legítima de Docker desde un dominio confiable.

Al examinar las transacciones de Ethereum BNB Smart Chain (BSC) para las direcciones listadas, el comando y control que identificamos en este ataque se extiende mucho más allá del evento actual, hasta una fecha de transacción inicial del 30/05/2025.

Figura 10: Transacciones de Ethereum BSC contra una de las dos direcciones listadas; todas contienen servicios de comando y control.

Como ahora poseemos los criptomateriales para sus transacciones BSC, podemos descifrar completamente todos los C2 usados históricamente por el operador. Hemos incluido esta lista debajo de la sección de IOC, ya que probablemente se puedan atribuir a otras campañas y difieren de nuestro alcance principal de análisis.

Conclusiones

Cuando hablamos de ataques "acelerados por IA", a menudo nos referimos a ataques agénticos o a scripts generados por LLM utilizados en un ataque. Sin embargo, a un nivel curiosamente literal, el ataque que observamos en este blog también está acelerado por IA, pero con un giro interesante. A medida que los usuarios aumentan su búsqueda de herramientas de IA, los sitios web de proveedores de IA se convierten en blancos propicios para el malvertising y, en algunos casos, incluso para el alojamiento malicioso en sí mismo. ¿Qué significa esto para los usuarios que quieren protegerse?

• No confíes implícitamente en los dominios de nivel superior. Un enlace legítimo de Claude.ai sirvió este enlace malicioso en particular. Esta campaña se está volviendo sorprendentemente común. 

• Ten mucho cuidado al usar motores de búsqueda. El malvertising pagado/SEO poisoning es un ataque bien documentado y de larga data. 

• Las herramientas de IA/LLM son poderosas. Están dando a los atacantes métodos avanzados de distribución de malware y nuevas facetas de ataque, pero también están dando a los defensores herramientas para lidiar con amenazas más complejas y entender los ataques de forma más profunda. 

IOC principales

Direcciones C2 extraídas