The Ghost City: Why Orphaned Subdomains Are Your Best Entry Point

As Penetration Testers, we are used to banging our heads against the wall of the "Main Application." It’s hardened, it sits behind a WAF, it has rate limiting, and the API Gateway is locked down tight.

But while you are testing the front door, there is likely a window wide open around the back.

We call this the "Ghost City" effect. It’s the result of decades of corporate expansion, abandoned projects, and "temporary" solutions that became permanent. Specifically, we are talking about Shadow APIs residing on Orphaned Subdomains.

If you rely solely on the client's Swagger documentation, you are missing the softest targets within scope. Here is the architecture of the flaw, how to hunt it, and why automating this discovery is the key to finding Criticals faster.

The Anatomy of a Ghost API

To visualize this, imagine the client’s infrastructure is a sprawling corporate industrial park.

Layer 1: The Shining Headquarters (The Main App)

This is app.company.com. It is well-lit, heavily guarded, and has a clear map at the entrance (OpenAPI docs) showing exactly which doors lead where. Traffic flows evenly on paved roads. Breaking in here is hard work.

Layer 2: The Forgotten Outpost (The Orphaned Subdomain)

This is a legacy DNS record like api-dev-2021.legacy-subdomain.com.

  • The Origin: A dev team spun it up three years ago for a partner integration. The partner left, the project ended, and the developers moved on.

  • The Status: The "road" leading to it was removed (no links from the main site), but the building itself was never demolished. It still sits on company land (DNS) and is connected to the power grid (the network).

Layer 3: The Unlocked Loading Dock (The Shadow API)

This is the actual endpoint running on the outpost, like /v1/admin/getAllUsers.

  • The Invisibility: Because it was a "temp" project, no one created a map for it. Current IT doesn't even know it exists.

  • The Vulnerability: It was built for speed, not security. The developers intended to add authentication "later." Later never came.

The Attack Chain: From Fuzzing to BOLA

An attacker exploits this "Ghost Infrastructure" not by breaking a lock, but by finding the building everyone else forgot.

Phase 1: Discovery (Mapping the Ruins) The attacker realizes they cannot breach the HQ, so they look for forgotten property. Using Certificate Transparency logs (crt.sh) and passive DNS, they spot anomalies like test-api-staging.company.com. These resolve to live IPs but often return generic "404 Not Found" pages in a browser.

Phase 2: Probing (Rattling the Doorknobs) The attacker knows a server is there but doesn't have the Swagger docs. They have to guess. They point automated fuzzing tools at the orphaned subdomain using wordlists of common API paths (/api/v1/users, /graphql, /actuator).

  • The Hit: Suddenly, api-dev.legacy.com/api/v1/users returns a 200 OK and a JSON blob.

Phase 3: Exploitation (The Smash-and-Grab) The attacker realizes that this endpoint lacks the security controls of the main app.

  • The Vulnerability: The legacy API uses weak auth or has Broken Object Level Authorization (BOLA).

  • The Action: They modify the API call from /users/me to /users/1, then /users/2, dumping the entire customer database because the API never checks if the requester is authorized.

The Chain of Impact

Uncovering Shadow APIs on orphaned subdomains is often more damaging than attacking the main application.

  1. Massive PII Exfiltration (BOLA): Legacy debug endpoints often return full user objects (hashes, emails, phone numbers) without auth checks.

  2. Full Account Takeover (ATO): Finding a forgotten endpoint for password resets or session generation that lacks verification.

  3. Business Logic Abuse: An old e-commerce endpoint that processes orders without validating payment status.

  4. Zombie Tokens: A Shadow API that accepts valid production JWTs but enforces fewer restrictions, allowing lateral movement.

The "Why" for Pen Testers: The Map to the Ghost City

"We give you access to soft targets and bypass hardened defenses."

For a Penetration Tester, the value is Path of Least Resistance.

  • Automated Fuzzing Recon: Discovering a subdomain is easy; realizing it hosts a hidden /v1/admin API requires fuzzing. ThreatNG automates this identification, saving you hours of "blind guessing" against 404 pages.

  • The BOLA Goldmine: These "Zombie APIs" are the most likely places to find BOLA vulnerabilities. We point you directly to the logic flaws.

  • Bypassing the WAF: Often, these legacy subdomains sit outside the modern WAF configuration. You aren't just finding a vulnerability; you are finding a vulnerability that is completely undefended.

Ask Yourself:

  • "How do I discover API endpoints that have no Swagger documentation and no links from the main site?"

  • "Do my current tools differentiate between a 'Dead' subdomain and a 'Shadow API' that only responds to specific fuzzing patterns?"

  • "Am I testing for 'Zombie Tokens'—where a Shadow API accepts prod credentials but bypasses prod security?"

Stop banging on the front door. ThreatNG hands you the map to the unlocked loading dock around the back.

Previous
Previous

From Black Box to White Box: Weaponizing Developer Breadcrumbs

Next
Next

The Shadow Periphery: Finding the Cloud Buckets Your Client Forgot