Exposed message broker to domain-wide ransomware: why patching the broker does not contain LockBit

A LockBit intrusion that starts on an internet-facing Apache ActiveMQ broker teaches a lesson responders keep learning the hard way: the entry point is not the incident. An unauthenticated remote code execution on the broker is only the first move. What follows is identity theft, lateral movement, data exfiltration, and a self-propagating encryptor. By the time you notice, patching the broker fixes almost nothing.

How it works

The broker is reachable from the internet and running a version vulnerable to a deserialization class of remote code execution. An attacker sends a crafted marshalled object over the OpenWire protocol, the broker deserializes it, and it fetches and loads an attacker-controlled Spring class from a remote host. Code now runs as the broker service account (T1190, Exploit Public-Facing Application). No credential was needed to get in.

From that foothold the affiliate reads LSASS memory on the broker host to harvest cached secrets (T1003, OS Credential Dumping) and recovers a domain account used to administer the broker. That credential authenticates over SMB admin shares and RDP to interior servers (T1078, Valid Accounts, and T1021, Remote Services), and the affiliate elevates to an account with directory-wide authority.

Before any encryption, a StealBit-style tool archives file shares and pushes them to external cloud storage over HTTPS (T1567, Exfiltration Over Web Service). Only then does the self-propagating encryptor run (T1486, Data Encrypted for Impact). The data theft comes 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 exposed broker into a domain-wide event.

The first is the stolen credential. A privileged domain credential recovered from LSASS is not one account. It is authority over the 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. Patching the broker does nothing to that credential. The door you closed is not the one the attacker is still using.

The second is self-propagation. The LockBit payload is built to spread itself. Given a valid privileged credential, it pushes to other hosts on its own. This is the property most responders underestimate. You find the broker, you pull it off the network, 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 execution signal on the broker is process lineage. A message broker JVM has no business spawning a shell or a living-off-the-land binary. A child process off the broker process, right after an inbound OpenWire connection from an unexpected address, together with a fetch of a remote class or XML, is the remote code execution landing. Queue depth, restarts, and normal client subnets are routine and will not tell you anything.

After that, the signal is the sequence: an LSASS read on the broker host, then a privileged logon originating from a host that had no business producing one (correlate a 4624 network or RDP logon with a 4672 privileged logon from the broker), then a large outbound transfer to unfamiliar cloud storage. That last event is the pre-encryption exfiltration in real time.

How to contain and shut it down

This is the part people get wrong. Patching or removing the exposed broker closes the RCE, but it does not undo the stolen valid credential and it does not stop a self-propagating payload. Isolating the one host you found is not containment. Treat the entire credential base as burned:

• Isolate the broker host and every host the stolen credential touched, not just the first machine you saw.
• Disable and reset the compromised privileged 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 credential-touched host for the staged encryptor before it detonates.

Then scope honestly. The upload already happened, so this is a reportable exfiltration event and a likely double-extortion demand, independent of whether you reverse the encryption. Paying for a decryptor does nothing about data that is already gone. Obligations follow the scoped data exposure, not the entry point.

Eradication closes the class, not the one broker. Take message brokers off the internet, patch them, run them under a least-privileged service account with no path to Tier 0, and inventory other exposed middleware for the same deserialization pattern.

Practice it

We built this as a scenario in GraphLattice Range: an unauthenticated RCE on an exposed message broker, credential theft, lateral movement to a privileged account, cloud exfiltration for double extortion, and a self-propagating encryptor staged for detonation. It forces the non-obvious call under time pressure. Patch the broker 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.