LockBit: from one identity to domain-wide ransomware, and why isolating a host will not save you
LockBit affiliates go identity-first: brute force into a valid account, dump LSASS, escalate to Domain Admin, exfiltrate to the cloud, then self-propagate before encrypting. Here is how it becomes org-wide and why containment means resetting krbtgt twice, not isolating one host.
LockBit is a ransomware-as-a-service operation. The people running the intrusions are affiliates who rent the payload and infrastructure, so the tradecraft varies but the shape is consistent: get in through identity, escalate to Domain Admin, steal data, then let a self-propagating payload do the rest. Encryption is the last act, not the first. The window before it is where an incident is won or lost.
How it works
The entry is rarely exotic. Affiliates favor internet-facing servers and valid accounts. A brute-force run against an exposed service, RDP endpoint, or VPN precedes a successful login with a real credential (T1190, Exploit Public-Facing Application, and valid-account reuse). Once on a host, the affiliate reads LSASS memory to harvest cached credentials (T1003.001, OS Credential Dumping: LSASS Memory). If one of those is a Domain Admin, the intrusion is effectively over before it looks like it has begun.
From there the affiliate moves over RDP and SMB admin shares using the stolen Domain Admin credential (T1021, Remote Services), disables endpoint protection on reachable hosts, and runs a StealBit-style tool to archive sensitive data and push it to external cloud storage (T1567.002, Exfiltration to Cloud Storage). Only then does the encryptor run (T1486, Data Encrypted for Impact). The data theft happens first, on purpose, so the crew has a leak threat even if you restore from backup.
Why it becomes org-wide
Two properties turn a single foothold into a domain-wide event.
The first is the credential. A Domain Admin credential recovered from LSASS is not one account. It is authority over the whole directory, and it works from anywhere until you invalidate it. Kerberos makes this worse: tickets already issued keep working, and the krbtgt account signs them all.
The second is self-propagation. LockBit is built to spread itself. Given a valid privileged credential, the payload can push to other hosts on its own. This is the property most responders underestimate. You find a compromised machine, you pull its network cable, and you feel contained. You are not. The credential still works everywhere, and the payload keeps moving to hosts you have not looked at yet.
How to detect it
The individual events look like admin work. The signal is the sequence on one host, in minutes: a brute-force burst then a valid-account login, then an LSASS read on that same host, then a Domain Admin logon originating from it. Correlate authentication (a 4625 burst then a 4624), an EDR LSASS handle or read alert, and a DA logon from a host that had no business producing one. Add a large outbound transfer to unfamiliar cloud storage and you are watching the pre-encryption phase in real time.
How to contain and shut it down
This is the part people get wrong. Isolating the host you found does not stop a self-propagating payload holding a live Domain Admin credential. Treat the entire credential base as burned:
- Isolate the beachhead and every host the Domain Admin credential touched, not just the first machine you saw.
- Disable and reset the compromised Domain Admin account.
- Reset krbtgt twice, with replication between the resets, so already-issued and forged Kerberos tickets die. Once is not enough because of how the key history works.
- Block the cloud exfiltration destination and confirm from proxy and DLP records exactly what left.
- Sweep every Domain-Admin-touched host for the staged encryptor before it detonates.
Then scope honestly. Even if you stop encryption, the data upload already happened, so this is a reportable exfiltration event and a likely double-extortion demand. Paying for a decryptor does nothing about data that is already gone.
Practice it
We built this as a scenario in GraphLattice Range: a LockBit-style affiliate going from a brute-forced valid account to Domain Admin, cloud exfiltration, and a self-propagating payload staged for detonation. It forces the non-obvious call under time pressure. Isolate one host and watch, or treat the credential base as burned and reset krbtgt twice. Teams that have made that call in a drill make it faster when it is real.