AWS security misconfigurations:
top 5 issues we find.

Publicly Accessible S3 Buckets

Despite years of warnings and high-profile breaches, publicly accessible S3 buckets remain the most common and most dangerous AWS security misconfiguration we encounter. In 64% of our cloud penetration tests, we discover at least one S3 bucket that's either completely public or has overly permissive access controls.

Why This Happens

S3 bucket permissions are complex, with multiple layers of access control including bucket policies, IAM policies, Access Control Lists (ACLs), and Block Public Access settings. Developers often make buckets public during testing or to troubleshoot access issues, then forget to revert the settings. Others misunderstand the difference between authenticated AWS users and truly private access.

Real-World Example

During a penetration test for a healthcare SaaS company, we discovered an S3 bucket named "backup-patient-records" that was publicly readable. The bucket contained unencrypted backup files with 847,000 patient medical records including names, addresses, social security numbers, and detailed medical histories. The bucket had been made public six months earlier during a migration project and was never secured.

The exposure would have resulted in HIPAA violations, regulatory fines exceeding $2 million, mandatory patient notification, and severe reputational damage. The bucket was discovered within 15 minutes of beginning our external reconnaissance.

How to Identify This Issue

Use AWS CLI to list all S3 buckets and check their public access status:

How to Fix This

• Enable Block Public Access at the account level: Go to S3 console → Account settings → Block Public Access → Enable all four settings
• Review and remove public ACLs: Audit all existing buckets and remove any grants to "Everyone" or "Authenticated Users"
• Use bucket policies instead of ACLs: Bucket policies provide more granular control and are easier to audit
• Implement least privilege access: Only grant the minimum permissions necessary for each use case
• Enable S3 Access Analyzer: Automatically detect buckets accessible from outside your AWS organization
• Regular audits: Schedule quarterly reviews of all S3 bucket permissions using automated tools

AWS Best Practices

Never disable Block Public Access unless you have a specific, documented business requirement for public buckets (like hosting a static website). Even then, only apply the minimum public access needed and implement additional security controls like CloudFront with OAI (Origin Access Identity).

Overly Permissive IAM Policies

In 91% of AWS environments we assess, we find IAM policies that grant far more permissions than necessary. This violates the principle of least privilege and creates opportunities for privilege escalation, unauthorized data access, and lateral movement within the cloud environment.

Why This Happens

IAM is complex, with over 7,000 possible actions across AWS services. Developers often start with broad permissions during development to avoid permission errors, then fail to scope them down for production. Many organizations also attach AWS-managed policies like "AdministratorAccess" to service roles when much more restrictive permissions would suffice.

Real-World Example

We tested an e-commerce platform where a Lambda function processing customer orders had been granted "s3:*" permissions on all buckets ("*"). This was intended to allow the function to write order data to a specific S3 bucket. However, the overly broad permission meant the function could also read, delete, or modify any S3 bucket in the account, including buckets containing backup data, source code, and customer PII.

When we simulated a compromise of this Lambda function (through a separate vulnerability), we were able to access sensitive data across 43 different S3 buckets, including financial records, source code with hardcoded credentials, and database backups.

Common Overly Permissive Patterns

• Using wildcards in actions: "s3:*", "ec2:*", "dynamodb:*"
• Using wildcards in resources: "arn:aws:s3:::*"
• Attaching AdministratorAccess to non-admin roles
• Granting "sts:AssumeRole" without conditions
• Policies with Effect: Allow and Resource: "*"

How to Identify This Issue

Use IAM Access Analyzer to identify overly permissive policies:

How to Fix This

• Implement least privilege: Grant only the specific actions needed on specific resources
• Use IAM Access Analyzer: Continuously monitor for overly broad permissions
• Remove unused permissions: Use IAM Access Advisor to identify unused permissions and remove them
• Avoid wildcards: Specify exact actions and resources whenever possible
• Use permission boundaries: Set maximum permissions that IAM entities can receive
• Regular permission reviews: Quarterly audits of all IAM policies and role assignments
• Implement SCPs: Use Service Control Policies in AWS Organizations to enforce account-level restrictions

Recommended Approach

Start with minimal permissions and add specific actions as needed based on actual CloudTrail logs of denied permissions. This ensures you only grant permissions that are actually used in production.

Unrestricted Security Group Rules

Security groups are AWS's virtual firewalls, controlling inbound and outbound traffic to EC2 instances and other resources. Unfortunately, we routinely find security groups with rules allowing unrestricted access (0.0.0.0/0) to sensitive services, effectively exposing them to the entire internet.

Why This Happens

During troubleshooting, engineers often temporarily open security groups to 0.0.0.0/0 to eliminate network connectivity as a variable, then forget to restrict access afterward. Others don't fully understand the risks of exposing management ports or misunderstand AWS's default-deny model.

Real-World Example

A financial services company had a security group allowing SSH (port 22) and RDP (port 3389) from 0.0.0.0/0 to all production EC2 instances. This was implemented years earlier for "emergency access" and never removed. Using automated scanning, we identified 67 instances with this exposure.

Through password spraying common credentials against the RDP service, we gained access to a Windows server within 4 hours. The server had administrative access to the production database and stored unencrypted credentials for various third-party services in a plaintext configuration file. From this single misconfigured security group, we achieved complete environment compromise.

Most Dangerous Unrestricted Ports

• 22 (SSH): Remote administration, common brute force target
• 3389 (RDP): Windows remote desktop, frequently exploited
• 3306 (MySQL): Database access, direct data exposure
• 5432 (PostgreSQL): Database access, credential theft
• 27017 (MongoDB): NoSQL database, often unsecured
• 6379 (Redis): In-memory database, session hijacking
• 9200 (Elasticsearch): Search engine, information disclosure

How to Identify This Issue

Find security groups with unrestricted access to sensitive ports:

How to Fix This

• Remove 0.0.0.0/0 rules: Replace with specific IP ranges or use AWS VPN/Direct Connect
• Use Systems Manager Session Manager: Provides SSH/RDP access without opening ports
• Implement bastion hosts: Centralized, hardened jump boxes for administrative access
• Restrict by source security group: Allow access only from specific security groups
• Use AWS VPN or Direct Connect: Secure connectivity from corporate networks
• Enable VPC Flow Logs: Monitor and audit all network traffic
• Regular security group audits: Automated scanning for overly permissive rules

Best Practice Architecture

Never expose management ports directly to the internet. Use AWS Systems Manager Session Manager for instance access, which provides fully auditable shell access without requiring open inbound ports.

Disabled or Incomplete CloudTrail Logging

AWS CloudTrail provides comprehensive logging of API calls and user activities across your AWS environment. It's essential for security monitoring, incident response, compliance, and forensics. Yet in 37% of our assessments, we find CloudTrail either completely disabled or configured with significant gaps in coverage.

Why This Happens

Some organizations disable CloudTrail to reduce costs, not understanding the security implications. Others enable it in some regions but not all, or fail to configure it for multi-account organizations. Some enable CloudTrail but don't protect the logs from deletion or tampering.

Real-World Example

A technology startup had CloudTrail enabled only in us-east-1, despite running production workloads in four different regions. When we simulated a breach by compromising an IAM access key, we created resources and exfiltrated data from their eu-west-1 region. Because CloudTrail wasn't enabled in that region, there was no audit log of our activities.

During the post-assessment debrief, the security team expressed concern that if a real attacker had taken the same approach, they would have no way to determine what data was accessed, what resources were created, or how the attack unfolded. This would make incident response impossible and regulatory reporting incomplete.

Common CloudTrail Gaps

• Not enabled in all regions
• Not configured for all accounts in AWS Organizations
• S3 data events not logged
• Lambda invocation logging disabled
• Log file validation disabled
• CloudTrail logs not protected from deletion
• No monitoring or alerting on CloudTrail events

How to Identify This Issue

Check CloudTrail configuration across all regions:

How to Fix This

• Enable multi-region trail: One trail can log events from all regions
• Enable for all accounts: Use AWS Organizations to apply CloudTrail across all accounts
• Enable log file validation: Ensures logs haven't been tampered with
• Enable S3 data events: Log object-level API activity on S3 buckets
• Enable Lambda data events: Track Lambda function invocations
• Encrypt CloudTrail logs: Use KMS encryption for logs at rest
• Protect log bucket: Use S3 bucket policies to prevent log deletion
• Enable CloudWatch Logs integration: Real-time monitoring and alerting
• Set up automated alerts: Notify on suspicious activities like CloudTrail deletion attempts

Compliance Consideration

Most compliance frameworks (PCI DSS, HIPAA, SOC 2, ISO 27001) require comprehensive audit logging. Without proper CloudTrail configuration, you cannot demonstrate compliance or conduct effective incident response.

Unencrypted Sensitive Data

Despite AWS making encryption easy with services like KMS, we regularly discover unencrypted sensitive data in S3 buckets, EBS volumes, RDS databases, and DynamoDB tables. This violates compliance requirements and exposes data if other security controls fail.

Why This Happens

Encryption isn't enabled by default for many AWS services, and organizations often prioritize getting workloads running over implementing encryption. Some teams lack understanding of encryption requirements or believe network-level security is sufficient. Others use default encryption settings without proper key management.

Real-World Example

An e-commerce platform stored customer payment information in an RDS MySQL database without encryption at rest. The development team assumed that because the database was in a private subnet and had restrictive security groups, encryption wasn't necessary. During our assessment, we exploited an SSRF vulnerability in their web application to access the RDS instance metadata and retrieve database credentials from the instance metadata service.

Using these credentials, we created a snapshot of the unencrypted RDS database and shared it with our testing AWS account. Within minutes, we had full access to credit card numbers, CVV codes, and customer personal information for over 250,000 customers. Had the database been encrypted with KMS, the snapshot would have been useless without the encryption keys.

Common Encryption Gaps

• S3 buckets without default encryption
• EBS volumes attached to EC2 instances unencrypted
• RDS databases without encryption at rest
• DynamoDB tables without encryption
• SNS topics and SQS queues unencrypted
• EFS file systems without encryption
• Secrets stored in plaintext in Systems Manager Parameter Store

How to Identify This Issue

Scan for unencrypted resources using AWS Config rules or CLI:

How to Fix This

• Enable S3 default encryption: Configure bucket default encryption with SSE-KMS
• Encrypt EBS volumes: Enable encryption by default in EC2 settings
• Enable RDS encryption: Create encrypted snapshots and restore to new encrypted instances
• Use AWS KMS: Customer-managed keys provide better control than AWS-managed keys
• Implement key rotation: Enable automatic annual rotation for KMS keys
• Encrypt data in transit: Enforce SSL/TLS for all connections
• Use AWS Secrets Manager: Securely store and rotate database credentials and API keys
• Enable encryption for new resources: Make encryption the default for all new deployments

Migration Strategy

For existing unencrypted resources, create encrypted snapshots, test the encrypted versions, then perform cutover during a maintenance window. AWS provides tools and documentation for migrating from unencrypted to encrypted resources with minimal downtime.