Cloud Penetration Testing

1.1. Define Objectives and Scope

• Objectives: What is the primary goal? (e.g., "Assess the security of our production EKS cluster," "Validate segmentation between dev and prod VPCs," "Determine if an unauthenticated user can access customer data in S3.")
• In-Scope Assets: Clearly enumerate all target assets.
• Examples: Specific VPCs/VNets, subnets, IP ranges, FQDNs, storage buckets (S3, Blob), serverless functions (Lambda, Azure Functions), container clusters (EKS, AKS, GKE), database instances (RDS, SQL Azure), and IAM roles.
• Out-of-Scope Assets: Explicitly define what not to test.
• Examples: The CSP's underlying infrastructure (this is the provider's responsibility), other tenants' assets, production systems during peak hours, denial-of-service (DoS) attacks.

1.2. Understand the Shared Responsibility Model

• The test must be scoped only to the "Customer" side of the shared responsibility model.

1.3. Establish Rules of Engagement (ROE)

• Permission: Obtain signed contracts and CSP-level approval.
• Testing Window: Define specific dates and times when testing is permitted.
• Communication Channels: Set up a dedicated channel (e.g., shared Slack, email alias) for real-time communication, especially for critical findings or if a system is inadvertently impacted.
• Data Handling: Define procedures for handling any sensitive data discovered. The goal is to prove access, not to exfiltrate large volumes of PII.

2.1. External Reconnaissance (OSINT)

DNS Enumeration:

• Identify subdomains, FQDNs, and their corresponding IP addresses.
• Look for records pointing to cloud assets (e.g., load balancers, S3 buckets).

Public Asset Discovery:

• Storage: Search for publicly accessible S3 buckets or Azure Blob containers (e.g., using s3scanner).
• Code Repositories: Scan public GitHub/GitLab repositories for leaked API keys, access tokens, or configuration files.
• Identify Cloud Services: Determine which CSP and services are in use (e.g., CNAME records pointing to *.amazonaws.com).

2.2. Cloud-Specific Reconnaissance (Enumeration)

Network Enumeration:

• Port scan in-scope public IP addresses (nmap) to identify exposed services (e.g., SSH, RDP, databases).

API & Metadata:

• Identify authentication endpoints (e.g., AWS Cognito, Azure AD).
• Note the instance metadata service IP (169.254.169.254). This is a key target for Server-Side Request Forgery (SSRF) attacks.

Tools:

• CloudMapper, ScoutSuite, and Pacu can be used (with credentials) to visualize and enumerate cloud environments.

3.1. Configuration Auditing (Key Focus Area)

Identity and Access Management (IAM):

• Check for overly permissive roles and policies (e.g., *:*).
• Look for privilege escalation paths (e.g., a role that can iam:PutUserPolicy or sts:AssumeRole on a more powerful role).
• Audit for lack of MFA on root/admin accounts.
• Enumerate users, roles, and policies to map permissions.

Network Security:

• Audit Security Groups (AWS) / Network Security Groups (Azure). Look for overly broad rules (e.g., 0.0.0.0/0 open on port 22 or 3389).
• Analyze VPC/VNet peering and routing tables to map potential lateral movement paths.

Storage Security:

• Systematically check all storage buckets/containers for public read/write access.
• Check for unencrypted S3 buckets, EBS volumes, or RDS instances.

Logging and Monitoring:

• Check if essential logging (e.g., CloudTrail, VPC Flow Logs) is enabled, comprehensive, and protected from tampering.

3.2. Automated & Service-Specific Scanning

VM/Instance Scanning:

• Run authenticated and unauthenticated vulnerability scans (e.g., Nessus, Qualys) on EC2/VM instances.

Container Security:

• Scan container images (e.g., in ECR/ACR) for known vulnerabilities.
• Check for Kubernetes misconfigurations (e.g., exposed Kubelet API, anonymous access, insecure RBAC policies).

Serverless (Lambda/Functions):

• Scan function code for vulnerabilities (e.g., injection, insecure dependencies).
• Audit function execution roles for excessive permissions.

4.1. Gaining Initial Access

Leaked Credentials:

• Use API keys or service principal credentials found during reconnaissance to access cloud APIs (e.g., using aws-cli or az-cli).

Exposed Services:

• Brute-force or use default credentials on public SSH, RDP, or database ports.
• Exploit web application vulnerabilities (e.g., SQLi, RCE) on applications hosted in the cloud.

SSRF:

• Exploit a web application's SSRF vulnerability to query the internal metadata service (169.254.169.254) and steal temporary credentials (IAM roles) from the underlying instance.

Misconfigured Storage:

• Write a webshell to a public-write S3 bucket that hosts a website, or read sensitive data from a public-read bucket.

4.2. IAM Privilege Escalation

• Once initial access is gained (e.g., a low-privilege IAM role from a compromised EC2 instance), attempt to escalate privileges.
• Use tools like Pacu (e.g., iam__privesc_scan module) to identify and exploit misconfigured policies that allow a user to grant themselves higher permissions.

4.3. Post Exploitation

• This phase simulates the actions an attacker takes after successfully gaining an initial foothold within a system or network.
• Note: This sophisticated level of testing will only be executed with explicit, documented authorization.

4.3.1. Lateral Movement

• Use the credentials from a compromised instance (e.g., via the metadata service) to access other cloud services (e.g., pivot from an EC2 instance to an RDS database it has access to).
• Move between subnets or VPCs if network security rules are too permissive.
• Use compromised credentials to dump data from storage or databases.

4.3.2. Persistence

• Create Backdoors:
• Modify Services:

4.3.3. Data Exfiltration (Proof-of-Concept)

• Simulate, do not perform full exfiltration.
• As a proof-of-concept, copy a single, non-sensitive file from a private S3 bucket to an attacker-controlled public bucket to demonstrate that data exfiltration is possible.

5.1. Reporting

Executive Summary:

• A high-level overview for management, focusing on business risk, key findings, and the overall security posture.

Technical Report:

For each finding:

• Description: A clear explanation of the vulnerability.
• Attack Narrative: A step-by-step account of how the vulnerability was exploited.
• Evidence: Screenshots, logs, and code snippets.
• Impact: The potential business impact (e.g., "Data breach," "Full system compromise").
• Risk Rating: A score (e.g., Critical, High, Medium, Low) to prioritize.
• Remediation: Provide clear, prioritized, and step-by-step instructions for fixing each vulnerability.

Remediation and Re-testing

• Present the findings to the client in a debrief meeting.
• After the client has implemented the fixes, perform a re-test to validate that the vulnerabilities have been successfully remediated.