How to detect double extortion ransomware

Threat snapshot

Double extortion ransomware changed the calculus of ransomware defense. When encryption alone was the threat, organizations with reliable backups could restore without paying. When attackers began exfiltrating data before encrypting it, even a full restoration from backup left the victim exposed to a second threat: publication of the stolen data on a leak site. That exposure creates regulatory breach notification obligations, reputational damage with customers and partners, and in healthcare and financial services contexts, direct legal liability that exists regardless of whether the ransom is paid.

The defining characteristic of a double extortion attack is the sequence: data staging and exfiltration first, encryption second. This sequence is also the detection opportunity. Data staging, the compression of large file sets into archives before exfiltration, generates detectable signals. Exfiltration to external cloud storage, tunneling services, or custom infrastructure generates network-level signals. The combination of these signals with the encryption-phase signals from the Mass File Encryption use case gives a SOC team a much wider detection window than encryption alone would provide.

Log360 covers double extortion detection across T1567 (Exfiltration Over Web Service), T1486 (Data Encrypted for Impact), and T1048 (Exfiltration Over Alternative Protocol) with 37 detection rules spanning Windows process creation events, network connection monitoring, and cloud audit logs. This page focuses on the exfiltration phase, since the encryption phase is covered separately in the Mass File Encryption use case.

Double extortion detection, at a glance

How double extortion attacks work

Double extortion operations follow a consistent pattern that separates them from single-extortion ransomware. Understanding the specific sequence allows SOC teams to identify the attack during the exfiltration phase, before encryption begins.

Data discovery and targeting

Before staging data for exfiltration, attackers enumerate the environment to identify the highest-value data. They search for files matching patterns associated with sensitive content: spreadsheets, database backups, HR files, legal documents, customer data, and source code repositories. This enumeration generates process creation events for search utilities (Get-ChildItem, findstr, dir /s) running across network shares or specific directories with file extension filters.

Data compression and staging

Once target files are identified, they are compressed into archives for efficient exfiltration. WinRAR and 7-Zip are the most commonly used tools, often with password protection to prevent interception or inspection during transit. The compression of dump files (LSASS dumps, NTDS.dit, database exports) is a specific sub-pattern that Log360 tracks because it combines credential theft artifacts with exfiltration staging. Archive creation of large file sets outside of normal backup windows is the primary staging signal.

Exfiltration via tunneling services

A growing proportion of double extortion operators route their exfiltration through legitimate tunneling services: Ngrok, Cloudflared, and Microsoft DevTunnels are the most commonly observed. These services provide encrypted tunnels over HTTPS, making the traffic appear as standard web traffic to network monitoring tools that do not perform deep packet inspection or DNS-based blocking. The process creation events for these tools and their DNS resolution patterns are detectable even when the traffic itself is encrypted.

Exfiltration via cloud storage APIs

Ransomware operators also exfiltrate directly to cloud storage services using their native APIs or sync clients. Dropbox API calls, rclone configured for cloud targets, and direct HTTP PUT requests to attacker-controlled storage are the primary patterns. The volume of outbound data and the specific API endpoint domains are the detection signals at the network layer.

DNS-based exfiltration

Some operators use DNS tunneling to exfiltrate data through a channel that is rarely inspected by perimeter security tools. Data is encoded and transmitted as DNS query strings to an attacker-controlled resolver. This generates an anomalous volume of DNS queries with long or randomized subdomains that have no legitimate business purpose. DNS exfiltration tools run as processes with specific behavioral signatures.

Real-world campaigns

Cl0p: structured exfiltration before encryption

Cl0p operations follow a particularly well-documented double extortion pattern. After obtaining domain admin credentials, they use rclone configured for remote cloud storage to exfiltrate data, then deploy their encryptor. The rclone configuration file creation and the rclone.exe process creation with cloud storage target arguments are detectable process creation events. Cl0p also specifically targets file shares containing contract documents, financial records, and customer databases, which means file access events on those specific share paths in the context of an unusual account are a secondary signal.

BlackCat/ALPHV: exfiltration via custom infrastructure with Ngrok relay

BlackCat affiliates have been documented using Ngrok tunnels to relay exfiltrated data through Ngrok's infrastructure to their collection servers, obscuring the ultimate destination. The Ngrok client process creation and its connection to Ngrok relay domains is detectable. BlackCat also maintains a leak site and has threatened to notify victims' customers and regulators directly, increasing the pressure to pay regardless of backup availability.

LockBit: StealBit custom exfiltration tool

LockBit affiliates use StealBit, a custom-built exfiltration tool designed specifically for high-speed data theft before encryption. StealBit is not a repurposed legitimate tool, so process name and hash-based detection rules are more effective against it than against operators using legitimate tools like rclone or 7-Zip. StealBit creates archive files with specific naming patterns and transmits them to LockBit-controlled infrastructure.

Business impact

• Backup-based recovery does not address the extortion threat: An organization that restores fully from backup still faces the threat of data publication. The attacker retains a copy of the stolen data regardless of whether the victim pays the ransom or restores independently. This fundamentally changes the cost-benefit calculation for ransom payment.
• Regulatory breach notification obligations are triggered by the exfiltration, not the encryption: Under GDPR, HIPAA, and most state-level breach notification laws, the obligation to notify affected individuals and regulators is triggered when personal data is accessed or exfiltrated by an unauthorized party. The notification clock starts at exfiltration, not at encryption. Early detection of exfiltration is therefore directly relevant to notification deadline compliance.
• Large data volumes increase both the ransom demand and the regulatory exposure: Double extortion groups calibrate their ransom demand based in part on the sensitivity and volume of data they have exfiltrated. Detecting the exfiltration phase early limits the amount of data the attacker obtains, which directly reduces the leverage they have and the regulatory exposure the organization faces.
• Customers and partners may be notified by the attacker before the organization is ready: Several major ransomware groups have a documented practice of contacting victims' customers, regulators, or media outlets directly if the victim does not engage with their ransom demand. This removes the organization's control over the breach disclosure narrative.

Detecting double extortion with Log360

The detection rules below focus on the exfiltration phase. For network-layer detection to work, Log360 must be receiving firewall, proxy, and DNS logs. Process creation events require Event 4688 with command-line capture or Sysmon Event 1. Cloud storage connection detection relies on DNS resolution and proxy logs capturing the destination domains.

Attack chain visibility

Investigation playbook

Step 1: Establish the data staging scope

• Query Log360 for all 7-Zip and WinRAR process creation events in the alert window. Identify the specific files or directories being compressed, the output archive path, and whether password protection was used. The compression target tells you what category of data the attacker is staging.
• If dump files are being compressed (NTDS Exfiltration Filename Patterns or 7Zip Compressing Dump Files alerts fired), treat this as a confirmed credential exfiltration scenario. All credentials in the environment must be assumed compromised regardless of whether the archive was successfully exfiltrated.
• Identify the account running the compression commands. Query this account's recent activity across all hosts for the prior 48 hours to establish the full scope of the staging operation.

Step 2: Determine whether exfiltration has occurred

• Query firewall and proxy logs for outbound connections to tunneling service domains (ngrok.io, trycloudflare.com, devtunnels.ms, tunnel.btunnel.com) from the affected host in the alert window. High outbound data volume to these domains confirms data has been transferred.
• Query DNS logs for the affected host for anomalous query patterns: high volume of queries to a single domain, queries with long or randomized subdomains, or queries to domains that do not resolve to known legitimate services. These patterns indicate DNS tunneling or unusual cloud storage activity.
• Check for SMTP traffic on port 26 in firewall logs from the affected host. This non-standard port is specifically used to bypass perimeter SMTP controls and indicates email-based exfiltration.
• Estimate the volume of data transferred based on the size of the compressed archives created in step 1 and the outbound traffic volume in step 2. This estimate is required for breach notification scope assessment.

Step 3: Assess notification obligations

• If personal data, customer records, financial data, or health information was accessible in the directories staged for exfiltration, initiate the breach notification assessment process immediately. The notification obligation is triggered by confirmed or suspected exfiltration, not by encryption.
• Document the timeline of the exfiltration with specific timestamps from Log360 events. The exact time the exfiltration began and the latest confirmed exfiltration event are required for breach notification filings.
• Preserve all relevant Log360 events and alert records as evidence. These records are required for regulatory filings, insurance claims, and any subsequent legal proceedings.

Response and remediation

Immediate actions

• Block tunneling service domains at the firewall and DNS level immediately: Once a tunneling service connection is confirmed, block the relevant domains (ngrok.io, trycloudflare.com, devtunnels.ms) at both the DNS resolver and firewall layers. This stops in-progress exfiltration and prevents the attacker from re-establishing the tunnel after an interruption.
• Isolate the host performing the compression and exfiltration: Network isolation stops active exfiltration. Every additional minute of connectivity means additional data transferred. Isolation does not destroy the forensic evidence of what has already been exfiltrated.
• Do not delete the staging archives: The compressed archive files created during staging are forensic evidence of exactly what data the attacker intended to exfiltrate. Preserve them for forensic review and breach notification scope assessment before any cleanup.
• Initiate breach notification assessment in parallel with technical response: The breach notification process should begin as soon as exfiltration is confirmed, not after the technical response is complete. Notification deadlines under GDPR (72 hours from awareness of the breach) and similar regulations do not pause while the incident response is ongoing.

False positive tuning