Table of Contents

Problem Statement

Security professionals need isolated, reproducible environments for practicing offensive and defensive techniques. Traditional approaches present significant challenges:

Local Resource Constraints: Running virtual machines for security testing requires substantial local hardware—RAM, CPU, and storage. Many laptops struggle to run both attacker and target VMs simultaneously with acceptable performance.

Environment Consistency: Manual setup of security testing environments is time-consuming and error-prone. Each rebuild requires hours of tool installation, configuration, and validation. Slight differences between environments can invalidate test results.

Isolation Requirements: Security testing must be isolated from production networks and sensitive data. Local VMs on corporate laptops create compliance and security risks. Cloud environments provide natural isolation with controlled egress.

Tool Accessibility: Offensive security tools like Metasploit, Impacket, and CrackMapExec require specific dependencies and configurations. Maintaining current tool versions across multiple machines is challenging.

Cost vs. Availability Tradeoff: Dedicated security lab hardware is expensive and often sits idle. Cloud resources can be provisioned on-demand but require infrastructure automation to be practical.

This project creates a cloud-based security testing lab that provisions in minutes, includes pre-configured offensive tools, and costs nothing when not in use.

Solution Architecture

Security Lab Design

The architecture implements a two-machine attack/target topology within an isolated AWS VPC segment, with full administrative access via SSH, RDP, and AWS SSM Session Manager.

graph TB
    subgraph "Admin Access"
        A[Your Workstation]
    end

    subgraph "AWS VPC - 172.31.0.0/16"
        subgraph "Security Lab Subnet"
            B[Attacker Box<br/>Ubuntu + Kali Tools<br/>t3.medium]
            C[Ubuntu Target<br/>Vulnerable Services<br/>t3.medium]
        end

        D[Security Group<br/>kali-attacker]
        E[Security Group<br/>ubuntu-target]
    end

    A -->|SSH/RDP/SSM| B
    A -->|SSH/RDP/SSM| C
    B -->|All Ports| C
    C -.->|Reverse Shells| B

    D --> B
    E --> C

    style B fill:#c62828,color:#fff
    style C fill:#1565c0,color:#fff
    style D fill:#ff9900
    style E fill:#ff9900

Key Components

1. Attacker Box (Ubuntu + Kali Tools)

• Ubuntu 24.04 LTS base for stability
• Kali Linux repositories for security tools
• Pre-installed: Metasploit, Nmap, Hydra, Impacket, CrackMapExec
• Wordlists: SecLists, PayloadsAllTheThings, PEASS-ng
• XFCE desktop with XRDP for GUI tools (Burp Suite, Wireshark)
• 60GB encrypted EBS volume

2. Ubuntu Target

• Ubuntu 24.04 with desktop environment
• Intentionally configured services: Apache, MySQL, SSH, FTP
• Lab user account for testing credential attacks
• Accepts all traffic from attacker for realistic scenarios

3. Security Architecture

• IMDSv2 required (prevents SSRF credential theft)
• Encrypted EBS volumes at rest
• SSM Session Manager for secure access (no open ports required)
• CloudWatch detailed monitoring enabled
• Tagged resources for cost tracking and management

4. Network Segmentation

• Attacker can reach target on all ports
• Target can only respond to attacker (for reverse shells)
• Admin access restricted to configured CIDR blocks
• No internet exposure for target (except updates)

Technical Implementation

Infrastructure as Code

Security Lab Terraform (terraform/infrastructure/security-lab.tf):

# Attacker box with Kali tools
resource "aws_instance" "kali_attacker" {
  ami                    = data.aws_ami.ubuntu_attacker.id
  instance_type          = var.security_lab_instance_type
  key_name               = aws_key_pair.security_lab.key_name
  vpc_security_group_ids = [aws_security_group.kali_attacker.id]
  iam_instance_profile   = aws_iam_instance_profile.security_lab.name

  # Security: Require IMDSv2 to prevent SSRF attacks
  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
  }

  root_block_device {
    volume_size = 60
    encrypted   = true
  }

  user_data = base64encode(file("scripts/install-kali-tools.sh"))
}

User Data Script (Kali Tools Installation):

#!/bin/bash
# Add Kali repositories to Ubuntu
curl -fsSL https://archive.kali.org/archive-key.asc | \
  gpg --dearmor -o /usr/share/keyrings/kali-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/kali-archive-keyring.gpg] \
  http://http.kali.org/kali kali-rolling main" > /etc/apt/sources.list.d/kali.list

# Install offensive tools
apt-get install -y -t kali-rolling \
  metasploit-framework nmap masscan nikto sqlmap \
  hydra john hashcat responder crackmapexec \
  impacket-scripts seclists wordlists

# Clone essential repos
git clone https://github.com/danielmiessler/SecLists.git /opt/tools/SecLists
git clone https://github.com/carlospolop/PEASS-ng.git /opt/tools/PEASS-ng

Security Controls

1. Instance Security

• IMDSv2 Required: Blocks SSRF attacks that try to steal instance credentials
• Encrypted Storage: All EBS volumes encrypted with AWS-managed keys
• No Public Keys in AMI: SSH key deployed via Terraform, not baked into image
• Minimal IAM Permissions: Instance role only has SSM and CloudWatch access

2. Network Security

• Attacker SG: SSH/RDP from admin CIDR only, full outbound for attacks
• Target SG: All traffic from attacker SG only, limited outbound for updates
• No Public Exposure: Target has no direct internet access except through attacker

3. Access Management

• SSH Key Authentication: Ed25519 key deployed via Terraform
• SSM Session Manager: Alternative access without opening ports
• Separate User Accounts: pentester on attacker, labuser on target

4. Cost Controls

• Tags: All resources tagged with Lab=security-lab for cost tracking
• On-Demand: No reserved capacity—stop instances when not testing
• Right-Sized: t3.medium provides adequate resources without overspending

Installed Security Tools

Reconnaissance:

• Nmap, Masscan - Network scanning
• Recon-ng, theHarvester - OSINT gathering
• DNSrecon, DNSenum - DNS enumeration

Exploitation:

• Metasploit Framework - Exploitation platform
• SQLmap - SQL injection automation
• Hydra, Medusa - Password attacks

Post-Exploitation:

• Impacket - Windows protocol attacks
• CrackMapExec - AD/SMB enumeration
• BloodHound - AD attack path analysis
• PEASS-ng - Privilege escalation checks

Web Testing:

• Burp Suite - Web proxy and scanner
• OWASP ZAP - Web vulnerability scanner
• Gobuster, FFuf - Directory brute forcing
• Nikto - Web server scanner

Wordlists:

• SecLists - Comprehensive wordlists
• PayloadsAllTheThings - Payload repository

Challenges & Solutions

Challenge 1: Kali Marketplace Subscription Issues

Problem: AWS Marketplace Kali Linux AMI requires subscription acceptance, but OAuth authentication was failing with “All OAuth retries failed” error. This blocked Terraform deployment.

Solution: Pivoted to Ubuntu base with Kali repositories. This approach actually provides better stability—Ubuntu LTS base with Kali tools pinned at lower priority prevents package conflicts while providing access to all security tools.

Lesson Learned: Marketplace dependencies introduce fragility. Self-managed tool installation is more reliable and provides better control over versions.

Challenge 2: Tool Dependencies and Package Conflicts

Problem: Installing Kali tools on Ubuntu can cause package conflicts. Metasploit in particular has complex Ruby dependencies that can break system packages.

Solution: Used APT pinning to set Kali repository at lower priority (Pin-Priority: 50). Tools are explicitly installed from Kali repo with -t kali-rolling flag, preventing automatic upgrades that could break Ubuntu base.

# /etc/apt/preferences.d/kali.pref
Package: *
Pin: release a=kali-rolling
Pin-Priority: 50

Lesson Learned: Package management strategy is critical when mixing repositories. Document pinning decisions for future maintenance.

Challenge 3: Remote Desktop Performance

Problem: GUI security tools (Burp Suite, Wireshark) require desktop access. VNC is slow and has security concerns. Native X11 forwarding is impractical over WAN.

Solution: Implemented XRDP with XFCE desktop. RDP provides better compression and encryption than VNC, and XFCE is lightweight enough for responsive remote sessions. SSM Session Manager provides fallback access.

Lesson Learned: Plan for GUI access from the start. Security professionals need visual tools, not just CLI.

Results & Metrics

Deployment Metrics

Provisioning Time:

• Infrastructure creation: ~2 minutes
• Tool installation (user-data): ~15 minutes
• Total time to operational lab: <20 minutes

Resource Utilization:

• Attacker: t3.medium (2 vCPU, 4GB RAM) - adequate for most tools
• Target: t3.medium - sufficient for vulnerable services
• Storage: 90GB total (60GB attacker + 30GB target)

Cost Analysis

Running Costs (us-west-1):

• EC2 (2x t3.medium): ~$0.083/hour = ~$60/month if 24/7
• EBS Storage: ~$7/month
• Data Transfer: Minimal (internal VPC traffic)

Optimized Usage:

• 4 hours/day testing: ~$10/month
• Weekend-only usage: ~$5/month
• Stopped when idle: $7/month (storage only)

Cost vs. Alternatives:

• Local hardware: $2000+ upfront for capable laptop
• Cloud security labs (HackTheBox, etc.): $15-50/month
• This solution: $5-15/month with full customization

Security Testing Capabilities

Supported Scenarios:

• ✅ Network penetration testing
• ✅ Web application testing
• ✅ Password attacks and cracking
• ✅ Active Directory simulation (with additional setup)
• ✅ Privilege escalation practice
• ✅ Reverse shell development
• ✅ Tool development and testing

Not Included (by design):

• ❌ Wireless testing (no physical hardware)
• ❌ Physical security testing
• ❌ Large-scale network simulation

Key Takeaways

1. Cloud Labs Enable On-Demand Security Practice

The ability to spin up a complete security lab in 20 minutes transforms how security skills can be practiced. No hardware investment, no VM management overhead, no laptop fan noise during password cracking.

2. Ubuntu + Kali Repos > Pure Kali

Using Ubuntu LTS as a base with Kali repositories provides better stability than pure Kali. Critical for cloud instances where you can’t easily recover from a broken package upgrade.

3. IMDSv2 Should Be Default

Instance metadata service v2 should be required on all EC2 instances. The performance impact is negligible, and it blocks an entire class of SSRF-based credential theft attacks. Made this a standard in all my Terraform modules.

4. SSM Session Manager is Underutilized

AWS SSM provides shell access without opening any inbound ports. Combined with IAM authentication, it’s more secure than SSH with key management. Should be the default access method for cloud instances.

5. Tag Everything for Cost Visibility

The Lab=security-lab tag enables precise cost tracking and easy cleanup. Can filter AWS Cost Explorer to see exactly what the lab costs, and use tag-based IAM policies for access control.

Future Enhancements

Phase 2: Expanded Target Environment

Additional Targets:

• Windows Server (AD environment simulation)
• Vulnerable web applications (DVWA, WebGoat, Juice Shop)
• Container environment (Docker security testing)
• Kubernetes cluster (k8s security assessment)

Network Complexity:

• Multiple VPC subnets (simulating network segmentation)
• VPN connectivity (testing VPN security)
• Load balancer target (WAF bypass testing)

Phase 3: Automation & CI/CD

Lab Management:

• Scheduled start/stop (cost optimization)
• Snapshot-based reset (clean slate for each session)
• Terraform workspace per scenario
• GitOps deployment triggers

Tool Updates:

• Automated tool version updates
• Custom tool deployment pipeline
• Wordlist synchronization

Phase 4: Purple Team Capabilities

Defensive Integration:

• CloudWatch Logs agent on target
• GuardDuty monitoring of lab activity
• Security Hub findings from attacks
• SIEM integration (Splunk/ELK)

Attack Detection:

• Correlate attacks with detections
• Develop detection rules from lab activity
• Purple team exercise automation

Resources

Project Links

• Repository: hmbldv/aws-sec (terraform/infrastructure/)
• Related Project: AWS Security Infrastructure Foundation

Tools Documentation

• Metasploit Framework
• Nmap Reference Guide
• Impacket Examples
• CrackMapExec Wiki

AWS Security Resources

• EC2 Instance Metadata Service v2
• AWS Systems Manager Session Manager
• Security Groups Best Practices

Learning Resources

• HackTheBox - Similar cloud-based labs
• TryHackMe - Guided security learning
• OSCP Certification - Industry standard pentesting cert

---

This project demonstrates proficiency in: Security Testing Infrastructure • Offensive Security Tools • AWS EC2 & Networking • Infrastructure as Code • Cost Optimization • Purple Team Operations

Part of the AWS Security Infrastructure ecosystem—see Foundation Project for state management and CI/CD