AI assistants are becoming part of the software supply chain. Developers ask them for documentation links, API endpoints, install commands, webhook URLs, registry names, and integration examples. Agentic systems can go one step further and fetch those URLs or wire them into automation without a human checking every reference.
That makes a new class of hallucination more dangerous than a bad answer. In Unit 42’s research on phantom squatting, large language models repeatedly generated plausible but nonexistent domains for real brands and services. Some of those domains were later registered and weaponized by attackers.
The uncomfortable takeaway: an LLM-generated URL can become an attacker-controlled dependency.
What is phantom squatting?
Phantom squatting is the domain-level cousin of slopsquatting. Slopsquatting describes an attacker registering package names that LLMs hallucinate. Phantom squatting applies the same idea to web infrastructure: domains, subdomains, portals, API hosts, webhook endpoints, and documentation URLs.
A model might confidently produce something like:
https://api.example-build-notifier.com/v1/eventsIf that host does not exist, an attacker can register it later. The next developer, AI agent, or automated workflow that trusts the same hallucinated output may send traffic, credentials, telemetry, or code-fetch requests to attacker-controlled infrastructure.
Unit 42 describes this as a supply-chain risk because LLMs are no longer just search boxes. They are becoming trusted intermediaries in development workflows. Their output can be copied into source code, CI/CD configuration, internal documentation, and agentic automation.
What Unit 42 found
Unit 42 analyzed hallucinated URL generation across 913 global brands. Their research executed 685,339 prompts across two LLM families and three temperature configurations, producing 2.1 million unique URLs.
The headline numbers are worth paying attention to:
- 13,229 generated URLs were confirmed malicious at the time of analysis.
- 41,313 additional URLs were categorized as high risk.
- 809,455 generated URLs resolved to nonexistent destinations.
- Those nonexistent URLs collapsed into roughly 250,000 registerable phantom domains.
The researchers also found that LLMs can generate the same false domains predictably. They describe “thermal hallucination persistence” as domains that keep appearing even at low-temperature, more deterministic settings. They also observed cross-model consensus, where different models converged on the same fictitious domain.
That predictability matters. If defenders can discover likely hallucinations, attackers can too.
The attack path
Phantom squatting does not need a traditional phishing email. The lure can be the AI assistant itself.
A practical attack path looks like this:
- An attacker probes models for plausible but nonexistent domains related to a target brand or service.
- They register the most useful hallucinated domains.
- They deploy phishing pages, fake documentation, malicious installers, or API lookalikes.
- A developer or autonomous agent asks an LLM for help and receives the hallucinated domain as a confident answer.
- The user or agent follows the URL because it came from a trusted tool already embedded in the workflow.
That is the structural difference from classic phishing. The fake domain is not necessarily delivered through email, ads, or a compromised website. It can be delivered by a model completing a plausible pattern.
Why reputation-based defenses struggle
New phantom domains start clean. At registration time they often have:
- no historical abuse reports,
- no blocklist entries,
- no reputation score,
- no long-lived telemetry,
- no obvious connection to previous malicious infrastructure.
Unit 42 calls this a zero-reputation bypass. Traditional URL and DNS defenses often need observation time before they classify a domain as risky. Phantom squatting compresses the useful window for defenders because the first meaningful traffic can come from a user or agent that already trusts the AI-generated answer.
Attackers can make that window worse with cloaking, CAPTCHA gates, redirects, or content that looks benign to automated crawlers.
Real-world examples from the research
Unit 42 did not present phantom squatting as only theoretical. Their monitoring found real registrations after their pipeline had identified high-risk hallucinated domains.
In one case, their system generated hallucinated URLs for a domain resembling a national postal service e-commerce marketplace. Twenty-three days later, an attacker registered the domain and deployed a phishing kit. Unit 42 says the kit, named Montana Empire, included a brand clone, PHP backend, payment and identity-data capture, Telegram-based command and control, and an operator panel for one-time-password relay.
In another case, their pipeline identified a hallucinated postal-service-themed domain 51 days before an attacker registered it. The registered site served a fake mobile app landing page and a malicious Android APK.
The key lesson is not the specific brands, which Unit 42 redacted. It is the timeline. Predictable hallucinations can create lead time for both defenders and attackers.
Why developers should care
Software teams are already using AI in places where URL trust matters:
- generating integration code,
- finding API documentation,
- writing CI/CD snippets,
- locating package registries,
- creating webhook configuration,
- building internal runbooks,
- letting agents fetch resources on their behalf.
Every one of those workflows can turn a hallucinated URL into a real dependency. The risk increases when generated output is pasted directly into production code or CI without verification.
For agentic systems, the blast radius can be larger. A human who lands on a phishing page still has to take the next action. An autonomous agent might fetch a URL, parse a response, execute an instruction, or copy an endpoint into configuration without the same pause.
How to reduce phantom squatting risk
Start by treating AI-generated infrastructure references as untrusted until verified. A generated URL should not be accepted just because it is plausible.
Practical controls include:
- Verify domains against official vendor documentation before adding them to code or CI.
- Prefer links from package metadata, signed releases, official docs, or known registries over model-generated URLs.
- Review new domains in pull requests, especially in install scripts, CI workflows, deployment config, and webhook code.
- Block agents from fetching arbitrary internet resources without allowlists or policy checks.
- Log and review outbound requests from CI/CD and autonomous agents.
- Use DNS and URL controls that flag newly registered domains, parked domains, and lookalike infrastructure.
- Keep dependency inventories that include not only packages, but also CI/CD actions, container images, and external service endpoints.
For high-risk automation, consider a simple policy: AI can suggest URLs, but humans or policy gates must verify the authority of those URLs before they become executable infrastructure.
Where SBOMs fit — and where they do not
An SBOM will not tell you whether an AI-generated webhook endpoint is fake. Phantom squatting lives partly outside the package dependency graph.
But SBOMs and inventory still help with the surrounding discipline. They force teams to ask what their systems depend on, where artifacts come from, and which build steps introduce external trust. The same mindset should extend to AI-assisted development:
- What did the model suggest?
- Which URLs, packages, registries, and actions entered the repo?
- Which of those references are authoritative?
- Which workflows can fetch or execute content from them?
Phantom squatting is a reminder that supply-chain visibility cannot stop at application packages. The development environment, CI/CD pipeline, AI assistant, and agentic workflow are part of the chain too.
boring.tools helps teams build practical software-supply-chain visibility across projects. Generate SBOMs, upload CI/CD artifacts, and keep dependency context connected to the projects that ship your software.