Incident response guide for AWS CloudTrail investigations – Part 2 | Amazon Web Services

What to do — the IMDSv2 command and its two flags

The summary names "enforce IMDSv2" but not the command or why both flags matter:

aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1

--http-tokens required forces callers to present a session token obtained via a PUT request, which a basic SSRF cannot perform — this alone would have stopped the attack at step one. --http-put-response-hop-limit 1 keeps the metadata response on the instance, so a request arriving from a container or proxy one hop away never receives credentials. The log field ec2RoleDelivery: "1.0" is the explicit confirmation that IMDSv1 was in use.

For persistence hunting, search the compromised session for these IAM write events specifically: CreateUser, CreateRole, CreateAccessKey, AttachRolePolicy. The failed adm1n CreateUser is the known start; confirm nothing similar succeeded. Correlate CloudTrail timestamps with VPC Flow Logs and application logs on source IP 75.3.231.105. Use IAM Access Analyzer to find and remove the unused permissions that let a web role reach Bedrock.

Forensic deception indicators (not in the summary)

The page's most transferable content is a set of three impersonation tricks threat actors use to mislead investigators — independent of this scenario:

• IAM user named root: attackers create an ordinary IAM user called root to masquerade as the account root user. Distinguish them by the type field in userIdentity, not the name.
• Homoglyph role names: a role named AWSServiceRoIeforSupport uses a capital I in place of the lowercase l in "Role" to imitate the legitimate AWSServiceRoleForSupport service-linked role. Actions look AWS-driven but are not.
• HIDDEN_DUE_TO_SECURITY_REASONS as a real username: CloudTrail normally substitutes this string in userName when a console sign-in fails on bad input. Attackers register it as an actual username so investigators assume the name was auto-redacted. Usually paired with a CreateUser/CreateRole event.

Caveats the page states

CloudTrail records the Converse call and token counts (944 input / 126 output here) but not prompt or response content — only Bedrock model invocation logging captures that. If it wasn't enabled before the incident, that content is unrecoverable; enable it now. The absence of userIdentity.invokedBy is itself evidence: it confirms a principal called Bedrock directly rather than via a service-linked workflow — a distinction that will matter more as agentic Bedrock workloads grow.