ACT I — PART 2
SUMMARY — Social Engineering Through IAM
What This Lab Demonstrated
This Lab focused on social engineering risk in AWS IAM, not deep technical exploitation. We modeled a realistic access request by creating a low-privilege identity (guest-contractor) that would normally pass review:
- No administrator permissions
- No IAM write access
- No ability to assume roles directly
The user was intentionally framed as a contractor / guest account.
The Social Engineering Angle
The risk did not come from obvious power. It came from a subtle permission (iam:PassRole) that is commonly misunderstood and approved. From a reviewer’s perspective, this user looked safe. From an attacker’s perspective, this user could influence AWS services to act with elevated privileges. This gap between perception and reality is where social engineering succeeds in cloud environments.
Key Takeaway
A user does not need admin permissions to create admin impact. Even though the EC2 launch ultimately failed due to a missing permission, the attack path existed. That makes this a latent, high-risk misconfiguration — not a false alarm.
Why This Matters Before LAB 3
LAB 2 proves that individual access reviews can fail even when everyone acts in good faith. LAB 3 will expand this into a multi-user environment, showing how many small, reasonable permissions combine into systemic compromise.
_End of LAB 2 Summary_
Screenshots from the Lab
