Malicious automation has enabled hackers to launch sophisticated attacks that easily evade the detection of static security tools such as Web Application firewalls. As well as creating new more intricate attacks, automated tools also enable hackers to launch traditional raids on applications at far greater scale than ever before. These heightened levels of efficiency have resulted in many more code vulnerabilities being exploited through the automated reconnaissance phase.
The combination of static tools, the cyber skills shortage and organizational complexity also contribute to attackers having the upper hand. In a world where many countries have introduced data breach notification laws, the business impact of data breaches has never been greater.
Kasada believes defeating malicious automation is a crucial, proactive step that all organizations should take to prevent their web applications leaking confidential customer data.
Marathon runners use the phrase “hitting the wall’ to describe the point at which their body fails to keep up with the race pace. Understanding where your malicious automation detection “hits the wall” is equally important. Kasada wouldn’t advise marathon runners, but we know defeating malicious automation requires organizations to invest in tools capable of lasting the distance.
The attacker’s toolkit
The internet provides a specialised tool for every malicious intent. From content theft and vulnerability exploitation all the way to paywall penetration and account takeovers, there are low or cost free tools readily available. The attacker’s toolkit image above lists only a few of the tools that Kasada detects on a daily basis.
I spy with my little eye, something beginning with…
Bot detection is often referred to as a game of “cat-and-mouse” but in reality it has more in common with another popular children’s game, “I Spy”. Understanding if a security solution is capable of observing the attacker’s toolkit is a crucial step in preventing malicious automation.
We recommend the following five tests as a way of gauging your solution’s ability to observe attack tools:
… something beginning with C
cURL is as easy as it gets to use, and fortunately it is also very easy to detect – if you are looking. For those not familiar with cURL, it is a command line tool using various protocols to transfer data.
The first test you can run in your evaluation is to check whether the solution is capable of detecting and blocking cURL requests:
Test 1
curl 'https://www.kasada.io'
You can switch kasada.io with your own domain.
This test makes no attempt to evade detection. If the solution you are testing does detect it, the next test changes the HTTP headers to make it look like it is coming from a normal web browser.
Test 2
curl 'https://www.kasada.io' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9' -H 'upgrade-insecure-requests: 1' -H
'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36'
-H 'accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'cache-control: max-age=0'
cURL is a basic program, but hackers use it to automate parts of very dangerous attacks. The inability to detect either or both of the first two attacks indicates that your solution is not prepared to defend against malicious automation.
… something beginning with B
The internet is awash with web scraping tools that are sold for the purpose of “decluttering” websites. These tools use automation to connect to a site and take content. However, they can also be used for more nefarious purposes – including paywall penetration. Websites such as Outline or Boilerpipe provide simple, free interfaces that allow content to be pilfered.
The third test allows you to test whether these tools can connect to your site:
Test 3
Type the following URL into your browser and switch kasada.io with your domain.
https://boilerpipe-web.appspot.com/extract?url=https://www.kasada.io
… something beginning with P
Headless browsers are a great tool for automating web testing. They are also a great tool for automating the delivery of attack payloads, launching sophisticated layer 7 DDoS attacks and banking trojans, and evading the detection of many legacy solutions.
In essence, headless browsers are browsers without a GUI.
Test 4
There are example scripts available on the PhantomJS and CasperJS websites that will enable you to test whether your existing security solution is capable of detecting a headless browser.
https://casperjs.org/
https://phantomjs.org/examples/
Stay tuned, we are planning a tool in our website that simplifies the process of running these preliminary tests.
… something beginning with S
Browser automation tools such as Selenium are as sophisticated as it gets to detect. They also happen to be a highly versatile and powerful attack tool. Selenium can be used to automate code vulnerability attacks, scrape content, automate account takeover attacks and launch sophisticated layer 7 DDoS attacks.
Selenium uses a real browser, which makes it far more challenging to detect.
Test 5
If you only have time/resources to conduct a small number of tests, this test should be your priority. We highly recommend you test your ability to detect and prevent any unauthorized users from employing browser automation tools against your site. Building Selenium scripts to test your site is well worth the additional effort as it is the attacker’s tool of choice.
Summary
Defeating malicious automation requires a solution that can detect all of these tools. Many legacy solutions claim to offer protection from bots yet they are unable to detect the tools that are most often leveraged to launch attacks.
Kasada regularly conducts these five tests alongside our customers to prove the efficiency of our service. Disarming these tools is the most effective way to stop the bots.
To learn more about advanced bot detection, read our blog post covering the most important components of non-static bot protection. Read full post here.
