AWS Misconfigurations

What Is It and Why It Matters

• AWS misconfigurations are the root cause of most cloud security incidents because the shared responsibility model puts configuration control in the customer’s hands, and the default settings aren’t always the most secure.
• A single misconfigured IAM policy, S3 bucket ACL, or security group can expose sensitive data to the entire internet within minutes.
• Cloud environments change rapidly — new services are deployed, permissions evolve, and resources are shared across teams — making continuous configuration monitoring essential.
• For security analysts, understanding common cloud misconfiguration patterns is critical because traditional network and endpoint detection tools often lack visibility into cloud control planes.

High-Impact Misconfiguration Categories

IAM Policy Misconfigurations

The most common source of cloud privilege escalation. IAM policies control who can do what with which AWS resources — and one overly permissive policy can grant an attacker full admin access.

Common patterns:

Detection: CloudTrail events PutUserPolicy, PutRolePolicy, AttachRolePolicy, AttachUserPolicy are the key events to monitor. A developer attaching the AdministratorAccess managed policy to a service role they work with is a common privilege escalation pattern.

SPL query — detect IAM policy changes that expand permissions:

index=cloudtrail
( eventName=PutUserPolicy OR eventName=PutRolePolicy OR eventName=AttachRolePolicy OR eventName=AttachUserPolicy OR eventName=CreatePolicy )
| search policyDocument = "*"
| rex field=requestParameters "policyDocument.*(Action|Effect|Resource).*(\*|FullAccess)"
| stats values(eventName) as Actions, values(userIdentity.arn) as Actor by sourceIPAddress, _time
| eval alert = "HIGH — IAM policy change with wildcard permissions"

S3 Bucket Misconfigurations

An S3 bucket with public read access exposes its contents to anyone on the internet. This is the most publicized cloud misconfiguration pattern for a reason — it keeps happening.

Common patterns:

Detection: CloudTrail events PutBucketPolicy, PutBucketAcl, and PutBucketPublicAccessBlock are critical. Monitor these in a dedicated CloudWatch alarm.

SPL query — detect bucket policy change to public:

index=cloudtrail eventName=PutBucketPolicy
| rex field=requestParameters "bucketPolicy.*(?<PrincipalPrincipal>(?i)\*)" 
| search PrincipalPrincipal="*"
| stats values(requestParameters.bucketName) as Bucket by userIdentity.arn, sourceIPAddress, _time
| eval alert = "CRITICAL — S3 bucket policy changed to allow public access"

Security Group Misconfigurations

Security groups are stateful firewalls for EC2 instances. Overly permissive rules expose compute resources to the internet.

Common patterns:

Detection: CloudTrail events AuthorizeSecurityGroupIngress and AuthorizeSecurityGroupEgress. Alert when source is 0.0.0.0/0 and port is a management port (22, 3389, 22) or database port.

CloudTrail Logging Disabled

If an attacker disables CloudTrail, they can operate in the account without leaving audit records. This is the cloud equivalent of clearing the Windows Event Log.

Detection: CloudTrail events StopLogging, UpdateTrail (set EnableLogFileValidation=false), DeleteTrail. These should trigger immediate critical alerts.

SPL query — detect CloudTrail logging changes:

index=cloudtrail (eventName=StopLogging OR eventName=DeleteTrail OR eventName=UpdateTrail)
| search requestParameters.name IN ("*")
| stats values(requestParameters.name) as TrailName, values(eventName) as Action by userIdentity.arn, sourceIPAddress
| eval alert = "CRITICAL — CloudTrail logging disabled or deleted"

Detection Workflow — Cloud Misconfiguration Triage

Step 1: Identify What Changed

When an alert fires for a misconfiguration, start with:

Step 2: Correlate with Other CloudTrail Events

A single misconfiguration is often part of a chain. Check for correlated events in the same time window:

• CreateUser or CreateAccessKey before a policy change — attacker created their own backdoor
• AssumeRole from an unexpected source — cross-account access abuse
• RunInstances in a new region — attacker launching compute for crypto mining
• GetSecretValue from Secrets Manager or SSM Parameter Store — credential access after privilege escalation

Step 3: Assess and Remediate

Step 4: Automate Remediation

Prevent future misconfigurations with:

• Service Control Policies (SCPs) — deny creation of resources without encryption, deny public S3 buckets, deny CloudTrail deletion
• AWS Config conformance packs — pre-built rule packs for CIS, NIST, PCI compliance
• EventBridge + Lambda automation — when a public bucket is created, automatically apply a bucket policy to block public access
• IAM Access Analyzer — continuously identifies resources shared with external principals

Prevention Toolkit

Real World Examples

• Capital One breach (2019) — A misconfigured web application firewall allowed a server-side request forgery attack that accessed S3 buckets containing over 100 million customer records, resulting in a $190 million settlement.
• Uber breach by Lapsus$ (2022) — The Lapsus$ group gained access through MFA fatigue and an exposed PowerShell script containing hardcoded admin credentials in a network share, then pivoted to Uber’s AWS environment.
• Pegasus Airlines S3 leak (2022) — A misconfigured S3 bucket exposed 23 million files including crew passports, flight logs, and sensitive aviation compliance documents.

Related

• Active Directory Basics — covers the active directory basics concepts
• Cloud Security Fundamentals — detection and response for T1525 techniques
• Common Ports and Protocols — covers the common ports and protocols concepts

Sources

• AWS IAM Best Practices
• AWS Security Incident Response Guide
• CISA — Cloud Security Technical Reference Architecture
• MITRE ATT&CK — Cloud Techniques
• AWS S3 Security Best Practices