Today it was discovered that an unknown actor had managed to exploit a vulnerability in Lockbit’s PHPMyAdmin instance (on their console onion site). Apparently they were running PHP 8.1.2 which is vulnerable to an RCE CVE-2024-4577. Which uhh… lol? It probably would have been prudent to do a post-paid penetration test on their own infrastructure at some point.
Further compounding the unfortunate situation, the actor was able to dump their database. This contained, as stated by Bleeping Computer, a number of tables such as bitcoin addresses, data about their build system such as bespoke builds for affiliates, A ‘chats’ table containing negotiation messages, which we’ll go through in a later post. And finally, of interest today, the usernames and passwords of LockBit agents using the console.
Of special importance, making our work markedly easier, these passwords were not hashed. Which sure is a choice, as an organization that performs ransomware attacks.
The vast majority of the passwords in this table as reasonably secure; it’s not solely hilariously weak credentials, but there still are a number that display poor security hygiene.
The weak passwords
Before going into my standard analysis, I’ll list off all of the weak passwords in question, and then we’ll go through the statistics of the whole set. The fun to highlight passwords:
- Weekendlover69
- CumGran0Salis
- Lockbit123
- Lockbitproud321
- Lavidaloca18
There isn’t much I need to say here regarding the selected weak passwords; extremely standard weak password patterns; upper lower and numbers appended. Absolute amateur hour stuff.
Similarly, sprayable usernames:
- admin
- kissme
- smelly
- Frank
- ExtortionLord
- btcdrugdealer
I especially love ExtortionLord honestly.
Complexity
Well I was going to put a table here of the complexity classes, but 100% of the records are mixedalphanumeric. Literally not a single password has special characters. Generally of the form like ‘u3PaP46hR2HXKzeWWcgw’; so the bulk of the stronger passwords are clearly generated by a password generator with a mixedalphanum for complexity, likely a password manager. Which is great! That’s a W at least.
Lengths
| Length | Count |
|---|---|
| 20 | 38 (50.67%) |
| 40 | 5 (6.67%) |
| 23 | 4 (5.33%) |
| 15 | 4 (5.33%) |
| 35 | 3 (4.0%) |
| 32 | 2 (2.67%) |
| 36 | 2 (2.67%) |
| 27 | 2 (2.67%) |
| 28 | 2 (2.67%) |
| 14 | 2 (2.67%) |
| 22 | 2 (2.67%) |
| 25 | 2 (2.67%) |
| 13 | 1 (1.33%) |
| 10 | 1 (1.33%) |
| 21 | 1 (1.33%) |
| 18 | 1 (1.33%) |
| 24 | 1 (1.33%) |
| 17 | 1 (1.33%) |
| 12 | 1 (1.33%) |
As with the complexity classes, the bulk of the passwords (38 in fact) are the same generated 20 character mixedalphanumeric. Not bad, but it doesn’t help when you’re not enforcing password complexity, lengths, and using a breached corpus to bump the passwords up to NIST 800-63B compliance. Not that it would have saved them in this case, given the vulnerability that lead to the dump.
Takeaways
Even ransomware operators suck at generating secure passwords, not only are there some extremely weak outliers, but if they were actually hashed, and an attacker was able to determine the weak complexity classes, it would have been reasonably straightforward to target the hashes with a mask and get hits. Just grab 8x5090s in the cloud for a few dollars and fire away.
It’s not enough to use simple alphanumeric passwords in 2025 with the affordability and availability of cracking hardware, if you stumble into a known length and character class you’re boned anyways. The passwords would have needed to both be hashed, and have better NIST-compliant complexity enforcement.