VEN0m Ransomware: A Case Study in BYOVD Attacks and Disk-Based AV Evasion

Hook

Most ransomware tries to kill antivirus processes in memory. VEN0m takes a different approach: it deletes the AV software's files from disk using a vulnerability in legitimate security software, forcing products to corrupt themselves until they fail.

Context

The arms race between malware authors and security vendors has traditionally focused on in-memory evasion techniques—process injection, hook bypassing, direct syscalls, and memory manipulation to avoid behavioral detection. Defenders have responded by hardening their agents with protected processes, kernel-level hooks, and sophisticated behavioral analytics. This back-and-forth has created an ecosystem where both sides invest heavily in runtime detection and evasion.

But there's always been a simpler question lurking beneath the complexity: what if you just deleted the antivirus software before it could stop you? The BYOVD (Bring Your Own Vulnerable Driver) technique exploits a persistent weakness in Windows driver signing enforcement. Attackers bundle legitimate but vulnerable kernel drivers, load them with administrative privileges, then leverage their capabilities to perform actions that would normally be restricted—like force-deleting files protected by active security products. VEN0m represents a practical implementation of this concept, weaponizing CVE-2025-26125 in IObit Malware Fighter's driver to corrupt AV/EDR installations before encrypting the victim's files. It's a reminder that sophisticated evasion doesn't always require sophisticated techniques—sometimes the most effective approach is to eliminate the defender entirely.

Technical Insight

VEN0m's architecture follows a deliberate multi-stage progression that mirrors professional ransomware operations. Written in Rust, it benefits from the language's memory safety guarantees and cross-compilation capabilities while maintaining the low-level system access necessary for kernel driver manipulation. The attack chain begins with privilege escalation through UAC bypass, then establishes persistence, disables security products, and finally encrypts user files.

The UAC bypass leverages a classic technique targeting slui.exe, an auto-elevating Windows binary used for license activation. By hijacking its registry key, VEN0m executes arbitrary commands with elevated privileges without triggering a UAC prompt:

// Simplified representation of the UAC bypass mechanism
use winreg::enums::*;
use winreg::RegKey;

fn bypass_uac() -> Result<(), Box<dyn std::error::Error>> {
    let hkcu = RegKey::predef(HKEY_CURRENT_USER);
    let slui_key = hkcu.create_subkey(
        r"Software\Classes\exefile\shell\open\command"
    )?;
    
    // Hijack the command execution path
    slui_key.0.set_value("", &format!("{}", get_payload_path()))?;
    slui_key.0.set_value("DelegateExecute", &"")?;
    
    // Trigger auto-elevation through slui.exe
    std::process::Command::new("slui.exe").spawn()?;
    
    Ok(())
}

Once elevated, VEN0m's most interesting component activates: the BYOVD implementation. The malware embeds the vulnerable IMFForceDelete.sys driver within its binary as a byte array, drops it to disk, and registers it as a Windows service using Service Control Manager APIs. This driver, originally part of IObit Malware Fighter (a legitimate security product), contains CVE-2025-26125—a vulnerability allowing unprivileged deletion of arbitrary files through IOCTL commands. The irony is palpable: a security product's own driver becomes the weapon to disable other security products.

The driver loading process requires careful orchestration. VEN0m must handle driver signing enforcement (if enabled), service registration, and proper IOCTL communication:

// Conceptual driver loading and exploitation flow
fn disable_security_products() -> Result<(), Box<dyn std::error::Error>> {
    // Drop embedded driver to disk
    let driver_path = r"C:\Windows\System32\drivers\imffd.sys";
    std::fs::write(driver_path, EMBEDDED_DRIVER_BYTES)?;
    
    // Register as kernel service
    create_kernel_service("imffd", driver_path)?;
    
    // Target critical AV/EDR files
    let targets = vec![
        r"C:\Program Files\BitDefender\Antivirus Free\bdagent.exe",
        r"C:\Program Files\Kaspersky Lab\Kaspersky Security Cloud\avp.exe",
        r"C:\Program Files\Microsoft Defender\MpEngine.dll",
    ];
    
    // Send IOCTL commands through vulnerable driver
    let device_handle = open_device_handle(r"\\.\imffd")?;
    for target in targets {
        send_force_delete_ioctl(device_handle, target)?;
    }
    
    Ok(())
}

After security products are compromised, VEN0m establishes persistence through the Winlogon\Userinit registry key—a classic technique that executes malware at every user login. This ensures the ransomware can re-encrypt files or maintain control even after partial system recovery.

The encryption mechanism itself is straightforward AES with a hardcoded 32-byte key. VEN0m walks the filesystem, identifies target extensions (documents, images, databases), and encrypts them in-place. The use of a hardcoded key is VEN0m's critical weakness—any captured sample can be reverse-engineered to extract the key and build a decryptor. The repository includes this decryptor utility, which essentially proves the point: this is educational malware, not a production threat.

The ransom note delivery demonstrates attention to user experience (from an attacker's perspective). Rather than dropping simple text files, VEN0m deploys a GUI application via Windows Task Scheduler, ensuring the victim sees the ransom demand prominently after reboot. This scheduled task survives basic cleanup attempts and guarantees message visibility.

From an engineering perspective, the Rust implementation is clean and modular. Each attack stage is compartmentalized into separate functions with clear error handling. The embedded driver is managed as a compile-time byte array, and the configuration (target extensions, encryption key, persistence locations) can be modified by editing constants. This modularity makes VEN0m an effective teaching tool—security researchers can study individual components without wading through spaghetti code.

Gotcha

VEN0m's most glaring limitation is the hardcoded encryption key embedded directly in the binary. This isn't just poor OpSec—it fundamentally undermines the ransomware's threat potential. Any security researcher who captures a sample can extract the key within minutes using static analysis tools like Ghidra or IDA Pro, then build a universal decryptor. Real-world ransomware uses asymmetric cryptography: a unique key pair per victim with the private decryption key held only by the attacker. VEN0m's approach makes it clear this is a proof-of-concept rather than a genuine threat, but it also means anyone testing this in a lab environment should keep the decryptor handy.

The BYOVD technique has an expiration date. Microsoft maintains a driver blocklist that prevents known-vulnerable drivers from loading, even with valid signatures. Once IMFForceDelete.sys is added to this blocklist, VEN0m's core evasion mechanism breaks completely. The author's detection date claim of '02-23-2026' appears to be a typo (likely meant to be 2025), which raises questions about testing rigor and whether the repository is actively maintained. Even if functional today, this approach has a short shelf life as security vendors coordinate blocklist updates. The UAC bypass also shows inconsistent results—it reportedly fails against Microsoft Defender while succeeding against BitDefender and Kaspersky, suggesting environment-specific dependencies that aren't well-documented. Finally, the legal and ethical implications cannot be overstated: possessing, distributing, or executing this tool outside of authorized security research is illegal in most jurisdictions and can result in serious criminal charges.

Verdict

Use if: You're a security researcher studying BYOVD techniques and disk-based AV evasion in an isolated lab environment, you're building detection signatures for endpoint security products and need reference implementations of current attack patterns, or you're a red team operator analyzing ransomware TTPs to improve defensive capabilities (but never deploy it—study the code and build safer simulation tools). Skip if: You lack proper legal authorization and air-gapped infrastructure for malware analysis, you need production-ready penetration testing tools (use Metasploit, Cobalt Strike, or Atomic Red Team instead), you're looking for actual ransomware deployment capabilities (don't—it's illegal and the hardcoded keys make it pointless), or you want maintained, reliable tooling (the detection date error and lack of updates suggest abandonment). VEN0m's value is purely educational: understanding how attackers weaponize legitimate driver vulnerabilities and why disk-based attacks remain a blind spot for many security products. Treat it as a case study, not a tool.