Why Your Deprecated Endpoints Are an Attacker’s Best Friend: The Rise of Ghost APIs

Summary

Ghost APIs are deprecated endpoints that remain live and accessible in production, creating a structural security gap distinct from shadow APIs. Unlike shadow APIs (unknown to the organization), ghost APIs are officially deprecated but never actually decommissioned, leaving legacy endpoints that predate modern authentication like MFA and zero-trust vulnerable to exploitation. Real-world incidents including the 2022 Optus breach (9.5M records) and 2023 T-Mobile breach (37M accounts) demonstrate attackers discovering these forgotten endpoints via directory brute-forcing, archive caching, and AI-assisted reconstruction, with remediation requiring traffic analysis, dependency mapping, and identity-based enforcement.

Full text

SecurityWhy Your Deprecated Endpoints Are an Attacker’s Best Friend: The Rise of Ghost APIs Ghost APIs are deprecated endpoints left active, exposing systems to attack. Learn how they differ from shadow APIs and why they create hidden security risks byArunkumar MathiyazhaganApril 13, 20268 minute read Key Takeaways Ghost APIs are deprecated endpoints that remain live and accessible; policy says dead, reality says otherwise. Unlike Shadow APIs (unknown to the org), Ghost APIs are known but never enforced off. Legacy endpoints predate MFA, zero-trust, and modern auth, making them ideal attack targets. GenAI tools can reconstruct deprecated API structures from public training data in minutes, lowering the attacker’s effort bar dramatically. Real-world breaches, including the 2022 Optus incident exposing 9.5 million records, trace directly to forgotten, unenforced API endpoints. – Three actionable steps: traffic analysis via service mesh, scream testing, and identity-based enforcement. Imagine a bank that upgraded its mobile app three years ago. The old v1/transfer endpoint was deprecated and removed from documentation, but the server was never decommissioned. Today, an attacker uses a cached version of that old app to bypass modern MFA because the Ghost API still honors the old security protocols. No alert fires. No anomaly is flagged. The endpoint was supposed to be dead. It was not. This is not a hypothetical edge case. It is a pattern playing out across cloud infrastructure at scale, and the industry has no reliable answer for it. Consider the 2022 Optus breach: an API endpoint originally built to serve customer data via a subdomain was rendered effectively unauthenticated by a coding error introduced in 2018. The endpoint was never deprecated, never removed, and never monitored. Four years later, an attacker discovered it, queried it without credentials using nothing more sophisticated than trial and error, and walked away with the personal records of 9.5 million Australians. The Australian Communications and Media Authority later noted that Optus had at least three prior opportunities to identify and fix the issue before it was exploited. None of them were taken. Ghost APIs’ legacy endpoints that remain accessible long after they have been officially deprecated represent a growing and largely unaddressed security debt. They are not a niche problem. They are a structural failure in how cloud-scale systems manage their own lifecycle. Ghost APIs vs. Shadow APIs: Not the Same Problem These two terms are often conflated. The distinction matters. Shadow APIGhost APIVisibilityUnknown to the organizationKnown; officially deprecatedDocumentationNever documentedRemoved from docsStatusUngoverned from birthPolicy says dead; reality says liveRoot causeGovernance gapEnforcement gap Shadow APIs are a discovery problem. Ghost APIs are an enforcement problem. You cannot fix a Ghost API by improving your API catalog; it is already in the catalog, marked deprecated. The failure is that marking it deprecated did nothing to make it inaccessible. The Deceptive Safety of “Deprecation” Every API has a beginning. Few have a clean ending. As organizations adopt microservices and accelerate release cycles, API surfaces expand rapidly. Each new service version introduces new endpoints. Older versions linger. Teams migrate forward, documentation gets updated, but the endpoints themselves often remain reachable, quietly responding to requests that no one is actively monitoring. Deleting a deprecated API at cloud scale requires answering a question that is surprisingly hard to answer with confidence: Is anyone still using this? In large distributed systems, the answer is rarely obvious. Consumers are spread across teams, organizations, and sometimes third-party integrations. Dependencies are partially documented at best. Long-tail usage of infrequent calls from legacy workflows can persist for years past official deprecation timelines. This creates a rational but dangerous incentive: keep the API alive rather than risk breaking something unknown. At scale, lifecycle management becomes a coordination problem that no single team can solve manually. The result is a widening gap between what the architecture is supposed to look like and what is actually running in production. The T-Mobile API breach of 2023, in which an attacker silently exfiltrated data from 37 million accounts over 40 days through an insufficiently governed API, illustrates how long these gaps can go undetected even at organizations with dedicated security teams. Several dynamics reinforce this failure: Long-tail consumers continue using deprecated endpoints well past announced timelines Dependency maps are incomplete, even in organizations with strong documentation practices Removal carries asymmetric risk: the cost of breaking a consumer is immediate and visible, while the cost of leaving an endpoint alive is diffuse and delayed AI-assisted development tools code completion, LLM-based copilots can silently resurrect deprecated API calls by drawing on training data that predates the deprecation, generating code that references endpoints the developer never knew existed API governance frameworks address naming, versioning, and lifecycle policy. They do not enforce runtime behavior. A policy that says “this API is deprecated” does not make the API inaccessible. How Attackers Find Ghost APIs Readers often assume that a removed documentation page means a removed endpoint. Attackers know better. Here are the techniques commonly used to surface Ghost APIs: Directory brute-forcing. Automated tools probe for predictable versioning patterns – /v1/, /v2/, /beta/, /legacy/, /test/ – against live hosts. If the server responds, the endpoint is live regardless of what the docs say. The Wayback Machine. Archive.org and similar services cache old API documentation, SDK changelogs, and developer portal snapshots. An attacker can retrieve the full endpoint structure of an API as it existed two or three versions ago, then probe the live system to see what still responds. Hardcoded and weak credentials. Older endpoints frequently rely on static API keys, basic auth, or weaker token schemes that predate modern credential management practices. These are easier to extract from old client binaries, mobile apps, or public repositories, and the Ghost API will often still accept them. GenAI-assisted reconnaissance. This is where the threat surface has shifted materially. Large language models trained on public data from GitHub repositories, Stack Overflow threads, developer blogs, and archived changelogs have absorbed years of API documentation that organizations assumed was gone. An attacker can prompt an LLM to reconstruct the likely endpoint structure, parameter names, and authentication patterns of a deprecated API based on nothing more than the service name and approximate era. What previously required hours of manual research across archived sources can now be done in minutes. LLMs also accelerate the generation of targeted brute-force wordlists, crafted specifically for a given company’s naming conventions rather than generic patterns. The combination is powerful: find the old endpoint via archived docs or LLM-assisted reconstruction, authenticate with a credential extracted from an old app, and bypass every security control that was added to the current API version. Why Ghost APIs Break Zero-Trust Legacy APIs are not just technical debt. They are active security liabilities. APIs built years ago predate modern security controls. Authentication mechanisms have evolved. MFA requirements have tightened. Zero-trust architectures have replaced implicit trust models. But a ghost API from five or ten years ago carries none of those improvements. It operates under the security assumptions of the era in which it was built. This creates a structural misalignment. API security risks frequently surface through outdated interfaces precisely b

Indicators of Compromise

• mitre_attack — T1526 — Discovery
• mitre_attack — T1589 — Gather Victim Identity Information
• mitre_attack — T1190 — Exploit Public-Facing Application

Entities