APIs have become very popular attack targets, and almost all the attacks we see against API endpoints leverage large-scale, federated botnets. The attack methods haven’t necessarily changed all that much in recent years, but the attacks have become automated, sophisticated, and evasive through the use of software robots.
In case you’re just coming up to speed on this attack vector, we’ll start with some back story:
What is a bot?
A bot is just a software robot — a program that does some task, usually operated over a network to automate a specific task. You probably have bots in your infrastructure that monitor systems, or that kick off builds, or that run test automation in your CI/CD pipeline. Bots have taken much of the drudgery out of system administration and service delivery, as has been the promise of robotics since humans first dreamed of a world where automatons cooked our meals and mowed our lawns.
Isaac Asimov famously built “don’t harm humans” into the firmware of robots in his futurist worlds. But the bots we’re worried about don’t necessarily follow Asimov’s First Law of Robotics.
These are bad bots, written to automate nefarious activities, written to poke and probe and prod legitimate systems for weakness, written to take the drudge work out of cyber-crime.
In flagrant violation of Asimov’s famous admonition, these bots are designed for attacks, and as the state of the art has advanced, cyber criminals are also using bots for scaled attacks, reconnaissance, discovery, and evasion.
Scaled attacks, aka botnets
A single software robot can do a lot of damage, but it’s slow, and often easy to detect and block. Smart attackers get around this by cleverly conscripting many computers into a network of systems, each running some variant of an attack. These networks of systems are the “botnets” you’ve heard so much about. Attackers build, buy, or rent botnet capacity and construct their bots in such a way that they operate across a federated bank of systems, each with its own IP address. In this way, they both increase the speed, frequency, and intensity of their attacks, and reduce the collateral damage to their own criminal efforts if a single node in that network is discovered and blocked.
The scale of these botnets can be staggering, and attackers use this scale three ways: First, they federate their recon activities, allowing them to build a dossier on a site very quickly. Second, they often generate overwhelming noise to distract defenders and defensive systems alike, hiding their REAL intent in a stream of traffic generated by hundreds or thousands of bots. And third, they use those same legion systems to bring legitimate systems to their knees, overwhelming them in the all-too-familiar distributed denial of service attack.
Using bots for discovery
We have observed attackers spending a lot of time in the reconnaissance stage of attacks recently, especially with APIs, which typically expose more business logic, and through that expose more data or PII. Attackers use bots in this phase because it allows them to quickly explore, gather information, and test things out without being detected.
For instance, when trying to identify a valuable or vulnerable target, attackers will frequently use a botnet distributed across thousands of hosts. Because each host has a unique IP address, and because traditional defensive systems use IP addresses as the primary control plane, this recon work often goes unnoticed. Consider a security team observing a single host (with a single IP address) trying to hit every URL or path – that’s obviously suspicious. But if that activity is distributed across multiple IP addresses, it looks like different users using different parts of the application. The nefarious activity wouldn’t be detected as quickly.
We often see this scenario play out when a new CVE is announced. If a security professional sees a potential attack pattern come through 500,000 times from a single IP address, that is obviously malicious. That bot gets blocked. But if the same attacker spreads the activity over hundreds or thousands of hosts in a botnet, each IP address remains below the threshold of detection, and the attack stays under the radar.
Ultimately, the attacker’s end goal is to use botnets and the scale they provide to avoid “being obvious” while they probe an API endpoint for weakness.
Using bots to attack
After discovery and reconnaissance, the attackers put the findings to use and launch an attack. Again, bots do the heavy lifting. And again, farming out the work to a federated network of attack bots can make the attack “low and slow” and thus hard for defenders to detect.
In the not-so-distant past, attacks were easier to spot. If you were hit with a DDoS or credential stuffing attack, you would see a huge increase in the number of IP addresses trying to reach your servers and either DDoSing you or trying to get login credentials. It’s easy to identify that as anomalous and suspicious activity. But today, we see a lot more low and slow attacks, where the attackers use a wide range of distributed IP addresses. Each IP address is only making one request, maybe every minute, or maybe even five minutes. These requests look legitimate, but they’re trying to steal credentials.
With the load distributed across multiple IP addresses this way, if one IP address gets blocked, there are thousands more ready to continue the attack. Alarmingly, this method is moving towards self-awareness, and we all know what happens when Skynet becomes sentient. In a credential stuffing attack, if the attackers know from their reconnaissance that after three failed login attempts, an IP address gets blocked, they’ll do two login attempts with one IP, then move to the next IP.
In the end, attackers can go much faster with the combination of hundreds of thousands of stolen IP addresses plus bots – they can get an API mapped, identify a vulnerable target, then target it, all without “losing” IP addresses.
Using bots for evasion
More and more, we are seeing attackers use bots as distraction so they can go after the real target unnoticed. To create this smoke screen, they’ll throw out a bunch of “obvious” attacks like DDoS, SQLi, or XSS, etc. These attacks will either overwhelm a security solution or trigger thousands of alerts that security has to chase down. Now the attacker’s real intentions are buried under the alerts. That real intention might be a more targeted attack like searching for a broken object level authorization or BOLA vulnerability on a particular API. With the security team distracted, the attacker can enumerate user IDs to figure out if an API has missing or broken authorization to get access to valuable data.
Check out our recent Live Q&A on Malicious Bots in Modern Threats.