CloudFormation bajo la mirada de un atacante

In this offensive cloud security workshop, viewers will start with limited IAM permissions and learn to identify and exploit misconfigured CloudFormation execution roles using iam:PassRole, service roles, and Lambda-backed Custom Resources. Viewers will weaponize CloudFormation templates to build persistence inside service-scoped IAM paths without needing direct administrative access.

The workshop digs into realistic cloud attack paths, delegated execution abuse, and the risks introduced by over-permissioned automation.

Session Summary

Most organizations audit IAM closely but give AWS CloudFormation a free pass, and that trust is exactly what attackers exploit. In this hands-on workshop, Samanta Aranda , Managing Senior Consultant at Bishop Fox, walks viewers through a realistic privilege escalation path that starts with a single set of low-privilege credentials and ends with a persistent backdoor role. Along the way, participants enumerate their own permissions, find a CloudFormation execution role they're allowed to pass, run into a CloudFormation Hook that blocks the obvious attack, and get around it with a Lambda-backed Custom Resource. The takeaway: the risk isn't CloudFormation itself. It's over-permitted automation that nobody is watching.

Key Takeaways

1. IAM is about control, not just access. iam:PassRole lets a user hand an AWS service a role that isn't theirs. IAM checks the user's permissions once, at the start, and doesn't check the user's identity again as CloudFormation assumes the role and builds resources. If you can influence an identity with more permissions than yours, you can escalate.
2. CloudFormation is a blind spot. It can create, modify, or delete almost any AWS resource, and malicious stacks look just like legitimate ones. That makes it hard for administrators to tell an attacker's deployment from routine infrastructure work.
3. Start by reading your own policies, conditions included. The attack begins with enumerating the inline and managed policies attached to the compromised identity. The conditions on iam:PassRole(which service, which tags, which role purpose) told attendees exactly which execution role to hunt for, and a short script checking role tags found it.
4. Test quietly with change sets. A CloudFormation change set is a dry run. It previews changes without creating or modifying resources, which makes it a clean way to confirm a role can be passed before committing to an attack. Cleaning up afterward keeps the footprint small.
5. The second hop is where the real privileges live. The passable execution role could create IAM roles, rewrite trust policies, and create, update, and invoke Lambda functions, with no conditions on the Lambda permissions. Each delegated role should be reviewed for what it can do, not just who can use it.
6. CloudFormation Hooks stopped the direct attack. Hooks act as a final security inspector between CloudFormation and AWS. When attendees tried to deploy a backdoor role trusting their own identity, a Hook blocked it even though IAM had allowed the action.
7. But Hooks only inspect what CloudFormation deploys. The workaround: deploy a legitimate-looking role that trusts only Lambda, then use a Lambda-backed Custom Resource to rewrite that role's trust policy after deployment and add the attacker as a trusted principal. The Lambda performed the exploit, not CloudFormation, so the Hook never saw it. Attendees then assumed the new role and captured the flag.
8. This isn't a hypothetical setup. The lab mirrors configurations that show up in real production environments. Delegated execution and over-permissioned automation deserve the same scrutiny as human IAM users.