Cloud Infrastructure Penetration Test: AWS S3 & DynamoDB Exploitation

As organizations rapidly migrate to the cloud, misconfigurations in storage buckets and NoSQL databases have become a primary attack vector. This case study details a comprehensive penetration test conducted on a simulated cloud-integrated environment (Hack The Box “Bucket”), demonstrating a full attack chain from initial reconnaissance to root privilege escalation.

🎯 Scope & Objective

• Target: Linux-based server integrating cloud-like services (AWS S3, DynamoDB).
• Objective: Identify vulnerabilities, exploit misconfigurations to gain unauthorized access, and provide actionable remediation strategies.
• Result: Successfully compromised the system, achieving full root access and extracting sensitive SSH keys.

⚔️ The Attack Chain (Kill Chain)

The penetration test followed a structured approach, uncovering a critical chain of misconfigurations that allowed full system compromise.

Phase 1: Cloud Storage Misconfiguration (S3)

Initial reconnaissance revealed an exposed AWS S3 bucket endpoint integrated with the web application. The bucket was configured with overly permissive Access Control Lists (ACLs), allowing unauthenticated anonymous access.

• Exploitation: I successfully uploaded a malicious PHP payload to the bucket. Due to an insecure synchronization mechanism between the S3 bucket and the backend Apache server, the uploaded backdoor was moved to the web root and executed, granting the initial reverse shell (www-data).

Phase 2: Internal Reconnaissance & DynamoDB

Once inside the system, internal enumeration revealed a locally running instance of DynamoDB accessible without authentication (http://127.0.0.1:8000).

• Exploitation: By interacting with the local DynamoDB API, I was able to manipulate database tables used by an internal application. This application processed user input to generate PDF reports.

Phase 3: Privilege Escalation via PDF Generator

The internal backend application contained a severe vulnerability in its PDF generation logic. By injecting malicious payloads into the DynamoDB tables, I forced the application to parse external entities and execute local file reads.

• Exploitation: I crafted a payload that tricked the PDF generator into reading the local system file /root/.ssh/id_rsa. Extracting the root user’s private SSH key allowed me to log in directly as root, completing the full system compromise.

🛡️ Remediation & Mitigation Strategies

Exploiting the vulnerabilities is only half the job. Based on the findings, I provided the following technical recommendations to secure the infrastructure:

1. Secure S3 Bucket Policies:
   • Disable anonymous uploads to the S3 bucket.
   • Implement strict IAM (Identity and Access Management) roles, ensuring the Principle of Least Privilege (PoLP).
   • Isolate the upload directory from the web server’s execution path to prevent PHP interpretation of uploaded files.
2. Database Access Control:
   • Bind DynamoDB instances to authenticated interfaces only. Block unauthenticated local access to table creation and modification endpoints.
3. Application Security (PDF Generator):
   • Implement strict input validation on the backend before processing data into PDF documents.
   • Disable the ability for the PDF generator engine to read local file paths (e.g., restricting file:// wrappers) to prevent Local File Inclusion (LFI) and sensitive data exposure.