VEN0m Ransomware: the weak point of Windows Defender

Summary

VEN0m is an open-source ransomware strain written in Rust that bundles a known-vulnerable kernel driver (IMFForceDelete.sys) to bypass kernel-level safeguards. In testing, the malware encrypted files, established persistence, and displayed a ransom note on a fully patched Windows 11 host with Windows Defender enabled. The end-to-end chain spans nine stages and hinges on successfully loading the vulnerable driver. The key defensive takeaway is straightforward: stop the driver from loading, and the attack breaks. The report underscores a recurring endpoint blind spot where risky kernel drivers can still become an execution enabler even on hardened systems.

Investigation

Ransom-ISAC recreated the intrusion in a controlled lab on Windows 11 Pro 24H2 and documented all nine phases. The chain begins with a UAC bypass that leverages slui.exe via a DelegateExecute hijack, then transitions into driver-assisted tampering through IOCTL operations to weaken defenses and enable file encryption. The same core behavior was observed across other endpoint stacks, while the MagicSword platform interrupted the activity by blocking the vulnerable driver before it could be loaded. The DFIR report also includes source-level observations and forensic artifacts, and is dated 26 February 2026.

Mitigation

Mitigation centers on preventing driver load and enforcing application control. Recommended measures include enabling Windows Defender Application Control (WDAC) or using a trusted third-party vulnerable-driver blocklist (for example, MagicSword), enforcing ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5, and turning on Hypervisor-Protected Code Integrity (HVCI). Run application control in enforce mode to block VEN0m.exe, and ensure driver deny rules explicitly include IMFForceDelete.sys. Keep blocklists current and alert on suspicious driver-install and driver-load activity.

Response

If VEN0m is detected, immediately isolate the host, terminate VEN0m.exe, and remove IMFForceDelete.sys from disk. Recover encrypted data from verified backups, then validate the integrity and configuration of Windows Defender protections. Apply or tighten WDAC and the relevant ASR policy, and complete a full forensic sweep for persistence artifacts such as altered Winlogon\Userinit values and suspicious scheduled tasks.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.

• Attack Narrative & Commands:

  1. Discovery: The attacker enumerates the system to locate the Windows Defender installation directory (C:Program FilesWindows Defender).
  2. Disable Defenses (T1562.001): Using a privileged process, the attacker deletes MsMpEng.dll and related Defender binaries, causing Sysmon to emit a FileDelete event with a target filename that ends with the Defender path.
  3. Deploy Malicious Driver (T1211, T1548.002, T1569.002): A malicious driver file ven0m.sys is copied to %AppData%LocalTemp. The attacker registers the driver as a service via sc create (UAC bypass leveraged through a scheduled task). This generates a FileCreate event for a .sys file under a temporary folder.
  4. Persistence (T1053.005): A scheduled task is created that runs the driver loader at system startup, ensuring the driver is loaded even after reboot.

• Regression Test Script:

  # VEN0m AV/EDR Shredding & BYOVD Simulation
  # -------------------------------------------------
  # 1. Delete Windows Defender binaries (simulated with copies)
  $defenderPath = "C:Program FilesWindows Defender"
  $dummyDefender = "$defenderPathMsMpEng.dll"
  New-Item -Path $dummyDefender -ItemType File -Force | Out-Null
  Write-Output "Simulating Defender binary deletion..." 
  Remove-Item -Path $dummyDefender -Force
  
  # 2. Drop malicious driver into a writable location
  $driverSrc = "$env:USERPROFILEDownloadsven0m.sys"
  $driverDst = "$env:LOCALAPPDATATempven0m.sys"
  # Create a placeholder driver file (empty binary for demo)
  Set-Content -Path $driverSrc -Value "Fake driver content"
  Copy-Item -Path $driverSrc -Destination $driverDst -Force
  Write-Output "Driver dropped to $driverDst"
  
  # 3. Register driver as a service (requires admin)
  $svcName = "Ven0mDrv"
  $svcCmd = "sc create $svcName binPath= `"$driverDst`" type= kernel start= demand"
  Write-Output "Registering driver service..."
  Invoke-Expression $svcCmd
  
  # 4. Create a scheduled task for persistence
  $action = New-ScheduledTaskAction -Execute "sc.exe" -Argument "start $svcName"
  $trigger = New-ScheduledTaskTrigger -AtStartup
  $taskName = "Ven0mPersistence"
  Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $trigger -RunLevel Highest -Force
  Write-Output "Scheduled task $taskName created."
  # -------------------------------------------------

• Cleanup Commands:

  # Cleanup VEN0m simulation artifacts
  # Stop and delete the driver service
  sc stop Ven0mDrv
  sc delete Ven0mDrv
  
  # Remove the driver file
  Remove-Item -Path "$env:LOCALAPPDATATempven0m.sys" -Force
  
  # Delete the scheduled task
  Unregister-ScheduledTask -TaskName "Ven0mPersistence" -Confirm:$false
  
  # Remove dummy Defender file (if still present)
  $defenderDummy = "C:Program FilesWindows DefenderMsMpEng.dll"
  if (Test-Path $defenderDummy) { Remove-Item -Path $defenderDummy -Force }
  
  # Remove temporary driver source file
  Remove-Item -Path "$env:USERPROFILEDownloadsven0m.sys" -Force