Skip to content
Cloud SecurityAWSAzure

Cloud Security – AWS & Azure Misconfigurations

90% of cloud breaches are caused by misconfigurations, not zero-days. Learn how to audit AWS and Azure environments for exposed storage, overly permissive IAM roles, and open security groups.

⏱ 30 min read📅 Updated September 2026✍️ Zentrion Security Team

AWS: S3 Bucket Security

Exposed S3 buckets are responsible for some of the largest data breaches in history. When conducting an audit, always check for public read/write access.

# 1. Enumerate and discover public buckets (Using open-source s3scanner)
s3scan -f /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# 2. Check the Access Control List (ACL) of a specific bucket
aws s3api get-bucket-acl --bucket example-bucket

# 3. Check if the bucket has Public Access Block enabled
aws s3api get-bucket-public-access-block --bucket example-bucket

# 4. If public, list the contents
aws s3 ls s3://example-bucket --recursive

AWS: IAM Misconfigurations

Identity and Access Management (IAM) controls who can do what. Privilege escalation occurs when roles are overly permissive (e.g., using the * wildcard).

# List all IAM users
aws iam list-users

# Check for access keys older than 90 days (Security risk)
aws iam list-access-keys --user-name admin

# Check if the root account has Multi-Factor Authentication (MFA) enabled
aws iam list-mfa-devices --user-name root

# Identify overly permissive roles
aws iam list-roles --query 'Roles[?IsDefault==`false`].{Name:Arn}'

AWS: EC2 & Networking (Security Groups)

Security Groups act as a virtual firewall. A common mistake is leaving management ports (SSH/RDP) open to the entire internet (0.0.0.0/0).

# Find Security Groups with SSH (22) or RDP (3389) open to the world
aws ec2 describe-security-groups --query 'SecurityGroups[*].{Name:GroupName,Rules:IpPermissions[?ToPort==`22` || ToPort==`3389`]}'

# Check for unencrypted EBS (Storage) Volumes
aws ec2 describe-volumes --query 'Volumes[?Encrypted==`false`].VolumeId'

Azure Security Checks (Storage, VMs, Entra ID)

The methodology in Microsoft Azure is similar, but relies on the Azure CLI (az) and different terminology (Storage Accounts, NSGs, Entra ID).

Storage Accounts & Containers (Azure's S3 Equivalent)

# List all storage accounts
az storage account list --query "[].name"

# Check for public Blob access
az storage account show --name myaccount --query "allowBlobPublicAccess"

# List containers with public access
az storage container list --account-name myaccount --query "[?publicAccess!='none'].name"

Virtual Machines & NSGs

# Check Network Security Groups (NSGs) for rules allowing all traffic (0.0.0.0/0) on port 22
az network nsg rule list --resource-group myrg --query "[?destinationPortRange=='22' && access=='Allow'].name"

Entra ID (Formerly Azure AD)

# Check for users without MFA or stale accounts (Password hasn't changed in over a year)
az ad user list --query "[?lastPasswordChangeTime<='2024-01-01'].displayName"

Practice Lab: CloudGoat

Do not test AWS/Azure misconfigurations on live corporate environments without permission. Instead, deploy CloudGoat.

CloudGoat (by Rhino Security Labs) is a "Vulnerable by Design" AWS deployment tool. It uses Terraform to automatically deploy vulnerable cloud infrastructure into your own AWS account for you to hack.

# 1. Install CloudGoat
git clone https://github.com/RhinoSecurityLabs/cloudgoat
cd cloudgoat
pip install -r requirements.txt

# 2. Deploy a vulnerable scenario (e.g., 'iam_privesc_by_rollback')
python3 cloudgoat.py create iam_privesc_by_rollback

# 3. Practice your attacks! Find the misconfigurations and escalate privileges.

# 4. CRITICAL: Destroy the environment so you don't get billed by AWS!
python3 cloudgoat.py destroy iam_privesc_by_rollback

For Azure practice, check out Flaws.cloud and Hacking the Cloud.