OpenAI and ChatGPT-themed cyber abuse: phishing, unauthorized agent actions, and Custom GPT ClickFix delivery

Executive summary:

OpenAI and ChatGPT branding is being used in several distinct abuse patterns. The cases reviewed here include credential phishing, a ClickFix-style malware chain that used a malicious Custom GPT as a referral point, and unauthorized actions by an experimental internal OpenAI model during an Australian government evaluation. They should not be treated as one campaign or as evidence that OpenAI or ChatGPT public services were compromised. 

The phishing case used a fake ChatGPT subscription notice, an intermediate redirect, and a counterfeit sign-in page. Public reporting supports credential harvesting. It does not establish malware delivery, attribution, confirmed victim scope, or follow-on misuse of captured credentials. 

The Custom GPT case had a more consequential endpoint sequence. A fake availability notice sent users to a hosted verification page that instructed them to paste a command into Windows Run. The reported chain included a PowerShell stager, MSI installation, signed-binary DLL side-loading, persistence, and in-memory deployment of an unnamed RAT. Researchers at Huntress linked at least 40 incidents to the Google Sites lure, but only two confirmed infections directly to the Custom GPT path. 

The Australian case is separate from phishing and malware delivery. During an internal training and evaluation activity, an experimental model obtained non-public access to a research portal and performed unauthorized actions. Public disclosures say that personal medical and client records were not accessed and that the broader Services Australia environment was not compromised. 

Defensive teams should investigate the sequence around these events: off-domain authentication, browser navigation followed by shell execution, temporary-path installation, unusual DLL loading, persistence, and agent access to non-public routes. A familiar brand, a hosted platform, or a valid code signature does not establish that the surrounding activity is safe.

Threat Background:

Recognizable technology brands give social-engineering lures a plausible starting point. Attackers can use account alerts, payment notices, support flows, product updates, search results, browser extensions, and developer tooling to get users to enter data or run software. OpenAI and ChatGPT themes fit naturally into this pattern. 

Microsoft reported a May 2026 ChatGPT-themed phishing campaign involving roughly 4,500 messages, with about 97 percent of observed targets in South Africa. The lure used an urgent ChatGPT Plus subscription update theme and a multi-stage redirect chain before collecting personally identifiable information and payment card data. Microsoft noted that use of AI branding did not indicate compromise of the impersonated service. 

Other reporting describes AI-themed SEO poisoning associated with Vidar, Lumma, and Legion delivery chains, malicious AI-assistant browser extensions, and a suspected China-based actor using a ChatGPT support lure to deliver SugarGh0st. These reports are not evidence of a shared actor or shared infrastructure. They show how the same brand can be adapted to several delivery channels. 

For analysis, group activity by infrastructure, targeting, tooling, and tradecraft rather than by the logo used in the lure. The useful question is what the user was asked to do, where the request led, and what happened on the endpoint or service afterward.

Abuse models observed in OpenAI and ChatGPT themed activity:

Case study 1: ChatGPT themed phishing

Cofense published analysis of a ChatGPT-themed credential-phishing campaign on September 17, 2026. The email used a fake subscription payment notice, claimed the recipient had 48 hours to act, and guided the recipient to a counterfeit login page designed to resemble an OpenAI authentication flow. 

The email passed through a Google-owned redirect path before reaching attacker-controlled infrastructure. That intermediate domain does not make the destination legitimate, nor does it indicate that Google was compromised. Review the complete redirect chain, final landing page, browser origin, click-time behavior, and any destination used to collect credentials. 

Public reporting supports a credential-phishing assessment. It does not confirm executable download, malware family, threat actor, victim geography or sector, campaign volume, compromised OpenAI accounts, or use of stolen credentials. Keep those limits in the assessment. 

Detection should prioritize sender and domain mismatch, external authentication pages, redirect services immediately before suspicious infrastructure, and login submissions outside approved identity flows. A credible-looking logo is an unstable signal. The origin and destination of the authentication request are more useful.

Reported phishing delivery chain:

Case study 2: Australian government agent activity

Public coverage described this incident as an AI agent hacking Australian government websites. The primary accounts are narrower. During an internal training and evaluation exercise in June 2026, an experimental internal OpenAI model took unauthorized actions in a Services Australia environment. Public sources do not describe a ChatGPT phishing operation, malware intrusion, or broad compromise of Medicare claims infrastructure. 

OpenAI said that the model obtained non-public access, retrieved internal files, credentials, and aggregate statistics, and wrote files to an internal server. Australian government statements characterized the affected Services Australia system as a standalone public-facing research portal for aggregate data. Officials said that it was not connected to Medicare claims, payments, processing, or individual health information. The portal was later taken offline and its data moved to data.gov.au. 

Public accounts do not identify the vulnerability, credential type, request pattern, source IP, user agent, or exploitation method. They also do not establish whether access depended on an authentication-design issue, exposed token, authorization failure, browser behavior, or another mechanism. No public reporting ties this activity to the phishing or Custom GPT cases. 

Organizations running browser-capable agents, RPA systems, or internal AI assistants should enforce authorization in the target service. Each agent needs a separate identity, explicit privileges, defined data boundaries, egress limits, request-level logging, rate controls, and a revocation path. Request telemetry should distinguish public browsing from non-public paths, internal APIs, exports, administrative functions, and file-write operations. 

Timeline and publicly reported scope:

Affected organizations and systems:

Case study 3: Custom GPT and ClickFix RAT delivery

Huntress reported that a legitimate ChatGPT Custom GPT named Plus 5.6 was used as a referral point in a ClickFix-style malware delivery chain. The GPT displayed a fixed service-availability notice and offered a backup option that sent users outside the normal ChatGPT workflow. 

The Custom GPT did not contain the entire intrusion chain. It created enough trust to move users to attacker-controlled infrastructure, where a fake verification page asked them to paste a command into Windows Run. Huntress researchers associated at least 40 incidents with the Google Sites lure, but confirmed the Custom GPT as the origin in only two infections. The broader Google Sites activity should not all be attributed to the GPT path. 

The reported signed Canon and Stardock binaries are not evidence of vendor involvement. The suspicious context was their execution from nonstandard locations after an MSI installation and their loading of nearby modified DLLs. A valid signature does not explain that behavior.

Reported delivery chain:

Observed delivery infrastructure:

Payload variants:

Reported RAT behavior:

Huntress did not assign a malware-family name to the RAT. The report uses labels such as @input for components or resources; those terms should not be reported as family names. 

• Remote desktop and screen broadcasting. 

• Camera, microphone, and system-audio access. 

• File search and file operations, plus browser discovery. 

• Host, antivirus, Defender, domain, network, and installed-software discovery. 

• Execution of follow-on EXE, DLL, MSI, PowerShell, and related payloads. 

• DNS-over-HTTPS resolution through public resolvers. 

The reporting does not confirm credential theft, browser-cookie theft, exfiltration volume, named command-and-control domains, or victim-sector attribution. Those issues are reasonable incident-response checks, not confirmed outcomes.

Technical assessment:

Initial access and user execution:

• The phishing path begins when a recipient follows a billing-themed link to a counterfeit login flow. The ClickFix path begins with search visibility or discovery of a Custom GPT and ends with the user pasting a command into Windows Run. Attachment controls and macro protections may not apply when the user initiates the process manually. 

• Endpoint telemetry should correlate browser events with shortly following command execution. Relevant signals include browser- or Explorer-adjacent launches of cmd.exe, powershell.exe, mshta.exe, wscript.exe, cscript.exe, or related interpreters; downloads or scripts in user-writable paths; MSI installation; and a signed binary running from an unusual location. 

Payload delivery and post-exploitation:

• In the reported ClickFix chain, a pasted command downloaded a numerically named PowerShell script to %TEMP%. The script used obfuscation, rebuilt payload material in memory, and installed an MSI package. The MSI used signed executables and modified local DLLs to load the next stage. The decimal form of 96[.]62[.]224[.]81, 1614733393, is useful for hunting because controls that only inspect dotted-quad addresses can miss alternate representations. 

• Reported techniques included AMSI bypass behavior, ntdll.dll unhooking, .NET CLR hosting, anti-virtualization checks, encrypted or embedded payload material, DLL side-loading, Run-key persistence, and scheduled tasks. The strongest evidence is in process lineage, execution path, DLL load behavior, and persistence, rather than a vendor signature or domain reputation alone. 

Credential and session risk:

• The phishing case directly involved web-portal credential capture. Reporting does not say which factors were requested, whether MFA was bypassed, or whether captured credentials were used. The RAT's browser-discovery capability warrants review of browser profiles, active sessions, saved credentials, and enterprise SaaS access, but cookie theft and session-token theft were not confirmed. Revoke affected sessions when evidence supports it. 

Infrastructure and investigation:

• The phishing case used a suspicious sender, an intermediate redirect service, and a counterfeit login page. The Custom GPT case used trusted platforms to send users toward attacker-controlled content. The Australian case centered on non-human access to web services. Each requires a different investigative question: where credentials were collected, what the endpoint executed, or whether the target service correctly enforced authorization. 

• Enrich investigations with full redirect chains and referrers, sender authentication and reputation, proxy and DNS activity, browser history, process lineage, file provenance, DLL load paths, persistence telemetry, identity-provider events, and agent request or authorization logs. Treat reported indicators as historical pivots, then validate them against current context before blocking. 

Securonix ThreatWatch Summary:

Securonix ThreatWatch team assesses the activity as three distinct risk patterns, not a single campaign. The available reporting does not establish a shared actor, shared malware family, or shared infrastructure. OpenAI and ChatGPT branding is the common social-engineering theme, but the relevant analytic differences are the user action requested, the access boundary reached, and the endpoint or service behavior that followed. 

The phishing incident is a conventional credential-harvesting operation. Confidence is high that recipients were sent through a redirect path to a counterfeit OpenAI login flow. Confidence is low on any claim beyond that. Public reporting does not identify a malware payload, compromised accounts, the victim population, or subsequent use of captured credentials. Triage should therefore center on off-domain authentication, credential-submission destinations, and identity events after the click. 

The Custom GPT case is more operationally significant because it crossed from social engineering into endpoint execution. Security researchers confirmed the Custom GPT as the origin in two infections and associated at least 40 incidents with the Google Sites lure. That supports a high-confidence assessment of a ClickFix delivery chain, but not the claim that every related Google Sites incident originated through ChatGPT. The key behavioral sequence is browser navigation followed by user-driven command execution, temporary-path PowerShell and MSI activity, signed-binary DLL side-loading, and persistence. 

The Australian incident should be handled as an agent authorization and safeguard failure, not as branded phishing or evidence of a public ChatGPT compromise. Public disclosures confirm unauthorized access to non-public material during an internal evaluation, while also stating that individual health and client records were not accessed and that the broader Services Australia environment was not compromised. For organizations operating browser-capable agents, the lesson is to enforce authorization in the target service and to retain request-level evidence for non-human identities. 

For detection engineering, do not promote a brand name, a trusted hosting platform, or a code signature into a verdict. Use them as pivots, then correlate them with destination, execution context, persistence, and identity activity. This approach gives analysts a defensible basis for escalation while limiting false attribution and unnecessary blocking of legitimate services.

Detection and hunting opportunities:

Telemetry to retain:

• Endpoint: process names, full paths, command lines, parent and grandparent processes, file provenance, signer data, Mark-of-the-Web, DLL loads, script telemetry, persistence, and process-attributed network connections. 

• Web and DNS: complete URL and redirect chain, referrer, HTTP method and response, download MIME type, browser user agent, DNS provider, DNS-over-HTTPS endpoint, certificate metadata, passive DNS, and URL category. 

• Email: sender address and return path, display name, SPF, DKIM, DMARC, sending IP, URL-rewrite results, clicks, detonation outcomes, recipient population, and campaign timing. 

• Identity: new sign-ins, new device registration, recovery-method and MFA changes, OAuth consent, anomalous locations or browser fingerprints, and sessions that stay active after password reset. 

• Agent systems: agent identity, request headers, route authorization decisions, data-access logs, egress, and file-write activity. 

Sequence based detections:

• A ChatGPT- or OpenAI-themed email followed by a visit to a non-OpenAI login page. 

• A Custom GPT or Google Sites visit followed by cmd.exe, powershell.exe, mshta.exe, wscript.exe, or cscript.exe. 

• PowerShell followed by script creation in %TEMP%, %APPDATA%, %LOCALAPPDATA%, Downloads, Public, or another user-profile path. 

• Temporary MSI installation followed by a signed executable launched from a nonstandard user-writable directory. 

• A signed executable loading a nearby unsigned DLL, creating persistence, or opening outbound connections. 

• Suspicious browser or script activity followed by identity anomalies or sensitive-data access.

Defensive recommendations:

MITRE ATT&CK mapping:

Indicators of compromise:

The following are reported historical indicators. Validate current ownership, resolution, and reputation before blocking. Redirect and hosting-platform indicators require context and should not be used to block broad trusted services. 

Conclusion:

The cases in this advisory describe separate risks: credential phishing that imitates OpenAI sign-in flows, user-driven malware delivery through a Custom GPT and ClickFix page, and an agent authorization failure during an internal evaluation. The available evidence does not support a shared actor, shared malware family, or single compromise path. 

Investigations should start with the behavior around the trusted interface: an off-domain login request, a redirected verification page that asks for local execution, a signed binary running from a temporary location, or a non-human identity reaching a restricted route. Those sequences are more reliable than branding alone and help keep assessment of scope, attribution, and impact proportionate to the evidence.

References:

• Cofense, "Chatbot Conundrum: Phishing Attempts of OpenAI's ChatGPT" 

• Global News, "OpenAI agent accessed Australian government website" 

• Huntress, "ChatGPT Custom GPTs used in ClickFix RAT delivery" 

• OpenAI, "How we will do better for Australia" 

• Australian Government, September 24, 2026 press conference transcript 

• Australian Prime Minister transcript, September 24, 2026 

• Australian Institute of Health and Welfare statement 

• Microsoft Threat Intelligence, "AI brands as bait: How threat actors are using the AI hype in social engineering" 

• Zscaler ThreatLabz, "Black hat SEO poisoning search engine results with AI to distribute malware" 

• Microsoft Threat Intelligence, "Malicious AI assistant extensions harvest LLM chat histories" 

• OpenAI, "Disrupting malicious uses of AI: SweetSpecter"