GuardDuty says exfiltration and the patch is four hours out: revoke the sessions first

The condition key is doing all the work. aws:TokenIssueTime is a property of the session rather than of the caller ^[7], so the inline policy sorts credentials by when they were minted and takes no interest in who holds them or which network they are calling from. That is why one document can be both a kill switch and safe for production: the attacker's copy was issued before the cutoff and dies on its next request, while each instance in the fleet asks the metadata service for a fresh set and gets one stamped after the cutoff ^[9]. The walkthrough notes the deny is evaluated on every request, so there is no propagation window to sit through ^[7].

The arithmetic is what rules out waiting. The sample credentials in the post expire at 16:00Z against a revoke timestamp of 10:30Z ^[14]. That is five and a half hours of remaining validity on a session someone has already copied off the box, measured against a four-hour patch estimate ^[3]; the stolen session outlives the fix by ninety minutes ^[1]. Doing nothing until the developers ship is not a slower version of the same outcome.

Revocation is also not containment. The same auto-refresh that keeps legitimate callers alive is available to anyone still sitting on the instance, because harvesting is a curl against 169.254.169.254 and a copy of three values ^[12], and post-cutoff credentials satisfy the condition by construction ^[9][2]. So the two moves the post separates are complementary: swapping the instance into an empty security group does not stop the exfiltration, since the S3 calls come from a different source IP entirely ^[11], but leaving the instance reachable means the deny buys one round of credentials and no more.

The bucket policy is the option to keep filed away. A Deny on s3:GetObject with Principal "*" on the bucket does stop the attacker, and it equally stops the application servers reading patient data, the backup jobs, the analytics pipelines, and every other IAM principal in the account ^[13]. That trade converts a read of sensitive data into a full outage of everything that touches it, which is a worse incident report than the one you started with.

The unglamorous part is the discovery hop at the top. You need describe-instances against the instance ID from the finding to get the instance profile ARN, then get-instance-profile to resolve the role name ^[4]. In the example the profile and the role are both ProdDataAccessRole and the second call looks redundant, which is exactly the assumption that will cost time on a role where they differ. Then put-role-policy attaches the inline deny under the name AWSRevokeOlderSessions ^[5]; the console's Revoke Sessions tab writes the same document for you ^[6], which matters mostly because it is one fewer hand-typed UTC timestamp at the point in the night where a typo sets the cutoff in the wrong direction.

Validation is two calls: get-role-policy to confirm the document landed, and a CloudTrail lookup for AccessDenied on s3.amazonaws.com after the cutoff ^[8], plus a head-object from a healthy instance on the same role to prove production still reads ^[10].