Detection was not the limiting factor. Response time was.
Compromised VPN credentials put an operator on the network. Over the next three days they scanned east to west across a broad range of ports, triggered Active Directory replication consistent with a credential dump, ran command and control over SSL, pushed data out to Wasabi cloud storage, and encrypted thousands of files. The customer had behavioural detection running and it saw all of it, stage by stage, while the intrusion was still reversible. Three days is a long time to be inside a network that is watching you.
What worked
The detection, and Darktrace is unusually blunt about which half of the problem it solved: "detection was not the limiting factor; response time was." The scanning was flagged. The replication anomaly was flagged. The command and control was flagged. More than 30 rare outbound connections to a Wasabi endpoint were flagged before a single file was encrypted, along with close to 3GB going to one external address and just under 4GB to another. None of that needed a signature or prior knowledge of the tooling, which is the case for behavioural detection made about as well as a vendor can make it.
What failed
Everything downstream of the alert. Autonomous Response was licensed and switched on in this environment, and the report says it "was not fully configured across the impacted devices, allowing the attack to progress to ransomware deployment." So the control that would have cut the sessions was bought, enabled, and inert on the machines that mattered. Nobody acted by hand either; the three days are the proof of that.
The uncomfortable reading is that this customer spent their detection budget correctly and finished in the same place as somebody who had spent nothing. Darktrace says as much in the counterfactual: "Prompt investigation and containment of devices exhibiting anomalous behavior could have prevented lateral movement, data exfiltration, and ultimately ransomware deployment." Every one of those stages was on a screen when it happened.
The number
3 days
from the first use of the compromised VPN credentials to encryption, with alerts raised at every stage in between and none of them acted on.
What to do instead
Go and check which of your automated response actions are actually armed, on which machines. Not whether the product is licensed, and not whether the feature is on in the console, but whether it will act tonight on the hosts that decide the outcome: domain controllers, file servers, the VPN concentrator, the jump boxes. A response capability configured across most of an estate is one the attacker routes around, and the part that was missed is never random. Ask for the coverage list rather than the coverage number.
Then write down who may cut a session, and when, and without whose permission. This intrusion ran for three days through alerts that a person could have acted on, and the reason teams default to watching is almost never that they did not believe the alert. It is that nobody has told them in writing that they are allowed to pull a host off the network at two in the morning and be wrong about it.
Then take the exfiltration signal seriously on its own. Rare-destination cloud storage is the most useful single rule here: more than 30 connections to a Wasabi endpoint from a host that had never spoken to it, carrying gigabytes, in an environment where nothing legitimate uses that provider. If your egress alerting is tuned on total volume rather than on destination rarity, that traffic looks like a backup job.
And rotate the VPN credentials and check what else they open. This started with valid credentials on remote access, which is the same first step as most of what lands in this section.