You detect this by watching for IAM role credentials that are normally sourced from the instance metadata service but are then used from non-AWS networks, endpoints, or user agents. Correlate API activity with known instance locations and attach context from network logs and CloudTrail. Unexpected use outside the expected AWS environment suggests credential theft or export.
How to tell whether IMDS-derived AWS credentials are being used somewhere they should not be
The core signal is a mismatch between where the role credentials should originate and where the AWS API activity actually appears from. A credential that is normally issued from an instance metadata service should be tied to a known EC2 host, subnet, account, and workload pattern. When the same role session shows up from unfamiliar IP ranges, geographies, user agents, or non-AWS network paths, treat it as suspicious and investigate immediately.
That mismatch is easiest to see when you correlate CloudTrail with instance inventory and network telemetry. The API caller identity alone is not enough, because IMDS credentials can look legitimate once they are stolen or exported. You need the surrounding context to decide whether the credential use still lines up with the expected host and runtime.
For investigations, build a simple comparison set: expected instance profile, expected source network, expected process or workload, and expected timing. Then compare those expectations against the first-seen source IP, ASN, VPC path, user agent, and API sequence. If the role is suddenly being used from outside your AWS footprint, you are likely looking at credential theft, a proxy or tunneling path, or a copied session token rather than normal instance activity.
Where the evidence usually comes from
The most useful evidence is a three-way join between CloudTrail, network logs, and the instance or workload inventory that owned the role at the time. CloudTrail tells you which API calls were made and by which session. Network logs help you distinguish a call that left from an AWS host from one that traversed the public internet or an unexpected egress point. Instance inventory tells you whether the source host actually existed and was in service when the calls occurred.
That is why detection should not stop at “the role name matched.” IMDS credentials are designed to be temporary and to move with the workload, so the meaningful question is whether the session behaved like a session generated from that workload. A role session used by a browser, a developer laptop, or a cloud shell session is very different from one used by the instance that should have owned it.
Operationally, Cloud Credential Compromise Playbook gives the response pattern for situations where AWS role credentials may already have been exported, including containment, session revocation, and log review. For a broader cloud role-credential abuse example involving IMDS, Capital One breach 2019 remains a useful reference point for how metadata-sourced credentials can be abused once exposed.
What to look for when the credential is being misused
Watch for source patterns that do not fit normal AWS-hosted activity: public IPs that are not yours, consumer VPNs, hosting providers unrelated to your estate, or user agents that do not match the expected workload. Also look for odd call timing, such as interactive bursts outside the normal runtime window, or API usage from regions where the workload has no presence.
The strongest detection is behavioural, not just geolocation-based. A stolen IMDS session often shows up with a different request cadence, a broader set of API calls than the workload normally needs, or a sequence that suggests discovery and privilege testing. If the session is reused from a remote tool or script, the user agent and surrounding API pattern often diverge from the host process that originally obtained the credentials.
If you need a broader identity-and-credential lens on this problem, Ultimate Guide to NHIs, What are Non-Human Identities is the clearest internal starting point for the credential types and runtime identities that often sit behind instance-based access. For practical credential lifecycle concerns, Guide to NHI Rotation Challenges is useful when the response needs to include revocation and rotation strategy after exposure is confirmed.
Risk and Threat Considerations
Once IMDS credentials are used outside the expected AWS environment, the main risk is that the session is no longer bound to the workload that originally obtained it. That can indicate secret theft, token export, or abuse of a proxy path that bypassed your normal trust boundary. The danger is not only unauthorized API use, but also the possibility that the attacker can enumerate resources, exfiltrate data, or create persistence before the original host is even touched.
Failure mechanism: A metadata-derived session token or role credential is copied off-instance and reused from an external network, so CloudTrail still shows a valid identity even though the access path no longer matches the intended host.
Impact: You lose the assumption that the workload owns its own AWS actions, which complicates attribution, delays containment, and can turn a single exposed host into broader account-level access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1552.005 — Unsecured Credentials: Cloud Instance Metadata API | Covers theft and reuse of metadata-sourced cloud credentials. |
| Recommendation — Map the suspicious session to cloud credential access and hunt for post-exfiltration use. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and services are monitored to find anomalies | Detects unusual source networks, geographies, and user agents for AWS API activity. |
| DE.AE-03 — Potential adverse events are analyzed to help determine impact and scope | Supports analyzing whether the role session indicates compromise or export. | |
| Recommendation — Correlate CloudTrail with network telemetry to flag API use from unexpected locations. Analyze the session mismatch to determine whether credential theft or abuse is underway. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | CloudTrail review is central to spotting misuse of instance credentials. |
| IA-5 — Authenticator Management | IMDS credentials are authenticators whose lifecycle and revocation matter after exposure. | |
| Recommendation — Review CloudTrail for source, timing, and call-sequence anomalies tied to the role session. Rotate or revoke exposed session material and shorten credential lifetime where possible. | ||
Practitioner Guidance
What to verify: Confirm the instance profile, the host’s expected egress path, and the first external source that used the role session. If the source cannot be tied back to the known instance lifecycle, treat the credential as compromised even if the API calls are otherwise valid.
Decision rule: If the role session is still active and has reached a non-AWS source, prioritize session revocation and credential containment before deeper forensic analysis. You can reconstruct the narrative later, but the blast radius shrinks only when the token can no longer be replayed.
Practitioner takeaway: The decisive test is not whether the AWS API call succeeded, but whether the session’s origin still matches the workload that should have owned it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org