The exploit landed on a Saturday night. The ransomware ran nineteen days later, on a Thursday, and took under ninety minutes once it started. Everything interesting about this intrusion happened in the gap.
This is a simulated incident — our own hosts, our own narrative, our own synthetic logs — built on the technique sequence documented publicly by The DFIR Report in their Apache ActiveMQ / LockBit case. Their analysis is their own work and worth reading in full; nothing here reproduces it. What's reproduced is the shape of the attack, run against this catalogue's real detection rules to see which parts it would actually have caught.
The nineteen days are the whole story
Ransomware timelines get discussed as though the encryption is the incident. It isn't. Encryption is
the receipt. By the time LB3.exe executes, every decision that mattered has already been made —
and in this chain, there were nineteen days of them.
So the exercise below isn't "would you have detected the ransomware". It's: given a catalogue of 52 real rules, how early could you have stopped this, and what would it have cost you to be ready?
What gets caught, and what doesn't
Four of the six stages are covered. Two are not, and neither gap is an oversight.
The initial exploit is invisible to this catalogue. It arrives over the broker's own binary wire protocol — not HTTP. Every web-facing rule here (WAF, reverse proxy, web server) is pointed at a protocol the attack never touches. This is worth sitting with, because the catalogue does have eight rules tagged to the same ATT&CK technique. The flow shows them, under "parallel detections". Technique coverage on a heatmap is not the same as being able to see the attack, and this stage is what that distinction looks like in practice.
Ransomware execution is deliberately undetected too. An alert when the encryptor runs tells you what you are about to lose, not how to keep it. Every response action at that stage is recovery. Every action that would have changed the outcome sits in the five stages above it.
The one that should sting is stage three. The Security log was cleared on the file server
seventeen days before anything was encrypted. WIN-1007 catches that, and log clearing is about
as unambiguous a signal as this job offers — it is almost never anything but someone destroying
evidence. The rule existed. The event fired. Nobody was watching.
The host you can't save
One host stays Unknown no matter what plan you build. The reception workstation has no Sysmon
deployed, so there's no telemetry for it in the window — it may be untouched, it may have been
encrypted, and the logs cannot say. No containment action changes that, because a containment cap
tells you nothing about a host you cannot see.
That row is the honest one, and it's the same point the phishing walkthrough makes with its unmanaged personal device. Coverage gaps don't show up as alerts. They show up as rows you can't answer questions about, during the week you most need answers.
Work the chain
Expand any stage for its detection rules, its MITRE techniques, and the response actions available at that point. Check an action and the impact panel recomputes — checking one assumes that control existed before the intrusion started, capping how far the attacker could get.
Stages flagged amber have either no detection rule or no response action in your plan yet. Try
building the cheapest plan that gets Encrypted to zero, then look at which SANS phase your chosen
actions actually fall into. On this incident, most of the ones that work are Preparation — things
that had to be true before the Saturday night, not decisions made during the Thursday.