One toolkit, many ransomware brands: why the ransom note lies about who hit you

Incident reports increasingly tie multiple ransomware brands to a single intrusion through a shared toolkit and affiliate crossover, with a commodity remote access tool observed on the wire. This is not a curiosity, and it is not speculation: CISA has documented that the RansomHub operation recruited affiliates from LockBit and ALPHV (advisory AA24-242A), and those affiliates bring the same tradecraft with them across brands. It breaks a habit most incident response teams still lean on: identify the gang, pull the gang’s playbook, respond to the gang. When one loader, one RAT, and one playbook serve three brands, the ransom note tells you almost nothing about how to respond.

The operators running these intrusions are affiliates. They rent a payload and infrastructure and bring their own tradecraft, and that tradecraft travels with them across brands. So the same person can hit you under one banner this month and another next month, using the same loader and the same RAT both times. The brand on the ransom note is a marketing label. The toolkit is the actual attacker.

How it works

The shape is consistent regardless of which brand ends up on the note. A phishing lure delivers a first-stage loader through a script host (T1566, Phishing, then T1059, Command and Scripting Interpreter). The loader stages a commodity RAT that beacons out to attacker infrastructure on a regular interval over HTTPS (T1071, Application Layer Protocol). This is a commodity RAT of the kind reported servicing more than one crew.

With a foothold established, the operator works hands on keyboard. They read LSASS and pull cached secrets from the beachhead (T1003, OS Credential Dumping), harvesting a helpdesk account and a cached admin credential. They then move over remote services to a management server and enumerate Domain Admins (T1021, Remote Services), staging the Active Directory escalation that precedes encryption. Before any encryptor deploys, sensitive shares are archived and pushed to a web-service upload endpoint (T1567, Exfiltration Over Web Service), preserving a leak threat that survives your backups.

Encryption, when it comes, is the last act. Every step before it is brand-independent.

Why brand attribution misleads you

If you anchor detection and containment on which gang this is, you chase the wrong artifacts. A ransom note appears far too late to help. A file hash attributed to one named family is unreliable precisely because the same tool serves multiple crews, and the next campaign repackages it anyway. A published IOC feed for the named gang will miss most of what the affiliate in front of you actually does, because that affiliate reuses tooling that predates and outlives any single brand.

The honest position is that brand attribution is low-confidence when tooling is shared. The named gang may not even be the actual operator. That has real consequences for how you report the incident, which we come back to below.

How to detect it

Detect on the behavior chain, not the brand. The reliable early signal is the sequence on one host: a script-host loader from a phishing lure, a RAT beaconing on a regular cadence to an external host, then an LSASS read on that same machine. Correlate the mail-gateway delivery, the EDR process tree, the regular-interval outbound beacon in proxy telemetry, and the credential-access alert. Add a large staged upload to an unfamiliar web endpoint and you are watching the pre-encryption phase in real time.

That chain fires the same way whatever brand eventually appears on the note. It is durable because it describes what the operator does, not what tool build they happened to use this week.

How to contain and shut it down

Containment keys on the shared TTPs and the burned credential base, independent of brand.

• Isolate the beachhead and sever the RAT command-and-control channel so the operator loses their remote session.
• Treat every credential harvested from the compromised hosts as burned. Reset the helpdesk account and the cached admin credential the operator pulled from LSASS, not just the phished finance user. One phished password is not the whole credential base.
• Scope from your own telemetry: EDR credential-access alerts, Windows 4624/4672 authentication logs, and proxy or DLP egress records. Those show which credentials were exposed, where they were used, and what data left. The ransom note and the RAT’s family name describe the toolkit, not your incident.
• If the operator reached a Domain-level credential, safe recovery means resetting krbtgt twice with replication between the resets so already-issued and forged Kerberos tickets die, then rotating the exposed privileged accounts before you restore trust.

Then scope honestly for the business. Data was staged and pushed to a web-service upload before any encryptor ran, so this is a reportable exfiltration regardless of whether encryption fired. Base notification on data type and jurisdiction, and flag brand attribution as low-confidence rather than naming a gang you cannot confidently prove.

Practice it

We built this as a scenario in GraphLattice Range: a phishing loader drops a commodity RAT, an affiliate harvests credentials and moves toward Domain Admin, and data is staged for exfiltration before any encryptor deploys, all while the tooling maps to multiple ransomware brands at once. It forces the non-obvious call under time pressure. Wait for threat intel to name the gang, or contain on the shared TTPs and burn the credential base now. Teams that have made that call in a drill make it faster when it is real, and they stop letting the ransom note dictate the response.