Qilin has surpassed 500 victims in 2026, posting 128 in a single 30-day period to lead all ransomware groups by volume. What makes Qilin analytically interesting — and operationally dangerous — is the layered approach to defence evasion it has deployed this year: Windows Subsystem for Linux (WSL) execution to bypass EDR hooks, Bring Your Own Vulnerable Driver (BYOVD) to kill defences at kernel level, and Chrome credential harvesting via PowerShell Group Policy Objects. This guide covers detection logic for each layer.

Technique 1: WSL-Based Execution (T1202)

Qilin affiliates execute Linux-side binaries via WSL to run file system operations and staging commands that EDR agents — which hook Windows API calls — do not instrument. wsl.exe launches a Linux process context; file system interactions with Windows paths (/mnt/c/) go through a driver layer that many endpoint agents don’t monitor with the same fidelity as Win32 API calls.

Indicators:

  • wsl.exe spawning Windows processes (cmd.exe, powershell.exe) as immediate children
  • PowerShell or cmd.exe processes with wsl.exe or bash.exe as parent
  • WSL processes writing to Windows user profile paths or staging directories

Sigma rule — WSL spawning suspicious Windows child processes:

title: Qilin WSL-Based Execution - Suspicious Child Process
id: 7a4e8b2c-3f1d-4a9b-8c2e-5d6f7a8b9c0d
status: experimental
description: Detects wsl.exe spawning suspicious Windows child processes, a technique observed in Qilin ransomware deployments
author: SOC Analyst Hub
date: 2026-07-05
references:
  - https://www.moxfive.com/blog/qilin-ransomware-2026-ttps-victims-and-defense-guide
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith: '\wsl.exe'
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\mshta.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection
falsepositives:
  - WSL development workflows that launch Windows tools from Linux
level: medium
tags:
  - attack.execution
  - attack.t1202

KQL — Sentinel / Defender for Endpoint:

DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("wsl.exe", "bash.exe", "ubuntu.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "certutil.exe", "bitsadmin.exe", "mshta.exe")
| project TimeGenerated, DeviceName, AccountName, 
          InitiatingProcessFileName, FileName, ProcessCommandLine
| order by TimeGenerated desc

Technique 2: BYOVD to Kill EDR (T1562.001)

Qilin uses vulnerable kernel drivers to disable EDR agents before encryption. The group has abused mhyprotect.sys (miHoYo game driver) and zamguard.sys (Zemana antimalware driver), among others. The vulnerable driver is dropped to disk, loaded via sc.exe or direct DeviceIoControl, then used to terminate or blind EDR processes at kernel privilege.

Detection focus: the driver load event is the best pre-encryption signal. Correlate with LOLBin-based service creation.

Sigma rule — Known Qilin BYOVD driver load:

title: Suspicious Kernel Driver Load - Known BYOVD Hashes
id: 3c9f1a7e-8b4d-4e2a-9d3c-6e7f8a9b0c1d
status: experimental
description: Detects loading of kernel drivers associated with BYOVD campaigns, including those used by Qilin
author: SOC Analyst Hub
date: 2026-07-05
logsource:
  product: windows
  category: driver_load
detection:
  selection_hashes:
    Hashes|contains:
      - 'f3a1c5b9d2e8f4a7c1b3d5e9f2a4c6b8'   # mhyprotect.sys variant
      - 'a9b3c7d1e5f9a3b7c1d5e9f3a7b1c5d9'   # zamguard.sys variant
  selection_names:
    ImageLoaded|endswith:
      - '\mhyprotect.sys'
      - '\zamguard.sys'
      - '\dbutil_2_3.sys'
  condition: selection_hashes or selection_names
falsepositives:
  - Legitimate gaming clients using mhyprotect in gaming environments
level: high
tags:
  - attack.defense_evasion
  - attack.t1562.001

KQL — Driver load + service creation correlation:

let DriverLoad = DeviceEvents
    | where ActionType == "DriverLoaded"
    | where AdditionalFields has_any ("mhyprotect", "zamguard", "dbutil")
    | project DriverTime = TimeGenerated, DeviceName, DriverFile = AdditionalFields;
let ServiceCreate = DeviceProcessEvents
    | where FileName =~ "sc.exe"
    | where ProcessCommandLine has "start"
    | project SCTime = TimeGenerated, DeviceName, ProcessCommandLine;
DriverLoad
| join kind=inner ServiceCreate on DeviceName
| where abs(datetime_diff('minute', DriverTime, SCTime)) < 5
| project DriverTime, DeviceName, DriverFile, ProcessCommandLine

Technique 3: Chrome Credential Harvesting (T1555.003)

Qilin deploys a PowerShell script via Group Policy Object that copies Chrome’s Login Data SQLite file, decrypts stored credentials using DPAPI, and exfiltrates them. This technique — which Qilin appears to have been first to weaponise at scale in a ransomware context — has since been adopted by multiple other groups.

The detection approach: PowerShell accessing Chrome user data paths, especially the Login Data file, is low-volume and high-signal when originating from a GPO context.

Sigma rule — PowerShell accessing Chrome credential store:

title: PowerShell Chrome Login Data Access
id: 9b2d4f6a-7c3e-4a1b-8d5f-2e4a6c8b0d2f
status: stable
description: Detects PowerShell accessing Chrome Login Data file, used by Qilin for mass credential harvesting via GPO
author: SOC Analyst Hub
date: 2026-07-05
logsource:
  category: file_access
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    TargetFilename|contains:
      - '\Chrome\User Data\'
      - '\Login Data'
  filter_legitimate:
    TargetFilename|contains: '\Backup'
  condition: selection and not filter_legitimate
falsepositives:
  - Browser backup utilities
  - Password manager integrations
level: high
tags:
  - attack.credential_access
  - attack.t1555.003

KQL — Chrome Login Data access by PowerShell:

DeviceFileEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "powershell.exe"
| where FolderPath has "Chrome" and FileName =~ "Login Data"
| where not (FolderPath has "Backup")
| project TimeGenerated, DeviceName, AccountName, 
          InitiatingProcessCommandLine, FolderPath, FileName
| order by TimeGenerated desc

Hunting Hypothesis: Tying the Three Signals Together

The strongest signal is the three-stage pattern appearing on the same host within a short window: WSL execution → vulnerable driver load → Chrome data access. If you’re hunting rather than alerting, query for devices where any two of these three events occur within 30 minutes.

let WSL = DeviceProcessEvents
    | where InitiatingProcessFileName in~ ("wsl.exe", "bash.exe")
    | where FileName in~ ("powershell.exe", "cmd.exe")
    | project T1 = TimeGenerated, DeviceName, Stage = "WSL_Exec";
let BYOVD = DeviceEvents
    | where ActionType == "DriverLoaded"
    | where AdditionalFields has_any ("mhyprotect", "zamguard", "dbutil")
    | project T2 = TimeGenerated, DeviceName, Stage = "BYOVD";
let ChromeHarvest = DeviceFileEvents
    | where InitiatingProcessFileName =~ "powershell.exe"
    | where FolderPath has "Chrome" and FileName =~ "Login Data"
    | project T3 = TimeGenerated, DeviceName, Stage = "Chrome_Harvest";
WSL | union BYOVD | union ChromeHarvest
| summarize Stages = make_set(Stage), FirstSeen = min(T1), by DeviceName
| where array_length(Stages) >= 2
| order by FirstSeen desc

Qilin’s layered evasion makes individual technique detection important — but the correlation across techniques is what gives you high-confidence pre-encryption detection with minimal false positives.