Before Encryption: Where Ransomware Intrusions Are Decided — Part 1 of 2: The Three Hours Before Encryption

This is Part 1 of a two-part series on detecting ransomware before encryption begins. This article explains why the decisive window of a ransomware intrusion occurs before the encryptor runs. Part 2 (coming soon) focuses on the specific detections SOC teams can implement to make that window observable and actionable.

Spend an hour reading post-incident write-ups, and you will notice a pattern emerge that has very little to do with encryption. The encryptor itself is almost a footnote: a payload dropped, a service started, files renamed with some extension that will be referenced in news articles for the next six weeks. The work that mattered, the work that determined whether the organization would be writing a postmortem or wiring a ransom, happened in the hours before. Yet most SOC runbooks, board-level ransomware briefings, and vendor demonstrations still focus on the moment files begin changing on disk.

That is the wrong center of gravity.

The misallocation we keep making

Defender attention and tooling investment are heavily weighted toward two places: initial access (phishing, exposed RDP, edge device CVEs) and the encryption event itself (canary files, file extension changes, immutable backups). Both matter. Neither is where the fight is won or lost on a ransomware intrusion.

The decisive window is what happens between “an operator has hands on the keyboard inside your environment with elevated privileges” and “the encryptor runs.” On well-tracked intrusions, this window has compressed considerably over the past several years. Mandiant’s M-Trends has reported global median dwell time in the single-digit-day to low-teens range, with ransomware-specific dwell typically shorter still. Separately, case-study reporting from The DFIR Report, Microsoft Incident Response, and Sophos X-Ops documents full intrusions progressing from initial access through encryption in under 24 hours, and in the most aggressive cases within a single workday. By the time the encryption stage runs, the adversary has already validated privileges, neutered recovery, blunted EDR, mapped the file estate, and staged or completed exfiltration. Each of those steps is noisy. Each is detectable. Most go uninvestigated until the morning the help desk lights up.

That is the misallocation. We are over-instrumented at the front door and at the burning building, and under-instrumented in the hallway in between.

What the pre-encryption phase actually looks like

A reasonable mental model: once the operator has a foothold and a credential, they have a checklist. The checklist is remarkably consistent across affiliates because the underlying constraints are the same: they need privilege, they need to remove your ability to recover and to detect them, they need to identify where the valuable data resides, and they need a copy of it.

Privilege validation and escalation. Operators frequently arrive with credentials harvested by an info-stealer or purchased from an initial access broker, and the first thing they do is confirm what those credentials are worth. Expect whoami /groups, net group "domain admins" /domain, nltest /dclist, and BloodHound-style collection (SharpHound) running against AD. MITRE maps this to T1087 (Account Discovery), T1069 (Permission Groups Discovery), and, for nltest /dclist and similar DC enumeration, T1018 (Remote System Discovery). The telemetry is unglamorous: process creation events (Windows Event ID 4688 with command-line logging, or Sysmon Event ID 1) showing LOLBins enumerating directory objects from a workstation that has no business doing so. Defenders miss this because the individual commands are benign in isolation; the signal is in the clustering and the source host.

Defense impairment (T1562). This is the technique family that should be lit up like a runway in the SOC, and frequently isn’t. Sub-techniques worth memorizing: T1562.001 (Disable or Modify Tools), T1562.004 (Disable or Modify System Firewall), T1562.002 (Disable Windows Event Logging). In practice this looks like sc stop, sc config ... start= disabled, Set-MpPreference -DisableRealtimeMonitoring $true, and BYOVD (bring-your-own-vulnerable-driver) tools dropping a signed but exploitable driver to kill EDR from kernel space: the AuKill, EDRKillShifter, Terminator (Spyboy), POORTRY/STONESTOP, and BurntCigar lineage. The telemetry: service start-type changes (Windows Event ID 7040), service state transitions (Event ID 7036), driver loads from non-standard paths (Sysmon Event ID 6), tamper-protection alerts from the EDR itself, and, critically, sudden silence from agents that should be heartbeating.

Inhibit System Recovery (T1490) and Data Destruction (T1485). This is where defenders most consistently leave money on the table. Before the encryptor runs, operators delete shadow copies (vssadmin delete shadows /all /quiet, wmic shadowcopy delete), disable Windows recovery (bcdedit /set {default} recoveryenabled No, bcdedit /set {default} bootstatuspolicy ignoreallfailures), wipe backup catalogs (wbadmin delete catalog -quiet), and target backup infrastructure directly: Veeam, Commvault, Rubrik consoles, often using credentials pulled from the same compromised admin workstation. Every one of these commands is high-fidelity. vssadmin delete shadows has essentially no legitimate use on an endpoint at 2 a.m. on a Tuesday. If your detection stack does not alert on this with a P1 severity, that is a gap you can close this week.

Discovery (T1083, T1135). File and directory discovery, network share discovery. Tools of choice include SoftPerfect Network Scanner, Advanced IP Scanner, and increasingly bespoke PowerShell that enumerates SMB shares and writes a target list to disk. The telemetry footprint is heavy SMB session establishment from a single source to dozens or hundreds of hosts in a short window. This is one of the cleanest behavioral signals in the entire kill chain and one of the easiest to baseline.

Lateral movement and staging. PsExec, WMI, and increasingly RMM tools that are already whitelisted in the environment: AnyDesk, ScreenConnect, Atera, Splashtop. Operators have learned that the fastest way past application control is to use the IT team’s own remote-administration tooling. T1021.002 (SMB/Windows Admin Shares), T1021.006 (WinRM), T1219 (Remote Access Software).

Exfiltration (T1567, T1048). On most modern intrusions this happens before encryption, not after. Rclone to a consumer cloud destination (MEGA, Dropbox, Backblaze) or a compromised cloud tenant; sometimes a custom uploader. The telemetry is large outbound transfers to consumer cloud destinations from server segments that should not be talking to those destinations at all.

The point of walking through the list is not novelty. None of this is new. It is density. Every one of these stages produces telemetry, and most produce telemetry that is difficult to generate benignly. The pre-encryption window is the loudest part of the intrusion.

If you take one thing from this article

• Encryption is the final step, not the decisive step.
• Attackers follow a repeatable checklist before it runs.
• Those steps generate unusually dense telemetry.
• Most environments already collect the signals needed to detect them.

Next in the series

Part 2 (coming soon) translates this model into practice, outlining the small set of high-fidelity detections that consistently surface attacker activity in the hours before encryption — and the operational changes that turn those detections into intervention rather than incident reports.