AML.T0074 Masquerading: Spotting Masqueraded Models and AI Payloads

AI teams load models, templates and agent skills by name from public registries, so an attacker who can make a malicious artifact look like the trusted one by name, path or behaviour gets it deployed by the defenders themselves. MITRE ATLAS tracks this as AML.T0074 Masquerading: manipulating features of an artifact so it appears legitimate or benign to users and security tools, including file metadata, misleading file types, and legitimate-looking task or service names. ATLAS adds an AI-specific form: reclaiming or recreating a previously trusted namespace in a registry such as Hugging Face after it is deleted or renamed, so systems that resolve stale, unpinned identifiers fetch the attacker's artifact. This page covers only that AI angle. General file, process and service masquerading on hosts is in the T1036 Masquerading Defensive Guide. It is written for ML platform engineers, MLOps and detection teams.

Key takeaways

• The model name is a dependency. Unit 42 showed that a deleted Hugging Face author namespace can be re-registered and a malicious model published under the same Author/ModelName identifier; unpinned references then load it.
• Redirects carry trust. Hugging Face redirects the old path after a rename or transfer, and Unit 42 found that reclaiming the old namespace displaced that redirect.
• Looking equivalent is the goal. In the poisoned GGUF template case the artifact behaved normally unless triggered, and the Hub page could show a different template from the file actually downloaded.
• Agent ecosystems add lookalike domains and skills. ATLAS cases show users confirming agent actions because a researcher's domain resembled the real skill registry.
• Pin, mirror and verify. Commit-pinned revisions, an internal model registry and hash or signature checks remove most of the name-based trust the technique abuses.

What the technique is

ATLAS added AML.T0074 on 14 April 2025, last modified it on 31 July 2026, rates it as Realized and places it in the Defense Evasion tactic (AML.TA0007). It mirrors ATT&CK T1036 Masquerading, which ATT&CK v20 places under Stealth. Pretending to be a trusted person or organisation is the sibling technique AML.T0073 Impersonation. The related ATLAS technique AML.T0123 Obfuscated Files or Information, which hides content rather than disguising identity, has its own page: MITRE ATLAS AML.T0123 Obfuscated Files or Information.

In AI systems the "names" people trust are different from those on a Windows host. They include registry namespaces (organisation and model names), model file names and formats, quantised variants of a known model, chat templates inside model files, agent skill names and the domains that skill registries use. Masquerading in this setting means getting one of those to point at, or look like, something the victim already trusts.

The last row is classic double-extension masquerading (ATT&CK T1036.007) used to deliver AI-enabled malware; host controls for it belong in the ATT&CK guide, not here.

How attackers use it against AI systems

Namespace reuse. Unit 42 (published 3 September 2025) explained that Hugging Face models are addressed as Author/ModelName. When an author is deleted the path returns 404 but the name can be claimed again; when a model is transferred, Hugging Face redirects the old path to the new one (HTTP 307), and re-registering the old organisation can capture that path. Hugging Face's own documentation confirms that renaming or transferring a repository redirects the old URL to the new location. The researchers found orphaned but verified models in Google Vertex AI Model Garden and reusable models in the Azure AI Foundry Model Catalog, demonstrated code execution on a Vertex AI endpoint and an initial foothold in an Azure environment, and also found reusable references in Kaggle, thousands of open-source repositories, model cards and notebooks. Google now runs daily scans to mark orphaned models as failing verification.

Lookalike organisations. In AML.CS0027 a researcher registered Hugging Face organisations named after real companies. Employees requested to join, which gave the researcher admin rights over an organisation staff believed was official and access to models they uploaded. The researcher's model then started a background process named training.bin; when the activity was flagged in an ML pipeline it was dismissed as expected training behaviour.

Equivalent-looking model files. Pillar Security (published 9 July 2025, with Fujitsu Research of Europe on the ATLAS case) showed that the chat template embedded in a GGUF file formats every prompt, runs at inference time and sits outside prompt and output filters. The malicious logic stayed dormant for ordinary requests. Pillar reported that the Hugging Face UI showed the template from the first GGUF file in a repository, so other quantised files could differ without appearing in review, and that common model scanners looked for malicious code rather than template behaviour. Hugging Face responded that it treated this as a matter of UI display rather than a vulnerability.

Lookalike skills and domains. Agent skill registries repeat the package-registry problem with higher privileges. In AML.CS0049 a researcher's skill caused the agent to call clawdhub-skill.com, which resembled the legitimate clawdhub.com, and the user approved the command; ATLAS records 16 users who ran the skill in its first 8 hours. The ClawHub Malicious Skills 2026 campaign used useful-sounding names and names imitating ClawHub's own tools to deliver credential stealers. See the Agent Skills Security Guide.

What to detect and where

Mitigations

ATLAS lists two mitigations against AML.T0074. AML.M0011 Restrict Library Loading: load libraries only from trusted locations and approved sets so disguised malicious libraries cannot load as legitimate dependencies. AML.M0025 Maintain AI Dataset Provenance: record dataset sources and modification history so datasets falsely presented as trusted can be identified. The controls below apply the same principle to models, templates and skills.

1. Pin every model to a commit. Use the revision parameter with a commit hash rather than a branch or name, as Unit 42 recommends. Fail the build when a load call has no pinned revision.
2. Mirror into an internal registry. Clone approved models to storage you control after scanning and verification, and point production at that copy, not at the public hub.
3. Record and check hashes and signatures. Store the hash of every approved file, including every quantised variant, and verify it at load. See the Model Signing Guide; ATLAS AML.M0014 Verify AI Artifacts and AML.M0013 Code Signing describe the related controls.
4. Inspect templates in every file. Extract and diff the chat template from each GGUF file you import, not only the first, and allowlist approved templates for production.
5. Prefer non-executable formats. Hugging Face warns that loading pickle files can run arbitrary code and that its pickle import scan is not foolproof; prefer safetensors or other non-pickle formats.
6. Verify publishers. Keep an allowlist of registry organisations and skill publishers, confirm a brand's organisation is controlled by that brand before staff join, and tie membership of your own organisation to company identity.
7. Baseline AI job processes. Record the processes and outbound connections each training and serving job normally makes and alert on anything else, whatever it is called.
8. Restrict egress. Limit outbound network access from training, serving and agent environments to the registries and endpoints they need.

Small versus large teams: a small team using a few public models gets most of the benefit from pinning, hash checks and safetensors. Larger organisations with many teams pulling models need the internal registry and code scanning for unpinned references, because nobody can track every identifier by hand. Track approved models in an AI bill of materials (ATLAS AML.M0023); see the AI Supply Chain and AI-BOM Guide.

Where identity fits

Several of these cases are identity problems. Namespace reuse works because the registry identity behind a model name can change owner. Organisation confusion works because staff trust an unverified organisation identity. The service accounts and tokens that CI and serving platforms use to pull models decide what an impostor artifact can reach once loaded, so scope those tokens to read-only access on approved repositories and log their use. See the Hugging Face Security Guide.

How to test

1. Inventory references. Scan repositories, notebooks and model cards for every model identifier and record whether it is pinned and mirrored.
2. Check identifiers against the registry. For each unpinned identifier, confirm the current owner and whether the path now redirects or returns 404.
3. Tamper test in staging. Replace an approved artifact in a staging registry with a modified copy (for example, a changed template text with no harmful content) and confirm the load fails on hash or template checks.
4. Process test. Start a benign, unexpected process from a training job in a test environment and confirm the alert fires even with a training-like name.
5. Skill install test. Install a benign test skill from an unapproved publisher and confirm policy blocks it and logs the attempt.

Roll back by restoring the approved artifact from the registry and removing test skills. Record results against the metrics below.

Measuring it

• Pinned load rate: percentage of model loads in code that specify a commit revision (target 100% in production).
• Mirrored share: percentage of production models served from the internal registry rather than a public hub.
• Hash verification coverage: percentage of model files, including quantised variants, checked against an approved hash at load.
• Orphaned identifiers: number of referenced identifiers whose owner is deleted or changed (target zero, reviewed weekly).
• Unapproved skill installs: blocked and allowed installs from publishers outside the allowlist.

Common failure patterns

• Trusting the name: loading Author/ModelName from a public hub in production with no revision pin, so a change of owner changes the model.
• Trusting the badge: treating a verified catalogue entry, a clean scan result or a tidy model card as proof that the downloaded file is clean; Pillar advises against relying on platform badges.
• Reviewing one variant: checking the first GGUF file in a repository and deploying another quantisation.
• Dismissing ML noise: closing an alert because the process looked like training, as in AML.CS0027.
• Approving agent prompts by domain shape: users confirming agent commands because a domain looks like the registry's own.

Framework mapping

For the OWASP view see the OWASP LLM Top 10 LLM03 Supply Chain Guide.

Practitioner checklist

• Pin every model load to a commit revision and fail CI when one is missing.
• Serve production models from an internal registry populated after scanning.
• Record hashes for every file and quantised variant and verify them at load.
• Extract and diff chat templates from every GGUF file before approval.
• Prefer safetensors and other non-pickle formats.
• Keep allowlists of registry organisations and skill publishers.
• Baseline processes and egress for training, serving and agent jobs.
• Check referenced model identifiers weekly for owner changes, redirects and deletions.

Standards and references

• MITRE ATLAS: Masquerading (AML.T0074)
• MITRE ATLAS: Model Namespace Reuse Supply Chain Attack (AML.CS0065)
• MITRE ATLAS: Poisoned GGUF Templates, Inference-Time Supply Chain Attack (AML.CS0064)
• MITRE ATT&CK: Masquerading (T1036)
• Palo Alto Networks Unit 42: Model Namespace Reuse
• Pillar Security: LLM Backdoors at the Inference Level, the Threat of Poisoned Templates
• Hugging Face: Repository Settings
• Hugging Face: Pickle Scanning

Related NHI Mgmt Group resources: MITRE ATLAS AML.T0111 AI Supply Chain Reputation Inflation, MITRE ATLAS AML.T0109 AI Supply Chain Rug Pull, Model Supply Chain Guide, MITRE ATLAS Guide.