You can’t defend what you don’t know exists. Yet it’s precisely those active but unmonitored pieces of infrastructure that become the point of failure for so many organisations.

We’ve been living through a period of huge digital transformation and amid all of the new infrastructure and technology that has piled into the digital enterprise, things are bound to go missing. It’s those unwatched pieces of infrastructure which are still active within their environment that form an enduring breach point for attackers and a fatal Achilles’ heel for defenders.

Misconfigured AWS buckets continue to leak sensitive information while forgotten DNS and subdomains from decommissioned services continue to become key vectors for exploitation. These are spun up by developers without proper controls or oversight who then leave them, unmanaged and unseen by the broader organisation, waiting for an attacker to pounce on them.

How shadow APIs are born

We see a looming example of that in the Application Programming Interface (API). The API serves as a kind of connective tissue which links software and services together. This has unlocked incredible potential in software development, largely precipitated by huge platforms – Google, Amazon and others – opening up their APIs to third party developers so as to build an ecosystem of apps that can be used within those platforms.

Indeed, the API has become a mainstay of modern software development to the extent that API traffic now forms the majority of internet traffic today. Yet as useful as they might be to developers, without the proper controls, they become extremely useful to potential attackers too. Just as for legitimate parties, the API is basically a high-speed train from the front end of an application, directly to the back end. If those APIs are left undefined or without authentication or controls, then they’ll be accessible by pretty much anybody.

And yet in many cases, that’s exactly what happens. Developers will spin up APIs with no broader oversight over the process and leave them there, undocumented, unmonitored and often without any controls or authentication to police who can access them and what they can access.

Thus, a shadow API is born. As an organisation further digital transforms, these rogue APIs get buried under other infrastructure, and their functions may be moved to newer API deployments. However, those shadow APIs linger there, unknown even to their owners and open to access by unauthorised parties.

Organisations may later improve their API handling and start implementing controls for new API deployments and meticulously cataloging them but as long as those old shadow APIs linger there, they remain a threat.

Cybercriminals on the hunt

Cybercriminals are actively looking to exploit them. Indeed, attackers will use various tools to brute force API paths and see if the targeted server responds with valid data that might reveal the presence of a shadow API. Others will merely guess API paths from the available system information they can gather. One study from Cequence shows in their analysis that roughly a third of malicious API requests directly targeted shadow APIs. When they do find those shadow APIs, they’ll be able to penetrate deep into the heart of its targeted organisation.

The problem seems widespread. Salt Security research shows that only around 25% of large organisations have full oversight over their APIs, while only 12% of small organisations do. On top of that, nearly three quarters of CISOs admitted in the study that they regularly uncovered APIs they had no idea existed and around 90% can’t confirm that they’re free of unmanaged APIs.

This is why traditional solutions for API discovery fail in this situation. These will require you to first pick a URL, upload an API specification and then run the scan. But shadow APIs were never documented, monitored, tracked or inventoried in the first place. A different strategy is required to tackle this risk.

How to find a shadow API

Even if the exact location of an API can’t be located – their behaviour and activity can still be detected within the environment through Network Traffic Analysis (NTA). In fact, the traffic metadata will reveal a huge amount about the presence and behaviour of a shadow API.

By taking metadata such as hostnames, subdomains, URL paths, HTTPS methods, response codes and authentication indicators, it can be established whether that traffic is actually hitting an endpoint. If the traffic hits an endpoint, we can be sure it exists.

That information can then be compared against a real inventory of APIs. From there, those API endpoints that have traffic flowing to them, but aren’t included within the inventory or Open API specifications thus making them shadow APIs.

That metadata will also contain key information not just about the presence of a Shadow API, but how much risk it poses too. For example, it can reveal the endpoint’s authentication status, what it can access and how often it is used.

Once that shadow API has been found, it can be scanned using an API Dynamic Application Security Testing (DAST) tool to find out whether it is actually exploitable and then brought under existing API management processes.

Digital transformation is often a far less controllable process than we would like to believe. The speed of development often far outpaces our ability to consciously secure and organise those developments. APIs are just such an example, and many have been put there and then quickly forgotten, remaining unwatched, unmonitored and unmanaged. Where traditional API discovery methods will fail to discover shadow APIs, network traffic holds the key to unearth this lurking threat.