Two Most Common Brute Force Attacks We See

The ThreatX Protection-as-a-Service team sees a lot of brute force attacks – or attacks that feature attackers using trial and error to try to access a system.  

These attacks come in a variety of shapes and sizes, but the one we see most frequently is credential stuffing attacks, and one type that is becoming increasingly more common is API brute forcing.  

Credential Stuffing Attacks 

Credential stuffing is the brute force attack we see most often. In a credential stuffing attack, attackers use previously compromised usernames and passwords to gain unauthorized access to user accounts. The attacker attempts to reuse the credentials across various services, exploiting the common practice of users reusing passwords. 

For example, if an attacker breaches one website or service and steals all the usernames and passwords, they will then try to break into a variety of other sites and services using those same usernames and passwords. This tactic is worth the effort because so many people use the same username and password for multiple sites and services.  

API Brute Force Attacks 

We have also seen an uptick in brute force attacks against APIs recently. An API brute force attack is when attackers attempt to brute force API endpoints by systematically trying different inputs, parameters, or authentication tokens to gain unauthorized access or extract sensitive information. 

A big reason for the uptick in these types of attacks is that implementing secure authorization techniques with API tokens is difficult. Also, as with password re-use and credential stuffing attacks, API tokens are rotated infrequently — even after they’ve been leaked. 

Do yourself a favor and double check your GitHub repo to ensure you don’t have API tokens available. Attackers commonly check GitHub and code repositories for API tokens uploaded by accident. Do not store API keys anywhere in clear text; they should be treated like passwords.   

Evasion Tactics 

We see attackers employ several evasion techniques in an attempt to disguise their brute force attacks, including: 

Timing: This is a common evasion technique that involves varying the timing of requests – for example, they’ll try one request every 10 seconds, then 30 seconds, then continue to switch up the timing.  

Randomizing header values: Another tactic to disguise identity and intent is to change the order of the headers and their values. For example, if they have been blocked once by a WAF, they will try to disguise themselves by moving the host header up and down, moving cookie headers around, or removing unneeded values. 

For example, this HTTP request: 

GET / HTTP/1.1 

Host: www.threatx.com 

Upgrade-Insecure-Requests: 1 

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.5938.63 Safari/537.36 

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 

Accept-Encoding: gzip, deflate, br 

Cookie: SomeCookie 

Accept-Language: en-US,en;q=0.9 

Connection: close 

And the HTTP request below would return the same result, but if it were a malicious request, a traditional WAF set-up does not identify this as an evasion technique. 

GET / HTTP/1.1 

Host: www.threatx.com 

Upgrade-Insecure-Requests: 1 

Cookie: SomeCookie 

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.5938.63 Safari/537.36 

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 

Accept-Encoding: gzip, deflate, br 

Accept-Language: en-US,en;q=0.9 

Connection: close 

IP rotation: Attackers often have lots of IP addresses, so rotating through different IP addresses is a common evasion tactic. 

Encoding: Attackers will try encoding their requests, often in multiple ways, in an effort to disguse their intent. 

The ThreatX platform is very effective and efficient at decoding payloads in order to completely evaluate its contents for risk.  Traditional WAFs and techniques struggle with this evasion technique. 

Spotting the giveaways  

Attackers successfully bypass most security solutions with these evasion tactics, but the ThreatX platform plus Protection-as-a-Service team are ideally suited to identify and thwart these maneuvers by using the following: 

TLS fingerprint: Often an attacker is using a script or platform to execute an attack. In these cases, the TLS fingerprints, even though they might be coming from different IP addresses, might be the same. So we might start tracking one TLS fingerprint and associate some risk value with its occurrence. 

Obvious things in request: Sometimes, attackers simply put obvious giveaways in a request. For instance, we’ve seen requests that say 1337haxor, PWNCaptain or things like that. And because our solution is backed by human beings, we immediately recognize and block obvious malicious requests like these.    

Skipping workflows: Another common way we identify malicious actors is through skipped workflows. When a normal user goes to a website, they go to the homepage, then the login page, and then submit their login credentials. But if somebody is not visiting the homepage or the login page and just hammering at the sending credentials part of the workflow, we know they’ve skipped A and B, and are clearly not a normal user.  

Reusing IPs or common attack patterns: Finally, we often identify malicious actors because they are reusing IPs or common attack patterns. For instance, we might notice payloads or special characters that we’ve seen before.  

Our Secret Sauce 

The secret sauce that really sets us apart and pulls together all the identification tactics above is our ability to aggregate risk around things that look potentially nefarious.  

For example, if we see a suspicious TLS fingerprint, we don’t block it immediately because the attacker could be using a browser or similar setup as some of our customers, and we don’t want any false positives, or to bock customers from using a website as intended. Instead, that TLS fingerprint would be one data point. Based on the analysis of several data points, we would decide to block. For example, if we observe that a suspicious TLS fingerprint, plus a user skipped a workflow, and included a common attack marker, that would lead to a blocking decision. 

This secret sauce is why ThreatX is so successful in effectively and accurately blocking so many attacks, especially brute force attacks.  

It’s also why the ThreatX Platform shines when addressing low-and-slow attacks that combine attack types and techniques slowly, over time, and are missed by traditional WAFs. More on that later …