Ransomware Early-Warning Detection

By the time files are encrypting, you have already lost the window to respond well. Modern ransomware is the last step of a longer intrusion, and it announces itself with loud precursors — the attacker deletes volume shadow copies, disables recovery, tampers with backups, and spikes file activity. The single best early-warning signal is shadow- copy deletion: it happens just before encryption and has almost no legitimate use at scale. This guide ships that detection and the recovery-focused hardening behind it.

Ransomware maps to MITRE ATT&CK T1486 — Data Encrypted for Impact, and its recovery-inhibition step to T1490 — Inhibit System Recovery. It rides on the lateral movement, credential theft, and BYOVD covered across the Windows detection cluster.

Why detect ransomware before encryption?

Encryption is fast and irreversible; detecting it as it happens leaves you watching the damage. But ransomware operators spend days or weeks inside a network first — gaining access, stealing credentials, moving laterally, exfiltrating data for double extortion, and disabling defenses and backups — before they push the encryptor. Every one of those stages is detectable, and each gives far more time to contain the intrusion than the encryption itself.

The most reliable single early-warning signal sits right before encryption: the attacker destroys the local recovery options so you cannot simply restore. That action is loud, rare, and almost always malicious at scale.

What are the ransomware precursor signals?

The earlier in this list you detect, the more of the intrusion you can stop. Shadow-copy deletion is the highest-value single rule; the file-change spike is the last chance before loss.

How to detect ransomware early

The core rule flags the recovery-inhibition commands, via process-creation telemetry.

title: Volume Shadow Copy Deletion or Recovery Disable
id: 9d2f1a83-darkpwn-illustrative
status: stable
logsource:
  product: windows
  category: process_creation
detection:
  vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains|all: ['delete', 'shadows']
  wbadmin:
    Image|endswith: '\wbadmin.exe'
    CommandLine|contains: 'delete catalog'
  bcdedit:
    Image|endswith: '\bcdedit.exe'
    CommandLine|contains: ['recoveryenabled no', 'bootstatuspolicy ignoreallfailures']
  condition: vssadmin or wbadmin or bcdedit
falsepositives:
  - Rare legitimate backup maintenance (allowlist the specific admin host/account)
level: high

Where the vssadmin rule fails

That rule is genuinely high value and it keys on a process, which is a place attackers have moved away from.

Shadow copies can be deleted without ever launching vssadmin.exe — through WMI, through PowerShell against the shadow-copy WMI class, or by calling the underlying COM interfaces directly from the encryptor. All of those achieve identical results and generate no vssadmin.exe process creation, so a rule matching on Image|endswith: '\vssadmin.exe' sees nothing at all.

Cover the outcome as well as the tool:

• Watch WMI and PowerShell touching shadow-copy classes, not only the command-line utility. This is a different rule against a different data source, and the command line is still readable in that path.
• Watch the backup subsystem’s own events. Windows logs backup-catalog deletion, and events from the volume shadow-copy service provide corroboration independent of how the deletion was requested — which is the property you want, since it holds regardless of the API used.
• Watch the state, not just the action. A scheduled check that shadow copies exist on critical systems catches deletion by any method, including ones nobody has documented yet. It is slower than an alert and it has no evasion.
• Use EDR API telemetry where you have it. Products that observe the underlying calls see the operation whichever wrapper invoked it.

The general lesson recurs across this site: a rule keyed to a tool detects that tool; a rule keyed to an outcome detects the technique. Keep the vssadmin rule — plenty of ransomware still takes the easy path — and do not let it be your only coverage for recovery inhibition.

The exfiltration window is the longest one you get

Every signal above fires minutes before encryption. Exfiltration happens days earlier, and it is the widest response window in the whole intrusion — as well as the one that decides whether good backups actually save you.

This matters more than it used to, because double extortion changed the arithmetic. An organisation with immaculate, tested, immutable backups still faces publication of whatever was taken. Restoring cleanly answers the availability problem and does nothing about the disclosure one. Backups are not a defence against data theft, and treating ransomware readiness as purely a recovery question quietly concedes half the incident.

What exfiltration looks like:

• Staging. Large archives appearing in temp directories, on file shares, or on a server that never produces them. Attackers collect before they send, and the collection is visible on disk.
• Transfer tooling that does not belong. Cloud-sync and file-transfer utilities appearing on servers are a hallmark of this stage — rclone in particular is closely associated with ransomware exfiltration, and a server has no ordinary reason to run it.
• Sustained outbound volume to cloud storage or file-sharing services from a host that has never used them, especially outside working hours.
• Access to file shares far beyond an account’s normal pattern, as the attacker inventories what is worth taking.

Two of those — an unexpected transfer utility on a server, and sustained upload to a file-sharing service — are cheap detections with very low false-positive rates in a server segment, and they fire while there is still time to prevent the theft rather than merely the encryption.

Incident-response reporting has consistently shown the interval from initial access to deployment compressing, with some intrusions moving in well under a day. Plan for the exfiltration window to be hours rather than weeks, and prioritise detections that do not require days of baselining to fire.

Backups: the questions that actually matter

“Tested, offline or immutable backups” is correct and abstract. These are the specific questions that determine whether yours survive an attacker with domain administrator rights.

• Can your backups be deleted with credentials the attacker will have? A domain-joined backup server administered with domain accounts is compromised at the same moment the domain is. This is the single most common reason a well-funded backup programme fails, and it is an architecture problem rather than a product one. Separate credentials, separate identity domain, separate administrative path.
• Is immutability enforced by the storage, or by policy? Object-lock or WORM storage refuses deletion regardless of who asks. A retention setting that an administrator can change is a preference, and the attacker will be an administrator.
• Have you tested a restore, or a backup? Backup jobs report success constantly while producing unrestorable data. The test that matters is a restore to a clean system, verified by someone who can confirm the data is correct.
• How long would a full restore take? This is the question that most often changes the plan. If restoring your estate takes six weeks, your backup strategy has not solved the problem it was bought for — and the answer is usually unknown until an incident measures it. Time a representative restore and extrapolate honestly.
• What is your recovery order? Domain controllers, identity, and the backup infrastructure itself come before application servers. An order improvised during an incident wastes days.
• Are backups scanned before restoration? Restoring a backup that contains the attacker’s persistence reintroduces the intrusion, and the dwell time means recent backups are the likely ones.

That fourth question is the one to take away. Organisations discover their real recovery time during the incident, and it is routinely an order of magnitude longer than assumed.

Should isolation be automatic?

Automated host isolation on the recovery-inhibition alert is recommended above, and it deserves a more careful treatment because the failure mode is severe in both directions.

For automation: encryption completes in minutes. Human response does not. If the alert fires at 3 a.m. and the response is a page, the encryption finishes before anyone reads it. This is one of very few detections where the time budget genuinely rules out a human in the loop.

Against automation: a false positive isolates a production system. If the rule misfires on a backup server or a domain controller during business hours, you have caused an outage with your security tooling — and the political cost of that lands on every subsequent automation proposal.

A workable middle:

• Automate isolation on workstations. The blast radius of a wrongly isolated laptop is one person for one hour, and workstations are where most encryptors start.
• Alert-only on servers and Tier 0, with a defined on-call action. Accept the slower response in exchange for not taking production down on a false positive.
• Require two signals for automated server isolation if you want it there — recovery inhibition plus a mass-file-change spike, for instance. Both together have essentially no benign explanation.
• Make the isolation reversible in one action, and make sure whoever is on call knows how. Automation people cannot undo quickly gets disabled after its first false positive.
• Test it deliberately. An isolation response nobody has exercised is a plan, not a control, and this is exactly the sort of thing that fails on a detail — an agent that isolates the host from the network including the management channel you needed to investigate it.

How do you respond in the first hour?

1. Isolate, do not power off. Pulling network connectivity stops spread. Powering off destroys volatile evidence and, with some families, triggers further encryption on the next boot.
2. Determine whether encryption is running or finished. These are different incidents — stopping an active encryptor saves whatever it has not reached yet, which is frequently most of the estate.
3. Identify the strain from the ransom note and a sample encrypted file. Public identification services and the No More Ransom project maintain free decryptors for a number of families, and the check costs minutes. It occasionally ends the incident.
4. Preserve the note, samples, and logs before remediating. They drive identification, attribution, and any insurance or regulatory process, and the instinct to clean up destroys them.
5. Assume data was exfiltrated and start that investigation in parallel. It has its own notification obligations and its own timeline, and it is not resolved by restoring.
6. Find the entry point before restoring. Restoring into an environment where the access remains open produces a second encryption event within days, and it has happened often enough to be a recognised pattern.
7. Check backups are intact and clean before you rely on them. Verify immutability held, verify the copies exist, and scan for the attacker’s persistence in the images you plan to restore.
8. Engage the people who need to be involved — legal, insurance, executive, and regulator contacts — early. Every one of those relationships works better when initiated in hour one rather than day three.

Point 6 is the one that separates a bad week from a bad quarter. Recovery is urgent and the pressure to restore is immense, and restoring before the intrusion is understood is how organisations pay for the same incident twice.

How to test your ransomware detection

In an isolated VM you own:

1. Run a benign vssadmin delete shadows in a lab and confirm the rule fires; allowlist the legitimate backup-admin path.
2. Simulate a mass-file-change spike (a benign script renaming test files) and confirm the rate detection triggers.
3. Deploy canary files and confirm access to them alerts.
4. Confirm normal backup maintenance, once allowlisted, stays quiet.

How to defend against ransomware

• Detect and contain the earlier stages — credential theft, lateral movement, exfiltration — for the biggest response window. Exfiltration in particular is the stage where detection still prevents something that backups cannot undo, which makes it the highest-value place to spend detection effort even though it gets the least attention.
• Automate host isolation on the shadow-copy-deletion alert for workstations, and require a second corroborating signal before automating the same action on servers — the encryption window is too short for a human, and a false positive that takes production down costs you every future automation proposal.
• Keep EDR tamper protection on and monitor for BYOVD — disabling the endpoint agent is a precondition for the encryptor running unimpeded, which makes agent health a ransomware signal rather than an operations metric.

Common ransomware-detection mistakes

• Waiting for encryption. Detect the precursors for a real window.
• No shadow-copy-deletion rule. The highest-value early signal goes uncollected.
• Online-only backups. The attacker deletes what they can reach.
• No isolation response. Detection without containment just watches.
• Matching only vssadmin.exe. Shadow copies can be deleted through WMI or COM with no such process created, and the rule then sees nothing at all.
• Never checking that shadow copies still exist. A scheduled state check catches deletion by any method, including ones nobody has documented.
• Treating backups as the answer to double extortion. They restore availability and do nothing about publication of what was already taken.
• Not watching for transfer tooling on servers. A cloud-sync utility appearing on a server is the exfiltration stage, and it fires days before encryption.
• Backups reachable with the credentials the attacker will hold. A domain-joined backup server administered with domain accounts falls at the same moment the domain does.
• Retention settings instead of storage-enforced immutability. A policy an administrator can change is a preference, and the attacker will be an administrator.
• Testing backups rather than restores. Backup jobs report success while producing unrestorable data.
• Not knowing your full restore time. Organisations measure it during the incident, and it is routinely an order of magnitude longer than assumed.
• Automating isolation on servers without a second signal. A false positive takes production down and costs you every future automation proposal.
• Restoring before finding the entry point. The same access produces a second encryption event within days.
• Powering off instead of isolating. Volatile evidence is destroyed, and some families continue encrypting on the next boot.

Ransomware early-warning detection checklist

1. Alert on shadow-copy deletion and recovery-disable commands (vssadmin/wbadmin/bcdedit).
2. Detect abnormal file-modification and rename rates, and unusual extensions, per host — the last-chance signal before data loss.
3. Deploy canary/honey files across shares and endpoints, named so they sort early in a directory walk, and alert on any access — nothing legitimate reads them.
4. Detect the precursors: credential theft, lateral movement, exfiltration, EDR tampering.
5. Automate host isolation on the recovery-inhibition alert.
6. Maintain tested 3-2-1 backups with an offline/immutable copy.
7. Segment the network and protect backup infrastructure as Tier 0, with its own credentials and its own administrative path rather than domain accounts.
8. Rehearse restoration; keep EDR tamper protection on.
9. Cover shadow-copy deletion through WMI and COM, not only vssadmin.exe, and run a scheduled check that shadow copies still exist.
10. Detect the exfiltration stage — staging archives, unexpected transfer tooling on servers, sustained upload to file-sharing services — which fires days earlier than anything else here.
11. Verify backups cannot be deleted with credentials the attacker will hold, and that immutability is enforced by the storage rather than by policy.
12. Measure your actual full-restore time and write the recovery order down before you need it.
13. Scope automated isolation to workstations, or require two signals on servers, and test that the isolation is reversible.

Item 12 is the one that most often changes the plan. Recovery time is assumed until an incident measures it, and organisations routinely discover that restoring the estate takes long enough to make the backup strategy inadequate for the outcome it was purchased to prevent.

The takeaway

Ransomware early-warning detection means catching the precursors — shadow-copy deletion first, then mass file change — instead of the encryption, backed by isolation response and recoverable offline backups. Detect the credential theft and lateral movement earlier for even more time. Continue with lateral movement detection and BYOVD detection, or browse the full Detection Engineering pillar.