A rare breed of the brute-force: A history of one attack

While routinely working on the security of one e-commerce website, I encountered an unusual type of a brute-force attack that was fairly hard to mitigate. It was based on a delicately simple technique that made it stand out from the crowd. Read this article to learn what kind of an attack it was and how I succeeded in protecting my customer’s site against it.

As you know, a classic brute-force boils down to guessing credentials. For instance, threat actors take known user accounts and pick passwords for them based on certain criteria -- either by generating them on-the-fly or using dictionaries. This is the basic way to hack an account.

In my scenario, though, the perpetrators acted somewhat differently. They did not use TOR or VPN services, instead, they used a large botnet consisting of several hundred infected computers located in different parts of the world. The security monitoring system perceived this traffic as if absolutely different computers or proxies with real people behind them were accessing the site. Such an attack can remain undetected for a really long time.

Aside from vast geographic distribution, the second peculiar trait of the attack was that the adversaries were trying to guess usernames rather than passwords. They were probably using dictionaries of popular passwords and stolen lists of usernames. First, they would try to match one known password with one username, then another, and another, and so on. This activity made it all look like regular customers using the same ISP kept failing to log in with their valid passwords. At first sight, it didn’t appear hostile whatsoever. Moreover, the queries were very infrequent -- one or two in a minute.

The third distinctive feature of this attack was that the botnet exhibited very "human-like" behavior: the clients were processing JavaScript and accepting cookies.

This combo of factors helped the incursion fly below the radar for a fairly long time. When I did detect it, though, a nontrivial question popped up: how do we stop this? None of the bots had any unique characteristics except a specific user agent error. However, I decided not to block the attack based on that attribute, because in that case, I would be unable to monitor the perpetrator’s activity any longer. I badly needed to identify some other anomalies.

As far as the IP addresses were concerned, nothing offbeat was happening. Blocking usernames that had many failed login attempts wasn’t a good idea either, because the frequency was very low and it was the username -- not the password -- that the attackers were trying to guess. My last resort was to implement captcha, but the person who hired us didn’t want it, thinking that captcha would push a lot of clients away. Meanwhile, the crooks had managed to guess correct combinations for some accounts.

You must be wondering why on earth someone might want to hack the accounts of an online store’s customers. The thing is, they hold bonus points that can be exchanged for discounts. Someone probably wanted to do some major shopping or sell the bonus points online.

At the end of the day, I convinced the client that setting up a captcha service by F5 Networks was worthwhile. It was supposed to appear after a predefined number of failed login attempts. But first, I needed to configure the login success criteria in the system. It turned out to be a bit harder than it appeared because in some cases the resource returns the same response code for any attempts of accessing an account. I ended up choosing the instance of domain cookie delivery to the customer as the criterion of successful login.

The latest version of F5 ASM (Application Security Manager) goes with a feature that responds to guessing attempts based on Device ID, a unique browser identifier. You add JS code to the page, and when a contaminated machine loads that page it sends back its unique identifier. In our case, the Device ID was identical for every IP address. It actually meant that one browser was accessing the site from one IP address.

Consequently, I could define the following criterion: if more than five unsuccessful login attempts come from the same web browser within 15 minutes, then a captcha should be displayed to that visitor. If it’s a regular user, they will easily solve it and log in. I also added an appropriate exception for scenarios where a browser didn’t support JavaScript. I used a different criterion to keep the defenses high with that one: captcha would appear if more than 20 unsuccessful login attempts came from the same IP address. Again, this shouldn’t be a problem for a normal user.

However, there are methods to get around captcha-based protection these days. For example, botnets outsource the job to China or India, where hard-working locals solve captchas for a small reward and send back the text values. Fortunately, there are countermeasures for that, too: if login attempts are unsuccessful even with captchas solved, you can block queries from a specific IP address or Device ID in case the number of failed logins exceeds a predefined value.

The last time the online store was targeted this way, I used captcha and it worked. The brute-force attack started fading away and stopped in its tracks after a while. It’s been a year ever since -- so far so good.

Image credit: ImilianShutterstock

David Balaban is a computer security researcher with over 15 years of experience in malware analysis and antivirus software evaluation. David runs the Privacy-PC.com project which presents expert opinions on the contemporary information security matters, including social engineering, penetration testing, threat intelligence, online privacy and white hat hacking. As part of his work at Privacy-PC, Mr. Balaban has interviewed such security celebrities as Dave Kennedy, Jay Jacobs and Robert David Steele to get firsthand perspectives on hot InfoSec issues. David has a strong malware troubleshooting background, with the recent focus on ransomware countermeasures.

© 1998-2018 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.