A basic request is enough because IMDSv1 answers a basic request. There is no session token in the exchange, so nothing distinguishes the application's own metadata call from one an attacker steered through a server-side request forgery flaw, and the response carries the temporary credentials for the attached role [8]. That is why AWS describes those credentials as the pivot point for everything after stage two [8].
The forensic detail worth copying is which record gave the game away. The event that identifies both the compromised role and the IMDSv1 origin of the credential is a *failed* `CreateUser` call in us-east-1 at 15:53:49 UTC [14]. The denied action is the high-signal one. The successful console sign-in at 15:59:29 UTC, without MFA, only shows the actor moving from programmatic to interactive access [15].
Subtract the two timestamps and you get 340 seconds [16]. That is the window between the first probe that any competent CloudTrail rule can catch and a live interactive session. Any runbook that routes denied IAM calls to a human queue is running slower than the attack it is meant to catch.
The pivot itself is the part that changes coverage. IAM operations were denied, so the actor turned to Bedrock, a service the role could reach [11], then moved from us-east-1 to us-east-2, in AWS's assessment to evade Region-specific monitoring and access controls [12]. Region hopping is a compliment to your us-east-1 detections and nothing more.
Applying these numbers to your own account comes down to three conditions holding at once. IMDSv1 has to still answer on the instance, because that is the only reason SSRF yields credentials rather than an error [8]. The instance role has to hold a permission that reaches an AI service, which is what turned a denied privilege-escalation attempt into productive access [11]. And your trail has to be collecting Bedrock activity in Regions where you deploy nothing, because that is where the calls landed [4]. Miss the third and the first two are invisible to you.
Note how the incident arrived: as failed IAM operations in one Region, a console sign-in with no MFA, and Bedrock API calls from another Region, which AWS says looked unrelated before its Security Incident Response Team tied them into one chain [4][5]. The alerts landed with three different owners and no shared identifier that an on-call engineer would have spotted at 16:00 UTC to tie them together. The role name in the denied call is that key.
Credit where it is due: this is a detection-engineering artifact, not a product post. AWS put its own SIRT casework on the page with timestamps, per-stage progression, and the hardening steps attached [1][9][17], the same way Part 1 handled cross-account S3 deletion and CloudFormation-launched crypto mining [2]. The check I would run in my own context is narrow: does a denied IAM call made with an instance-role credential page anyone, and if it does, can that person act inside six minutes.
