Ransomware Services Exposed: Behind the Screens of the LockBit Leak

Our ongoing analysis of ransomware activity offers technical insight into these attacks. In 2021, the Conti leak revealed the inner workings, hierarchy and tactics of Ransomware-as-a-Service (RaaS) gangs. Yet, the actual operations, from breach to extortion, are carried out by affiliates, who use platforms and malware provided by these groups.

This attack model includes victim-specific malware builds, infrastructure for ransom negotiations, storage for stolen data and sample delivery, all typically managed through an affiliate panel.

On May 7 2025, the affiliate panel of LockBit 4.0 – one of the most active RaaS operations – was hacked. Its homepage was defaced and replaced with a message and a link to a database dump. Notably, the message mirrored a similar defacement on the Everest Ransomware gang just weeks earlier in April 2025.

The leaked data – particularly the chat logs between affiliates and victims – offers a rare window into how ransomware affiliates operate. Based on these conversations, we’ve identified seven key insights into the behaviors, tactics, and mindset of actors within RaaS ecosystems.

Overview of the Leaked Data

The leaked dataset appears to be a full dump of the LockBit 4.0 affiliate panel, spanning December 18, 2024 to April 29, 2025 – almost the entirety of LockBit 4.0’s known operational period, which began with its announcement on December 19. The database contains several key tables that shed light on the internal mechanics of the operation:

Cryptocurrency Payments

• ~60,000 Bitcoin (BTC) addresses are listed as controlled by LockBit administrators for collecting their 20% cut from affiliate earnings.
• Only 159 addresses are directly associated with attacks.

Payment Invites

• The invites table lists 3,693 entries that map to 2,338 Bitcoin and 1,355 Monero wallets. These are likely tied to deposits or subscription fees from wannabe affiliates.
• Only 12 invites show BTC wallet transactions, 10 map to known user accounts, while the remaining 2 may be test or legacy entries (linked to LockBit 3.0).
• Some affiliates with associated BTC wallets paid no deposit, possibly due to a pre-existing trust or reputation.

Affiliate Accounts

• The users table includes 75 entries, one administrator, one test account managed by the admin (matrix777) and 73 affiliate accounts.
• Each user is assigned a tag by LockBit administrators, including: “newbie”, “pentester”, “verified”, “scammer”, and “target ru” (used only once).
• Accounts can be marked as “paused”, likely due to inactivity or violations of affiliate agreements.

Notably, account credentials are stored in cleartext, as shown in the image below.

Ransomware Builds

• The builds table contains information on 1,183 ransomware builds across 631 unique targets. These builds are victim-specific and include encryption keys, target domains, and notes on victim revenue.
• After filtering out placeholder entries (e.g. com) around 550 unique targets remain.

Victim Data

• The clients table lists 246 potential victims, of which 156 are linked to at least one build
• This implies that affiliates could pre-load victim profiles into the panel, regardless of whether an attack was launched.

Chat Logs

• The chats table includes 4,423 messages across 208 conversations between affiliates and victims.
• Some negotiations spanned multiple threads, consolidating the dataset down to 132 unique victims.
• Of these, only 116 had more than the initial automated message sent from the platform, shown below:

Focus of This Analysis

• Among the 88 victims with meaningful chats, only 59 had an associated HTTP server.
• We manually reviewed these domains and selected 20 that belong to critical infrastructure sectors: manufacturing, healthcare, financial services, transportation and government.
• Roughly half of these targets are located in Asia, with the remainder split between the Americas and Europe.

 

Insight #1: Ransomware Affiliates Vary Widely in Skill, Tactics, and Targets

The 20 attacks we analyzed were carried out by 10 distinct affiliates. Four of them, responsible for nine attacks, carried the “verified” tag, indicating a higher trust level from LockBit admins. Only five users in total had this designation, shown in the image below. The sole inactive one, “Brown”, hasn’t been active since early April.

Beyond admin assigned labels like “newbie” or “verified”, affiliates differ markedly in their approach to negotiation, victim selection, and use of pressure tactics. A few examples illustrate this diversity:

Cristopher (“verified”)

• Targets: Three Asian companies, a Philippine investment fund, a Taiwanese optical lens manufacturer, and a Hong Kong-based infrastructure company.
• Tactics: Maintained a cooperative tone despite language barriers. Two negotiations concluded successfully; one victim disengaged post-ransom request, interestingly their data was never leaked.

BaleyBeach (“newbie”)

• Targets: Two U.S. financial institutions
• Tactics: Aggressive and coercive. Conversations feature high ransom demands allegedly based on analysis of the victim’s cyber insurance coverage. Intimidation methods included spamming employee inboxes and repeated calls (“mail and call bombing”). Threats included limiting visibility of stolen data until payment was made, or until the data was published. Both cases were unresolved at the time of the leak.

Swan (“verified”)

• Targets: Three European organizations: a Turkish mining company, and two municipalities in Austria and Czechia.
• Tactics: Varied by victim. The Austrian municipality responded quickly and agreed to a $21,000 payment. The Czech municipality claimed the stolen data was non-critical, but remained open to negotiation, which was still ongoing at the time of the leak. In the case of the Turkish mining company, Swan demanded 4 BTC (around $340,000 at time of request), but no agreement was reached.
• Observations: Exhibited impatience during stalled negotiations. No wallet transactions were observed for the Czech case. For the Turkish case, the absence of commission payments to LockBit indicates the negotiation failed.

 

Insight #2: Ransomware Affiliates Exhibit Industrial and Regional Biases

An analysis of the 10 affiliates behind the 20 selected attacks reveals clear preferences in both geography and industry, suggesting these attackers are not entirely opportunistic, but follow recognizable patterns in victim selection:

• “PiotrBond” generated ransomware builds for 26 websites. Of the eight with live web servers five are Chinese, two Taiwanese, and one Singaporean. They are mostly manufacturers and technology companies.
• “Christopher” targeted 37 distinct websites. Early attacks focused on Spanish-speaking countries, but later activity shifted exclusively to Taiwan and Hong-Kong, without a consistent industry focus.
• “umarbishop47” demonstrated a strong geographic preference, with 16 out of 20 targets located in Latin America, again with no clear sectoral bias.
• “Swan” focused primarily on European victims, with 33 out of 42 targets based in Europe. These also spanned multiple sectors.
• “Iofikdis” and “BaleyBeach”, both tagged as “newbie”, displayed more concentrated patterns: the former targeted Chinese manufacturing firms, while the latter focused on U.S. financial institutions.

These patterns suggest that affiliate targeting is often guided by geographic or sector familiarity, or potentially by the perceived profitability or responsiveness of certain industries. While we cannot definitively attribute intent, it is plausible that some affiliates specialize in negotiating with specific regions or sectors, expected higher returns from certain victims, or are motivated by ideological preferences.

 

Insight #3: Some Affiliates Abandon Attacks Without Publishing Data

In several cases, affiliates did not publish stolen data, even after victims ceased communication and no ransom was paid. This behavior suggests either strategic disinterest or a degree of discretion toward low-value or unresponsive targets.

One example is Swan’s attack against the Turkish mining company (see Insight #1), where the victim did not engage after the initial ransom request. No data was leaked, and no transaction to LockBit’s BTC addresses occurred.

Another case involved PiotrBond, who demanded 0.8 BTC from a home-appliance component manufacturer. After the ransom request, the conversation ended abruptly with no further messages or payments. Despite this, PiotrBond remained active, conducting subsequent attacks, indicating this was not due to “retirement” or deactivation.

Across the 20 incidents, five similar cases occurred, each involving a different affiliate. This pattern may suggest that some attackers deprioritize low-value or non-responsive targets, possibly due to limited resources, time constraints, or an internal calculus of reputational risk and return on effort.

These findings also highlight a broader implication: the observable ransomware landscape likely underrepresents the true scale of activity. Many incidents, especially failed or abandoned ones, may never be disclosed by either victims or perpetrators.

 

Insight #4: Affiliates Often Fail to Support Victims After Payment

Ransomware affiliates do not always provide functional decryptors, and in some cases offer little to no post-payment support. Two incidents involving the affiliate Iofikdis illustrate how victims are often left without recourse after paying.

Case1: Incomplete Decryption and Ignored Support Requests

A Chinese manufacturer infected by Iofikdis was initially asked to pay $15,000. After negotiation, the ransom was reduced to $6,000 and paid on March 24. The victim received a decryptor, but soon discovered that many files could not be recovered.

When they contacted the affiliate on March 30 for assistance, they were told “we are very busy” and that “the boss often responds after 3-5 days”. By April 7, the victim asked again for an update, to which the attacker replies that their boss did not reply. Subsequent messages from the victim were largely ignored.

On April 12, the affiliate shifted the blame for the failed decryption, stating that the victim’s “security systems, including your anti-virus software [which] interfered with the encryption process, thereby making your files undecryptable”. When the victim, seemingly working with a third-party recovery firm, requested the encryptor, the affiliate claimed it had already been deleted.

The conversation continued one-sidedly, with the victim sending multiple follow-up messages expressing frustration and distress. The last message, dated April 21, went unanswered. The affiliate provided no further support after receiving the ransom, despite breaking LockBit’s own terms of service (ToS), which require affiliates to fulfil pre-payment agreements made in chat.

Despite these unresolved issues, Iofikdis continued to report additional victims, seven between March 19 and March 30, and another on April 24, all based in China.

Case2: Damaged Reputation and Tool Ineffectiveness

In a separate incident, Iofikdis negotiated with a representative from a consultancy supporting a victim. After they rejected a counteroffer to the initial ransom, the affiliate was accused of lacking credibility.

The negotiator claimed experience with previous LockBit-affiliated cases and asserted that their decryptors frequently failed to restore all data. This accusation points to a broader issue: some affiliates are either unable or unwilling to provide reliable decryption or support. undermining trust in their own extortion model.

These cases highlight a recurring problem in the ransomware ecosystem: once payment is made, victims often have no leverage, and affiliates may fail to deliver what they promise, even in violation of their own group’s supposed terms of service.

 

Insight #5: Affiliates May Switch or Circumvent RaaS Providers

Affiliates do not always remain loyal to a single Ransomware-as-a-Service (RaaS) provider and may even attempt to bypass platform controls — including revenue sharing obligations.

In one case, Iofikdis told a victim that they recently migrated to LockBit from BreachForums because their previous ransomware “was not perfect”. This suggests that affiliates evaluate platforms based on technical capability and may switch allegiance to improve operational outcomes.

In another incident, BaleyBeach appeared to resume an earlier negotiation that began under the RansomHub affiliate program. When asked for clarification, they responded “RansomHub closed, we moved here. So existing companies (including yours) which we had to deal with still have chance to prevent their data leak.”

In two additional cases, conversation between affiliates and victims appear to have moved off-platform. This behavior likely serves to obscure evidence of payment agreements and avoid paying LockBit its percentage. We observed no transactions to the affiliates’ known wallets in either case, supporting the theory that the negotiations continued outside the monitored environment.

Insight #6: A Single Ransom Can Yield Six-Figure Profits

Ransomware affiliates operating under LockBit 4.0 demonstrated that even a small number of successful attacks can generate substantial financial returns, both for the affiliates and for the LockBit administrators.

Of the 159 BTC addresses associated with victims, only 19 received funds. Eighteen of those received just a single transaction. One address received two, including the highest single ransom payment we observed in this dataset: 4.22BTC (approximately $433,061 at the time of writing).

Swan’s $2 Million Ransom

The 4.22 BTC payment was linked to Swan, tagged as a “verified” affiliate, and traced to a Swiss IT infrastructure and cloud provider.

• Initial contact: May 19
• Claim: Data from 24 companies using the victim’s services had been encrypted and stolen
• Assessment: Before naming a ransom amount, Swan said they would review the victim’s financial status
• Ransom demand: On May 24, Swan requested $2 million USD

A closer examination of the transaction reveals that the sender wallet had previously transferred 16.8BTC (approximately $1.72 million), bringing the total wallet balance to 22.377BTC (around $2.28 million). The subsequent transfer of 4.22 BTC likely represents LockBit’s 20% commission on the full amount (22.377 x 0.20=4.475) suggesting a possible discount of 0.25 BTC applied.

We linked this transaction to a chat between Swan and a victim, a Swiss IT infrastructure and cloud provider. Swan initiated contact on May 19, claiming that data from 24 of the provider’s client organizations had been encrypted and exfiltrated.

The following day, Swan informed the victim that, given the scale of the breach, they would first assess the company’s financial situation. On May 24, four days later, the attackers formally demanded $2 million USD, justifying the amount based on their financial assessment of the victim.:

The victim attempted to negotiate, but Swan demanded full payment promptly and threatened to double the ransom if delayed. The victim agreed and began working through the logistics, including challenges with Swiss anti-money laundering checks. The conversation ended after Swan shared payment instructions. As of now, the BTC remains unmoved in the address communicated to the victim. No public disclosure of this breach has been identified.

Affiliate Revenue Flows

Excluding Swan’s high-value case, the remaining 18 BTC addresses associated with ransom payments generated a total of 0.74BTC (approximately $76,000). As of this writing, all Bitcoin received by LockBit remains unmoved.

The most active affiliate among these was Christopher, linked to nine successful attacks and contributing  0.54BTC (~$55,474) to LockBit’s revenue. In seven of those cases, Christopher funneled proceeds through Bitcoin mixers or tumblers, obscuring further tracing.

However:

• In one case, funds were traced to a KuCoin hot-wallet: bc1q9wvygkq7h9xgcp59mc6ghzczrqlgrj9k3ey9tz
• In another, the trail led to a high-frequency wallet previously linked to the Akira ransomware gang: bc1qng0keqn7cq6p8qdt4rjnzdxrygnzq7nd0pju8q
• A third case involved the verified user Brown, whose ransom funds were also deposited into the same Akira-associated wallet.

LockBit Platform Revenue

LockBit’s commission model requires affiliates to pay 20% of extorted funds, either per transaction or in advance. One rule states:

“When you join, you deposit 1 bitcoin in our wallet… this amount is an advance and will be used at your subsequent payments.”

While this could explain Swan’s apparent discount, the invites table tells a different story, showing the BTC or XMR amounts paid for registration. Converting them with the exchange value for that day consistently returns a value ranging from 770 to 785 USD, which matches the $777 value disclosed by users JamesCraig and Christopher.

We verified 12 such BTC-based registration payments, bringing LockBit’s confirmed revenue to ~$85,000, excluding additional Monero-based fees which we cannot verify.

Notably only four payments tied to registration fees were later transferred out of LockBit wallets. These include two unlinked transactions mentioned earlier, and two from FezaanBlanchard and king457533579 (the account tagged ‘target ru’). The rest remain static or fragmented across LockBit-controlled addresses.

Based on cross-referencing chat transcripts and wallet activity, we conclude that only 19 ransom payments occurred within the platform during the leak period. All were traceable to either LockBit’s commission wallet or remained unpaid. Although some chats mention Monero-based payments, we found no verifiable evidence of such transactions.

 

Insight #7: Russian Targets Hit Despite LockBit’s No-Attack Policy

Like many other RaaS groups, LockBit explicitly forbids affiliates to attack organizations in Russia and the Commonwealth of Independent States (CIS).

This policy is codified in its Terms of Service, typically seen as a nod to geopolitical boundaries or tacit non-aggression pacts. Despite this, we found four instances in the leaked database involving .ru domains. One is a test website, another is a build targeting a Russian bank but with no associated chat or ransom activity, so we discarded them. The remaining two involved active extortion attempts against a Russian state-owned construction company and a Russian municipality.

In the case of the construction company, affiliate “king457533579″ contacted the victim who immediately identified themselves as a part of the “Russian administration”. The attacker replied that they have “new rules” and proceeded to demand $50,000. The victim pushed back, questioning the professionalism of the approach and escalating frustration at the affiliate’s lack of response:

“More than an hour has passed without a response. If you have the decryption tool, we trust that you will find a way within your network to assist in resolving this issue. You have emphasized the importance of reputation, and we believe you will uphold your commitment. The company’s IT services are currently down, and we need to restore operations as soon as possible. We appreciate your prompt attention to this matter.”

At this point, a LockBit administrator took over the chat. Despite claiming to be based in the Netherlands, they switched to Russian and provided free decryptors along with recovery instructions. They claimed the affiliate account had been hacked and speculated that this may be a “special FBI operation to destroy their reputation or a setup from competitors”.

Ultimately, the decryptor did not work. The admin blamed the affiliate, suggesting they may have intentionally corrupted the encrypted files to sabotage LockBit’s reputation. The conversation ended here.

Notably, the Russian victim immediately identified themselves a Russian state-owned organization and expressed disbelief that such an attack could be intentional, criticizing the attacker for being unprofessional.

The affiliate account was subsequently suspended and tagged “ru target” in the admin panel.

In another chat ransomware affiliate “amleto” targeted a Russian municipality. Both parties quickly switched to the Russian language, the victim identified themselves as the administrator of the municipality, and expressed fear of the organizational consequences and being extorted for payment. Amleto reassured them that the decryptor would be provided for free.

However, the decryptor failed to restore the files. The affiliate offered additional troubleshooting support, but to no avail. The victim then, probably reassured by their colleagues or superiors, stated that “the Main Directorate is nervous” and “to fix this, the Main Directorate will contact the federal authorities”.

The conversation ended on April 25, which leaves us unsure whether the matter was eventually resolved. The affiliate account involved was also suspended.

These incidents show that even top-tier ransomware groups struggle to enforce internal policies across a decentralized affiliate network. While LockBit acted quickly to mitigate fallout and maintain its “do not target Russia” stance, these conversations reveal either:

• Operational mistakes by rogue or inexperienced affiliates
• Deliberate sabotage (internal or external)
• Or a sign that internal enforcement mechanisms are weaker than advertised

In both cases, the failure to decrypt and the administrative response underscore tensions between ideology, reputation management, and the loose governance inherent to RaaS ecosystems.

 

Conclusion and Mitigation Recommendations

The leaked LockBit chats offer a rare window into how ransomware affiliates operate, including how they select victims, negotiate ransoms and handle operational errors.

These insights underscore several key takeaways for organizations assessing their own exposure and response readiness:

• Ransomware targeting is rarely random. Many affiliates demonstrate preferences for specific industries or geographies and some perform detailed reconnaissance, including analysis of cyber insurance policies or stolen data to tailor ransom demands. Given the diversity of affiliates and targeting strategies, any organization may eventually become a target, regardless of size or sector.
• Paying the ransom is no guarantee of recovery or silence, especially for smaller targets. Our findings show that decryptors often fail, and support from attackers is unreliable or non-existent. In some cases, affiliates abandon negotiations altogether. Even when a ransom is paid in full, there’s no assurance that stolen data will be destroyed, and leaks like this one may still expose the incident publicly, undermining attempts to contain reputational damage.

Ultimately, preparation is more effective than negotiation. Organizations should invest in resilient backup strategies, robust segmentation, and detection of known ransomware TTPs. Our analysis of common ransomware TTPs shows how to detect and mitigate the most common ransomware affiliate techniques .

Here is our guidance from our common ransomware TTPs blog:

• Identify and patch vulnerable devices in your network
• Segment the network to avoid spreading an infection
• Monitor network traffic to detect signs of intrusion, lateral movement or payload execution.
• The table below summarizes specific prevention and detection actions for the most common ransomware TTPs:

 

How Forescout Can Help

The Forescout 4D Platform™ collects telemetry and logs from a wide range of sources such as security tools, applications, infrastructure, cloud and other enrichment sources, correlates attack signals to generate high-fidelity threats for analyst investigation and enables automated response actions across the enterprise.

Forescout has multiple detection rules for MITRE ATT&CK techniques, with a strong focus on those most commonly used by ransomware affiliates, including:

• User Execution (T1204) with 148 rules
• Valid Accounts (T1078) with 124 rules
• Phishing (T1566) with 115 rules.

The figure below shows a description of the “Phishing Attack Detection – Email Attachment/Link” detection rule. This rule is triggered when a sequence of Sysmon events indicates that a user has opened an attachment, a network connection has been established, and a malicious process has been launched – a common affiliate tactic in initial access campaigns.

Manage risks. Contain events. Mitigate threats. See the Forescout 4D Platform™ in action.