EC2 instances still answering IMDSv1 metadata requests
What does ZopNight detect here?
Instance Metadata Service v1 hands out credentials to any process that can reach 169.254.169.254, which is the classic SSRF escalation path. ZopNight reads each running instance's HttpTokens setting and flags those not set to required, abstaining whenever the metadata options were not captured at discovery.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-152 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | ec2_imdsv2.go |
Where it applies
How IMDSv1 becomes a credential leak
Every EC2 instance serves its own metadata, including the IAM role’s temporary credentials, at 169.254.169.254. Under IMDSv1 a single unauthenticated GET returns them. That means any server-side request forgery bug, misconfigured proxy or URL preview feature that can make the instance fetch an address can exfiltrate live AWS credentials; the 2019 Capital One breach ran through exactly this path. IMDSv2 closes it by requiring a session token obtained via a PUT with a hop-limited TTL header, a handshake an SSRF primitive generally cannot perform.
The one field that decides the finding
The check is narrow by design. An instance’s metadata options carry an HttpTokens field, and the finding fires when a running instance reports it as anything other than required; in practice that means optional, which keeps v1 answering. Discovery records this from the instance’s metadata options; when that block was not captured, the rule abstains instead of guessing.
Audit the fleet in one command
aws ec2 describe-instances \ --filters Name=instance-state-name,Values=running \ --query 'Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens]' \ --output tableEvery row showing optional is this finding.
Enforcing v2 without an outage
aws ec2 modify-instance-metadata-options \ --instance-id i-0123456789abcdef0 --http-tokens requiredThe change is live immediately and needs no restart. The risk is old software: agents and SDKs from before roughly 2020 may speak only IMDSv1 and will start failing their metadata calls. Check MetadataNoToken, one of the instance metrics EC2 reports to CloudWatch, first: it counts v1 requests, and a flat zero over a couple of weeks means enforcement is safe.
Boundaries of the check
Stopped instances are skipped, and an instance whose metadata options are absent from discovery produces no finding rather than a guessed one. The rule does not probe the network, does not know which process on the box still calls the metadata service, and claims no dollar saving. The finding is pure security posture, and its cost fields are all zero.