AI
Why Black-Box AWS Hacking Is an Unsolved Problem
Cloud security engagements almost always start with credentials in hand. The attacker gets a key, a role, a set of permissions — and the methodology picks up from there. What most methodologies skip is the step before that: getting access at all. Black-box AWS hacking, starting from the public internet with no keys and no scanner credentials, is the gap.
“today’s talk is about how you can hack an AWS account from the internet.” — Eduard Agavriloae
Entry Points and AWS Account ID Resolution
Four entry vectors exist: supply-chain attacks (ruled out for ethical engagements), phishing employees, compromising runtime resources like EC2 or Lambda, and finding exposed access keys in public repos or pre-signed S3 URLs. That last one does double duty. Any access key — persistent or temporary — can be fed into a small script that returns the owning AWS account ID. Pre-signed URLs embed the key ID directly in the URL string; Agavriloae spotted one in the wild and pulled the account ID from it in seconds. AWS Cognito credentials work the same way: temporary credentials issued to app users can be reverse-engineered to the same result.
Live Demo: S3 Bucket to Account Enumeration
The target is “generic company.” Agavriloae ran the Greyhat Warfare API + S3AccountSearch live demo (04:28): query the Greyhat Warfare API by company name, pick a matching public bucket, then feed it to S3AccountSearch. That tool took about four minutes to return the account ID. From there, he ran AWS Eyes blackbox resource enumeration (06:34), pulling public AMIs, EBS snapshots, RDS snapshots, and SSM documents owned by that account. The demo covered one region. Repeating across all 14 enabled regions extends the same technique with no additional access.
At-Scale Attempt: 350K Buckets, 4 Days, Real Limits
He showed the bug bounty + Greyhat Warfare at-scale scan results (08:01). BB Scope pulled every HackerOne program, Subfinder generated 1.1 million subdomains, Katana crawled 38,000 URLs, and after 4 days of continuous scanning, the pipeline surfaced 20 S3 buckets. He then pulled Greyhat Warfare’s full list, 350,000 buckets, and ran the same enumeration. Four more days. Around 4,000 buckets processed, owned by 2,800 distinct accounts. Zero public resources found. Each bucket took roughly one minute, even after parallelizing parts of the search. Scaling to the full list would have required 50 to 100 Lambda functions reading from a queue, which he judged too expensive for the return. His read on the thin results: broad lists dilute signal. Specific targets yield better odds.
Defensive Posture: Treating Account ID as a Secret
“AWS tells you that the AWS account ID is not a secret. Uh but inside the research community we kind of know that um it should be a secret. It’s just that AWS doesn’t admit this” — Eduard Agavriloae
Treat it as a secret anyway. Serve public S3 content through CloudFront, not directly from the bucket — yes, it costs more, but it stops the account ID from leaking. Use non-guessable names for roles and users; conventional names hand attackers a ready-made wordlist. Avoid pre-signed URLs where possible: they embed an access key ID in the URL, which is enough to reverse-engineer the account. “Any exposure brings the attackers closer to your environment.” Every surface you harden removes one more step from the chain.
Q&A
What is the most interesting resource you could reach from a bucket, and can defenders detect this enumeration? A public AMI is the farthest you can reach, because its contents may hold credentials that grant direct environment access, and defenders cannot detect the enumeration — none of these techniques write logs to the victim’s CloudTrail. ▶ 13:48
What is your opinion on honey buckets and the best deception techniques available right now? Honey S3 buckets alone offer little value, but canary AWS access keys planted inside the environment are effective because an attacker has no way to distinguish them from legitimate credentials, and any use immediately confirms an active intrusion. ▶ 16:45
You said the enumeration calls don’t write to CloudTrail — how is that possible when everything is API calls? The S3-based account ID brute-force runs entirely inside the attacker’s own environment, so AWS checks the policy internally but never sends logs to the target account owner. ▶ 22:00
Notable Quotes
today’s talk is about how you can hack an AWS account from the internet. Eduard Agavriloae · ▶ 0:27
AWS tells you that the AWS account ID is not a secret. Uh but inside the research community we kind of know that um it should be a secret. It’s just that AWS doesn’t admit this Eduard Agavriloae · ▶ 11:42
No, you can’t. So most of I think all of these techniques they actually don’t generate logs in uh the in your organization. Eduard Agavriloae · ▶ 15:43
any exposure brings the attackers closer to your environment Eduard Agavriloae · ▶ 12:47
Key Takeaways
- Reverse-engineer any AWS access key or public S3 bucket name to expose the owner’s account ID without touching their logs.
- Treat the AWS account ID as a secret and serve public assets through CloudFront, not directly from S3.
- Black-box AWS enumeration leaves no CloudTrail footprint in the victim’s account — assume you are being profiled silently.
About the Speaker
Eduard Agavriloae
Ex-web developer and ex-penetration tester. In 2022 I conducted my first cloud security configuration review in AWS, and since then, I have remained deeply immersed in the realm of cloud computing. Now my focus is on doing novel research, writing articles, tools and presenting around the world at security conferences.