Hunting Data Theft Before the Ransom Note: Detecting Pre-Ransomware Exfiltration

Your backups did their job. The encrypted servers are restored in 36 hours, the ransom never gets paid, and the incident report closes with a win. Then, three weeks later, your company's customer database shows up on a leak site, and legal starts the breach-notification clock you never planned for.

That sequence is now the normal outcome of a ransomware incident, not the exception. Zscaler's ThreatLabz 2026 Ransomware Report, published today, puts a hard number on it: ransomware data theft grew more than 275% year over year, reaching 896.2 terabytes of exfiltrated data. Blockchain-tracked payments hit $328 million, and the average payment rose 5.3% to $431,995. Their summary is worth quoting directly: "Successful ransomware extortion is shifting away from file encryption that often causes business disruptions to less visible, but more damaging data theft attacks."

The practical consequence for defenders is this: by the time your EDR fires on an encryptor, the attack has already succeeded. The theft — the stage that creates the breach notification, the regulatory exposure, the actual leverage — happened days earlier, quietly, with tools that look boring on a wire. This hunt is about catching that stage.

The problem: encryption is the distraction

Walk through the modern ransomware playbook and notice where the leverage actually sits:

Initial access. Compromised credentials, an exploited VPN or firewall (BlackFog's recent analysis of Gunra affiliates cites internet-facing VPN and firewall systems as the way in), or a phishing foothold.
Quiet hands-on-keyboard time. Operators work manually: Impacket, SMB, RDP, SSH tunneling for lateral movement, credential gathering, and data collection. Gunra crews, for example, spend significant time collecting data and targeting backups before encryption ever starts.
Staging and exfiltration. Files get collected, compressed (7-Zip is a fixture here), and moved with dual-use tools — Rclone, MEGA, FileZilla, OneDrive, SharePoint, WinSCP — into attacker-controlled storage. In the Osiris case, operators used Rclone to push staged data into Wasabi cloud buckets. All of this happens before the encryptor deploys.
Encryption. The noisy part. This is what pages you at 3 a.m.

Defenses are still optimized for stage 4 and almost blind to stage 3. And stage 3 is the one you cannot undo. Backups restore encrypted systems; nothing restores stolen data.

The second uncomfortable truth: the exfil channels are trusted infrastructure. Zscaler flags that actors increasingly abuse Microsoft Teams and Quick Assist for social engineering, lateral movement, and data theft. When the transfer rides a sanctioned collaboration platform to a "normal" cloud destination, your perimeter-oriented exfil monitoring never blinks.

The hypothesis

If a ransomware affiliate is preparing for double-extortion, then we will find data staging and exfiltration precursors — large archives appearing in staging directories, execution of dual-use transfer tools with cloud destinations, or unusual outbound volume to file-sharing services — before any encryption-stage indicators exist. Catching any of these early is worth more than any encryptor rule.

Mapped techniques: T1560 Archive Collected Data, T1048 Exfiltration Over Alternative Protocol, T1567 Exfiltration Over Web Service, T1020 Automated Exfiltration.

Data you'll need

Log source	Table / index	What it gives you
Microsoft Defender for Endpoint	DeviceProcessEvents	Execution of exfil tools + full command lines
Microsoft Defender for Endpoint	DeviceFileEvents	Archive creation in staging directories
Microsoft Defender for Endpoint	DeviceNetworkEvents	Outbound connections to file-sharing domains
Sysmon	EventCode 1 / 11 / 3 (or Splunk index)	Process, file-creation, and network events on non-Defender estates
Proxy / firewall logs	Web proxy or NGFW logs	Per-user upload volumes and destinations, including from trusted apps

Worked example 1: the exfil tool that shouldn't be running

Ransomware crews love Rclone because it's a legitimate, signed binary that speaks dozens of cloud protocols, and it does not look like malware. The tell is not the binary — it's the arguments and the context.

Sigma — Rclone execution with exfiltration indicators:

title: Rclone Execution With Cloud Exfiltration Indicators
id: 5f2c1a8b-4d3e-4f6a-9c1b-2e5f8a3d6b9c
status: experimental
description: Detects rclone (possibly renamed) executing with arguments consistent
  with pushing data to attacker-controlled cloud storage.
logsource:
  category: process_creation
  product: windows
detection:
  selection_binary:
    Image|endswith: '\rclone.exe'
  selection_renamed:
    CommandLine|contains:
      - 'rclone'
      - '--config'
      - ' copy '
      - ' sync '
      - 'mega:'
      - 's3:'
      - 'ftp:'
      - '--bwlimit'
  filter_legit:
    InitiatingProcessFileName:
      - 'sccm*'
      - 'intune*'
    ParentImage|contains: 'legit-backup-svc'
  condition: (selection_binary or selection_renamed) and not filter_legit
falsepositives:
  - IT administrators using rclone for sanctioned cloud sync; tune with allow-listed
    service accounts and destinations.
level: high
tags:
  - attack.exfiltration
  - attack.t1048

Notes on the logic: matching rclone.exe alone misses renamed copies, which is why the command-line arm catches copy, sync, mega:, s3:, ftp:, and --bwlimit — a flag that shows up in practice because attackers throttle uploads to stay under the radar. That last one is almost never in legitimate admin usage. The filter arm exists because the only honest response to this rule firing in most environments is "find out whether IT did this," and a one-line allow-list for your backup service accounts keeps the rule honest instead of noisy.

KQL — same hunt in Defender:

// Hunt: dual-use transfer tools with exfil indicators, ranked by risk
let ExfilTools = dynamic(["rclone.exe", "winscp.exe", "megasync.exe", "filezilla.exe", "azcopy.exe"]);
let ExfilArgs = dynamic(["mega:", "s3:", "ftp:", "--bwlimit", " copy ", " sync ", "wasabi"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FileName in~ (ExfilTools)
   or (ProcessCommandLine has_any (ExfilArgs) and FileName endswith ".exe")
| extend RanFromStaging = ProcessCommandLine has_any (@"\Temp\", @"\ProgramData\", @"C:\Windows\Temp"),
         HasExfilArgs = ProcessCommandLine has_any (ExfilArgs)
| extend SuspicionScore = (iff(FileName in~ (ExfilTools), 2, 0)
   + iff(HasExfilArgs, 2, 0) + iff(RanFromStaging, 1, 0))
| where SuspicionScore >= 2
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, SuspicionScore
| order by SuspicionScore desc, TimeGenerated desc

SPL — for Splunk shops running Sysmon:

index=wineventlog EventCode=1
| eval Tool=case(match(Image, "(?i)rclone\.exe$"), "rclone",
                 match(Image, "(?i)winscp\.exe$"), "winscp",
                 match(Image, "(?i)megasync\.exe$"), "mega")
| where isnotnull(Tool)
| stats count, values(CommandLine) as cmds, values(ParentImage) as parents
    by host, Tool, User
| where count > 0

Pair it with this: sysmon EventCode 3 (network connection) from the same process GUID within minutes, with a DestinationHostname in a file-sharing service, tells you the upload actually happened.

Worked example 2: the staging pile

Before data leaves, it gets collected — swept from file servers into one place, compressed, often password-protected. Attackers stage in predictable locations: C:\ProgramData\, C:\Windows\Temp\, user temp folders, world-writable shares. An archive that appears in one of these and then never moves is just a backup; an archive that appears and is followed by outbound transfer traffic is a case.

Sigma — large archive created in a staging directory:

title: Large Archive Created in Staging Directory
id: 8a7d2f1e-6b4c-4a9d-8e2f-1c5b7a9d3e6f
status: experimental
description: Detects creation of archive files in directories commonly used by
  ransomware operators to stage data before exfiltration.
logsource:
  category: file_create
  product: windows
detection:
  selection:
    TargetFilename|endswith:
      - '.7z'
      - '.zip'
      - '.rar'
      - '.tar.gz'
    TargetFilename|contains:
      - '\Temp\'
      - '\ProgramData\'
      - '\AppData\'
      - '\Windows\Temp\'
  condition: selection
falsepositives:
  - Legitimate backup and software-installation archives; correlate with process
    context (who created it) and subsequent network activity.
level: medium
tags:
  - attack.collection
  - attack.t1560.001

The real hunt chains these two together: archive created in staging directory → exfil tool executed within hours on the same host → outbound connection to a file-sharing domain. Each step is medium confidence alone; the chain is what makes an investigation.

Worked example 3: the trusted-app blind spot

Zscaler's report specifically calls out Microsoft Teams being abused for data theft. A KQL angle that works here: look for upload volume anomalies from Teams or other collaboration tools per user, rather than trying to detect "Teams doing Teams things":

// Hunt: unusual upload volume per user through collaboration tools
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("Teams.exe", "ms-teams.exe")
| where ActionType == "ConnectionSuccess"
| summarize TotalBytesSent = sum(BytesSent),
            DistinctDestinations = dcount(RemoteUrl)
    by DeviceName, InitiatingProcessAccountName, bin(TimeGenerated, 1d)
| where TotalBytesSent > 5000000000  // 5 GB: tune to your environment's baseline
| order by TotalBytesSent desc

Five gigabytes is a starting threshold, not a law — the point is to establish your own baseline first. A finance analyst pushing 2 GB a day through Teams is normal; the same analyst pushing 40 GB at 2 a.m. from a host they've never used is a phone call.

What a true positive looks like

Putting the chain together from a lab-style example:

Tue 02:14 — 7z.exe runs on WS-FIN-0233 under a service account that has never launched it before, creating C:\ProgramData\svc_backup\archive_01.7z (38 GB).
Tue 02:31 — a process named sysupdate.exe (hash doesn't match anything in your baseline, but the strings match Rclone) runs with --config pointing at a config file in the same directory and copy to a mega: remote.
Tue 02:33–03:10 — sustained TLS sessions from sysupdate.exe to MEGA infrastructure, ~38 GB egress.
Thu 09:02 — the encryptor deploys across the finance VLAN.

Everything before Thursday morning is your window. The shadow-copy deletion hunt I wrote about previously catches the pre-encryption moment; this chain catches the moment before that, when the data still exists only in your hands and theirs.

Defensive takeaways

Hunt the chain, not the step. An exfil tool execution alone is a triage ticket. Staging + exfil tool + outbound volume from the same host within hours is an incident. Write the correlation into your SIEM, not just the individual detections.
Baseline outbound volume per user and per app. You can't detect "unusual" uploads without knowing usual. Trusted-app exfil (Teams, OneDrive, SharePoint) is invisible to binary-blacklist thinking — volume baselines are the control that catches it.
Treat staging directories as tripwires. Large archives appearing in C:\ProgramData\, C:\Windows\Temp\, or world-writable shares are cheap to monitor and almost never belong to normal users.
Allow-list your exfil-class tools. Rclone, AzCopy, WinSCP, and the AWS CLI are legitimate admin tools and the ransomware exfil toolkit. Know which accounts are allowed to run them, from which hosts, to which destinations — then alert on everything else.
Backups are necessary and insufficient. They recover you from encryption. They do nothing about the leak site. Your IR runbook needs an exfiltration-assessment step (check for rclone/WinSCP/MEGA/cloud-storage activity on every ransomware call) before you declare victory, because the breach-notification clock starts when data leaves, not when you notice the leak.