Security Experts:

Spring 2018 Password Attacks

The first time I heard about distributed brute-force login attacks was from master web application firewall (WAF) administrator Marc LeBeau. At the time he was defending a hotel chain against attackers who were brute-force guessing customer passwords and withdrawing hotel points.

LeBeau had been brought in to administer a WAF to stop the bleeding, which topped $50,000 a month. His initial policy stymied the attackers . . . for about two weeks. Then they resumed their assault, this time trying each password from a different IP address. The distributed nature of this type of attack makes it difficult to differentiate between a legitimate user trying to remember his password and a gang of points thieves.

I checked back with LeBeau recently to see what he’s up to, because he’s always got some interesting insights into the attacker/defender landscape. 

According to LeBeau, there’s a popular attack vector among brute-force attackers right now that takes advantage of the 90-day password expirations commonly used by enterprises. When a company becomes large enough, it accumulates several dudes who can’t ever remember their passwords and end up calling IT 200 times a year. To avoid becoming like the fabled B.O.F.H., admins assign these dudes a password like Spring2018 because it’s easy to remember and aligns to the 90-day expiration. 

“With tech shop churn and socialization, <SeasonYear> just became a de facto standard. So this specific password works wonders when attacking enterprise because it's really just an enterprise employee problem.” – Marc LeBeau

If an organization runs a password audit, they’re likely to find this scheme in use for several users. Blame legalized marijuana, if you like, and its effect on short-term, um, what was I talking about? Anyway, here’s LeBeau’s regex for matching against the SeasonYear scheme:


There’s a password that includes a three letter word for the natural act of reproduction, a deity, and a two digit number. According to LeBeau, it is particularly hot among home users right now, but not with my puritanical editors, who don’t believe you’re mature enough to read it without your head exploding. The owners of this password may think they’re deities, but online they are clearly infosec mortals.

No limits

LeBeau says a modern WAF can prevent distributed brute-force login attempts with various levels of rate-limiting. If the authentication model is very open (little to no rate-limiting), then, yes—attackers spray the site with an identical password list. If a site has something worth getting, the attackers will hammer it in any and every way possible till there's nothing left. 

Relaxed rate limits

If the authentication model is relaxed but imposes limits only in bulk and only for short periods of time, say 50-100 requests in 15 minutes (think the cheap “easy button” cloud WAFs), then the spray and stuffing attacks will still work, though the attackers have to rent more botnets. A hundred requests in 15 minutes means 9,600 attempts from a single source IP per day; 10 IPs is 96,000, and LeBeau has seen up to 38,000 unique IPs in a week, making for 364,800,000 possible daily attempts.

Attack campaigns tend to come in waves; weeks of heavy volumes are interspersed with quiet periods lasting a few days. Common launch times are nights and holidays (especially MLK Day for some reason), when SecOps is sleeping or down to one or two people. You'll normally see volumes that work just around your minute/second limits during peak hours otherwise. The credential-stuffing attacks are pretty broad, making wide use of leaked creds from the big breaches at Ashley Madison, Yahoo, LinkedIn, and others. If a credential combo works at one site, they'll try it everywhere.

LeBeau has also been observing attackers merging password lists with regular expressions to find similar accounts and build a password list for that group of UIDs. For example, new lists might include usernames jimbobjones69, [email protected], and jimbobjones2012, each with a unique password. The attackers will use those three passwords across the three usernames as they test elsewhere. Success and failure are tracked and will be "shelved" for a future seasonal attempt.

Advanced rate limit/Lockout auth model

With heavy rate-limiting in place, you will likely only see focused credential-stuffing attempts. Once they discover how much control is in place, attackers will ensure they do their research before wasting too much time with spray attacks. The attack volume will be light in comparison; however, distinction from legit traffic will be equally difficult. To ensure this, they specifically target peak hours relative to your region, regardless of where they live. This is where you see the highest sophistication of the credential regex correlation they use for distributed brute forcing.

LeBeau says that regardless of the controls in place, attackers know they're not going to jail and probably won't even hear from their ISP. So when you implement these advanced controls, you do become a "project" for some attackers and others who are just curious. Authentication is bigger than poking at a website with SQLi, so advanced controls with SQLi may actually encourage an increase in this kind of probing.

End scope

Sites that offer small redemptions will experience heavy attacks by skilled groups. Financial institutions will have fewer attackers, but those who try will be significantly more sophisticated, according to LeBeau. 

Hotel points and bank accounts may seem like similar targets, but they can be two extremes of an attack spectrum mixing rate-limited attacks, password spraying, and credential stuffing. At his Project BAIU site, LeBeau maintains the rate-limiting logic he’s learned from defending travel chains and financial services. 

view counter
David Holmes is an evangelist for F5 Networks' security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5's Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.