What GuidePoint reported
An entity calling itself “Ransom Busters” and “Ransom Busters LTD” approached ransomware victims before their incidents had become public, according to GuidePoint Security’s Research and Intelligence Team, or GRIT. The purported recovery provider offered to supply decryption keys and arrange the deletion of stolen data for payments ranging from $20,000 to $60,000, GRIT reported.
GRIT assesses with moderate confidence that Ransom Busters was not an independent recovery provider. The researchers’ assessment is that the entity was probably the ransomware affiliate responsible for the intrusions and was seeking an additional payment outside the ransomware-as-a-service, or RaaS, operation used in each attack.
That relationship has not been proven, and NewsForge is not treating Ransom Busters’ suspected role as a confirmed fact. The assessment rests on a combination of forensic overlap and unusually early knowledge of attacks that were not yet public.
GRIT’s technical report is the primary basis for this attribution analysis. BleepingComputer separately summarized the findings and reported on the recovery offers. The RaaS operations named by GRIT in connection with the incidents were DragonForce, Settra, and Anubis.
If GRIT’s assessment is correct, the suspected affiliate was pursuing an additional payment through a purported recovery service outside the original ransomware operation. It could also indicate an attempt to bypass or deceive the RaaS operators whose infrastructure and branding supported the attacks. It is a notable variation on the division of labor commonly associated with subscription-based cybercrime.
The forensic evidence linking the recovery alias to the intrusions
Timing made the approaches suspicious, but timing alone did not establish the connection. GRIT said its assessment was based on technical overlap between the ransomware intrusions and the purported recovery service.
The reported links included:
- Shared tooling associated with the incidents.
- A backdoor account using the password
Numlock!123. - The hostname
DESKTOP-BBETH6K, identified across two incidents. - Matching datasets connecting material held by Ransom Busters with data involved in the intrusions.
According to GRIT, the recurrence of these artifacts across separate cases supported the view that the recovery alias and the intrusion operator were connected. The matching datasets indicated that Ransom Busters possessed or knew details about victim material; that finding does not, by itself, establish how the entity obtained the data or prove direct access to the victims’ systems.
Ransom Busters’ contact with victims before public disclosure adds corroborating context. An ordinary recovery vendor could learn about an incident through a victim, insurer, attorney, or incident-response partner. An unsolicited provider that already knows about a non-public compromise presents a different question: how did it obtain that knowledge?
In this case, GRIT said the timing appeared alongside the shared account, hostname, tools, and data. Its conclusion therefore did not depend solely on the early outreach.
Sensitive indicators can also have investigative value beyond a public report. Organizations should preserve original messages and technical metadata and share indicators through authorized channels with incident responders, counsel, insurers, law enforcement, or appropriate information-sharing organizations. Public or uncontrolled circulation of wallet addresses, domains, or other indicators can alert an actor or complicate an active investigation.
Why the assessment remains at moderate confidence
GRIT explicitly placed its assessment at moderate confidence. The reported artifacts support a connection, but the available account does not establish a verified human identity behind Ransom Busters or directly prove who controlled every relevant account, system, and RaaS panel. Shared credentials and hostnames can be strong investigative leads, but access can be transferred, shared, stolen, or deliberately imitated.
NewsForge’s analysis is that higher confidence would require evidence that closes those attribution gaps. Examples could include a verified payment trail, authenticated panel records, infrastructure ownership information, operational logs, or independently validated communications tying the same operator to both the intrusions and the recovery offers. Such evidence has not been supplied for this report.
The confidence label separates a technically supported assessment from a proven identity or a formal finding by an authority.
Ransom Busters’ competing explanation
Ransom Busters reportedly described itself as having “exploited vulnerabilities in RaaS admin panels.” Under that version of events, it was not the affiliate behind the attacks but an outside party that gained access to ransomware operations and then used that access to approach victims.
That is the actor’s unverified self-description. It has not been established as the mechanism behind the incidents and should not be read as an independent technical finding.
GRIT’s forensic assessment points in a different direction: the shared intrusion artifacts and datasets were more consistent with Ransom Busters being the affiliate involved in the attacks. The difference between those accounts remains unresolved because the operator behind the alias has not been publicly verified.
Ransom Busters LTD appears to be an anonymous alias rather than a verified corporate identity. NewsForge had no verified corporate representative from whom to seek a response.
What happened to the victims’ data and payments
GRIT said it did not observe any victim paying Ransom Busters. The reported cases therefore do not demonstrate that the purported recovery service delivered a working decryptor or caused stolen data to be deleted.
In one case, GRIT said the victim paid the original ransomware operation. The victim’s data was subsequently not seen leaked, according to the researchers. That outcome does not verify Ransom Busters’ claims, nor does the absence of an observed leak prove that every copy was deleted.
This distinction is important when evaluating any claim of data deletion. A victim usually cannot independently establish that every copy, backup, transfer, or derivative dataset has been removed from systems controlled by an unknown party. A promise not to publish data is not the same as verifiable destruction.
The Ransom Busters offers combined two services that victims urgently want: restoration through decryption and prevention of disclosure through deletion. Those promises should be evaluated separately. Possession of a functional decryption key would not, by itself, prove that the provider can delete stolen information.
Independent corroboration and remaining unknowns
BleepingComputer reported that Coveware confirmed a separate incident involving outreach attributed to the same Ransom Busters actor or group. That corroborates the existence of similar contact beyond the incidents examined by GRIT. It does not independently confirm GRIT’s assessment that Ransom Busters was the ransomware affiliate behind the attacks.
The known and unknown elements can be separated as follows.
Reported findings
- Victims received unsolicited recovery offers before their incidents became public.
- Ransom Busters offered decryption and data deletion for $20,000 to $60,000.
- Technical overlap included shared tooling, the
Numlock!123backdoor password, theDESKTOP-BBETH6Khostname, and matching datasets. - DragonForce, Settra, and Anubis were the RaaS operations named in the cases.
- GRIT did not observe a victim paying Ransom Busters.
- GRIT assesses with moderate confidence that Ransom Busters was the affiliate behind the attacks.
- Coveware confirmed a separate incident involving similar outreach, as reported by BleepingComputer, but did not thereby confirm the suspected affiliate relationship.
What remains unverified
- The real identity of the person or group operating as Ransom Busters LTD.
- The exact contractual or operational relationship between that actor and each RaaS operation.
- Whether the actor exploited RaaS administration panels, as it claimed.
- Whether it could reliably provide decryption or ensure deletion.
- Whether additional victims paid without GRIT observing the transactions.
Warning signs when evaluating a recovery provider
Unsolicited outreach does not automatically prove that a provider is connected to an attacker. In the Ransom Busters case, however, foreknowledge of non-public incidents appeared alongside forensic overlap. Organizations evaluating a provider should investigate both the contact and the provider’s identity before sharing data or authorizing payment.
Warning signs include:
- Knowledge of a non-public incident that the provider cannot credibly explain.
- Refusal to disclose a verifiable legal name, physical presence, ownership, or responsible personnel.
- Communication conducted only through anonymous accounts or newly encountered contact details.
- Pressure to pay quickly or avoid involving counsel, insurers, law enforcement, or an established incident-response team.
- Claims that stolen data can be deleted without explaining what evidence could support that claim.
- Requests for cryptocurrency or sensitive technical access before contractual and identity checks are complete.
- An unwillingness to document the scope of work, fees, data handling, conflicts of interest, and use of subcontractors.
- Assertions of privileged access to an attacker that cannot be independently validated.
A credible provider should be willing to undergo ordinary vendor checks. Depending on the organization and jurisdiction, that can include corporate registration checks, references, conflict screening, review by counsel, insurance coordination, and sanctions-related due diligence. A provider should also explain whether it communicates with threat actors directly and how it protects evidence and confidential information.
None of these checks can guarantee that a provider is trustworthy. Together, they reduce the risk of giving an attacker-linked intermediary more money, information, or access.
Preserving evidence after unsolicited outreach
An unexpected recovery offer may become evidence in an incident investigation. Staff should avoid replying impulsively, opening attachments, clicking links, or moving the conversation to another platform before the security and legal teams assess it.
Preservation steps should include:
- Retain the original message in its native format, including full headers and attachments.
- Record when and how the message arrived, who received it, and whether anyone replied.
- Preserve related logs from email systems, identity providers, endpoints, firewalls, remote-access tools, and affected servers.
- Capture the alias, domains, telephone numbers, payment instructions, wallet information, and exact wording without testing attacker-controlled infrastructure from a normal business device.
- Maintain a documented chain of custody for exported messages, images, disk data, and log files.
- Give copies to the organization’s incident-response team and counsel rather than forwarding them widely.
- Compare the sender’s knowledge with facts that were not public. This can help investigators determine where the information may have originated.
- Coordinate external communications so that public statements do not expose investigative details or create conflicting accounts.
Organizations should not allow a purported recovery vendor to connect to affected systems until its identity, role, and access requirements have been reviewed. If technical access is approved, it should be restricted, logged, monitored, and separated from unaffected systems.
Evidence-preservation practices should be aligned with instructions from qualified incident responders, counsel, and the authorities responsible for the relevant jurisdiction. Authorized sharing with responders or authorities is different from public distribution of sensitive indicators.
Reporting, sanctions, legal, and insurance considerations
Incident-reporting duties, payment rules, sanctions exposure, and evidence requirements depend on the organization’s location, sector, contracts, and affected data. Organizations should have qualified counsel identify the current rules and official guidance that apply in each relevant jurisdiction.
For incidents affecting US organizations, response teams should consult current guidance from relevant authorities, which may include the Cybersecurity and Infrastructure Security Agency, the FBI and its Internet Crime Complaint Center, the Treasury Department’s Office of Foreign Assets Control, and applicable federal or state regulators. Organizations outside the United States should consult the corresponding national law-enforcement, cybersecurity, sanctions, privacy, and sector authorities.
Before any payment or negotiation, the response team should also involve the cyber insurer when a policy may apply. Insurers can have notice, consent, vendor, and documentation requirements. Those requirements should be confirmed from the actual policy rather than assumed.
Sanctions screening requires particular care because an alias may conceal the recipient’s identity or relationship with another entity. A recovery intermediary does not eliminate that uncertainty. Legal and compliance teams should assess the recipient, associated infrastructure, and proposed transaction under the rules applicable to the organization.
Organizations should also determine which authorities or regulators must or should receive a report. That decision should be based on current official instructions and legal advice, not on assurances from a recovery vendor or threat actor.
Practical response checklist
When an unsolicited provider claims it can decrypt systems or delete stolen data:
- Treat the communication as potential evidence.
- Do not click links, open attachments, or grant access from the initial message.
- Preserve the original message, metadata, payment instructions, and related logs.
- Notify the incident-response lead, counsel, insurer, and relevant executives.
- Ask how the sender learned about the non-public incident.
- Verify the provider’s legal identity, personnel, ownership, references, and conflicts.
- Separate claims about decryption from claims about data deletion.
- Require a written scope, fee structure, access plan, and data-handling terms.
- Conduct applicable sanctions and compliance checks before considering a transaction.
- Confirm reporting obligations with qualified advisers and current official guidance.
- Keep access limited and monitored if an outside provider is engaged.
- Do not treat the absence of leaked data as proof that stolen copies were deleted.
NewsForge will update this report if independently verified evidence or official findings clarify the identity of Ransom Busters, its relationship with the named RaaS operations, or the results of its approaches to victims. Readers seeking a correction should use NewsForge’s established editorial contact channel.
