Examkin

Question

Difficulty: HardHost, Network, and Architecture Vulnerabilities

During a threat hunting exercise, a security analyst reviews network logs from a Kubernetes host node running enterprise microservices. The log entries indicate that a compromised container instance successfully issued a request to extract infrastructure credentials:

[2026-07-20 09:14:02 UTC] TCP 10.244.1.45:49152 -> 169.254.169.254:80 GET /latest/meta-data/iam/security-credentials/node-role HTTP/1.1
[2026-07-20 09:14:02 UTC] HTTP 200 OK (Content-Length: 1248, IAM Role: NodeInstanceRole)
[2026-07-20 09:14:15 UTC] AWS STS API call initiated directly from container IP 10.244.1.45 using retrieved token

Which host and architecture vulnerability is the root cause of this credential exposure?

  1. Reliance on Instance Metadata Service Version 1 (IMDSv1) without session tokens, combined with unrestricted container access to the host link-local metadata endpointAnswer
  2. B
    Reliance on network perimeter firewalls that assume internal container traffic is inherently trusted and does not require outbound metadata filtering
  3. C
    Absence of an inline Web Application Firewall (WAF) to inspect incoming external HTTP request headers before they reach the pod
  4. D
    Failure of host-based intrusion prevention systems to detect SQL injection payloads embedded inside the HTTP request URI

Answer

Reliance on Instance Metadata Service Version 1 (IMDSv1) without session tokens, combined with unrestricted container access to the host link-local metadata endpoint
The root cause vulnerability is the reliance on Instance Metadata Service Version 1 (IMDSv1), which processes unauthenticated HTTP GET requests for cloud node IAM credentials, paired with a lack of host network namespace isolation for container workloads. Because IMDSv1 does not require session tokens (unlike IMDSv2), any process or container with access to the link-local IP 169.254.169.254 can extract the host's IAM role credentials and assume those privileges.

Step-by-Step Solution

1
Analyze the log entry to identify the targeted IP address and request method
The container IP (10.244.1.45) made a plain HTTP GET request to 169.254.169.254 targeting security credentials.
The IP address 169.254.169.254 is a standard link-local address used in cloud infrastructure to host the Instance Metadata Service (IMDS).
2
Determine the vulnerability inherent in the request design
IMDSv1 responds to basic HTTP GET requests without requiring session tokens or pre-authentication.
Because IMDSv1 does not enforce token-based headers (introduced in IMDSv2) or hop-limit restrictions, microservices sharing the host network namespace can freely extract node IAM privileges.
3
Identify the primary architectural root cause
The combination of unauthenticated IMDSv1 endpoints and lack of pod egress isolation allowed credential theft.
Enforcing IMDSv2 and restricting access to 169.254.169.254 via network policies mitigates this cloud host vulnerability.

Key Concept

Cloud Host Instance Metadata Service Vulnerabilities (IMDSv1 vs IMDSv2) and Workload Egress Isolation
Rate this question

Topics

Host, Network, and Architecture Vulnerabilities