After conducting cloud security assessments across hundreds of AWS environments — spanning financial services, healthcare, SaaS, and enterprise technology — we have documented the misconfigurations that appear with remarkable consistency. These are not obscure edge cases. They are the everyday mistakes that real organisations make, and they lead to real compromises.
1. Overly Permissive IAM Policies (The Star Problem)
The most prevalent finding across all assessments is IAM policies containing `Action: "*"` or `Resource: "*"`. These grant either all actions or actions on all resources — often both. They appear most commonly on EC2 instance profiles, Lambda execution roles, and developer IAM users who were given broad access for convenience and never had their permissions scoped down. An attacker who compromises any principal with `*` permissions owns the account.
2. Publicly Accessible S3 Buckets with Sensitive Data
Despite years of high-profile breaches, we continue to find S3 buckets with public access enabled containing customer PII, internal configuration files, API keys, and database backups. The introduction of S3 Block Public Access helped, but it is frequently disabled at the bucket level to support a specific use case and never re-enabled. We also find buckets where Object ACLs grant public read even when the bucket policy does not.
3. EC2 Metadata Service v1 Enabled
IMDSv1 (Instance Metadata Service version 1) allows any process on an EC2 instance — including an SSRF vulnerability in a web application — to retrieve the instance's IAM credentials without authentication. IMDSv2 requires a session token obtained via a PUT request, which stops SSRF-based metadata exfiltration. A surprising number of production workloads still run on IMDSv1, often because it is the default for older launch templates and AMIs.
4. Secrets in Lambda Environment Variables
Lambda environment variables are convenient for configuration but are visible to anyone with `lambda:GetFunctionConfiguration` permission — which is granted broadly in many environments. We routinely find database passwords, third-party API keys, and JWT secrets stored as Lambda environment variables. AWS Secrets Manager or Parameter Store (with encryption) are the appropriate alternatives.
5. Unused IAM Access Keys for Root
AWS best practice is to never create access keys for the root account. Despite this, approximately one in three environments we assess has active root access keys — typically created during early account setup and never rotated or deleted. Root credentials bypass all service control policies and IAM permission boundaries. Compromise of a root access key is complete account takeover.
6. Security Groups Allowing 0.0.0.0/0 Ingress on Administrative Ports
SSH (22), RDP (3389), database ports (3306, 5432, 27017), and Kubernetes API (6443) should never be exposed to 0.0.0.0/0. We find this in development environments that were promoted to production, in disaster recovery infrastructure that was stood up in a hurry, and in environments where developers found VPN access too slow and opened direct access instead.
7. CloudTrail Not Enabled in All Regions
CloudTrail records API activity across your AWS account, but it must be explicitly configured to cover all regions. Organisations often enable CloudTrail for their primary regions and leave others uncovered. Attackers who know about this gap can perform reconnaissance and staging activities in unused regions without generating log events. We have seen this used to stage resources for lateral movement.
8. Cross-Account Role Trust Policies Without External ID
When granting a third party access to your AWS account via a cross-account role, the role's trust policy should include a condition requiring a specific ExternalId. Without it, any AWS account that knows your account ID and role name can assume the role — a vulnerability known as the confused deputy problem. Third-party SaaS integrations and managed service providers are common sources of this misconfiguration.
9. RDS Instances with Public Accessibility Enabled
RDS instances should never be directly accessible from the internet. They should be deployed in private subnets with access mediated through application tier EC2 instances or Lambda functions. We consistently find RDS instances with `PubliclyAccessible: true`, often because a developer needed direct database access during development and the configuration was never corrected for production.
10. KMS Key Policies Granting Broad Decrypt Access
KMS customer-managed keys are often configured with overly permissive key policies that grant Decrypt access to wide groups of principals. This negates the data protection value of encryption at rest. If any role in the account with Decrypt access is compromised, encrypted data is accessible. Key policies should grant Decrypt only to the specific roles that require it.
11. Unrestricted Egress from VPCs
Most organisations implement ingress controls through security groups and NACLs, but leave egress completely unrestricted. Unrestricted egress allows malware running on a compromised instance to establish C2 channels, exfiltrate data to arbitrary internet destinations, and pivot to other cloud providers. Egress filtering is consistently underinvested relative to its impact on blast radius reduction.
12. S3 Bucket Policies Granting Access to Any Authenticated AWS User
A subtle but critical misconfiguration: bucket policies containing `Principal: { AWS: "*" }` with a condition of `aws:PrincipalOrgID` that is not set — or containing the ARN `arn:aws:iam::*:root` — grant access to any authenticated AWS user across any account. This is frequently introduced by copying policy examples from Stack Overflow without understanding the `*` principal semantics. Any of the 300 million+ AWS accounts can then access the bucket.
Fixing the Pattern, Not Just the Findings
These 12 misconfigurations share a common root cause: they are the path of least resistance in an environment without strong guardrails. The sustainable fix is not remediation of individual findings — it is implementing preventive controls via Service Control Policies, AWS Config rules, and Security Hub standards that stop these misconfigurations from reaching production in the first place.
UnlockSec's Cloud Security Assessment covers all of the above and more, with a focus on identifying the compensating control gaps that allow these misconfigurations to persist undetected. Contact us to scope an assessment for your environment.