Last Tuesday, Palo Alto Networks' Unit 42 published research that deserves more attention than it's getting in the small business world. It describes a new attack class that didn't exist two years ago, is already being used in the wild, and works by exploiting the exact behavior you're probably encouraging your team to rely on: asking AI for help finding things online.
They're calling it phantom squatting. Here's what it is and why you should care.
AI Hallucinates Domains. Attackers Are Registering Them.
Most people know AI models hallucinate facts. What's less understood is that they also hallucinate URLs — plausible-sounding web addresses for real brands that simply don't exist.
Ask ChatGPT, Gemini, Copilot, or most other LLMs for the customer support portal for a bank, the documentation site for a software tool, or where to file a complaint with a government agency. A meaningful portion of the time, you'll get back a URL that looks completely legitimate and is completely made up. Something like supportcenter.bankname.ca or docs.sometool.io/api-v2 that the model invented because it pattern-matched to what a real URL for that brand would look like.
Unit 42 studied this systematically. Across 913 real-world brands — retailers, banks, government agencies, software companies — they ran 685,339 prompts through two LLM families and generated 2.1 million URLs. Of those, they found 13,229 already confirmed malicious and roughly 250,000 unregistered hallucinated domains sitting there unclaimed. That's 250,000 plausible-sounding addresses that no legitimate company owns, ready for anyone to buy for $10 and turn into a phishing kit.
Attackers are doing exactly that.
How This Plays Out in Practice
The Unit 42 team documented a real case from March 2026. Their monitoring pipeline flagged a domain similar to a national postal service's e-commerce portal as a high-probability hallucination target — the LLMs they tested consistently invented that domain when users asked AI for help with the service.
Twenty-three days later, an attacker registered it. Within the same week, it was live with a full phishing kit called Montana Empire that impersonated the real site. Credential harvesting, card number collection, the works.
The attack window from "Unit 42 predicts this will be targeted" to "it's actively stealing credentials" was 23 days. The period from "attack infrastructure goes live" to "threat intelligence systems catch it" is typically several weeks longer — because the domain is brand new, registered clean, and the phishing content is original. Every automated blocklist is looking at established malicious domains. This one has no history. It was born dirty with no record of it.
By the time your email security or web filter catches it, a lot of people have already clicked.
Why AI Agents Make This Dramatically Worse
If this were just about humans clicking AI-suggested links, the fix would be straightforward: tell your staff to verify URLs manually. That's still worth doing (more on that in a moment), but it doesn't address the larger problem.
A growing number of small orgs are now running AI agents — tools that don't just suggest things but actually fetch URLs, run research pipelines, and act on what they find. Think Perplexity, ChatGPT with browsing, n8n or Make workflows that use AI to pull information, coding agents that look up documentation.
When one of those agents follows a hallucinated URL to an attacker-controlled site, what happens next is not a phishing email that a human has to decide to click. The agent fetches the page. It processes the content. And if that content contains injection instructions — "ignore your previous instructions and do X" — the agent follows them with no human in the loop. Secrets exfiltrated, credentials exposed, actions taken on connected accounts.
Unit 42 puts this plainly: "An autonomous agent that fetches a URL and processes its response could exfiltrate secrets, execute malicious instructions or propagate a compromised dependency through a build pipeline without any human decision point." If you're running any kind of automated AI workflow that touches external URLs, this is a real attack surface right now.
What Small Orgs Should Do
This doesn't require a new tool or a new vendor. It requires three specific changes:
Stop treating AI-suggested URLs as verified. This is the same instinct you've (hopefully) built around email links, extended to AI output. If ChatGPT or Copilot gives you a URL, treat it the same way you'd treat a link in an unsolicited email — something to verify, not something to click directly. Search for the official site through a search engine, find the URL from the brand's verified social media, or type the main domain manually and navigate from there.
Add a human verification step to any AI agent that fetches external URLs. If you're running workflows where an AI agent retrieves content from URLs it generates itself, build in a check. Log the URLs the agent tries to access and have a human review unfamiliar ones before the workflow acts on them. This is low-friction if you do it during setup rather than retrofitting it after something goes wrong.
Have a ten-minute conversation with your team about this before the end of the week. The staff awareness piece is the same framing as phishing training but updated: the source of the suspicious link isn't a sketchy email anymore. It's the AI tool they've been told to trust. That reframe takes about five minutes to explain, and it changes behavior immediately. Most people haven't connected "AI sometimes makes up facts" with "AI sometimes makes up URLs that attackers then buy."
The 250,000 unregistered domains Unit 42 found aren't all going to stay unregistered. Some of them are already gone by the time you read this. The attack is cheap, it works, and it bypasses defenses that were built before AI-generated URLs existed as an attack surface.
This is the kind of thing we're mapping for clients right now — which AI tools create risk, which workflows need guardrails, and what the ten-minute staff conversation actually needs to cover. If you're trying to figure out where your org is exposed, that's where we start.