Ransom notes are a receipt, not the crime. Most teams still plan for the encryption: locked files, a countdown, a recovery clock ticking against clean backups. That plan is a decade out of date. Operators steal the data first and encrypt second, because the threat to publish gets paid even when your restore works perfectly.
The reordering changes where you have to be looking. By the time files encrypt, the leverage already walked out. The theft happened earlier, quietly, on access the foothold already holds.
The theft phase breaks no rule
An operator with a foothold uses real credentials in an authenticated session. The file shares it reads are shares that account is allowed to read. The egress path is one the environment already trusts: an approved cloud storage bucket, a sanctioned SaaS sync, an outbound connection that reads like nightly backup traffic.
So staging and exfiltration do not trip anything. Valuable data walks out on access granted on purpose, through channels that exist for legitimate reasons. Every move is permitted. The pattern is the breach.
Permission-based tools have nothing to grab here. A SaaS control sees an authorized account uploading to an approved destination. A network control sees an allowed egress route carrying encrypted traffic it cannot read into anyway. An endpoint tool hunting known malware sees a session that, at the file level, looks like an admin doing admin work. None of it is a violation.
Encryption-first detection watches the wrong moment
Mass file modification, the entropy spike of encryption in progress, ransom notes appearing on shares: real signals, and the tools that catch them earn their place. But they fire after the data is already gone. Encryption is the operator announcing the theft. It is not when the theft occurs.
A window opens long before that announcement. The intruder lands, moves laterally, finds what is worth taking, stages it, and pushes it out, sometimes over days, sometimes weeks. Across that entire window the only activity is data movement the environment is configured to allow, one permitted action at a time. That window is where the exfiltration lives. It is also the window most stacks were never built to watch.
Catch the pattern while it forms
You can only catch the theft phase at runtime, on the movement itself, while it happens. Not before, where predictive tools guess at intent and bury teams in false alarms. Not after, where the disclosure letter is the only artifact left. While the data moves.
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not read content, and it does not need to read your data to see that a pattern is wrong. Each move resolves to a probabilistic, source-dependent identity: which account, the job behind it, the destination, and whether this fits how that identity has moved data across months of history.
Run a real foothold-driven exfiltration against that vantage and the deviation shows up across layers at once. The account reaches into high-value paths it never touches. Its reads go broad and pile into a short window instead of the narrow, routine reads it usually performs. The destination carries an unusual volume even though the channel is approved. The timing sits outside that identity's envelope.
Take any one of those signals alone and it is noise. A legitimate backup also moves a lot of data to an approved destination. A migration also reads broadly. No single move is the point. The shape of the whole sequence is, resolved to the identity behind it and scored against how that identity actually behaves. Hilt writes that shape as a case, built from the moves that compose it, so nobody has to reconstruct the story from logs later.
When the case crosses the line, Hilt isolates the host at the network from the control plane. The host comes off the network and the staged data stops leaving. The collector never sits inline, never drops a packet, never stands between your data and where it is going. Isolation at the network, not interference with traffic.
Where it fits in your ransomware response
Hilt can stand in for your endpoint sensor, and many clients retire their EDR once it is in place. Keep an EDR alongside only if you want the malware and intrusion layer too, the known tooling and malicious binaries Hilt does not look for. Backup and recovery still bring the business back when files do encrypt. Network controls still enforce the policy that defines what counts as approved. Those layers do real work, and Hilt replaces neither of them.
They share one structural limit. They judge whether each action is permitted, or they catch the loud event after the quiet one is finished. None of them scores the pattern of movement across permitted actions, in the window before the encryption announces itself. That window is the blind spot. Runtime data movement governance closes it by watching the movement directly, while it forms, and resolving it to a job and an identity instead of a rule.
Double extortion rests on one assumption: the theft happens unobserved, and you learn of it only when the operator decides to tell you. Watch the theft phase at runtime and that assumption is gone. The leverage the operator counts on, data already copied out before anyone noticed, is exactly what a kernel view of data movement catches as it is being assembled.
So the question for your stack is narrow. Can it answer this: did this account just move an unusual volume of high-value data to an approved destination, in a pattern it has never shown, in the days before anything encrypted? If it cannot, the pre-encryption window is your gap.
If you want to see how the theft phase looks from the kernel, the next step is a 30-minute technical call, engineer to engineer. No slideware. Just the architecture and where it sits relative to your traffic.