Weaponized Custom GPT: a RAT delivered from chatgpt.com

A Custom GPT that delivers a trojan

In late September 2026 the security firm Huntress observed a campaign that turns a Custom GPT hosted on chatgpt.com into a malware delivery channel. The GPT is named «Plus 5.6» and imitates a commercial subscription offer.

The starting point is a sponsored Google result for searches such as «chatgpt». Anyone who clicks lands on two addresses under the chatgpt.com domain, with the name of the Custom GPT at the top of the page. Design, certificate and trademark belong to the real platform.

The GPT answers prompts with a «Service Availability Notice». The message offers two paths: upgrade to the paid plan, or move to a fallback domain on Google Sites, justified as a remedy for «limited availability on the primary domain». A closing invitation pushes anyone looking for immediate access toward the second option.

Huntress counts at least 40 users infected^[1] in this campaign.

The technical chain, piece by piece

The fallback domain displays a fake CAPTCHA check carrying the Cloudflare trademark.

From there a ClickFix scheme begins. The victim copies a PowerShell command and runs it by hand in their own terminal, convinced they are clearing an anti-bot verification.

The command leads to an MSI installer, «ISOSimple.msi». The installer loads a Canon-signed binary, «COTFileReadApp.exe», and uses it to sideload a malicious DLL, «ceiinfolog.dll». That library is the original Canon DLL, altered to load a second one, «rdCore.dll», which carries no signature.

The final stage extracts an encrypted loader from a .WAV audio file, runs shellcode and installs two objects: a persistence script and the RAT payload. Every link in the chain rests on a component that a surface-level check treats as legitimate: a known domain, a signed binary, a music file.

The digital signature on the Canon binary stays valid throughout the path. The hostile code lives in the library loaded alongside it, a sideload pattern fifteen years old that still works today.

What the attacker got to skip

The severity of this campaign is measured by subtraction. Zero OpenAI vulnerabilities. Zero compromised accounts.

Zero lines of code, too: a Custom GPT is built with natural-language instructions and reference files uploaded by hand, exactly as the feature allows for any user.

The attacker needed three things: an account on the platform, an advertising budget for the sponsored result, a free site on Google Sites. Trust in the domain did the rest.

Here lies the difference between a product flaw and feature abuse. A CVE closes with a patch and a version number. A feature built to accept free-form instructions from anyone is governed with moderation, telemetry and revocation, three things that live outside the code.

The defense perimeter moves from the binary to the published content, and the job of watching it changes hands.

The trusted domain replaces the exploit

Corporate blocklists treat chatgpt.com as a productivity domain. Proxies let it through, DNS filters ignore it, users recognize it at a glance.

A hostile page hosted there inherits all of that reputation. The same holds for Google Sites, which offers free hosting under a high-reputation domain.

The result is a delivery chain built entirely on respectable third-party infrastructure. Traffic toward the AI platform's domain looks identical to that of colleagues using the same service every day. The useful signal arrives downstream, when PowerShell starts, and by then the command has already been pasted by the user.

Anyone defending a network today has to assume that the best-known AI domains host arbitrary content created by anyone with an account.

The same logic applies to shared artifacts, to public conversations and to connectors. Every surface that lets an outsider publish text under an AI platform's domain becomes a distribution channel.

A pattern with documented precedents

This campaign follows other abuses in the same family. Huntress recalls shared chatbot conversations used as bait and malicious Claude artifacts employed to spread stealers and remote access trojans.

The broader pattern concerns AI inside intrusions. BleepingComputer reports the case of zero-days in Zammad that, according to DIVD, opened the way to an AI-driven network breach^[2].

The Record, meanwhile, collects Google's analyses of AI-related vulnerabilities and cyberattacks^[3]. Two distinct directions: AI as the attacker's tool, the AI platform as staging ground. The «Plus 5.6» case belongs to the second.

The distinction matters for anyone writing a policy. The first scenario calls for controls on the exposed surface; the second calls for controls on what employees reach inside services already approved.

Three questions for an enterprise AI team

An incident account describes; the decision belongs to whoever runs the stack. These three questions close the perimeter with answers verifiable within a week.

1. Who oversees the third-party content moving across the AI domains approved in the company?
2. Can a standard user today run a PowerShell command pasted from the clipboard?
3. Which EDR rule flags an MSI installer signed by a vendor outside the software estate?

The answers belong on paper with a name beside them. An orphaned security question becomes technical debt, and in security technical debt is paid with an incident.

The most effective control here stays upstream: block execution of pasted commands by a standard user. ClickFix lives on that gesture, and a well-tuned execution policy switches it off.

The second control is telemetry on installers signed by vendors outside the inventory. A Canon binary on a workstation with no Canon printer is a strong signal, cheap to collect.

Both controls already exist in the EDR products in use. What is missing here is the configuration.

Procurement, build/buy and the P&L

For a CTO the practical lesson touches domain categorization. An AI platform's domain deserves the same wariness as a file sharing platform: arbitrary content uploaded by external users, solid hosting, high reputation.

For a Head of Engineering the question concerns connectors. Every integration that brings third-party generated content into a corporate flow goes treated as hostile input, with an explicit execution barrier.

For a CFO the math is linear. Forty compromised workstations cost far more in remediation, downtime and credential rotation than the application control license that would have stopped them.

The purchasing committee holds a concrete contractual lever. In renewals with AI platform vendors it pays to ask in writing for removal times on reported content, an abuse channel with an SLA, and logs the customer can consult.

What stays open

Moderating user-published content on an AI platform is a problem of scale. Today it gets handled with tools designed for toxic text, poorly suited to a message that nudges politely toward an external domain.

The falsifiable prediction is this: within six months a similar campaign will appear on an equivalent feature of another widely used AI platform, with the same ClickFix scheme downstream. The surface is identical and the cost of entry stays close to zero.

Until then the practical defense sits on the endpoint, because the trusted domain already arrives past the perimeter.

Anyone keeping an inventory of approved AI services should take one step further: beside each service, write which third-party content that service can host. That column, empty almost everywhere today, is the map of the real attack surface.