🌐 IMDS Deception

Simulated Instance Metadata Service endpoints.

→ Explore in ATT&CK matrix (2 mappings) Deployment detail

What it is

A fake instance metadata service on a decoy machine. Attackers who land on a cloud machine query the metadata service almost at once, because it hands out the machine's cloud credentials. The fake service logs every request and returns decoy credentials that grant nothing, so both the request and any later use of the credentials are signals.

Implementation requirements

Deploy only on decoy instances, never on real ones: real workloads depend on the metadata service. AWS: disable the real service (aws ec2 modify-instance-metadata-options --http-endpoint disabled) and run a responder that answers on 169.254.169.254 through a local redirect
Azure: Microsoft's documented way to restrict the metadata service is local firewall rules, not a switch like AWS's. Give the decoy VM no managed identity, block 169.254.169.254 in the local firewall for every process, and redirect it to the responder. The fake must require the Metadata: true header, reject requests carrying X-Forwarded-For, and serve /metadata/instance and the managed-identity token path /metadata/identity/oauth2/token
GCP: create the decoy VM with no service account (--no-service-account --no-scopes), so the real metadata server has no token to give, then redirect 169.254.169.254 (which metadata.google.internal resolves to) to the responder. The fake must require the Metadata-Flavor: Google header and serve /computeMetadata/v1/, including instance/service-accounts/default/token
On Azure and GCP, treat the responder's own log as the alert. A forged token is rejected by the cloud, and you should not count on that rejection reaching a log you can see
The responder serves plausible metadata, and at the credentials path returns honeytoken credentials (D006, D010) that grant nothing
Monitoring: the responder logs every request, especially to the credentials path. Use of the returned credentials alerts again in CloudTrail
Safety: confirm nothing on the decoy needs real metadata (agents, user data). OPSEC: response format, headers and token behaviour (IMDSv2 session tokens) like the real service
Rollback: Stop the responder and remove the local redirect. Re-enable the real metadata service, or terminate the decoy instance.
Upkeep: Track metadata-service changes (new paths, IMDSv2 behaviour), so responses stay realistic. Monthly proof-of-life credential request.

Technologies

NetworkAWSAzureGCP

ATT&CK coverage 2

Technique	Tactic	Status	Confidence	Tier
T1040 Network Sniffing	Credential Access	theoretical	moderate	T2
↳ Detection point: the decoy fires at a later step of the attack
↳ Evidence (3 sources) Automating the Injection of Believable Decoys to Detect Snooping — Peer-reviewed prototype that injects believable bait traffic (credentials) into a campus wireless network to expose eavesdroppers; believability confirmed by a user study. MITRE ATT&CK Enterprise v20.0 — ATT&CK v20 documents T1040 Network Sniffing as an adversary behaviour. MITRE Engage — adversary engagement matrix and ATT&CK mapping — MITRE Engage maps T1040 to its Lures activity.
T1552.005 Cloud Instance Metadata API	Credential Access	theoretical	moderate	T2
↳ Detection point: the decoy fires at a later step of the attack
↳ Evidence (2 sources) Tracebit for AWS — canary resources and credentials — Deploys canary credentials on EC2 instances. MITRE ATT&CK Enterprise v20.0 — ATT&CK v20 documents T1552.005 Cloud Instance Metadata API as an adversary behaviour. Not specifically through the metadata service.

Evidence

Decoy Network Resource (D3-DNR) — MITRE D3FEND standard
Automating the Injection of Believable Decoys to Detect Snooping — Bowen, B.; Kemerlis, V.; Prabhu, P.; Keromytis, A.; Stolfo, S., ACM WiSec 2010 peer-reviewed
MITRE Engage — adversary engagement matrix and ATT&CK mapping — MITRE 2022 standard
MITRE ATT&CK Enterprise v20.0 — MITRE 2026 standard