Unauthenticated S3 Write Access to Remote Code Execution: Anatomy of a Cloud Misconfiguration

Executive Summary

This report documents a simulated penetration test conducted against a single externally facing Linux host, performed as part of a controlled training exercise on the HackTheBox platform. The objective was to assess the security posture of a web application backed by cloud object storage (AWS S3 compatible), identify exploitable weaknesses, and determine the real world impact of any findings.

During testing, a critical-severity vulnerability was identified: the application's backend S3 bucket which also served as the live webroot for the public facing website was configured with unauthenticated write access. This allowed an external, unauthenticated actor to upload arbitrary files directly into the production web directory, resulting in remote code execution (RCE) on the underlying host.

This finding mirrors a well documented class of real world cloud misconfigurations that have led to breaches at numerous organizations, and serves as a practical demonstration of why cloud storage permissions must be treated with the same rigor as traditional server access controls.

Key findings:

• Publicly writable S3 bucket serving as application webroot Severity: Critical. Impact: Unauthenticated RCE, full host compromise.
• Subdomain/vhost disclosure of internal storage endpoint Severity: Low–Medium. Impact: Information disclosure, attack surface expansion.

1. Scope and Rules of Engagement

• Target: Single Linux host (10.129.227.248), simulating a small business web presence for a fictional concert ticketing company ("The Toppers").
• Authorization: Testing was conducted exclusively within an isolated HackTheBox lab environment under explicit platform terms of use. No production systems were involved.
• Testing window: Black-box, no credentials or internal documentation provided at the start of the engagement.
• Goal: Identify and responsibly chain vulnerabilities to determine maximum achievable impact (flag capture used as the lab's proof of impact marker).

2. Methodology

The assessment followed a standard external penetration testing methodology:

1. Network and service reconnaissance
2. Web application enumeration
3. Subdomain / virtual host discovery
4. Cloud service interaction and configuration review
5. Exploitation and privilege verification
6. Post-exploitation impact confirmation

3. Technical Findings

3.1 Network Reconnaissance

An initial service scan was performed to fingerprint the attack surface:

Result: Two services were exposed:

• Port 22 — SSH
• Port 80 — HTTP (Apache)

3.2 Web Application Review

With no credentials available for SSH, the web service was selected as the primary entry point.

An initial request was made using curl with verbose output enabled, to inspect server headers and raw response behavior before engaging a browser:

This returned the full HTTP response headers alongside the page's HTML source, confirming the server identification and allowing inline inspection of the page markup without relying on browser dev tools. Reviewing this output revealed a static concert-ticket booking page with non-functional booking logic. The embedded form submission pointed to/action_page.php, and navigation confirmed the application's landing page was served at /index.php both consistent with a PHP-based backend.

The site's contact section referenced an email address under the domain thetoppers.htb, which was not yet resolvable. This was added to the local hosts file to allow name resolution during testing:

3.3 Virtual Host Enumeration

Given the custom domain, the host was assessed for additional virtual hosts sharing the same IP a common configuration where a single server differentiates applications based on the HTTP Host header.

Result: This enumeration disclosed a previously unknown subdomain, s3.thetoppers.htb, which was not linked from anywhere on the public site a form of information disclosure through infrastructure naming conventions.

After adding this subdomain to the hosts file, browsing to it returned:

3.4 Cloud Storage Configuration Assessment

Using the AWS CLI configured with arbitrary placeholder credentials (the endpoint did not enforce authentication), the storage service was queried directly:

This is the core vulnerability: a storage layer intended for static assets was both world-writable and directly executable by the web server, collapsing the separation between "data storage" and "code execution" that should exist in any secure architecture.

3.5 Exploitation

To validate impact, a minimal PHP web shell was constructed:

The file was uploaded directly to the bucket,Because the bucket was synced live to the public web root, the shell became immediately accessible and executable:

3.6 Post-Exploitation: Interactive Access

To move from a one-shot web shell to a stable interactive session, a reverse shell was staged:

Attacker-side listener:

Payload (shell.sh):

Payload delivery (hosted locally):

Triggered via the existing web shell:

3.7 Impact Verification

Access to a sensitive file at a fixed system path was used as the lab's confirmation of successful compromise:

4. Risk Analysis

Attack complexity:_ Low no authentication bypass or advanced tooling required Privileges required: None User interaction: None Impact: Full remote code execution, complete compromise of web host Exploitability: Trivial once misconfiguration identified_

This finding is representative of a broader, well documented category of real world incidents where organizations have suffered data breaches due to improperly scoped S3 bucket permissions including cases involving publicly writable buckets, missing authentication on internal storage APIs, and buckets serving as direct application code repositories.

5. Recommendations

1. Enforce least-privilege bucket policies. Storage buckets backing production applications should never allow public or unauthenticated write access. Write access should be restricted to specific IAM roles tied to the deployment pipeline.
2. Separate storage from execution. Static assets served from object storage should be isolated from any directory the web server treats as executable. User-uploaded or dynamically-synced content should never share a path with interpretable code (e.g., .php, .jsp, .asp).
3. Avoid exposing internal infrastructure via guessable subdomains. Internal service endpoints (storage APIs, admin panels, staging environments) should not be discoverable through predictable naming patterns, and should sit behind network-level access controls, not obscurity alone.
4. Implement Web Application Firewall (WAF) rules to detect and block uploads of script files to object storage endpoints exposed to the internet.
5. Regularly audit cloud storage configurations using automated tools (e.g., AWS Config, Scout Suite, Prowler) to catch public-write misconfigurations before they reach production.