Cloud misconfigurations are the leading cause of data breaches in organisations running workloads on AWS. Unlike traditional vulnerabilities that require exploitation of a software flaw, misconfigurations are often a single API call away from full exploitation — no exploit kit, no zero-day, no sophisticated technique required. Here are the ten we find most often and what to do about each one.
1. Publicly Accessible S3 Buckets
S3 buckets set to public-read or public-read-write expose their contents to anyone on the internet. Common in organisations that inadvertently enable public access for a single bucket and then replicate the configuration. AWS's Block Public Access setting, introduced after a wave of high-profile breaches, should be enabled at the account level and enforced via Service Control Policies (SCPs) in multi-account environments.
Fix: Enable S3 Block Public Access at the account level. Audit all existing buckets with aws s3api list-buckets and check each bucket's ACL and policy. Use AWS Macie to detect buckets containing sensitive data.
2. Overly Permissive IAM Policies
The AdministratorAccess policy — or custom policies with *:* — granted to long-lived IAM users and service accounts is a persistent finding. When any one of these credentials is compromised (via phishing, code repository exposure, or application vulnerability), the attacker inherits full account control.
Fix: Apply least-privilege IAM. Use IAM Access Analyzer to identify unused permissions. Replace long-lived access keys with IAM roles for EC2 instances and Lambda functions. Enforce mandatory MFA for all human IAM users.
3. Security Groups with 0.0.0.0/0 Ingress on Sensitive Ports
Security groups that allow inbound access from any IP address on ports 22 (SSH), 3389 (RDP), 3306 (MySQL), 5432 (PostgreSQL), or 27017 (MongoDB) are one of the most frequently exploited misconfigurations in cloud environments. Brute-force and credential-stuffing attacks against exposed management ports are automated and continuous.
Fix: Restrict SSH and RDP to known IP ranges or VPN egress addresses. Use AWS Systems Manager Session Manager for shell access to EC2 instances without exposing port 22. Audit security groups with aws ec2 describe-security-groups and alert on 0.0.0.0/0 ingress rules.
4. CloudTrail Logging Disabled or Incomplete
CloudTrail is the forensic backbone of AWS — without it, you have no visibility into who did what and when. Organisations that disable CloudTrail (to reduce costs), fail to enable it in all regions, or don't enable management event logging are flying blind during an incident.
Fix: Enable CloudTrail in all regions and enable management event logging (read + write). Store logs in a separate, write-protected S3 bucket with versioning enabled. Forward logs to CloudWatch and alert on CloudTrail disablement events.
5. No MFA on Root Account and Privileged IAM Users
The AWS root account has unrestricted access to all services and cannot be restricted by IAM policies. An unprotected root account is a single point of catastrophic failure. IAM users with elevated permissions fare only marginally better without MFA.
Fix: Enable hardware MFA on the root account immediately. Create an IAM admin user for day-to-day operations and lock the root account away. Enforce MFA via IAM policy condition for all privileged users.
6. Secrets Hardcoded in EC2 User Data and Lambda Environment Variables
Access keys, database passwords, and API tokens embedded in EC2 launch configurations, Lambda environment variables, CloudFormation templates, and (critically) Git repositories are a pervasive finding. EC2 metadata service exposes user data to anyone with shell access to the instance.
Fix: Store all secrets in AWS Secrets Manager or Parameter Store with KMS encryption. Grant applications IAM roles that can retrieve secrets at runtime rather than embedding credentials at deployment time. Run git-secrets or TruffleHog on your repositories to detect historical credential exposure.
7. RDS Instances Publicly Accessible
RDS databases with PubliclyAccessible: true and permissive security groups are directly reachable from the internet. Combined with weak credentials or unpatched database engines, this is a direct path to data breach.
Fix: Set PubliclyAccessible: false on all RDS instances. Place databases in private subnets with no internet gateway route. Use a bastion host or VPN for DBA access. Enable RDS encryption at rest and in transit.
8. Unrestricted Outbound Traffic
Security groups and NACLs that allow all outbound traffic enable exfiltration of data from compromised instances to any destination. Attackers who achieve code execution inside your VPC can freely transfer data to external C2 infrastructure.
Fix: Apply egress filtering to restrict outbound traffic to known-necessary destinations and ports. Use VPC endpoints to keep AWS API traffic within the AWS network. Enable VPC Flow Logs and alert on anomalous outbound connections.
9. ECS and EKS Workloads Running as Root
Containers running as root with excessive host privileges — privileged mode, host network, host PID, mounted host paths — can escape container isolation and achieve host-level access. A single compromised container becomes a cluster-wide incident.
Fix: Enforce non-root containers via PodSecurityPolicy (Kubernetes) or ECS task definition. Disable privileged mode. Use read-only root filesystems where possible. Apply container-specific IAM roles with minimal permissions.
10. No GuardDuty or Security Hub
AWS provides managed threat detection (GuardDuty), security posture management (Security Hub), and configuration compliance (AWS Config) as native services. Organisations that haven't enabled these are missing continuous detection of credential compromise, crypto mining activity, reconnaissance, and configuration drift.
Fix: Enable GuardDuty in all regions. Enable Security Hub with the AWS Foundational Security Best Practices standard. Enable AWS Config with managed rules for your key security controls. Route findings to a central Security Operations platform (SIEM or ticketing system) with defined response playbooks.
A Note on Automated vs. Manual Cloud Security Testing
Tools like Prowler, ScoutSuite, and AWS Trusted Advisor catch most of the above misconfigurations automatically. But automated tools miss business-logic misconfigurations — IAM policies that are technically minimal but allow privilege escalation chains, resource-based policies with subtle trust boundary violations, and multi-account role chaining vulnerabilities. Manual cloud security testing catches what the tools miss.
Key Takeaways
- This post covers practical, actionable guidance for security and engineering teams.
- All findings and techniques are mapped to recognised frameworks (OWASP, NIST, ISO).
- Contact Vynox Security to test your systems against the vulnerabilities described here.