AWS IMDSv2: Detect Credential Theft

IMDSv2 protects the retrieval step, not every credential use

AWS IMDSv2 credential theft begins with a workload crossing a boundary it was not meant to cross. An exposed web fetcher, compromised process, container escape, or malicious dependency reaches the EC2 Instance Metadata Service and requests the temporary credentials assigned to the instance profile. The later AWS API calls look correctly signed because the credentials are genuine.

IMDSv2 changes metadata retrieval into a session-oriented exchange. The client first sends an HTTP PUT to obtain a token with a bounded lifetime, then supplies that token in subsequent metadata requests. Requiring HttpTokens=required removes the tokenless IMDSv1 path and disrupts many simple server-side request forgery chains whose intermediaries cannot issue or preserve the required method and header.

That protection is substantial but bounded. Code executing on the host can normally perform the token exchange. A container may reach IMDS depending on networking and hop-limit design. A broad instance role can turn one workload compromise into control-plane access. The AWS metadata-options documentation therefore belongs beside process isolation, egress design, and IAM least privilege—not in place of them.

CloudTrail shows how the issued role session was exercised

Metadata requests themselves are not ordinary CloudTrail management events. Detection begins after issuance by following API activity made with the instance role. The CloudTrail userIdentity reference documents ec2RoleDelivery: 1.0 identifies credentials delivered through IMDSv1 and 2.0 identifies the newer scheme.

This authored example is a teaching artifact, not production telemetry:

{
  "eventTime": "2026-11-10T10:42:18Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "ListBuckets",
  "awsRegion": "eu-west-1",
  "sourceIPAddress": "203.0.113.24",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::111122223333:assumed-role/web-prod/i-0123456789abcdef0",
    "sessionContext": {"attributes": {"ec2RoleDelivery": "2.0"}}
  }
}

The 2.0 value proves how AWS delivered the credential; it does not prove the calling process was legitimate. Compare source IP and network ownership with the instance, NAT, VPC endpoint, and approved egress paths. Compare event name, resource, Region, time, and error pattern with the workload’s intended function. A role normally reading one bucket should not enumerate IAM, secrets, or unrelated storage simply because its signature validates.

VPC Flow Logs cannot fill the metadata-request gap: AWS lists traffic to 169.254.169.254 as a VPC Flow Logs limitation. Collect host or eBPF network telemetry where justified, but protect it against tampering and avoid claiming its absence proves no request occurred.

Detect use that no longer fits the instance

Start with a role-to-workload inventory: instance or Auto Scaling group, application owner, expected APIs, resources, Regions, VPC endpoints, egress addresses, and session behavior. Then identify API calls whose role session name maps to an instance but whose source or action does not fit that inventory.

GuardDuty can produce an InstanceCredentialExfiltration finding when credentials created for an EC2 instance are used from an external IP. Treat it as a high-value lead, then validate authorized export workflows, corporate proxies, and affiliated accounts. AWS notes that repeated external behavior may eventually be learned as expected, so detection assurance cannot depend on one managed analytic.

High-confidence combinations include a vulnerable workload signal followed by new role-session activity; instance credentials used outside the expected AWS network; rare API families; enumeration followed by sensitive reads; denied privilege escalation followed by successful access elsewhere; or a role session active after the instance is isolated. Keep bounded claims: CloudTrail demonstrates credential use, not the exact retrieval mechanism, unless runtime evidence connects the process to IMDS.

Contain the role session and the workload together

Isolate the instance through an approved containment mechanism while preserving volatile evidence. Deny or narrow the instance role, quarantine affected resources, and stop persistence or exfiltration paths. Replacing the role or terminating the instance without reviewing accessed resources can erase evidence while leaving copied data, changed policies, or attacker-created credentials behind.

Inventory every CloudTrail event tied to the role session and access key, including cross-Region activity and data events where enabled. Determine which objects, secrets, queues, snapshots, keys, and identities were read or changed. Rotate downstream secrets exposed to the workload. Rebuild from a trusted image when integrity cannot be established.

Containment has availability consequences. An emergency deny on a shared production role can break every instance using it; terminating an Auto Scaling member may immediately launch a replacement with the same vulnerable template. Coordinate workload, IAM, application, and incident owners under the cloud shared responsibility model.

Enforce IMDSv2 without breaking legitimate workload paths

Inventory instances where tokens are optional and measure IMDSv1 use before enforcement. Update SDKs, agents, bootstrap scripts, and images. Test containers separately: AWS notes that a response hop limit of one can cause problems in container environments, while increasing it changes how far token responses can travel.

Apply controls in layers: require IMDSv2 in launch templates, set account or organizational defaults, restrict changes to metadata options, minimize instance-role permissions, disable metadata tags unless required, and disable the metadata endpoint where no workload needs it. Use policy conditions such as ec2:MetadataHttpTokens and credential-delivery context where they fit the control plane.

Roll out through discovery, canary workloads, monitored enforcement, and exception expiry. A production outage caused by a legacy agent is a real tradeoff, but an undocumented permanent exception is not a safe migration outcome. The goal is a narrow, owned path from workload identity to necessary AWS actions.

Turn one metadata finding into durable cloud coverage

The final assessment should state what is observed—role-session use from a source and against resources—what is inferred—likely credential export or workload compromise—and what remains unknown. Record whether evidence supports IMDS retrieval, another credential leak path, or only anomalous use.

Next step: map this page into your cloud threat intelligence priorities and token and session detection model. Validate one authorized IMDSv2 request and one controlled credential-misuse simulation, clearly labeled as test activity, against CloudTrail and GuardDuty. The deliverable is not a generic “metadata alert”; it is an evidence chain with an owner, consequence, containment route, and tested prevention control.