LockBit really can’t catch a break. Following a year of law enforcement disruptions and loss of affiliate base, the world mostly recently witnessed one of the most notorious Ransomware-as-a-Service (RaaS) gangs hit by yet another setback – they’ve been hacked. On a gloomy Thursday morning, our analysts awoke to news of LockBit’s hack – and immediately snapped into action. Not only was this crucial given the many victims we have helped contain LockBit-attributed incidents, but it posed an excellent opportunity to gain insights into the RaaS’ inner workings.

This blog summarises our key takeaways from our analysis of LockBit’s leaked database.

So, what happened?

On 7 May, LockBit’s dedicated leak site was modified, replacing their usual display of victim listings with a plain message, and link to a ZIP archive curiously named “paneldb_dump.zip”.

The archive contained one single “paneldb_dump.sql”, a full dump of the SQL database in a file, obtained from LockBit’s affiliate panel’s MySQL database.

Upon downloading the leaked files, we observed the following operational data disclosed:

• Bitcoin addresses – contained 59,975 unique bitcoin addresses
• Attack builds – disclosed specific malware created by affiliates, including respective public keys, and in some cases the corresponding victims’ name(s)
• Configurations – specifying technical parameters for configuring encryption per ransomware strain (e.g., for ESXi variant – which ESXi servers should be skipped and what files should be encrypted)
• Victim Negotiations – complete chat history between LockBit and victims, including the links to sample stolen data and tree of stolen data (though most links are expired)
• Users – list of 75 administrators and affiliates with access to the affiliate panel, including their plaintext passwords

Assessing the Impact on Existing Victims

Our first priority when analysing the leak was to determine the scope and impact to our existing clients previously hit by LockBit. To do so, we first performed a check of the builds table to identify any relevant victim mentions. We then further referenced the chats table for any additional mentions. Upon identifying relevant victims, we rapidly notified them of the severity of the exposure and how they can respond to further safeguard their information.

Our Key Observations from Leak Analysis

1. Scope of impact was restricted to victims targeted by the LockBit 4.0 strain

Based on two key indicators, we ascertained the scope of the leakage was contained to the LockBit 4.0-related attacks. This is given (1) ransom notes referenced in the chat history(s) pertained to LockBit 4.0, and (2) the chats table which over 4.4K messages were dated between 19 December 2024 and 29 April 2025. This aligns exactly to the LockBit 4.0 public release on 19 December 2024.

2. Chat history revealed the initial access vectors used

Weak passwords. Though LockBit affiliates are known to leverage multiple means of intrusion (e.g., exploiting vulnerable servers, phishing, etc.) – weak passwords were the apparent theme across multiple chats. To quote one of the impacted victims, “So our vulnerability is simply that the password was too weak?” Yes.

Note: ironic, considering the leaked plaintext passwords of LockBit’s 75 admins and affiliates evidenced their own use of weak passwords (e.g., LockbitProud231, Weekendlover69)

3. Some victim domains contained in the ‘builds’ table were not observed on the leak site

Our initial hypothesis was that this corresponded to the 16 victims who paid the ransom. We validated this to be partially true, with only two (2) of the 16 victims who paid still listed on LockBit’s leak site. Additionally, per our recent LockBit-related incident experience, we observe cases in which compromised victims have not been listed on the leak site, which we suspect is due to the lack of data exfiltration performed during their intrusion.

4. Affiliates weaponise victims’ pre-installed AnyDesk instances for persistent access

LockBit, like many RaaS groups, leverage AnyDesk frequently for persistent, remote access to victim environments. In one instance, we observed a victim prompt the group to divulge how AnyDesk was used in their case. The negotiator confirmed that the affiliate leveraged multiple pre-installed (by the victim) AnyDesk instances to re-access multiple hosts.

5. Watch what you say, chats are ‘forever’

In at least one instance, the victim requested for LockBit to remove all chat content, to which LockBit confirmed they cannot clear the chat, only delete it. What we further observed is even if the chat was deleted, the content remains stored in their backend database. So, unless the database itself is deleted or scrubbed, any sensitive or leaked content shared within the chats remains stored on LockBit servers.

As an example, in one conversation we observed the victim gossiping with LockBit, and (whether jokingly or not) telling LockBit to attack their competitor’s site. A good reminder that anything shared on the Internet lives forever – in this case not only posing reputational damage, but potential implications regarding the victim’s negligence.

6. Victim invited to join the dark side

Referencing chats and builds, we observed something surprising. Following negotiations, one victim was offered the opportunity to join the RaaS affiliate network for USD 777. “Immediately after payment you will get access to LockBit ransomware control panel where you can create builds of Windows, ESXi, Linux encryptors and communicate with attacked victims.”

7. LockBit’s own OPSEC fails

Aside from their use of weak passwords, whilst the root cause has not been confirmed by LockBit operators, the panel was operating on a vulnerable version of PHP 8.1.2, susceptible to remote code execution vulnerability (CVE-2024-4577). This is not the first time LockBit’s operators have overlooked their attack surface exposure, as we recall their announcement regarding their February 2024 PHP-related “penetration test” intrusion:

This begs the question – is LockBit’s bug bounty program not active (or effective)? It is hard to tell, with LockBit only announcing the first bounty payout of USD 50K on 17 September 2022. Perhaps their standing payout incentive varying from “USD 1000 to 1 million” isn’t as incentivising as they had hoped…

LockBit’s Response

On 8 May 2025, Rey shared their Tox conversation with LockBitSupp (LockBit developer). The operator claims that only the “light panel with auto-registration was hacked” – no decryptors, stolen victim data, or source code was compromised.[1] 

This messaging was further reflected in an announcement on LockBit’s updated leak site. It additionally stated that the root cause has been determined and a rebuild is in progress – with the full panel and blog functioning back to normal. We also see LockBitSupp asking the same question on all of our minds – who was behind the leak? Defaulting to their bug bounty tactics, the group is willing to pay for information on the attackers behind the hack.

Conclusion

Per LockBit’s response, the group show no signs of halting operations – in spite of their latest battle. Whilst it is unknown who these attackers “from Prague” could be, we observe speculation within the community that DragonForce may be at fault.[2] Though we do not observe evidence to support this claim, it is plausible given the assumption that newer ransomware players could be seeking to ‘take out the competition’ in a bid for talent (affiliates).[3],[4] Whether true or not, we continue to observe new RaaS groups emerging with novel differentiators – both in the tooling and affiliate structure – as a means to establish presence within the ecosystem. As the threat of ransomware continues to evolve, it is crucial that organisations maintain preparedness to prevent, detect, and contain ransomware-related threats.

Recommendations

• Incident Response (IR) Plan and Drills – create a detailed IR plan outlining roles, responsibilities, and procedures for responding to ransomware incidents. Regularly conduct IR drills to ensure readiness and identify areas for improvement. Ensure to factor in consideration of legal and regulatory compliance, including Data Protection Regulations, Mandatory Reporting and Timelines, Documentation, and so forth.

• Maintain Offline, Encrypted Backups – Regularly back up and encrypt critical data and ensure backups are stored offline or in a secure cloud environment. Periodically test backup restoration processes to ensure data can be recovered quickly and accurately.

• Security Awareness Training – Conduct regular training sessions to educate employees about social engineering techniques (e.g., infostealers, phishing, etc.) and safe online practices.

• Restrict Lateral Movement Opportunities – to minimise ransomware propagation via remote service protocols (e.g., RDP, SMB) and use of third-party remote monitoring and management (RMM) tools, such as AnyDesk.

• Reduce your “low hanging fruit” – monitor, minimise, and maintain visibility of your attack surface exposure to proactively identify and remediate potential security weaknesses that may expose you to external threats. Detailed recommendations here.[5]

• Behavioural Based Detection – identify, detect, and investigate abnormal activity and potential traversal of the threat actor across the network, such as ensuring coverage of Endpoint Detection and Response (EDR) tools on critical endpoints, including workstations, laptops and servers.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.