~/tutorials / cloud-misconfigurations-with-flaws
Cloud Misconfigurations with flAWS
Learn how AWS environments really get breached, through public buckets, leaked keys, and metadata exposure, using the free flAWS challenges.
Lab only. Practice these techniques on your own machines or on platforms that explicitly authorize testing. Informational and educational use only.
Cloud breaches rarely involve clever exploits. They come from configuration: a bucket left public, a key committed to a repository, an over-permissive role. flAWS and flAWS 2 by Scott Piper are free, browser-based challenges that teach exactly these mistakes against infrastructure built for the purpose.
Practice only on flAWS, your own AWS account, or deliberately vulnerable labs. Probing other organizations’ cloud resources without authorization is illegal, even when they are misconfigured.
Set up the tools
You need the AWS CLI and a throwaway AWS account of your own for comparison testing. Never use credentials from a production account.
aws --version
aws configure --profile lab # your own lab account keys
aws sts get-caller-identity --profile labget-caller-identity is the first command to run with any set of credentials. It tells you which account and identity they belong to, and it works even with no other permissions.
The concepts flAWS teaches
Without spoiling the levels, these are the ideas you’ll meet:
S3 bucket permissions. Buckets can be readable by anyone, by any authenticated AWS user, or only by specific identities. “Any authenticated user” sounds restrictive but includes every AWS customer on the planet.
Static site hosting reveals bucket names. A site served from S3 often uses a bucket named after the domain. DNS records and response headers give it away.
Secrets in version history. Deleting a key from the latest commit does not remove it from history. Anything ever pushed should be considered leaked and rotated.
Instance metadata. EC2 instances can query 169.254.169.254 for information about themselves, including temporary role credentials. An application with an SSRF bug can be tricked into fetching them. IMDSv2 requires a session token and blocks most of these attacks.
Over-permissive roles. An identity that can list, read, or pass roles it doesn’t need turns a small foothold into a large one.
Reading permissions
When you obtain credentials in a lab, enumerate before acting:
aws iam get-user --profile lab
aws iam list-attached-user-policies --user-name lab-user --profile lab
aws s3 ls --profile labMany identities can’t call IAM read APIs at all. That’s normal. Work out what they can do from the errors you get, and note every AccessDenied as carefully as every success.
Defending what you learn
| Mistake | Fix |
|---|---|
| Public S3 bucket | Turn on S3 Block Public Access at the account level |
| Keys in code | Use roles instead of long-lived keys, scan repos with gitleaks or trufflehog, rotate on any leak |
| Metadata via SSRF | Require IMDSv2 and set the hop limit to 1 |
| Broad IAM policies | Least privilege, IAM Access Analyzer, no wildcards on actions or resources |
| No visibility | Enable CloudTrail in every region and alert on unusual API calls |
Run Prowler or ScoutSuite against your own lab account. They check hundreds of these settings and explain each failure.
Going further
- flAWS 2 has separate attacker and defender paths. Do both.
- CloudGoat by Rhino Security Labs deploys vulnerable scenarios into your own account. Tear them down when finished to avoid charges.
- HackTricks Cloud documents techniques across AWS, Azure, and GCP.
Takeaway
In the cloud, configuration is the attack surface. Learn to read policies the way you’d read code, and always run get-caller-identity first.