The malware was hosted on chatgpt.com, and that was the point

You are searching for ChatGPT. You type it into Google, the way a few hundred million people do every day. The first result is an ad. The ad says ChatGPT, links to ChatGPT, and lands you on a page whose address genuinely begins with chatgpt.com. So far nothing is wrong. Nothing looks wrong because nothing visibly is wrong: you are on OpenAI's real domain.

Then the page tells you the website is down. "We're experiencing high traffic right now," it says. "Our website is temporarily unavailable due to a large number of users." It suggests you download the desktop app instead. There is a button. You are on chatgpt.com, the service is clearly having a moment, and a desktop app is a reasonable thing to want. You click.

That is the whole trick, and security researchers at Push Security documented it at the end of May, in a campaign they call LLMShare. It is worth understanding in detail, because it is a clean example of an attack pattern that is going to keep showing up: not breaking into a trusted service, but renting its reputation.

The page really was on chatgpt.com.

ChatGPT, like most large AI products, lets you share a conversation. You click share, you get a link under chatgpt.com/s/, and anyone with the link sees a rendered copy of the exchange. Useful, ordinary, everywhere.

The catch is what "rendered" means. These shared pages can include the model's output, and that output can contain HTML and CSS — the same ingredients any web page is made of. So instead of sharing a conversation, the attacker shares a "conversation" whose contents are a hand-built fake: a pixel-faithful OpenAI outage notice, complete with the right fonts, the right blue, the right tone. According to the research, the giveaway is subtle — the shared view still carries ChatGPT's own "Show code" and "Remix" controls, the tell that the "outage page" is just custom markup someone authored.

The point of doing it this way is the URL. The malware lure does not live on chatgpt-downloads-official.biz. It lives on chatgpt.com, a domain with a spotless reputation, a valid certificate, and a place in the muscle memory of everyone who has ever used the product. Every defense that works by asking "is this a domain we trust?" answers yes, because the honest answer is yes.

The download server lies to the scanner.

Click the download button on the fake outage page and you are sent off chatgpt.com to openew[.]app, a site dressed up as OpenAI's official download portal. This is where the second piece of cloaking lives.

Cloaking means showing different content to different visitors. The attacker's server looks at who is asking. If the request smells like an automated security scanner — and a great deal of the internet's safety relies on services like URLScan crawling URLs and rendering them in a sandbox — the server serves something innocent. In this case, according to the research, scanners visiting the URL were shown a harmless augmented-reality / virtual-reality company website. Clean. Nothing to flag. If instead the request smells like a real human who followed the lure, the server serves the malware.

So the automated verdict on openew[.]app is "benign," and the human verdict — the one that matters — never gets a second opinion. The download is offered for both macOS and Windows, because the attacker does not know or care which you are on; they want both audiences. (The Windows sample even checks whether it is running inside a virtual machine before it proceeds, a common move to dodge analysis sandboxes — hold that thought.)

None of this is exotic. It is the same family of tradecraft as the malvertising and SEO-poisoning chains we have written about before. What makes LLMShare worth a post is the quality of the trust it borrows. The same researchers say the pattern is not unique to ChatGPT: they have seen the share/render features of other AI products — Claude's Artifacts, shared Grok conversations — pressed into the same service. Any product that lets a stranger publish rendered HTML under your brand's domain has, without meaning to, become a hosting provider for whoever wants to abuse that brand.

Why every checkpoint waves it through.

Walk back through the chain and notice that each defensive instinct a careful user has is satisfied by design:

This is the uncomfortable part. The standard advice — inspect the URL, trust scanned links, watch for sloppy phishing, be wary of weird domains — is good advice, and this campaign sails straight through all of it. When the trusted-domain signal is the attack, the signal stops helping. You cannot tell a careful person to be more careful about a page that passes every check they know.

So the interesting question is not "how could the user have spotted it." For most users, on most days, they could not. The interesting question is: what happens at the moment the binary actually runs?

The whole thing happens in one tab.

Look at the chain again and notice where it lives. The ad opens in the browser. The chatgpt.com page renders in the browser. The fake outage notice is a web page in the browser. The redirect happens in the browser. The download is initiated by the browser. The only step that leaves the browser is the last one — when the downloaded installer is run and starts doing whatever it was built to do, on the computer, with the user's files and permissions.

That last hop is the whole game. Everything before it is staging. The attacker spent real effort on the ad budget, the convincing page, the cloaking infrastructure — all of it in service of getting one binary to execute on one machine. If the binary executes somewhere that contains nothing of yours, the attacker spent all of that to compromise an empty room.

This is the geometry Bromure changes. In Bromure, the browser does not run on your computer in the ordinary sense. Each tab runs inside a disposable Linux virtual machine — a sealed guest with its own filesystem, started from a clean image, that has no view of your files, your keychain, your other tabs, or your local network. The web page, the renderer, the JavaScript, the download, and the first run of the downloaded program all happen inside that guest. When you close the window, the guest and everything in it is destroyed.

Notice what the trusted-domain signal buys the attacker here: nothing. The whole campaign is engineered to defeat the question "do I trust this page." Bromure does not ask that question. It does not need to know whether chatgpt.com is trustworthy, because it does not let the contents of any page — trusted or not — reach past the guest VM in the first place. The page could be the most legitimate page on the internet and the containment would be identical. Trust is simply not the load that the architecture bears.

The same goes for the scanner-cloaking trick. The attacker worked hard to make openew[.]app look benign to automated analysis. Bromure does not depend on that analysis being right. Even if the download host is scored as perfectly clean and the file is waved through, the file arrives in a disposable guest. And recall the Windows sample that checks whether it is running in a virtual machine before unpacking: that anti-analysis reflex now works against the attacker, not for them — the malware that refuses to run in a VM refuses to run in the one place it managed to land.

What this does not solve.

Isolation contains execution. It does not edit reality. Two honest gaps are worth naming.

First, Bromure does not stop you from being convinced. If the page talks you into typing your real OpenAI password into a real login form, or into carrying a file out of the guest and onto your Mac and running it there yourself, the isolation has been routed around by your own hands. The protection is that the staging and the first run of the malware are contained — not that social engineering becomes impossible. A page that is this good at impersonation is still a page worth being suspicious of; the architecture lowers the stakes of being fooled, it does not raise your odds of spotting the fool.

Second, this is fundamentally a browser-delivered attack, and that is exactly why containment is decisive. The whole chain — ad, page, redirect, download, first execution — lives in the tab. There is no separate native app to compromise, no email client, no second program the user trusts. Decapitate the chain at the point where the binary runs and there is nothing left downstream. When the attack starts and ends in the browser, a browser that absorbs the hit is the right place to stand.

The next one will be on a domain you trust too.

LLMShare is not really a story about ChatGPT. It is a story about a technique: take a service people trust, find the corner of it that lets a stranger publish rendered HTML under its name, and use that corner to host the lure. ChatGPT today; the researchers already see Claude and Grok used the same way; tomorrow it will be whatever product is both popular and generous with what it will render on your behalf.

You cannot win this by getting better at spotting bad domains, because the whole move is to use good ones. You win it by making the address bar irrelevant to your safety — by arranging things so that the worst thing a page can do, no matter whose logo is on it, is fill a disposable room that you empty by closing a window.

That is what Bromure is for. Install it, make it your default, and let the borrowed trust buy the attacker nothing.