Implicit trust is one of the most useful tools in a threat actor’s arsenal. Organizations spend significant resources identifying suspicious domains, blocking newly registered websites, and training users to recognize phishing attempts. These defenses support a simple assumption: Unfamiliar domains are risky and trusted domains are safe.
The LLMShare campaign exploited that assumption. Instead of directing victims to attacker-controlled infrastructure, attackers exploited ChatGPT’s conversation sharing feature, using it to distribute malicious sites through legitimate chatgpt.com URLs.
These links did not raise suspicion because they were hosted on a recognized domain that organizations increasingly trust for routine business operations. The result was a campaign that bypassed many of the usual flags that users and security teams are trained to look for.
The LLMShare campaign
LLMShare is a malvertising campaign discovered by Push Security that abuses Google Ads to direct users searching for ChatGPT to a malicious page hosted on chatgpt.com. Threat actors purchase ads for the “ChatGPT” keyword, which allows the attack to be delivered through a legitimate OpenAI domain. On May 29, 2026, Push Security confirmed instances of the campaign across their customer environments.
A Claude variant used shared Claude.ai conversations, disguised as installation guides with fake "Apple Support" branding, that walked users through opening a terminal and pasting a curl command that downloaded and executed an infostealer. The presence of both variants suggests attackers were experimenting with multiple platforms to maximize reach and effectiveness.
The attack chain
The campaign started with a paid search ad. Attackers purchased Google Ads targeting terms like "chatgpt," "chatgpt free," "chat gpt," and common typos including "chatgo," "chatgot," and "cvhatgpt." Clicking the ad took the victim to a legitimate chatgpt.com/s/ URL, a shared content link from OpenAI. Because the domain belongs to OpenAI, reputation-based controls and domain-focused rules are less likely to identify the content as suspicious.
The page displayed a fake outage notice reading "We're experiencing high traffic right now. Our website is temporarily unavailable due to a large number of users."
The download button prompted users to install a desktop app instead. Push Security noted that the page also included "Show code" and "Remix with ChatGPT" controls, revealing that the fake outage notice was generated from custom HTML and CSS rendered by a ChatGPT prompt. It was a web page inside a web page, hosted on a domain that carries implicit trust.
Clicking download redirected the user to openew[.]app. This site presented a convincing imitation of OpenAI's download portal, offering applications for both macOS and Windows.
The infrastructure was also designed to frustrate analysis. When security tools like URLScan visited the site, they were redirected to a harmless website for a legitimate company instead of the fake download page.
Real users saw the malicious content while automated scanners saw nothing of interest. This cloaking technique is a well-established evasion pattern in the malvertising ecosystem that makes the infrastructure harder to identify and take down.
The payload
The malicious executables distributed through openew[.]app are flagged by multiple security engines on VirusTotal. Malwarebytes documented a concurrent fake ChatGPT download campaign in late May 2026. They identified the macOS payload as Odyssey Stealer, a fork of Atomic macOS Stealer targeting browser credentials, cryptocurrency wallet data, and active session tokens.
Both a Windows and macOS variant were distributed. Offering cross-platform payloads reflects the campaign's design as a numbers game: sponsored search ads targeting ChatGPT-related queries reach a broad population, and the combination of both OS variants and Google Ads for distribution maximizes how wide a net the attackers could cast.
The assumption behind the LLMShare campaign
The LLMShare campaign succeeds because of a common form of implicit trust that exists in most environments.
The domain is at the core of the attack. Chatgpt.com is not a newly registered domain, nor is it flagged as suspicious. This means there is no signal for web filtering tools that operate on reputation or blocklists because the malicious content lives at a legitimate chatgpt.com/s/ URL.
The delivery chain exploits the common security assumption that the trustworthiness of the domain reflects the trustworthiness of content hosted on it. In this scenario, the domain was legitimate, but the content directed users toward malicious outcomes.
How a Zero Trust approach addresses this risk
LLMShare is a useful example of why Zero Trust focuses on what can execute, not just where it originates. Reputation-based controls failed because the origin was legitimate. Controls that operate on execution continue to enforce policy regardless of where the file originated.
Allowlisting operates on a deny-by-default basis. If an application isn’t approved, it cannot run. If a user downloaded the LLMShare installer and attempted to execute, the execution would be blocked because the file hasn’t been approved, regardless of what domain it appeared to come from.
The user can submit a request to review. An administrator who sees a request to run an unsigned executable downloaded from an unknown site has a concrete opportunity to identify the threat before it executes.
In the event the file was somehow approved or misidentified as a legitimate installer, Ringfencing™ limits what the application can do after it runs. It does not rely on correctly identifying the payload in advance. Access to other processes, files, and system resources is restricted by default, reducing the potential impact of malicious activity after execution.
Web Content Control is most effective for containment control at the second stage of the attack, blocking access to attacker-controlled infrastructure. In environments that restrict access to approved business websites, a destination like openew[.]app may represent an opportunity for policy enforcement.
Blocking access to unapproved or unclassified sites by default would prevent the user from reaching the fake download portal entirely.
Finally, while Privileged Access Management does not directly prevent LLMShare's initial payload from executing, it limits what an attacker can do after a successful compromise.
Most modern infostealers can operate without administrator privileges, but restricting elevation and removing unnecessary local administrator rights reduces opportunities for persistence, lateral movement, and post-compromise escalation. This reduces the attacker's ability to expand access beyond the initially compromised user.
The broader pattern
The LLMShare campaign is part of a broader trend in which attackers abuse trusted AI platforms as delivery mechanisms, hosting platforms, and intermediaries. Earlier campaigns demonstrated prompt injection phishing techniques that could redirect users through ChatGPT, and DNS exfiltration methods that used the platform's network egress to leak data.
LLMShare represents the next wave: AI products as a hosting platform for traditional malvertising.
The throughline is the same. Techniques that once required purpose-built phishing infrastructure can now run on the back of legitimate, high-reputation domains. AI platforms are now sufficiently trusted by users, by web filters, and by ad networks. As these services become embedded in everyday workflows, the trust associated with them has also become a target.
Zero Trust doesn't predict which legitimate platform an attacker will abuse next. It enforces controls at the point where an attack has to produce a result, such as execution, privilege use, and credential access, requiring explicit approval at each of those steps.
LLMShare succeeded by exploiting implicit trust, and Zero Trust removes implicit trust from the equation.
The malicious link was trusted. The downloaded application was not. The attack still had to execute code, access credentials, and interact with the operating system. Zero Trust controls remain effective regardless of how trustworthy the delivery mechanism appears.
ABOUT THE AUTHOR
Andrea Pomaranski is a Special Projects IT Engineer at ThreatLocker, working on R&D‑focused technical initiatives across enterprise systems, identity infrastructure, and platform integrations. She studied Computer Science at the University of Florida and began her career in IT before moving into software development, supporting mission‑critical systems in highly regulated production environments. A longtime CTF competitor, Andrea honed her security skills through university, independent study, and past workplaces, including as an active member of UF’s Security and Information Technology (SIT) organization. Outside of work, she maintains a hands‑on homelab where she experiments with hardware and operating systems. She brings a builder’s mindset and a deep interest in how vulnerabilities emerge in real‑world systems to product research and technical investigation.
