Bots are lurking in your zombie and shadow APIs

By far this year’s biggest trend that we’ve observed in the land of APIs is that every organization has shadow and zombie APIs and they’re a much bigger issue than most people want to believe. Maybe they’re taking the “If I’ve never seen it, then it doesn’t exist” approach to API security. This is also known as the “If I don’t know about it, I can’t get blamed for the breach” approach. Either way, you’ll surely get bit in the you-know-what for not being more proactive.

Unmasking shadow and zombie APIs

Shadow APIs are the ones that are deployed without security teams’ knowledge, and often without adequate protections. Most security teams have a good understanding of the mission-critical APIs that they built to power their business applications. The trouble arises when third-party APIs are added in to provide additional functionality without being disclosed for security review, or API endpoints get deployed accidentally or with the intention that they’ll be cleaned up later (but rarely are).

Zombie APIs commonly arise when old and less secure versions of your APIs are left to live another day. There is usually some good business reasoning for leaving them accessible, such as “We can’t force updates because some of our customers have old devices.” But when V17/profile/edit requires authentication, and V3/profile/edit doesn’t, the only people who will end up smiling are the bot operators who make this discovery.

For some reason, finding shadow and zombie APIs seems to be a much easier task for bad actors than it is for internal security and risk teams. (Or maybe they’re just a bit more motivated.)

Hackers and attackers find these APIs through brute force enumeration using tools like Burp Intruder or fFuf and API reconnaissance like reading your external API docs or the accidently-left-accessible Swagger documentation which happens way too often!

We often see attackers attempt to bypass bot protection by looking for subtle deviations to known “good” APIs. For example, if the login API is /api/auth/login then the attackers will try variations that contain a trailing slash or dash which will be difficult to detect, such as:

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

Your unprotected APIs ARE being targeted

An accurate API inventory is necessary to ensure you’ve got adequate protections. If you don’t know an API endpoint exists, your bot mitigation tools can’t defend it. Most organizations truly have no idea how many APIs they have exposed. We did a survey recently and found that only 16% of organizations use an automated tool to inventory their APIs, while 64% took manual inventories. However, manual inventories are incredibly inaccurate. For instance, one customer’s manual inventory underestimated their APIs by 2.5X, creating a zombie(API)land.

Because most organizations have decent protections for their obvious login endpoints and other critical APIs, it’s the zombie and shadow APIs that have become the tasty treats that bots feast on. Some of the biggest attacks observed and blocked by our Bot Defense product have happened on shadow APIs. One was an attack on a duplicate gift card API that spiked total traffic by 28X, and another customer had a shadow API hit with 20 million requests over a weeklong credential stuffing attack that drove a 1000% increase in traffic.

Surviving the zombie apocalypse

If you don’t have bot monitoring or protection for your zombie and shadow APIs, how will you know that you have malicious activity on those APIs? Here are some things to look for that might indicate an attack against an unknown API:

• Spikes in user database connections which may signal that more users are logging in than usual
• Spikes in queries to post-authentication services like balance checking, profile details or any other service that might be of value to a fraudster
• Stress on backed databases, like a retailer’s inventory database, or spikes in errors

Unfortunately, if you do not have an API security solution in place that finds and protects your shadow APIs, then it is likely that, by the time you discover these kinds of attacks, the bot operator has already moved on to a new shadow API.

It is critical today that your API security and bot prevention solutions can adapt as quick as the bots and ensure long-term protection for your entire digital footprint. Consider solutions that are equally responsive to the changing threat landscape as well as your changing application environment. We have created this guide that walks you through the necessary criteria for API security and bot prevention solutions.

While Hollywood suggests that using the six F’s—Fight, Flee, Fire, Food, First Aid, and Fix & Repair—is the right plan for surviving a real zombie attack, surviving an attack on your zombie and shadow APIs requires the three Ds: Detect, Discover, and Defend. Detection starts with bringing all your shadow APIs into the light and ending those zombie APIs for the last time. It’s up to you whether you use a flamethrower, machete, or chainsaw to defend yourself.