TL;DR: Attackers are abusing shared ChatGPT and Claude content, plus sponsored malvertising and SEO poisoning, to deliver malware from pages hosted on trusted domains and to evade URL reputation checks before victims reach the payload, according to Push Security. The pattern shows that platform trust, not just malicious infrastructure, is now part of the attack surface.
At a glance
What this is: This is Push Security’s analysis of LLMShare attacks, where trusted AI chatbot pages are abused as malware delivery infrastructure.
Why it matters: It matters because identity and browser controls that rely on domain trust, URL reputation, or user recognition can miss attacks that begin on legitimate AI platform domains and end in credential theft or malware execution.
By the numbers:
- Search-based delivery is now the dominant channel for malware distribution, with ClickFix attacks reached via search results rather than email in 4 of 5 cases.
- Attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
👉 Read Push Security's analysis of LLMShare attacks in ChatGPT and Claude
Context
LLMShare attacks abuse shared AI chatbot content to make malware delivery look like ordinary platform usage. The immediate governance problem is that security controls often trust the domain first and inspect the destination second, which breaks when the attack begins inside a legitimate AI platform such as ChatGPT or Claude.
For IAM and security teams, this is a browser-layer and identity-trust problem as much as a phishing problem. The campaign blends trusted domains, malvertising, SEO poisoning, and conditional rendering, which means human judgement, URL categorisation, and perimeter reputation checks all become less reliable signals.
The article shows a typical abuse pattern for modern platform trust. A legitimate service is used as the host, the user is pulled in through search, and the malicious handoff happens after the trust decision has already been made.
Key questions
Q: What breaks when malware is delivered through shared AI chatbot pages?
A: Domain reputation stops being a reliable control when the attack begins on a legitimate platform page that later redirects or renders malicious content. Security tools may trust the top-level domain, while the user is manipulated into downloading or running malware. The failure is the assumption that a trusted host always contains trusted content.
Q: Why do shared chatbot pages create a phishing problem for IAM and browser security?
A: They create a trusted session boundary that can carry users from a reputable AI domain into an unsafe download flow. IAM and browser controls that depend on URL categorisation alone miss the provenance of the interaction, which means search, ads, and shared content become part of the attack chain.
Q: How do security teams detect abuse of legitimate AI platform content?
A: They need browser telemetry and content-aware inspection that can see the rendered page, the redirect chain, and the final payload delivery. Scanner-only checks are weak when the same URL shows benign content to bots and malicious content to real users. Detection must follow user behaviour, not just blocklists.
Q: How should organisations respond when search ads lead to AI platform malware delivery?
A: They should treat sponsored search results as a high-risk intake path and pair user awareness with browser controls that inspect downloads and execution prompts. The goal is to stop the trust chain before the user reaches the payload, not after the malware has already been staged.
Technical breakdown
Shared AI content as an attack host
Shared conversations and rendered pages on AI platforms create a distribution layer that looks legitimate because the top-level domain is legitimate. In this campaign, the malicious content is not hosted on an obviously bad site but inside shared ChatGPT and Claude resources, which means reputation systems may pass the page before the user reaches the redirect or download stage. The attacker is exploiting the gap between platform trust and content trust, then layering social engineering on top of that gap. That makes the initial URL look safe while the rendered content performs the harm.
Practical implication: Treat trusted AI platform URLs as content containers that still require inspection of the rendered behaviour, redirects, and downloads.
Rendered-page evasion and conditional delivery
Push describes a variant that uses ChatGPT code rendering to generate a fake service disruption page, then redirects users to a convincing download clone. This matters because the content is no longer a simple pasted prompt or text-only conversation, but a self-contained HTML and CSS page that can mimic a genuine product notice. The same infrastructure can show different content to scanners and real users, which is classic conditional rendering. That split undermines automated analysis because the benign view shown to bots is not the malicious view shown to victims.
Practical implication: Validate content as rendered in a real browser session, not just through scanners that may receive a benign response.
Search, malvertising, and platform trust chaining
The delivery chain combines search engine ads, SEO poisoning, and legitimate platform domains to compress user trust. A user searching for a common product term can be routed to a shared AI page on chatgpt.com or claude.ai, then through a download flow that appears normal. That chaining matters because each step individually looks plausible, and each step narrows the chance that a user or a control will stop the flow. In practice, the attack is not just phishing content. It is trust chaining across search, platform, and application layers.
Practical implication: Review browser controls and user training for chained trust decisions, not only for standalone phishing URLs.
Threat narrative
Attacker objective: The attacker wants the victim to run malware from a trusted-looking AI platform flow so credentials, data, or system access can be stolen.
- Entry occurs when victims are drawn in through sponsored malvertising ads and SEO poisoning that surface shared ChatGPT or Claude content on trusted platform domains.
- Credential or payload access happens when the user follows installation instructions or clicks a download button that leads to a malicious executable or infostealer.
- Impact follows when the payload runs on macOS or Windows systems and steals data, credentials, or session material for follow-on compromise.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- OmniGPT breach — OmniGPT breach exposed API keys, email addresses and chat logs.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Platform trust is becoming a security control failure when identity and content are conflated. This campaign works because chatgpt.com and claude.ai are treated as trusted by default, even when the content rendered inside them is malicious. That means the real control gap is not simply malware detection, but the assumption that a trusted domain implies trusted content. Practitioners should treat platform trust as conditional, not absolute.
LLMShare is the right name for a new trust-abuse pattern, not just a new phishing lure. The campaign is not only about fake download pages or fake support language. It is about distributing malicious intent through legitimate shared content infrastructure, which makes the attack resilient to basic reputation checks and easy to mutate across platforms. That is a browser and identity governance problem, because the user is being guided through a trusted session boundary into an untrusted action.
Identity programmes now need controls that understand where a user came from, not only where they clicked. The article shows that search, ads, and AI platform sharing can form a single malicious chain. The governance implication is that session context and content provenance matter more than the surface URL alone. Security teams should treat platform-hosted shared content as a distinct attack class in their browsing, detection, and awareness models.
The real failure mode is trust chaining across legitimate services. Attackers do not need to own the domain that starts the chain if they can ride a legitimate platform, a search ad, and a convincing download page in sequence. That changes the threat model for NHI-related browser security, because the attack surface now includes AI platform sharing features that can be abused like any other distribution channel. Practitioners should build policy around chained legitimacy, not single-point URL reputation.
From our research:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Our research also found that 80% of organisations report AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
- For a broader view of how these patterns become breach paths, see the 52 NHI breaches Report and compare where trust, access, and containment controls failed.
What this signals
LLMShare turns browser trust into a governance problem, not only a content-moderation problem. Teams that have built controls around domain allowlists will need to add browser-layer inspection and session context analysis, because the attack begins on a trusted platform and ends somewhere else. The right mental model is chained legitimacy, where each step looks acceptable in isolation but unsafe in sequence.
The named concept here is platform trust chaining: attackers use a legitimate service, a trusted search path, and a convincing follow-on page to move a victim through multiple benign-looking decisions. That changes how practitioners should think about phishing resilience, because the control objective is not simply to block bad domains, but to detect when legitimacy is being stitched together into an attack path.
With 80% of organisations already seeing AI agents act beyond intended scope, per AI Agents: The New Attack Surface report, the broader signal is that trusted software surfaces are increasingly being used as attack infrastructure. Security teams should prepare for more abuse of legitimate collaboration, automation, and content-sharing features across the browser stack.
For practitioners
- Inspect rendered content, not only the URL Add browser-side controls that evaluate the actual rendered page, redirects, and download behaviour inside trusted AI platform sessions. A safe-looking domain is not enough when the malicious action occurs after rendering.
- Block paste-and-run installation workflows Reduce exposure to terminal-based social engineering by restricting direct execution from browser content and by warning on command-copy patterns that originate from shared chatbot pages.
- Tune detections for shared-content abuse Create detections for shared ChatGPT and Claude content, especially pages that request downloads, show fake service notices, or redirect to non-platform domains.
- Review search-ad intake as a phishing path Treat sponsored search results as a primary delivery channel for browser-based malware, and pair that review with controls that flag common typos and lookalike AI platform queries.
- Use browser telemetry for trust-chain analysis Correlate the search term, landing page, shared-content URL, and final executable download so investigators can see the full path rather than only the final malicious domain.
Key takeaways
- Trusted AI platform domains can still serve malicious content, so URL reputation alone no longer captures the real attack surface.
- The campaign shows a measurable shift toward search-led delivery, where user trust is assembled across ads, shared content, and download prompts.
- Browser telemetry, rendered-content inspection, and chained-trust detection are now necessary to stop platform-abuse phishing before execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared platform content is abused as an identity-bearing delivery surface. |
| NIST CSF 2.0 | PR.AC-4 | The attack exploits weak trust decisions around access and content provenance. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Chained legitimacy defeats implicit trust in a single URL or service boundary. |
Apply continuous verification to browser sessions and content provenance, not just the destination domain.
Key terms
- LLMShare: LLMShare is a shared-content abuse pattern where attackers use legitimate AI chatbot sharing features to host or distribute malicious material. The domain may be trusted, but the content, redirect chain, or download target is not. It matters because the attack starts inside a service many controls already whitelist.
- Platform Trust Chaining: Platform trust chaining is the use of multiple legitimate services in sequence so each step looks safe on its own. A search ad, a shared AI page, and a download prompt can combine into a single attack path. The risk is that trust decisions are made per step, while the threat exists across the whole chain.
- Conditional Rendering: Conditional rendering is when the same URL shows different content to different visitors, such as a benign page for scanners and a malicious page for real users. Attackers use it to evade automated analysis and reputation systems. In browser security, it means the page a tool sees may not be the page a user gets.
- Browser-Layer Telemetry: Browser-layer telemetry is the visibility collected from the user’s browser session, including page transitions, downloads, prompts, and execution cues. It gives security teams context that perimeter tools often miss. For attacks that begin on trusted platforms, it is often the only place where the full trust chain is visible.
Deepen your knowledge
Shared AI platform abuse and browser-layer phishing are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with trusted-domain abuse, it is worth exploring.
This post draws on content published by Push Security: LLMShare attacks abusing ChatGPT and Claude shared content to deliver malware. Read the original.
Published by the NHIMG editorial team on 2026-05-29.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org