After spending years working in “the pit” for Fortune 500 companies on security operations and engineering, I did a long stint as a penetration testing consultant. I hacked into everything from banks to law firms, to insurance companies, major global retailers, and eventually into the industrial security sector.

Automation is a critical component of every one of these roles. It is impossible to deal with enterprise-scale attack surfaces without leveraging computers to do the heavy lifting. When the work becomes insurmountable, we build…

Bots. Botnets. Scrapers. Vulnerability Scanners. As an operations analyst, IT engineer or even as a member of your organization’s marketing team, you likely see these terms come across your desk on a weekly basis. Unfortunately, they’ve become an accepted aspect of doing business on the Internet. These attacks are the white noise of the Internet. Automated intrusions are by far the most common attacks leveraged against an organization, and for good reason. Computers don’t ever have to stop to eat, sleep, or go to work. And sure as heck they don’t get bored or demotivated. Even when you’re being targeted by a malicious human being, they’re almost always going to leverage automated attack tools against your web infrastructure. In fact, the better and more modern your defenses, the greater your chance of being the victim of bot attacks, due simply to the sheer level of attempts necessary to find a way around them.

But why are these attackers even out there in the first place? Why invest the time and effort in creating this automated nightmare? The most common answer is an obvious one: money. Time and money in, and (hopefully) exponentially more money out. Literally a “Bot Economy.” Using automation reduces the “Time In” aspect, allowing a single creation to be leveraged against infinite targets while simultaneously exponentially increasing payout potential by increasing target count. While this is certainly not the only reason, it’s the one we end up dealing with the most here at Kasada. These cash-incentivized attacks generally come in four forms:

  • Account Takeover “ATO”: Automated attempts to compromise legitimate users’ accounts, usually via the use of credentials from recent breach leaks, wordlist-based password attacks, or straight brute forcing. The end goal of this is usually to directly or indirectly access funds associated with compromised accounts.
  • Intellectual Property Theft “Scraping”: Many companies such as hotels, real estate organizations and airlines openly host data on their websites, which is free for perusal by the general public. This is good for business. But many nefarious organizations (yes, sometimes these are even competitors) will take advantage of this situation by scraping the data en masse, making off with an ocean of information to be leveraged or sold.
  • Fraudulent Purchasing “Sniping / Scalping”: The use of automated methodologies to legitimately purchase goods such as sneakers and event tickets, usually for the purpose depleting the stock and reselling them at a higher price.
  • Obfuscating stolen funds “Money Laundering”: Abuse of “loyalty” or other programs to use stolen funds or credit cards to purchase difficult-to-trace spending mechanisms such as cryptocurrency, gift cards or “points.”

Generally, the process of automating an attack against a robust, modern target application looks like this:

  1. Reverse-engineer the target site or application to the extent necessary for the creation of a bot that can interact with undetected. This often means identifying the weakest target that still delivers the desired output, such as the Backend APIs which often are not subjected to the same security measures as user-facing login forms, etcetera. For more modern websites, this routinely requires a bot that can handle cookies and execute JavaScript. Many free toolkits and frameworks already exist for this, such as Selenium, PhantomJS, and others. Sometimes headless browsers are used, or even tools like Puppeteer for controlling a legitimate, “normal” browsers in the same manner as would a human. Bots of this nature are extremely difficult to detect and defend against without Polyform.
  2. Write the bot. This can take anywhere from an hour to several weeks depending on the complexity of the application, protections in place, and the desired goal. These bots or target-specific configs for existing bots are often publicly available and freely hosted for all to use. Tutorials on how to build a bot to target a specific company are close by, thanks to Youtube and
  3. Test the bot. This is usually relatively simple: either it works or it doesn’t. If it doesn’t…
  4. Troubleshoot and rewrite. This can be an extremely time-consuming and potentially impossible task, especially when faced with the severely obfuscated and encrypted fingerprinting mechanism that Kasada has designed and implemented within Polyform.This is one of the points at which the attacker must make a judgement call as to whether or not further time investment is worth the payoff. Many decide against this, and the attack permanently ceases.
  5. Once functional, the bot must be hosted somewhere, and it must have access to a plethora of IP addresses to bypass the many ancient technologies out there which still rely on IP blacklisting. The latter part is extremely simple, with no end of VPNs which offer effectively un-bannable residential IPs. The former usually relies on personal or stolen cloud hosting accounts, such as AWS. Amazon Lambda is an extremely common platform for this, as it is the cheapest option around for low-CPU processes such as HTTP requests.
  6. Launch the bot, and get a sandwich. Come back later, check up, make some tweaks to speed, etc. If necessary, wash, rinse, repeat.
Image of the scraping job on freelancer

The “sandwich” part is where Kasada’s Polyform gets super-crafty. Once Polyform detects the utilization of automation code within the bot client environment (which it is able to do on the VERY FIRST REQUEST), Polyform does NOT just “block.” Instead, it has the ability to target the underlying CPU resources of the bot. Polyform will feed the bot a cryptographic challenge that is extremely difficult for any computer to solve, regardless of computational resources.

At this point, the CPU on the bot’s host system is spiked through the roof, effectively rendering any processing within that system useless. Not only is the bot attacking the Polyform-protected site stopped (without alerting the owner), any other bots and/or malicious activities being run on this system against ANY other targets are also stopped as well. If the host is one of the many, many attacks we see using Lambda services, the associated AWS account almost instantaneously depletes its funds, and NO requests are able to be served until more funds are deposited in that account. Doing so is of course futile, as the problem will persist. The attacker can either quit, or literally run out of money (. . .and then quit). If the attacker is running on a scalable cloud server system, they can if they like add more CPUs to the node or cluster (at great expense), which once again prove futile.

Image from istat view of my CPU running at 100% for 24 hours without submitting a single request. You can see it getting flaky in the last few hours…

The combination of extremely accurate fingerprinting combined with effectively impossible cryptographic challenges Polyform leverages completely destroys bot creators’ Return on Investment. Launching a bot attack against any web application protected by Polyform has only two possible results. One is the creation of a “time sink” for the bot programmer, which causes them to be unable to attack the protected, or any other. The other is a complete depletion of computational AND FINANCIAL resources, forcing an abandonment of the attack.

If you’d like to talk more about this, and see Polyform in action. Feel free to contact the Kasada team here or drop us a line at