AML.T0060 Publish Hallucinated Entities: Blocking Attacker Claims on AI Invented Packages and Domains

When a model invents a package name, web address or contact that does not exist, anyone can register it, and every user who trusts the model is then sent straight to the attacker. MITRE ATLAS tracks this as AML.T0060 Publish Hallucinated Entities, in the Resource Development tactic (AML.TA0003). ATLAS describes an adversary creating an entity they control, such as a software package, website or email address, that matches a source an LLM hallucinated, so that the victim's interaction with it lets the attack proceed. Package names are the best documented case and are covered in depth in the Slopsquatting and Package Hallucination Guide. This page takes the wider ATLAS view: every entity type the technique names, where in your estate an invented name turns into a real request, and how to stop the step where the attacker's registration meets your user, developer or agent. It is for AppSec, platform and brand protection teams and for anyone deploying assistants or coding agents.

Source note: technique and case study details follow the MITRE ATLAS data release 2026.10 (modified 28 October 2026); study figures are attributed to their publishers. Confirm against the official text before relying on it.

Key takeaways

• The attacker's work is registration, not intrusion. AML.T0060 is a resource development step: the attacker claims a name on a public registry, domain registrar, code host or mail provider and waits for model users to arrive.
• Packages are only one entity type. ATLAS lists package names, commands, URLs, company names and email addresses. Netcraft found that 34% of domains a model suggested for brand login pages were not owned by the brand, and 29% were unregistered, parked or inactive.
• Existence checks fail once the name is claimed. A control that only asks "does this package or domain exist?" passes the attacker's entity. Age, ownership, provenance and an internal allowlist are what separate it from the real thing.
• Agents remove the human pause. A coding or browsing agent that resolves and acts on an invented name in one step will install, fetch or email the attacker's entity before anyone reads the suggestion.
• ATLAS links no mitigation object to AML.T0060. Defence therefore rests on controls you own: curated registries, egress and DNS policy, output validation in the AI application and defensive monitoring of names your users are being told about.

What the technique is

ATLAS added AML.T0060 in March 2025, rates its maturity as demonstrated and assigns it to the Generative AI and Agentic AI platforms. It is the second half of a pair. In AML.T0062 Discover LLM Hallucinations the adversary prompts models and collects invented entities with no real-world source; in AML.T0060 they publish an entity under one of those names. The ATLAS description of AML.T0079 Stage Capabilities also lists hallucinated entities among the ways adversaries choose names for staged artefacts, alongside typosquatting and impersonation of real products.

The technique works because model output is treated as a pointer. A user copies an install command, clicks a suggested link, or sends a message to an address the assistant supplied. Nothing about the invented name looks wrong, because it was generated to sound plausible, and once the attacker owns it the name resolves to something real.

Entity types and where they land

The table maps each entity type ATLAS names to the place an attacker publishes it, the evidence that it happens, and the control point that sits between the model's answer and the action.

Not every hallucination is claimable. Lasso found Go and .NET produced many invented names that were hard to exploit, because Go paths often pointed at existing users' accounts or already-taken domains, and many .NET names used reserved prefixes. Ecosystems with open, first-come naming carry most of the exposure. Netcraft also observed that credit unions, regional banks and mid-sized fintech platforms fared worse than large national brands, which matters if your organisation is smaller or less well known.

The ATLAS case study: AML.CS0022

ATLAS case study AML.CS0022 ChatGPT Package Hallucination (an exercise by Vulcan Cyber and Lasso Security, dated June 2024) shows the full chain:

1. Discovery (AML.T0062): the researchers asked ChatGPT coding questions through the public API (AML.T0040) and found it recommending pip install huggingface-cli, a package that did not exist. The real tool ships in huggingface_hub.
2. Publication (AML.T0060): they uploaded an empty package under the invented name to PyPI to count downloads.
3. Supply chain (AML.T0010.001 Software): other users of the same or other LLMs received the same suggestion. ATLAS notes that multiple LLMs produced the same hallucination.
4. Execution (AML.T0011.001 Malicious Package): a real attacker's package would run when installed or loaded.
5. Impact (AML.T0048.003): harm to the user or organisation.

Lasso's write-up adds that a README in an Alibaba research repository contained installation instructions for the invented package. Once a hallucinated name appears in human-written documentation, it stops being an AI problem only: search engines, people and later models all repeat it. The AI Incident Database records the case as incident 731.

How the attack reaches your estate

• Developer chat: a developer pastes an install line from a chat assistant into a terminal. The package runs with their tokens and SSH keys.
• Coding agents: TrendAI research from Trend Micro (June 2025) found that advanced coding agents roughly halved hallucinated package counts compared with foundation models, but invented names still appeared on the hardest tasks. An agent that installs without approval turns one invented name into code execution. See the AI Coding Agents Security Guide.
• Employee and customer assistants: a user asks where to log in or whom to contact and receives a domain or address the brand does not own. Netcraft's example had an AI search engine rank a phishing page on a free site builder above the real bank login.
• Browsing and email agents: an agent told to "contact the vendor" or "download the installer" resolves a name the model invented and sends data or fetches content from it.
• Generated documentation: AI-written READMEs, runbooks and knowledge base articles freeze an invented name into text that is later indexed by search and by your own retrieval systems.

Prevention: controls at each step

ATLAS links no mitigation to AML.T0060, so the table below sets out our recommended controls by the step they interrupt. The package controls are summarised only; their settings are in the slopsquatting guide.

Brand owners: the other side of the technique

If you are the brand an assistant gets wrong, your customers are the victims. Netcraft argues that registering every possible hallucinated variant in advance is impractical, because the variations are effectively unlimited, and recommends continuous monitoring and fast takedown instead. Practical steps:

• Ask the models: periodically ask the major assistants and AI search engines where to log in, how to contact support and which package or SDK to install for your product, and record any answer that is not yours.
• Publish canonical answers: clear, crawlable pages listing your official domains, apps, SDK package names and support addresses give retrieval-grounded engines a correct source.
• Reserve the obvious names: claim the SDK and CLI names developers would guess on the registries your customers use, and the lookalike domains that models keep returning. See the Domain Portfolio and Lookalike Domain Management Guide.
• Take down fast: treat a confirmed hallucinated domain hosting a login page like any lookalike, using the Brand Impersonation and Lookalike Domain Takedown Playbook.

Detection

• Registry misses: the internal package proxy logs requests for names that do not exist upstream. Repeated misses for the same name from different developers are a strong sign an AI tool is suggesting it. That name is a squatting target: block it and, where you own the ecosystem namespace, reserve it.
• First install of a young package: alert when a build or agent resolves a package that is new to the organisation and was published recently, especially one with no repository link or a single maintainer.
• Newly registered domains in AI traffic: correlate DNS logs from agent hosts and AI gateway egress with domain age. A request to a domain registered days ago, made by an agent or immediately after an assistant session, deserves review. See the DNS Logging and Detection Guide.
• Entities in model output: extract package names, URLs and email domains from completions at the AI gateway and compare them with allowlists and registries. A rising rate of unknown entities in a particular use case shows where grounding is weak.
• Agent tool calls: log every install, fetch and send action an agent takes with the conversation that led to it, so a malicious entity can be traced back to the prompt and model version.

Metrics: share of package installs and agent egress that pass through controlled proxies; count of distinct non-existent names requested per month and time to block each; share of new direct dependencies reviewed before merge; rate of unverified entities in model output per application; for brand owners, the share of assistant answers about your login and support channels that point to domains you own.

How to test

1. Sample your own assistants: run the questions your developers and customers really ask, at production settings, and record every package, domain and address returned. Check each against the registry and WHOIS. Do this for each model version and system prompt change.
2. Exercise the controls with a harmless canary: in a test environment, point an agent at a task that needs a package name you have confirmed does not exist, and confirm the proxy blocks it, the miss is logged and the agent asks for approval rather than retrying elsewhere.
3. Check domain controls: confirm protective DNS blocks or holds newly registered domains from agent and build hosts, and that output validation flags an unknown login domain in a chat answer.
4. Roll back safely: introduce blocking in report-only mode, measure false positives for a few weeks, then enforce with an exception path, so a legitimate brand-new dependency does not stop delivery.

Do not publish packages or register domains under hallucinated names outside an authorised research programme. The ATLAS case study used an empty package to measure downloads; real-world registration still creates an entity others will install. The AI Red Teaming Guide covers scoping such tests.

Common failure patterns

• Allowlisting by existence: a CI check that confirms a package exists on PyPI or npm passes the attacker's package as soon as it is published.
• Treating it as a package problem only: the same assistant that invents a library also invents login pages, support addresses and API endpoints, and those reach staff outside engineering.
• Agents with direct internet egress: a coding agent installing straight from public registries bypasses the proxy, the cooldown and the logs.
• No feedback from misses: registry-miss logs exist but nobody reviews them, so a name that dozens of developers have been told to install stays open for an attacker.
• Trusting documentation that copied the model: as the huggingface-cli README shows, an invented name in a respected repository looks authoritative to people and to later models.

Where identity fits

The damage from a published hallucinated entity depends on the identity that interacts with it. A package installed on a developer laptop runs with that developer's cloud keys, registry publishing tokens and SSH keys; in CI it runs with pipeline service account credentials; in an agent session it runs with whatever tokens the agent holds. Short-lived, narrowly scoped non-human credentials and separate identities for agents and build jobs limit what one bad install can reach. See the AI Coding Agents Security Guide for agent credential scoping.

Framework mapping

Practitioner checklist

• Route every package install from developers, CI and agents through an internal proxy that logs and alerts on misses.
• Block and, where possible, reserve names that internal logs show AI tools repeatedly request but that do not exist.
• Require review of every new direct dependency, using age, maintainers and provenance, not existence.
• Apply protective DNS with a newly registered domain policy to agent and build hosts.
• Validate packages, domains and email addresses in model output against allowlists before showing or acting on them.
• Configure agents to propose, not perform, installs, new-domain fetches and first-contact emails.
• Ground assistants on approved package lists and verified supplier and brand directories.
• As a brand owner, regularly ask major assistants for your login, support and SDK details and take down hallucinated domains that go live.
• Keep developer, CI and agent credentials short-lived and narrowly scoped.

Standards and references

• MITRE ATLAS: Publish Hallucinated Entities (AML.T0060)
• MITRE ATLAS: ChatGPT Package Hallucination (AML.CS0022)
• OWASP: LLM09:2025 Misinformation
• Lasso Security: Diving into AI Package Hallucinations
• Netcraft: Large Language Models are Falling for Phishing Scams
• TrendAI (Trend Micro): Slopsquatting, When AI Agents Hallucinate Malicious Packages
• arXiv: Spracklen et al., A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs
• AI Incident Database: Incident 731

Related NHI Mgmt Group resources: MITRE ATLAS Guide, Slopsquatting and Package Hallucination Guide, Malicious Package and Dependency Confusion Guide, Disinformation and Brand Impersonation Guide, AI Hallucination Business Risk Guide.