Tarek CHEIKH

Posted on Jun 1 • Originally published at aws.plainenglish.io on May 31

Your EC2 Instances Are Probably Exposed Right Now

#security #cybersecurity #aws #awsec2

Part 1 of 3 in the EC2 Security Series

We’ve all been there.

You spin up an EC2 instance. Pick an AMI. Click through the wizard. Security group? “Allow SSH from anywhere”, just for testing. Public IP? Sure, need to connect somehow. IAM role? Skip for now. Encryption? Default is fine.

“I’ll lock it down later.”

You won’t.

The Numbers Don’t Lie

EC2 is the backbone of AWS. It’s the first service most teams adopt, and it’s the one most teams get wrong.

According to Datadog’s 2024 State of Cloud Security report, only about a third of EC2 instances enforce IMDSv2. That means roughly two-thirds still allow IMDSv1, the exact metadata weakness behind the Capital One breach.

And it is not just metadata. SSH (port 22) and RDP (port 3389) left open to the entire internet remain among the most common cloud exposures. Not to a bastion host. Not behind a VPN. To the whole internet, reachable by anyone with an IP scanner and a password list. RDP, full graphical access to Windows servers, is a favorite ransomware entry point.

But the real problem isn’t just open ports. It’s everything else.

The Attack Surface You Don’t See

When people think “EC2 security,” they think firewalls. Security groups. Maybe NACLs. That’s about 20% of the picture.

Here’s what actually gets you breached:

Metadata Service Exploitation (IMDSv1)

Remember the Capital One breach? 106 million customer records. The attack started with a server-side request forgery (SSRF) that hit the EC2 metadata service (IMDSv1) to steal IAM role credentials.

IMDSv1 serves credentials to any process that makes an HTTP GET to **_169.254.169.254_**. No authentication. No session tokens. Just… here are your keys.

AWS introduced IMDSv2 in November 2019, which requires a PUT request to get a session token first. That was more than six years ago, yet most EC2 instances still allow IMDSv1.

Secrets in User Data

EC2 User Data runs scripts at launch. Developers use it to bootstrap instances: install packages, configure services, set environment variables. The problem? User Data is stored in plaintext and accessible via the metadata service.

I’ve seen production instances with AWS access keys, database passwords, API tokens, and private keys hardcoded in User Data. Anyone who can reach the metadata service (or anyone with **_ec2:DescribeInstanceAttribute_** permissions) can read them.

Public AMIs

Teams share AMIs to speed up deployments. Sometimes they accidentally make them public. A public AMI might contain embedded credentials, proprietary code, database connection strings, or internal certificates. Anyone with an AWS account can launch your AMI and extract everything in it.

Overprivileged IAM Roles

“Just give it admin access, we’ll scope it down later.”

Sound familiar? An EC2 instance with **_AdministratorAccess_** or wildcard **_\*:\*_** permissions is a lateral movement goldmine. One compromised instance means the attacker owns your entire AWS account.

Unencrypted EBS Volumes

EBS volumes contain your data. Your databases, your application state, your logs. Without encryption at rest, anyone with physical access to the underlying hardware, or anyone who steals a snapshot, can read it all. AWS offers free EBS encryption. There’s no excuse.

Public EBS Snapshots

This one is brutal. You take a snapshot of an EBS volume for backup. You set the permissions wrong. Now anyone with an AWS account can restore your snapshot, mount it, and read your entire disk. Database dumps, configuration files, SSH keys. Everything.

In 2019, security researcher Ben Morris of Bishop Fox presented research at DEF CON 27 showing that publicly exposed EBS snapshots leaked passwords, SSH private keys, TLS certificates, application source code, and API keys from real organizations. He estimated as many as 1,250 exposures across AWS regions.

Real-World EC2 Breaches

Capital One (2019): 106 Million Records, $80M Fine

The most famous EC2-related breach. A former AWS employee exploited a misconfigured WAF to perform SSRF against the EC2 metadata service (IMDSv1). She obtained temporary credentials from the IAM role attached to the instance, then used those credentials to access S3 buckets containing customer data. The root cause chain: misconfigured WAF, then IMDSv1, then an overprivileged IAM role, then unprotected S3 data. Capital One paid an $80 million regulatory fine.

Imperva (2019): Database Credentials Stolen

Imperva, a cybersecurity company, disclosed a breach affecting their Cloud WAF (Incapsula) product. An AWS API key was stolen from an internal EC2 instance that had an overly permissive security group. The stolen credentials led to access to a database snapshot containing customer email addresses and hashed passwords.

Ongoing: Cryptomining Campaigns

Compromised EC2 instances are a prime target for cryptomining. Attackers scan for instances with open ports, weak credentials, or exploitable metadata services, then deploy miners that rack up thousands in compute costs before anyone notices. Sysdig’s 2024 Global Threat Report found that cloud attackers can go from initial access to impact in 10 minutes or less.

The Compliance Problem

If you’re in a regulated industry, EC2 misconfigurations aren’t just a security risk, they’re a compliance violation.

CIS, AWS Foundational Security Best Practices, PCI DSS v4.0.1, HIPAA, SOC 2, ISO 27001, ISO 27017, ISO 27018, GDPR, NIST 800–53. Across these 10 major frameworks , there are 137 controls that map directly to EC2 security configurations.

That’s 137 things auditors will check. 137 potential findings on your next report.

None of this is theoretical. I’ve seen every item on this list in production environments.

46 Things That Can Go Wrong

Instance security. Network security. Storage. Access control. Logging. Patching. Network exposure. Tagging.

That’s 8 categories. 46 distinct checks. Each one represents a real attack vector, a real compliance gap, or a real operational risk.

And most organizations fail at least a third of them.

What Now?

Running that command manually is just the beginning. There are 45 more things to check.

In Part 2, I’ll show you how to check all of them with one command: an open-source scanner that scores every instance from 0 to 100 and maps each finding to 137 compliance controls across 10 frameworks. In Part 3, we’ll fix everything it finds.

But first, go check if your security groups allow SSH from **_0.0.0.0/0_**. Right now.

aws ec2 describe-security-groups \
  --filters "Name=ip-permission.from-port,Values=22" \
             "Name=ip-permission.to-port,Values=22" \
             "Name=ip-permission.cidr,Values=0.0.0.0/0" \
  --query "SecurityGroups[*].[GroupId,GroupName]" \
  --output table