The Cloud Security Championship organized by Wiz has launched its first challenge. Over the next 12 months, they will be publishing different challenges, each prepared by one of their researchers.
This first challenge is called Perimeter Leak and tells us that we must find a secret in an S3 bucket.
In AWS, managing root credentials has always been a friction point for organization administrators. Every time a new account was created, we had to configure MFA for root access following best practices and the maturity model. However, enabling MFA is a manual step, and with AWS Organizations, this problem scaled. We could ignore it, apply an SCP to block actions performed with the root user, and deal with the failed check reported by all security tools.
In 2023, AWS announced that MFA would become mandatory, and the time is near. On March 24, 2025, registering an MFA will be required when using the root user.
To address this issue, on November 15, 2024, AWS announced a new feature that allows centralized root access management within an organization without having to manually intervene in each account. However, if we have a large number of accounts, performing the actions one by one is not the most convenient approach.
To simplify this management, we have created aws-root-manager, a tool that efficiently and automatically manages the state of root credentials across all accounts in an organization.
If you use Steampipe with your AWS organization, this will interest you. We have built this tool to automate the creation and maintenance of the configuration files necessary to work with all the accounts in an AWS organization.
In environments with multiple AWS accounts, managing roles can be a challenge. AWS IAM offers us a robust solution for managing roles within each account, but when it comes to consistently implementing roles across all accounts in an organization, the task can become complex.
In this post, we will see how to automatically deploy IAM roles across all accounts in an AWS organization as code, using CloudFormation, Organizations, and Terraform.
You know we can't resist anything with a scoreboard and related to the cloud... And neither distance nor time zones were going to stop us from giving a shot at the CTF organized by Cloud Village at #DEFCON32 last weekend.
Continuing with the series of posts related to IAM misconfigurations, we are going to delve a bit into its use focused on the AWS S3 service.
To do this, we will look at the different ways we can control the security of the service and how dangerous it is to apply a policy without clearly understanding what it does.
Info
If you want to directly try the examples we are going to present, take a look at our repo .
We have prepared different scenarios in Terraform .
This post is based on the introduction of the talk IAM policy mishaps: A cautionary tale of cloud misconfigurations that we presented on Saturday, January 27th, at Sh3llCON (Reinosa). It is going to be the first in a series about IAM misconfigurations (yes, unfortunately, it's a topic that provides enough material for a series).