AWS Building Blocks for Security
The five services and two boundaries that decide every AWS engagement.
What you will learn
- -Read an ARN and know exactly what resource it points at
- -Explain why us-east-1 and IMDS show up in almost every AWS attack
- -Sweep every region instead of trusting the console default
An AWS account is a hard wall. Everything inside it, every bucket, instance, key, and role, belongs to one 12 digit account ID, and by default nothing crosses from one account to another without someone explicitly allowing it. When you own a set of , the first thing to learn is which account they live in and what they represent. That is one command.
$aws sts get-caller-identityThe ARN in that output is worth reading slowly, because you will read hundreds of them. The format is arn:aws:service:region:account-id:resource. So arn:aws:iam::123456789012:user/deploy-bot is an user named deploy-bot in account 123456789012. IAM has no , which is why that slot is empty. comfortable parsing ARNs cold, because access and denial in AWS are written entirely in them.
Regions are not cosmetic
AWS splits the world into regions like us-east-1 (Northern Virginia) and eu-west-1 (Ireland). Resources live in exactly one region and mostly cannot see each other across the line. This matters to you as an attacker or defender for one blunt reason: people hide things in regions nobody watches. A crypto miner spun up in ap-south-1 will not show in a console that opened on us-east-1.
$aws ec2 describe-regions --query 'Regions[].RegionName' --output text$for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do echo "== $r =="; aws ec2 describe-instances --region $r --query 'Reservations[].Instances[].InstanceId' --output text; doneus-east-1 is special and you should treat it as such. IAM, STS, billing, CloudFront, Route 53, and the account's global CloudTrail all anchor there. When a service says it is "global," its home is us-east-1. If you only look in one place, look there first, then sweep the .
The services you actually meet
Five carry most engagements. IAM and STS hand out and vouch for identities. S3 holds the data everyone leaks. EC2 is the virtual machines, and it drags in the single most abused feature in cloud, the .
IMDS lives at the link-local address 169.254.169.254 on every EC2 instance. Ask it nicely and it hands back the of the role attached to that instance. That is the whole prize behind most cloud : get a vulnerable app on an EC2 box to fetch that , and you get keys.
$curl http://169.254.169.254/latest/meta-data/iam/security-credentials/IMDSv1 answers a plain GET with no , so any SSRF or open proxy on the instance leaks role credentials. forces a short-lived session token via a PUT request first, which most SSRF cannot send. If you defend AWS, enforce IMDSv2 everywhere. If you attack it, check which version is on before you write the payload off.
Run every command here against your own free-tier account or a lab like CloudGoat or flAWS.cloud. Enumerating an AWS account you were not contracted to test is unauthorized access, and cloud accounts hold data belonging to real people and companies.
The last two to know by name are Manager and SSM Store. Both store secrets, both are read through the , and both are where you look the second you have any credential worth using. A read on those is often the difference between one foothold and the whole environment.
You run get-caller-identity and confirm valid credentials, but describe-instances in us-east-1 returns nothing. What is the correct next move?