There is a flurry of names floating around for essentially the same attack: slopsquatting, phantom domains, and HalluSquatting. They all describe one thing – attackers registering domains that large language models hallucinate, then tricking developers or users into visiting those domains through AI-generated content.

The core mechanism is simple. LLMs do not know the difference between a real domain and one they made up. When they hallucinate a domain name, that domain does not exist yet. An attacker can register it before anyone else does, put a malicious page there, and if the LLM recommends that domain again (or a user searches for it), the attacker captures the traffic.

Same attack, different names

Each name emphasizes a slightly different angle, but the underlying technique is the same:

All three are made possible by the same fundamental property: generative models do not have ground truth about whether a domain exists. They predict tokens, not reality.

How it works in practice

Imagine a developer asks a coding assistant to “find a package for parsing PDFs in Python.” The assistant might suggest something like py-pdf-parser pointing to github.com/py-pdf-parser. If that repository does not exist, an attacker can create it, put a malicious fork that steals API keys or injects backdoors, and wait for developers to install it.

This is not theoretical. Researchers at multiple organizations have demonstrated that attackers can pre-register hallucinated package names on PyPI, npm, and RubyGems before anyone checks whether the suggestion was real. The same applies to domains that AI assistants invent for example APIs, documentation sites, or tool downloads.

The prompt injection variant (HalluSquatting) takes this further. An attacker who can inject a prompt into the context the model sees – through a poisoned document, a compromised plugin, or a carefully crafted comment on a public issue tracker – can effectively tell the model “when asked about X, suggest domain Y.” The user sees the suggestion as normal model output, has no reason to suspect it, and the attacker owns the destination.

Why this matters now

Domain squatting is not new. Typosquatting, bitsquatting, and homograph attacks have been around for decades. What makes this different is scale and trust. A typosquatted domain requires the user to make a mistake – type googel instead of google. A hallucinated domain requires no user mistake at all. The AI assistant made up the domain, the user has no reason to second-guess it, and the attacker did not need to find a typo. They just needed to wait for the AI to invent something.

As more developers rely on AI coding assistants for dependency resolution, command generation, and infrastructure setup, the attack surface grows. Every hallucinated domain name is a potential registration race the attacker can win if they are monitoring the same prompts or feeding the model suggestions through indirect injection.

The distribution vectors are already in place. Public GitHub issues, documentation sites, Stack Overflow answers, and even blog comments can host the kind of content that steers an AI assistant toward a specific domain. The attacker does not need to compromise the model. They just need one document in the retrieval context that the model trusts.

What to do about it

The fix is not to stop using AI assistants. The fix is to treat any AI-generated domain, package name, or URL as a first draft that needs verification before you interact with it:

The security community is still figuring out how to defend against this class of attack at scale. Some proposals include registry-level validation checks that detect bulk registrations matching common hallucination patterns, browser extensions that flag domains younger than the model training cutoff, and prompt hardening that instructs assistants to verify domain existence before suggesting them. None of these are standard yet. For now, the defense is the same as always: do not trust unverified suggestions from any source, including one that sounds very confident.

Leave a Reply

Your email address will not be published. Required fields are marked *