Top 10 Cloud Security Misconfigurations (and How to Fix Them)

Cloud breaches rarely happen because attackers broke through some novel zero-day vulnerability. In the overwhelming majority of cases, they walked through a door that was accidentally left open. The 2024 Verizon Data Breach Investigations Report found that misconfiguration remains one of the top contributing factors in cloud incidents. This post walks through the ten misconfigurations that appear most frequently in cloud environments, what can go wrong when they're left in place, and exactly how to remediate them.

1. Publicly Accessible S3 Buckets

What Goes Wrong

An S3 bucket set to public allows anyone on the internet to list or download its contents. Millions of records — customer PII, financial data, API keys stored in config files — have been exposed this way. The bucket doesn't need to be explicitly shared; a single misconfigured bucket policy or ACL that grants s3:GetObject to * is enough.

Remediation

Enable S3 Block Public Access at the account level. This is the nuclear option and the right default:

aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Then audit existing buckets:

aws s3api list-buckets --query 'Buckets[].Name' --output text | \
  xargs -I {} aws s3api get-bucket-acl --bucket {}

For buckets that legitimately need public read (static sites, public assets), use CloudFront with Origin Access Control instead of making the bucket itself public.

2. Security Groups with 0.0.0.0/0 Ingress

What Goes Wrong

A security group rule that allows inbound traffic from 0.0.0.0/0 on sensitive ports (22 for SSH, 3389 for RDP, 5432 for PostgreSQL, 6379 for Redis) exposes those services to the entire internet. Automated scanners find these within minutes of deployment. Credential stuffing, brute force, and exploitation of unpatched services follow.

Remediation

Audit all security groups for wide-open rules:

aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values='0.0.0.0/0' \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].{ID:GroupId,Name:GroupName}'

Replace 0.0.0.0/0 with specific CIDR ranges for your office/VPN, or better yet, deploy a bastion host or AWS Systems Manager Session Manager so SSH/RDP never need to be exposed at all.

3. Root Account Usage for Day-to-Day Operations

What Goes Wrong

The AWS root account has unrestricted access to everything in the account — including the ability to delete GuardDuty findings, disable CloudTrail, and close the account. Using it for routine work dramatically increases blast radius if credentials are compromised. Root credentials also cannot be restricted by SCPs.

Remediation

1. Enable MFA on the root account immediately (hardware MFA key preferred).
2. Delete any root access keys if they exist:

aws iam delete-access-key --access-key-id <ROOT_KEY_ID>

3. Create a dedicated break-glass procedure: seal root credentials in a vault, require dual approval to retrieve them, and log every use.
4. Use AWS Config rule root-account-mfa-enabled to alert on MFA being disabled.

4. No Multi-Factor Authentication on IAM Users

What Goes Wrong

A stolen IAM password without MFA gives an attacker full access to whatever that user can do. Phishing, credential stuffing, and leaked .env files all yield plaintext passwords. Without MFA, there's no second barrier.

Remediation

Enforce MFA via an IAM policy that denies all actions except MFA enrollment when MFA is not present:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptMFAEnrollment",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Audit current MFA compliance:

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F, 'NR>1 && $8=="false" {print $1}'

5. Overly Permissive IAM Policies

What Goes Wrong

Attaching AdministratorAccess or PowerUserAccess to developers, applications, and service accounts means a single compromise leads to full account takeover. Wildcards like s3:* or ec2:* violate least privilege and expand the blast radius of any incident.

Remediation

Use IAM Access Analyzer to generate least-privilege policies from CloudTrail activity:

aws accessanalyzer start-policy-generation \
  --policy-generation-details '{"principalArn":"arn:aws:iam::123456789012:role/MyRole"}' \
  --cloud-trail-details '{"trails":[{"cloudTrailArn":"arn:aws:cloudtrail:us-east-1:123456789012:trail/MyTrail","regions":["us-east-1"]}],"startTime":"2025-01-01T00:00:00Z","endTime":"2025-07-01T00:00:00Z"}'

For applications, use Permission Boundaries to cap the maximum permissions a role can ever assume, even if the policy is accidentally broadened later.

6. Unencrypted Storage (S3, EBS, RDS)

What Goes Wrong

Data at rest without encryption means that anyone who gains physical or logical access to the underlying storage can read it. This includes AWS employees, unauthorized users who guess a storage endpoint, or anyone who gets hold of a snapshot.

Remediation

S3: Enable default encryption on all buckets using SSE-KMS:

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/..."
      }
    }]
  }'

EBS: Set the account-level default to encrypt new volumes:

aws ec2 enable-ebs-encryption-by-default

RDS: Storage encryption can only be enabled at creation time. For existing unencrypted instances, create an encrypted snapshot and restore.

7. CloudTrail Not Enabled or Incomplete

What Goes Wrong

Without CloudTrail, you have no audit trail of who did what in your account. When an incident occurs, you cannot determine how an attacker got in, what they accessed, or what they changed. Many compliance frameworks (SOC 2, PCI DSS, HIPAA) require audit logging.

Remediation

Enable a multi-region trail that captures management and data events:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --include-global-service-events

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [
      {"Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::"]},
      {"Type": "AWS::Lambda::Function", "Values": ["arn:aws:lambda"]}
    ]
  }]'

Enable log file validation to detect tampering. Store logs in a separate, locked-down account.

8. Unrestricted Outbound Traffic

What Goes Wrong

Security groups and NACLs that allow all outbound traffic (0.0.0.0/0) let compromised instances reach attacker-controlled command-and-control servers, exfiltrate data, send spam, or participate in DDoS attacks. Cryptomining malware typically beacons outbound on port 80/443 to pool servers.

Remediation

Restrict outbound rules to only what's needed. For workloads with known egress destinations, enumerate the required ports and destinations explicitly. Use VPC endpoints for AWS service traffic (S3, DynamoDB, SSM) to keep that traffic off the public internet entirely:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-12345

Use AWS Network Firewall or a third-party egress filter for applications that need internet access.

9. Using the Default VPC

What Goes Wrong

The default VPC in every AWS region has all subnets public by default (instances receive public IPs automatically). Security groups in the default VPC default to allowing all outbound and inbound traffic between instances in the same group. This is convenient for getting started but inappropriate for production workloads.

Remediation

Delete the default VPC in all regions after creating purpose-built VPCs with proper subnet segmentation (public/private/data tiers):

# List default VPCs across regions
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws ec2 describe-vpcs --region $region \
    --filters Name=isDefault,Values=true \
    --query 'Vpcs[].VpcId' --output text
done

New VPCs should have private subnets for compute, separate data subnets for databases, and tightly controlled public subnets only for load balancers.

10. Publicly Accessible RDS Instances

What Goes Wrong

RDS instances with PubliclyAccessible=true and a security group open to 0.0.0.0/0 on port 3306/5432 are directly reachable from the internet. Attackers running database-specific scanners find these within hours. Combined with weak or default credentials, this is an instant critical breach.

Remediation

Set all RDS instances to not publicly accessible:

aws rds modify-db-instance \
  --db-instance-identifier my-db \
  --no-publicly-accessible \
  --apply-immediately

Place RDS instances in private subnets with no route to the internet gateway. Access from applications should go through the application's private subnet. Access for administration should go through a bastion host or Systems Manager Session Manager with port forwarding.

Audit current exposure:

aws rds describe-db-instances \
  --query 'DBInstances[?PubliclyAccessible==`true`].{ID:DBInstanceIdentifier,Endpoint:Endpoint.Address}'

Putting It Together: Continuous Detection

Fixing these misconfigurations once is not enough. Teams make changes, new resources are provisioned, and configurations drift. Use AWS Config rules, Security Hub, or a dedicated CSPM tool to continuously evaluate your environment against these controls and alert when drift is detected. Many of the checks above map directly to CIS AWS Foundations Benchmark controls, which provides a structured framework for ongoing measurement.

Automate remediation where safe to do so — for example, automatically re-enabling S3 Block Public Access if it's turned off, or flagging new security groups with wide-open rules for immediate review.