How Hackers Steal Cloud Credentials with SSRF and How to Stop It

Key technological concept / threat model

• The video demonstrates how SSRF (Server-Side Request Forgery) can be used to steal AWS cloud credentials without malware, password cracking, or direct intrusion.
• The attacker needs only one crafted URL parameter (sent via curl) to exploit a vulnerable server that fetches arbitrary URLs.

Cloud architecture used (and why it still fails)

Even with “good security” choices, the setup is vulnerable due to an outdated default configuration in EC2:

• Secrets handling
  • Uses an AWS IAM role attached to the web server instead of hardcoding long-term access keys.
• Storage security
  • Uses an S3 bucket with “Block Public Access” enabled, so it should only be reachable with valid credentials.
• Networking
  • A VPC with two subnets in different Availability Zones (to support an Application Load Balancer requirement).
  • An internet-facing ALB on port 80.
  • A stricter firewall on the web server that only allows traffic from the ALB.
• Goal of the web server
  • It needs to read a private S3 object (a “secret file”) from the blocked bucket.

Vulnerable component (the SSRF point)

• A small EC2 instance runs a Python app with a “link preview” feature:
  • Input: a URL
  • Behavior: the server retrieves the provided URL and returns the response
• The app performs requests without validation, enabling SSRF.

Main attack mechanism: EC2 Instance Metadata SSRF

• The SSRF targets EC2’s instance metadata service at:
  • 169.254.169.254
• The critical misconfiguration:
  • IMDSv1 is enabled
  • IMDSv1 token is optional

With SSRF, the attacker causes the server to request metadata, which returns:

• The IAM role name
• A temporary access key
• A secret key
• A session token

Credential theft → privilege use

• The attacker runs a second EC2 instance without any IAM role (emulating an external attacker/laptop).
• The attacker sends a single request to the ALB, but sets the SSRF URL parameter to the metadata address.
• The stolen temporary credentials are used to access the private S3 bucket, allowing the attacker to read the “secret file.”
• The video claims the credential theft completes in ~30 seconds.

How to stop it (fix without changing application code)

• The defense is to change one configuration parameter:
  • Switch EC2 metadata service from IMDSv1 to IMDSv2
• With IMDSv2:
  • Metadata requests must begin with a cryptographic token flow (a session token obtained via a required PUT + header).
• The SSRF flaw only supports simple GET via the URL parameter, so it:
  • cannot perform the required token PUT
  • therefore cannot retrieve credentials

Demo result: credentials don’t leave the instance (returned content length becomes zero).

Tutorials / labs / guide elements mentioned

The video advertises two free, practical learning assets:

1. Five mini-labs (one each): IAM, S3, VPC, ALB, EC2 — to learn each piece individually.
2. A final stage lab that combines everything to practice the SSRF metadata theft scenario (“play both sides”), then apply the fix by switching to IMDSv2.

Final lab: high-level step sequence

• Create a read-only IAM role and attach it to the web server.
• Create an S3 bucket with public access blocked; place a secret file.
• Build a VPC with two AZ subnets, an internet-facing ALB, and lock EC2 behind it.
• Deploy the link preview app.
• Add an attacker machine without a role.
• Attack by directing the preview URL to 169.254.169.254.
• Fix by enabling IMDSv2 and repeat (SSRF fails).

Main sources / speakers

• Primary speaker: Not explicitly named in the subtitles (narrator/instructor).
• Technical sources referenced:
  • AWS services: IAM roles, S3 (Block Public Access), VPC, Application Load Balancer, EC2
  • EC2 Instance Metadata Service: IMDSv1 vs IMDSv2
• Example attacker/target implementation:
  • A “tiny Python web application” (link preview)
  • An “attacker” EC2 instance—described by the narrator.