350,000 Files Cite Two Domains That Show Scams Only to Macs — and Every Static Check Cleared Them

2026-09-28 Agent & Supply Chain Security by al-ice.ai Editorial

Manifold Security published the second part of its placeholder-domain research on 24 September 2026, and the numbers reframe the problem. Part I covered third-party[.]com — a documentation stand-in hard-coded across 1,700+ repositories that was turned into a Windows ClickFix lure. Measured by citations, that turns out to be the small case. Researcher Cody Nash swept for every other placeholder domain of the same class that is not IANA-reserved and found thirteen more, cited by 1,536 agent skills. Two of them are serving scams right now.

yoursite[.]com and your-domain[.]com sit on parking services, which is why they carry advertising at all. Manifold rendered the pair twenty-four times in a real browser. Twenty renders ended on a parking page or an ordinary ads article; one hit a Cloudflare challenge; one failed to load. Two ended on fraud — a counterfeit "MacOS Security Center" claiming four viruses and selling a discounted fake McAfee renewal, and a counterfeit ZDFheute news article built around a fabricated talk-show confrontation between two German politicians, selling an investment scheme. Both hits were on macOS. None of the eight Windows or Linux renders reached either one. Between them, these two domains appear in over 350,000 GitHub files and roughly 350 skills in Manifold's corpus.

The finding that should change practice is not the scam content. It is that every static check cleared all thirteen domains. Manifold ran registry RDAP for ownership and recent changes of control, blocklist history, twenty-one years of archived page sizes, and a 52-request probe varying the User-Agent across Windows, macOS, and Linux. All clean. They were clean because the lure is not hosted on these domains at all — you fetch the parking page, and the redirect to the scam fires after that page's JavaScript runs, one hop away on another host. A text-only fetch never sees it, however many User-Agents you send.

The detection problem is structural, not a coverage gap

Three properties here defeat the checks most organizations actually run, and they compound.

The lure is downstream of JavaScript. Any scanner that issues an HTTP GET and inspects the response body is looking at a parking page. Reaching the scam requires executing the page and following the ad chain — which means a real browser, not a fetch with a spoofed header. Manifold's own 52-request UA sweep is the control experiment: varying the User-Agent on a static fetch does nothing, because the decision point is in code that a static fetch never runs.

The targeting is probabilistic. Two hits in sixteen macOS renders. A single check clears the domain almost every time, and the destination changes between visits. This is not a domain that is malicious in the way a blocklist models malice — it is an on-ramp into a general malvertising market, where what a visitor gets depends on who is buying that day. Both parking pages load the same ad-redirect account, and between them Manifold reached tech-support scareware, a counterfeit BBC article, and a counterfeit ZDF article through different redirectors and different ad networks. One campaign it is not.

Blocklists are weaker than their reputation. Manifold notes a public blocklist added third-party[.]com on 7 July and dropped it ten days later — while the lure was live throughout. That is the expected outcome when a page serves its payload to one operating system and a decoy to everyone else: a scanner fingerprinted as one platform sees nothing from the other, concludes the domain is clean, and removes it. The delisting is not an error in the blocklist so much as an accurate report of what that scanner saw.

There is a fourth property that makes blocking harder still. The scareware page runs five screens ending in an expiry notice with a countdown, and its exit function ships as a single line of obfuscated JavaScript. Deobfuscated, it fires a one-pixel tracking image and then navigates — whether or not the pixel loads, and clearing the page's own exit guard on the way. Crucially, the destination is assembled at runtime from the page's own query string via getURLParameter("domain"), with the https:// and path fragments hidden in an obfuscated lookup table. No hostname appears anywhere in the code. Scanning the page yields nothing to block, and the operator can rotate routing domains without editing the page at all.

Manifold followed one exit: a day-old click ID led through the router prosecutoralliance[.]com to an affiliate click tracker, fastdltrk[.]com, and from there to a genuine McAfee landing page carrying the affiliate parameters that credit a sale. The business model is lead generation — fake virus warnings funneling people into real subscriptions for commission. Manifold is careful here and so are we: that is one observation, from Germany, and the same router feeds other scam pages, so other visitors may be sent elsewhere. Nothing suggests McAfee is a party to it; the abuse is of its affiliate program. But the defensive implication is sharp: a scanner that follows the chain to its end lands on a legitimate company's website, so every detection signal at the terminus points somewhere entirely innocent.

The distribution channel is the part that is unique to this class

Manifold checked urlscan.io's public index for other entrances to the same scam page in the week to 23 September and found five besides their own — all bank and parcel lookalikes, including scotiabank-secure[.]info, fedexsupportverification[.]com, and lnterac-transfer-login[.]com (a lowercase L standing in for the I in Interac). At least four arrived carrying the same router in the query string. The redirector above it handled 95 different entry domains across a three-day sample. These are floors, not totals — the index holds only what somebody thought suspicious enough to submit.

What separates the placeholder domain from those five is marketing cost. A lookalike domain has to be pushed in front of a victim: phishing mail, paid ads, search placement. The placeholder needs none of that. It arrives inside documentation people already trust, copied into hundreds of thousands of files. It is the one entrance with a distribution channel the operator did not have to build.

And the projects citing these domains are victims of a change, not parties to it. Of the affected skills Manifold could date from git history, the third-party[.]com lines went in on 2026-01-19 and 2026-02-28 — months before the domain began serving its lure, which it has done since at least June. Those citations were correct when written. Control changed hands afterward, and nothing in the skill had to change for the meaning of the line to invert. One of those skills has since been forked 1,089 times, and every copy carries it.

The citation table is uncomfortable reading for security practitioners specifically. Two of the most-starred repositories citing yoursite[.]com are security projects: pwnlandia/mhn, the Modern Honey Network, and RoseSecurity/Red-Teaming-TTPs, a red-team reference. Security tooling is citing a domain whose advertising chain also serves scareware. The broader table is a reminder of scale — foo.com appears in 333,312 GitHub files, yourdomain.com in 195,072, yoursite[.]com in ~185k, your-domain[.]com in ~174k. Eleven of the fourteen tracked domains were clean when Manifold looked. All fourteen are purchasable.

Why agents are the exposed population

Manifold makes a restrained claim and it is the right one: these pages are built for a person at a browser, and a discerning person usually evades them. The more exposed reader is an agent — because agents fetch and act on the documentation these citations live in. The report explicitly does not test whether models fall for a fake renewal page, and flags that a sophisticated model may well refuse; the population it expects to be more susceptible is agents on cheaper, smaller models tuned for speed.

That restraint is worth preserving, but the structural point stands without any claim about model gullibility. An agent that resolves a documented example URL at runtime is making a network request to a host somebody else controls, inside a trust context the user granted to the tool. That is the same shape as a package that ships with valid provenance and fetches its payload later, and the same shape Manifold found in its earlier work on curl | bash install instructions: documentation pointing an agent at a remote resource that nobody re-checks at the moment it runs. The CIS MCP benchmark's egress recommendations exist for exactly this — the domain in the example was dormant when it was written, and dormancy is not a property that persists.

What to do

Grep your own corpus for the fourteen. Search skills, MCP server docs, READMEs, and agent instruction files for yoursite.com, your-domain.com, third-party.com, foo.com, yourdomain.com, acme.com, mysite.com, myapp.com, your-app.com, yourapp.com, your-site.com, company.com, mycompany.com, and vendor.com. Match on the scheme separator so you catch URLs rather than prose.
Replace them with RFC 2606 reserved names. example.com, example.org, and example.net are reserved by IANA and can never be registered by anyone. Every domain in the table above can be bought. This is a one-line fix per occurrence with no downside.
Check forks and vendored copies, not just your source of truth. The 1,089-fork example is the point: a corrected upstream does not correct the copies, and agents install from wherever they install from.
Replace "is it on a blocklist" with "who owns it now, and what does its ad chain do today." Manifold's framing is exact. Ownership and current behavior are the questions; blocklist membership answers neither, as the ten-day listing demonstrated.
If you must validate domains, render them. Headless-browser rendering on the operating systems your readers actually run, repeated — not a single fetch with a spoofed User-Agent. One check clears these domains almost every time, so a single clean result is close to meaningless.
Constrain agent egress by policy rather than by reputation. An agent following documentation should not be able to reach arbitrary hosts. Allow-list the destinations a tool legitimately needs; the placeholder problem disappears entirely when an unknown host is simply unreachable.
Treat documentation as executable supply chain. Every URL an agent may resolve is a dependency with no version pin and no integrity check. It deserves the same review as a package reference — and the same alarm when its owner changes.

The durable lesson is about time. A code dependency is pinned; a cited hostname is not. The skills in this report were written correctly, reviewed successfully, and forked a thousand times, and then someone bought the domain and the same unchanged line started pointing at a fake virus warning. Nothing in the repository moved. Audit the domains you cite on ownership and live behavior, or stop citing domains you do not control — and in documentation an agent will read, prefer the second.

Sources: