Fake ChatGPT 'Plus 5.6' attack drops a RAT, and quarantining it didn't help
TL;DR
- A paid Google result for "chatgpt" led some victims to a fake Custom GPT called "Plus 5.6" on chatgpt.com. It told them the service was limited and sent them to a "backup domain" that asked them to paste a command into their terminal.
- That one paste installed an MSI, side-loaded malicious DLLs through a legitimately signed Canon binary, and ran a remote access trojan in memory. At least 40 incidents traced back to the same lure page, two of them through the Custom GPT.
- In at least one case, Microsoft Defender quarantined the installer. The installer had already run, and two persistence entries that restore each other kept the attack going.
- Our point of view: "quarantined" is a verdict on one file, not on the host. An alert that looks handled still needs an investigation, and that is the job Armor Investigate was built for.
What happened
Starting in late September, a ClickFix campaign borrowed the ChatGPT brand to get past people's guard. Huntress documented it on September 28, 2026. Most ClickFix chains run two or three hops. This one has eight.
- In some of the incidents, the path started with a sponsored Google result for "chatgpt", sitting above the real link. It pointed to a Custom GPT on chatgpt.com titled "Plus 5.6", listed under a "community builder".
- Any message to the GPT returned a "Service Availability Notice": the service was "experiencing limited availability on the primary domain". Upgrade to Plus, or continue through a "backup domain".
- The backup domain was a Google Sites page dressed up as a Cloudflare check. It asked the visitor to copy a command and paste it into their terminal.
- The command ran PowerShell with the execution policy bypassed, pulled a script from a server written as a decimal IP (1614733393, which is 96.62.224[.]81), and ran it.
- The script silently installed an MSI, ISOSimple.msi, which presented itself as "Advanced Printer Configuration Reader" from "Softplicity". It landed under the user's local AppData Programs folder.
- The MSI launched COTFileReadApp.exe, a legitimate Canon-signed binary. That binary loaded a patched, unsigned ceiinfolog.dll, which pulled in the malicious rdCore.dll. Classic DLL side-loading.
- rdCore.dll read a loader out of a WAV file, decoded it and ran it in memory. The loader opened an encrypted archive, monitor.raw, holding a persistence script and the RAT.
- The RAT ran in memory. It can run remote desktop sessions, capture camera, microphone and system audio, drop follow-on payloads, fingerprint the host, and find its command server over DNS over HTTPS.
Persistence came as a pair: an HKCU Run value and a scheduled task, both named "Canon Configuration Reader". The script checked for the Run value every 150 seconds and the task every 875 seconds, and recreated whichever was missing.
After the researchers reported it to OpenAI, the Custom GPT was taken down as of September 25. Two days later a replacement GPT tied to the same campaign was live, and still up when the report was published. A second wave swapped the Canon binary for a signed Stardock one, with a persistence name to match ("Stardock DeElevation Tool"). All the custom DLLs carry a compile time of September 24, 2026, 22:46 UTC. This is fresh tooling, not a recycled kit.
The alert that looked finished
In at least one of these incidents, Microsoft Defender did its job. It flagged ISOSimple.msi as Trojan:Script/Wacatac.H!ml and quarantined it.
By then the installer had already run. The Run value and the scheduled task were in place, and the chain carried on without the MSI. Delete the Run value while the implant is running and it comes back within minutes. Delete the task and the same thing happens. The right order is to kill the process first, then remove both.
Here is the part we care about. Picture how that Defender event looks in a SOC queue: one alert, a file hash, a host name, and the word "Quarantined" in the status column. To a tired analyst, or to an automation rule that auto-closes remediated detections, that reads like a finished ticket. Meanwhile the RAT was still running in memory, with remote desktop, camera and microphone access on the table.
The antivirus verdict was correct. The conclusion people draw from it was not.
Why this one gets through
Three things stack up here, and none of them is a zero-day.
The trust chain is all real brands. A Google ad, a chatgpt.com URL, a Google Sites page, a Cloudflare-looking check, a Canon-signed binary. Every hop borrows reputation from something the user and the security stack already trust. The "community builder" label under the GPT's name is a tell for people who know how Custom GPTs work, which is not most people.
The user does the running. ClickFix means there is no exploit to patch and no attachment to detonate. One paste in a terminal is the compromise. Huntress says ClickFix makes up about 2.2% of its managed EDR detection signals this year, and nearly 99% of those are high severity. Rare, and almost never harmless.
The workflow treats an AV verdict as the end. Antivirus answers one question: is this file bad? It does not answer what the file did before it was caught, what it left behind, or where the host has been talking since. Most SOC processes, and most automation playbooks, close the loop at "quarantined". Whether by design or by luck, this campaign lives in that gap.
What a quarantine alert should kick off
A quarantine is evidence that something ran on the host, not evidence that it stopped. Treat it as the start of a short investigation:
- What ran before the catch. Look at the process tree around the quarantined file. Here, PowerShell launched msiexec.exe on a 32-character hex-named _ISOSimple.msi in %TEMP%. That parent chain is the real story, not the MSI's hash.
- What it left behind. Check autoruns and scheduled tasks created in the same window. A Run value and a task that share a name, and come back after deletion, are the signature of this campaign.
- What else is living under the same roof. A signed vendor binary (Canon or Stardock) running from %LOCALAPPDATA%\Programs\ instead of a real install path, especially when msiexec started it, with unsigned DLLs sitting next to it.
- Where the host has been talking. This RAT resolves its command server over DNS over HTTPS through Cloudflare, Google and Quad9, which keeps the lookup out of plain DNS logs. Look at the egress from the Canon or Stardock process itself, not just at DNS.
- Whether anyone else clicked. The same Google Sites lure fed at least 40 incidents. One host is a reason to check for the same artifacts across the fleet.
Only then does "remediated" mean anything. And when the host is cleaned, the order matters: kill the implant process first, then remove the Run value and the task.
How Arambh handles it
Armor OS works every alert that reaches it, and a quarantine event is an alert. It gets investigated to a verdict instead of filed as done.
Armor Investigate picks up the Defender detection and builds the case around it: the PowerShell to msiexec parent chain, the install folder, the new Run value and task, the signed host binary loading unsigned DLLs, and the host's outbound connections. It returns a true-positive verdict with the full attack path on a timeline, and recommends isolating the host with an analyst approving. It also keeps watching after the case is closed. When new activity touches the same host or the same indicators later, the case reopens and the verdict gets re-evaluated with the new evidence.
Armor Hunt takes the published indicators and the behaviors above and sweeps the rest of the environment: every host that ran a hex-named MSI from %TEMP% through PowerShell, every Canon or Stardock binary living under a user profile, every "Canon Configuration Reader" or "Stardock DeElevation Tool" task. If it finds more, it maps the blast radius and offers containment.
Armor Detect turns the pattern into a durable rule rather than a hash match: a signed vendor binary started by msiexec from under AppData\Local\Programs, with a sideloaded DLL beside it. It backtests that rule against historical endpoint data first, so the team sees how often it would have fired on legitimate installs before it goes live. The next wave will probably swap the Canon binary for another signed one, the way this one swapped in Stardock. A behavioral rule survives that. A hash list does not.
One honest limit: all of this depends on endpoint process telemetry being collected. If the EDR only forwards its alerts and not the process events around them, the parent chain is invisible to any platform, ours included.
Detection notes
Indicators and behaviors from the original report, for teams that want to check their own fleet. The Canon and Stardock binaries are legitimate and signed. Hunt for where they run from, not for the files themselves.
Full hashes for every stage are in the original report.
Frequently asked questions
Was ChatGPT hacked?
No. The attackers built a Custom GPT, a feature anyone can use, and named it to look like an official product. OpenAI removed the first one after researchers reported it. A second one appeared two days later.
Why didn't the Defender quarantine stop the attack?
The quarantine removed the installer after it had already run. Persistence was in place by then: a Run value and a scheduled task that recreate each other. The RAT was running in memory, so there was no file left on disk for antivirus to catch.
What is the one detection to add first?
A signed vendor binary launched by msiexec from under AppData\Local\Programs, with a sideloaded DLL next to it. It is behavioral, so it holds up when the next wave swaps in a different signed host application.
How should a "remediated" alert be handled in the SOC?
As the start of an investigation, not the end of one. Check what ran before the catch, what persistence it left, where the host connected afterward, and whether other hosts hit the same lure. Then close it.
See how Armor Investigate works a quarantined alert all the way to a verdict. Book a demo, or read how to choose an AI SOC platform if you are earlier in the process.
