Cloud Metadata Service (IMDS) / SSRF Credential Theft Response
Covers triage, revocation, isolation, root cause eradication, and IMDSv2 hardening for instance role / service account credentials (AWS STS temporary key, Azure Managed Identity token, GCP OAuth token) obtained via SSRF or direct IMDS access in a cloud environment.
169.254.169.254. Verify that AWS, Azure, and GCP's newer-generation IMDSv2/IMDS require token-based authentication; older versions may still be left active for accessibility. Revoke compromised IAM role credentials and restrict the scope of permissions granted to that role according to the principle of least privilege.Prepare
8 steps- Audit log verification
Periodically verify that CloudTrail (all regions, S3 data events), Azure Activity Log, and GCP Cloud Audit Logs are flowing to central SIEM without data loss
- IMDSv2 inventory scan
Document instances where `HttpTokens=optional` remains using the `aws ec2 describe-instances --query "Reservations[*].Instances[*].[InstanceId,MetadataOptions]"` output; these instances must be recorded as the primary attack surface
- MetadataNoToken metric alert
Set up an alert monitoring the `MetadataNoToken` metric under CloudWatch namespace `AWS/EC2`; a value greater than zero indicates an IMDSv1 call in the account
- IAM role permission review
Audit IAM roles assigned to instances for wildcard permissions such as `s3:*`, `iam:*`, `ec2:*` using IAM Access Analyzer; document roles without a Permission Boundary applied
- SSRF WAF rules
Verify that rules blocking requests targeting `169.254.0.0/16`, `169.254.169.254`, and `metadata.google.internal` are active in AWS WAF, Azure WAFv2, or GCP Cloud Armor
- Break-glass account and escalation