Phantom squatting: the new IA-driven phishing threat that invents non-existent domains

The big language models are generating a new attack vector that deserves immediate attention: they invent plausible web addresses that do not exist, and the criminals buy them on the flight to turn them into phishing traps. Palo Alto Networks Unit 42 has baptized that tactic as phantom squatting and has found it already operating in real conditions, with cases where the models suggested non-existing domains and, weeks later, those same names were registered and used to steal financial data and credentials.

The central danger is the automatic transfer of trust: developers, assistants and automated agents tend to treat a link that gives them a model as if it were true. When the domain did not exist at the time of the generation, who first records it inherits that trust without the need for mass mail campaigns or malicious ads; it is enough for a reliable tool to redirect the victim. Unit 42 submitted to models questions about hundreds of brands and obtained millions of links, many of which were consistent inventions between models and adjustments, making them predictable for an attacker.

That these domains do not come from direct memories of training but from the statistical patterns of the model is particularly disturbing: it means that the repeated appearance of the same fictitious direction is not a random error but a reproducible behavior. This consistency turns the threat into something usable on a large scale: an attacker who tracks the exits of a model or who knows the generation patterns can anticipate and record domains before anyone.

The ephemeral nature of a newly registered domain plays in favor of the attacker. The services of reputation, blocklists and threat feeds need evidence of abuse to react; a newly created domain has no history or signs and therefore goes unnoticed until it does harm. In the incidents documented by Unit 42, domains predicted by the models were converted into exact clones of shops and banks, with phishing kits that captured cards and documents, and even operations that distributed malicious applications for Android.

This is not an isolated phenomenon: there is a history in development ecosystems where code-generating models propose names of packages that do not exist and attackers record those names to distribute malware or backdoors - a vector known as slopsquatting -. The lesson is the same when the model output becomes operational input: if it is acted without verification, the temporary reaction window is short and expensive.

For security companies and equipment, defensive options exist and must be applied urgently. It is possible to predictively map the directions a model will tend to invent and monitor its record, as well as to establish early alerts against new records that match those patterns. It is also effective to impose controls on agents and assistants so that do not open or download content from links generated by models without human or prior automated validation and use real-time reputation checks (e.g. with safe navigation APIs and DNS / WHOIS consultations) before allowing sensitive interactions.

For individual users and developers the most practical rule is clear: do not blindly trust a link provided by an IA. Confirm that the domain corresponds to the official website before entering passwords or keys, review TLS certificates, and activate good practices such as multifactor authentication and allowlist policies in automated agents. Organizations should also consider selective defensive purchases, agreements with registrators and brand protection services, although such a strategy may be expensive to scale.

Model and platform providers must assume technical responsibility: to implement the outputs to mark links generated by IA, to provide integrated domain verification tools and to design mechanisms to reduce the likelihood of models producing viable but non-existent names. At the architectural level, some limitations of the models make the generation of these false positives difficult to eradicate completely, so operational and process mitigation will be key.

The good news is that the predictibility of the phenomenon leaves a defensive opportunity: companies can move forward by mapping the "patterns of invention" of the models they use, monitoring records and deploying blocks or sinkholes before the domains are exploited. For resources and practical guidelines on how to protect against phishing and domain abuse, see the security incident response investigations such as those published by Unit 42 of Palo Alto Networks and the operational recommendations of Internet security as the safe navigation guides of suppliers and authorities, for example the technical documentation of Google Safe Browsing in developed.

Ultimately, the essential problem is confidence: the IA amplifies both the utility and the risk of unverified shortcuts. If the defenders do not anticipate and monitor these invented domains, the prize to arrive first will be for the attackers. The response is to combine technical controls, verification and training processes: treat the output of a model as a draft that requires validation before becoming action.