How Shadow APIs Simplify Automated Attacks

The term shadow API can convey a sense of a complicated, nebulous object, which doesn’t necessarily convey the security risks when they are discovered in the wild. The reason attacks on shadow APIs are so effective is that they exploit seemingly innocuous mistakes in development and asset management control. These mistakes are frequently abused by bots, who rely on the lack of API visibility among the defenders. With the understanding that you cannot protect what you cannot see, let’s take a look at two recent customer examples of attacks on shadow APIs.

Shadow API Exposes Improper Access Control

One of the techniques we see is attackers bypassing incumbent bot protection by first scanning for obscure, yet subtle deviations on known login APIs. For a given login API, such as /api/auth/login, an attacker will probe the server for valid failed/successful login responses using subtle deviations like:

• /api/auth/login1
• /api/auth/login/
• /api/auth/login%2A
• /api/auth/login

These API deviations, particularly the trailing slash or dash, can be particularly difficult to detect and mitigate as those are common characters used in API creation, and are not an obvious anomaly. The request payloads also look identical to the valid login endpoint, as attackers are simply trying to carry out a credential stuffing attack here, not any kind of malicious command injection. During an attack on a shadow API, typical monitoring systems that track legitimate applications and microservices traffic may not spot any anomalies, and the first indicator for a network defender could be a spike in queries to post-authentication services like user profile or gift card information. This would be an indication of an attacker scraping information after they have successfully executed an account takeover via the shadow API. Attackers can take advantage of this lag in discovery and response to “step on the gas” and ramp up their attack volume, exploiting the improper access control API flaw with a basic bot.

Shadow API Under Attack: 1000% Traffic Spike

A recent attack on a customers’ shadow API saw nearly 20 million requests per week attempting credential stuffing via shadow APIs, which represented a 1000% increase in traffic relative to legitimate login volume. Bot attacks like this can bypass basic access controls like geo-fencing and rate-limiting by making two very simple modifications.

1. Use residential or Bulletproof Proxies to mask true location by routing traffic through the most-used country of the target.
2. Randomize URIs used in the attack to avoid IP address and URI-based rate limiting. Bots simply need to send a single request per IP address to a unique URI, which is still responding from the same microservice. The attacker takes advantage of the improper access control and randomizes URIs, attacking /api/auth/loginabc123, /api/auth/logindef456, etc., rendering rate-limiting useless.

Improper API Inventory Management

The second example of shadow APIs under attack is in a microservices environment that is hosting two different APIs developed and maintained by two different teams with overlapping responsibilities for a critical application like payment processing and checkout.

One team might have been the first to market with this API, while the second worked on a more robust, feature-rich version which would eventually represent the go-to API. But the organization cannot afford to wait for the perfect API to begin processing and fulfilling orders, which means that live traffic may be hitting both APIs for a period of time. As the go-to API rolls out across the enterprise all human traffic will eventually interact with it, while the early version may be limited to old versions, perhaps for a mobile app. The risks arise when the early API is not disabled or deprecated because it may negatively affect conversion rates. This API is on its way to becoming a shadow API, and as most attacks move to newer APIs, the defensive attention shifts as well, leaving shadow APIs ripe for abuse.

Shadow API Under Attack: 28X Traffic Spike

One of our customers recently saw an attack on their gift card API that saw a 28X daily spike to 1.8 million daily malicious requests attempting to steal gift card information from customers. In this example, attackers had exploited the duplicate shadow API and routed their traffic through IPVanish, a low cost, no logs or connection limits VPN provider.

While shadow APIs may be a relatively new term in the market, the attack trends observed by the threat research team indicates it is impossible to decouple API security from bot protection. In the cases described above, shadow APIs are a security problem, that quickly becomes both a development and bot problem.

Uncovering Attacks on Shadow APIs

As the name implies, attacks on shadow APIs often appear out of nowhere. The known APIs commonly used by both legitimate users and bots will not display any abnormal activity or signs of attack. Instead, the abnormal behavior will appear as mysterious indicators or issues with services residing deeper in the infrastructure. For example, if you’re under a bot attack through a shadow API, you may observe:

• Spikes in user database connections are indicative of more users logging in
• Spikes in queries to post-authentication microservices like gift card balance checking, profile details, and any type of value a fraudster might be after post-login.
• For online retailers, shopping bots will frequently attempt to find shadow APIs to checkout coveted goods. In this case you would observe stress on backend inventory databases, anomalous spikes in out-of-stock errors, and availability issues that seem to be coming out of nowhere.

During this attack, many of the systems that are monitoring a specific login/signup/checkout endpoint that humans use will not be reporting anything out of the ordinary, making pinning down the attack and stopping it difficult. Oftentimes, by the time the attack is identified, the bot operator seen success and has found other shadow APIs to target. By the time you pin down and shut off the initial shadow API abuse, the attacker has hopped to a different shadow API under the assumption that shadow APIs are endemic across the development organization. More often than not, the attacker has assumed correctly.

How Cequence Can Help

In both of these examples, the Cequence API Security platform was able to help our customers fend off the attack. The platform integrates seamlessly with your API management infrastructure to perform runtime identification and inventory of all public-facing and internal APIs – including those considered shadow APIs. Once the APIs are discovered, risks are identified for remediation using predefined and custom assessment rules. Automated threats are blocked automatically based on our patented, ML-based Behavioral Fingerprinting that determines if the transactional intent is malicious or legitimate.