Skip to content

Prerequisites

  • My-Desktop-Key-Pair key pair exists.
  • AWS CLI configured with appropriate IAM credentials.

Network Topology

Base Layout
(Click to zoom)

Overview

This guide demonstrates how to identify and exploit vulnerable VPC configurations, specifically focusing on open security groups, Network ACLs (NACLs), and improperly configured VPC subnets.

VPC misconfigurations are one of the most common cloud security issues, often resulting from overly permissive security groups or network ACLs that allow unrestricted access to critical resources from the internet.

In this scenario, we'll deploy a deliberately vulnerable VPC configuration with open security groups and NACLs, then demonstrate how an attacker can discover and exploit these vulnerabilities to gain unauthorized access to EC2 instances.

What Makes a VPC Configuration Vulnerable?

VPC misconfigurations typically occur when administrators unintentionally configure security groups or network ACLs with overly permissive rules, allowing unrestricted access from the internet to critical resources like EC2 instances, databases, or application servers.

These mistakes often stem from a lack of understanding of AWS networking security, rushed deployments, or attempts to quickly troubleshoot connectivity issues without considering the security implications.

VPC configurations become vulnerable through different areas.

A few of the most common include...

  • Open Security Groups: Security groups allow traffic from 0.0.0.0/0 (all IPs) on high-value ports like SSH (22), RDP (3389), or database ports. Frequently happens from copy/paste of templates without understanding what the security group rules are doing.
  • Permissive Network ACLs (NACLs): NACLs allow all inbound and outbound traffic without restrictions. NACLs operate at the subnet level and can override security group restrictions if misconfigured.
  • Public Subnets Without Proper Controls: EC2 instances are deployed in public subnets with direct internet access, but lack proper security controls or are only protected by overly permissive security groups.
  • Default VPC Usage: Using default VPC configurations without hardening, which may have overly permissive default settings.

👉 In production environments, VPCs should follow the principle of least privilege with security groups that only allow necessary traffic from trusted sources, and NACLs should be configured to block unnecessary traffic.

Deploy Vulnerable VPC Configuration

Run CloudFormation Template

Navigate to the CloudFormation service in the AWS Console.

Select Create stack ➔ Choose an existing template.

Choose Upload a template file and select the open-vpc.yaml template from https://github.com/projectsecio/exercise-files/tree/main/cloud-attacks-101/attacks_cf_templates

Stack name: open-vpc

Configure Parameters

  • KeyPairName: Select My-Desktop-Key-Pair
  • InstanceType: Leave default (t3.micro)

Leave everything else default.

Submit

Wait for the stack creation to complete. This should take 2-3 minutes. You can monitor the progress in the CloudFormation console.

👉 The CloudFormation template automatically: - Creates a VPC named delete-me-vuln-vpc with a public subnet - Deploys a public EC2 instance with an Elastic IP - Configures an open security group allowing access on high-value ports (22, 3389, 80, 443, 3306, 5432, 1433, 5900, 5985, 5986) - Configures permissive NACLs allowing all traffic

Verify Deployment

Once the stack is created, verify that the EC2 instance is running and accessible:

# Get the EC2 instance public IP from CloudFormation outputs
PUBLIC_IP=$(aws cloudformation describe-stacks \
  --stack-name open-vpc \
  --query 'Stacks[0].Outputs[?OutputKey==`EC2PublicIP`].OutputValue' \
  --output text)

echo "EC2 Public IP: $PUBLIC_IP"

Discovery

Identify the VPC and Subnets

Time to put our attacker hat or lens on.

How do attackers find vulnerable VPC configurations?

Network Scanning: Automated tools like nmap can scan IP ranges and discover open ports on EC2 instances. When security groups or NACLs allow unrestricted access, these instances become visible to internet-wide scanners.

👉 Tools like nmap, masscan, or zmap are popular command line tools used to discover open ports and services on the internet. We have used nmap many times in the past.

Shodan/Censys: Search engines for internet-connected devices can index publicly accessible services. If your EC2 instances have open ports, they may appear in these databases.

Cloud Metadata: Misconfigured instances may expose metadata or other information through HTTP endpoints.

Enumeration: Attempting common AWS IP ranges or looking for exposed services in known cloud provider ranges.

For this scenario, assume you've discovered the public IP address through network scanning or reconnaissance.

Verify Open Ports

Let's verify that the security group is indeed open and accessible:

# Test SSH (port 22) - should be accessible
nc -zv $PUBLIC_IP 22

# Test RDP (port 3389) - should be accessible (if Windows AMI was used)
nc -zv $PUBLIC_IP 3389

# Test HTTP (port 80)
nc -zv $PUBLIC_IP 80

# Test HTTPS (port 443)
nc -zv $PUBLIC_IP 443

Using nmap to scan for open ports:

# Comprehensive port scan
nmap -p 22,80,443,3306,5432,1433,3389,5900,5985,5986 $PUBLIC_IP

# Full port scan (takes longer)
nmap -p- $PUBLIC_IP

Enumeration Phase

Port Scanning

Once you've confirmed the instance is accessible, enumerate high value open ports:

# Scan common high-value ports
nmap -p 22,80,443,3306,5432,1433,3389,5900,5985,5986 -sV $PUBLIC_IP

# More comprehensive scan
nmap -sV -sC $PUBLIC_IP

Service Enumeration

Identify what services are running on the open ports:

# Check SSH banner
nc $PUBLIC_IP 22

# Check HTTP service
curl -I http://$PUBLIC_IP

# Check HTTPS service
curl -I -k https://$PUBLIC_IP

Exploitation Phase

Attempt SSH Access

With port 22 open to the world, we could attempt to connect via SSH through brute forcing the password:

# Try SSH connection (will fail without credentials, but demonstrates the vulnerability)
ssh -i ~/.ssh/My-Desktop-Key-Pair.pem ec2-user@$PUBLIC_IP

# Or using the key pair specified in the template
ssh -i /path/to/your/key.pem ec2-user@$PUBLIC_IP

👉 Key Finding: If we take a look at the security group. The security group allows SSH from anywhere (0.0.0.0/0), meaning anyone on the internet can attempt to brute-force credentials or exploit weak authentication.

Test RDP Access (if applicable)

If Windows was used, we could test to see if RDP (port 3389) would be accessible:

# Test RDP connectivity
nc -zv $PUBLIC_IP 3389

👉 Key Finding: RDP exposed to the internet is extremely dangerous. Attackers can attempt brute-force attacks or exploit known RDP vulnerabilities.

Database Port Exposure

Check if database ports are accessible:

# Test MySQL (port 3306)
nc -zv $PUBLIC_IP 3306

# Test PostgreSQL (port 5432)
nc -zv $PUBLIC_IP 5432

# Test SQL Server (port 1433)
nc -zv $PUBLIC_IP 1433

👉 Key Finding: Database ports exposed to the internet without proper authentication are critical vulnerabilities. Even with authentication, exposed database ports increase the attack surface significantly.

Potential Impact

Based on the open ports and vulnerable configuration, an attacker could:

  • Unauthorized Access: Gain access to EC2 instances via SSH or RDP through brute-force attacks or credential compromise
  • Data Exfiltration: Access databases or file systems to steal sensitive data
  • Lateral Movement: Use compromised instances as a pivot point to access other resources in the VPC
  • Service Disruption: Exploit vulnerable services running on open ports to cause denial of service
  • Malware Deployment: Deploy malware or ransomware on accessible instances
  • Privilege Escalation: Attempt to escalate privileges once initial access is gained

👉 In a real attack, an attacker would likely use the open ports to gain initial access, then explore the VPC for additional targets and attempt lateral movement.

Detection and Prevention

How to Detect Vulnerable VPC Configurations

  • AWS Config: Enable rules to detect security groups with overly permissive rules
  • CloudTrail: Monitor security group and NACL changes
  • GuardDuty: Detects suspicious network activity and port scans
  • Security Hub: Provides comprehensive security findings including open security groups
  • VPC Flow Logs: Analyze network traffic patterns to identify unusual access
  • Access Analyzer: Identifies resources accessible from outside your account
  • Regular Audits: Periodically review security group rules and NACL configurations

Best Practices for VPC Security

  • Principle of Least Privilege: Only allow necessary ports from trusted IP ranges
  • Restrict SSH/RDP Access: Limit SSH (22) and RDP (3389) access to specific IP ranges or VPN endpoints
  • Never Expose Database Ports: Database ports should never be accessible from the internet; use VPC peering or VPN for access
  • Use Security Groups as Primary Defense: Security groups are stateful and should be your primary security mechanism
  • Configure NACLs for Defense in Depth: Use NACLs to provide additional subnet-level protection, but don't rely solely on them
  • Regular Security Reviews: Periodically review and audit security group rules
  • Use Network Segmentation: Separate public and private subnets, and place sensitive resources in private subnets
  • Monitor VPC Flow Logs: Enable VPC Flow Logs to monitor network traffic and detect anomalies
  • Implement Network ACL Rules Carefully: Understand that NACLs are stateless and require rules for both inbound and outbound traffic

👉 Always follow the principle of least privilege when configuring security groups and NACLs. Only open the ports you absolutely need, and restrict access to trusted IP ranges whenever possible.

Cleanup

Warning

After completing this exercise, choose Delete on CloudFormation stack to remove all resources.

aws cloudformation delete-stack --stack-name open-vpc

Wait for the stack deletion to complete:

aws cloudformation wait stack-delete-complete --stack-name open-vpc

👉 The CloudFormation stack will automatically clean up all resources including the VPC, subnets, security groups, NACLs, and EC2 instance.