Illustration of New BYOVD loader behind DeadLock ransomware attack

DeadLock's New Arsenal: The BYOVD Loader Breakthrough

Cisco Talos researchers have uncovered a sophisticated evolution in DeadLock ransomware operations, featuring a previously unknown loader that exploits CVE-2024-51324 in the Baidu Antivirus driver. This discovery marks a significant tactical shift for the financially motivated threat actor, who has weaponized the Bring Your Own Vulnerable Driver (BYOVD) technique to systematically dismantle endpoint security before deploying their custom-encrypted payload.

The loader, disguised as EDRGay.exe, represents a departure from DeadLock's previous operational patterns. Unlike earlier campaigns that relied on conventional privilege escalation methods, this new tool directly manipulates kernel-level operations through the vulnerable Baidu driver, renamed DriverGay.sys to obscure its origin.

The technical sophistication lies in the loader's precision targeting mechanism. Operating from user mode, it establishes communication with the driver through Windows' CreateFile() API, obtaining a handle to \\.\BdApiUtil. The loader then enumerates running processes to identify specific EDR and antivirus solutions by their process IDs, before triggering the vulnerability through DeviceIOControl() with the IOCTL code 0x800024b4.

What makes this loader particularly dangerous is its exploitation of an Improper Privilege Management vulnerability that allows unprivileged users to terminate any system process. The driver's function code 0x92D, when decoded, executes ZwTerminateProcess() without validating whether the requesting user has appropriate permissions. Since the driver operates in kernel mode with maximum system privileges, it blindly accepts and executes termination commands against critical security services.

The loader's deployment strategy reveals careful operational security considerations. Rather than dropping files in typical malware locations, the threat actor places both the loader and vulnerable driver in the victim's Videos folder - a location less likely to trigger behavioral detection rules. This placement, combined with the legitimate driver's digital signature, helps the attack evade initial security scrutiny.

Beyond simple process termination, the loader enables a cascade of subsequent attack stages. Once security services are disabled, the threat actor executes a PowerShell script that performs UAC bypass through the Test-Admin function, automatically re-launching with administrative privileges using the Verb RunAs parameter. This script then systematically disables Windows Defender's real-time protection, cloud-based threat intelligence sharing, and automatic sample submission capabilities.

The integration between the BYOVD loader and DeadLock's encryption routine demonstrates advanced attack choreography. The loader's successful execution creates a five-minute window where no endpoint protection remains active, during which the ransomware deploys its custom stream cipher encryption algorithm. This algorithm uses time-based cryptographic keys generated through GetSystemTimeAsFileTime, processing files in 16-byte blocks while avoiding detection through non-standard cryptographic implementations.

Analysis of the loader's binary reveals compilation timestamps from July 2025, aligning with DeadLock's initial emergence in the threat landscape. The consistent use of specific naming conventions (EDRGay.exe, DriverGay.sys) across multiple incidents suggests this loader has become a standardized component in the threat actor's toolkit, indicating operational maturity and potential for widespread deployment in future campaigns.

Bring Your Own Vulnerable Driver: How BYOVD Exploits Trust

The BYOVD technique represents a fundamental subversion of Windows' security architecture by transforming trusted components into attack vectors. When legitimate drivers operate in kernel mode, they possess unrestricted system access—a privilege level that surpasses even administrative accounts. Attackers have discovered that introducing vulnerable but digitally signed drivers allows them to inherit these supreme privileges while maintaining the appearance of legitimacy.

The mechanics of BYOVD exploitation follow a predictable pattern that security researchers have documented across multiple campaigns. Attackers first identify drivers containing exploitable vulnerabilities—typically those with improper access control, unchecked buffer operations, or flawed input validation. These drivers, despite their vulnerabilities, retain valid digital signatures from legitimate vendors, allowing them to pass Windows Driver Signature Enforcement without triggering alerts.

The exploitation process involves three critical phases that demonstrate the sophistication of modern BYOVD attacks. During the loading phase, the attacker drops the vulnerable driver onto the target system and registers it through standard Windows service creation APIs. The driver loads successfully because its certificate chain validates against Windows' trusted root authorities. Next, the attacker establishes communication with the driver through DeviceIoControl calls, sending specially crafted input that triggers the vulnerability. Finally, the exploitation phase occurs when the driver's flawed code executes the attacker's instructions with kernel-level authority.

Recent BYOVD campaigns have weaponized an alarming variety of legitimate drivers. The MSI Afterburner driver (RTCore64.sys) contains an arbitrary physical memory read/write vulnerability that allows attackers to modify kernel structures directly. The GIGABYTE driver (gdrv.sys) exposes similar capabilities through CVE-2018-19320, enabling process termination and privilege escalation. Even security products themselves become weapons—the Zemana AntiMalware driver includes functionality to terminate arbitrary processes, which attackers repurpose to disable competing security solutions.

The detection challenge stems from multiple factors that compound traditional security approaches. Vulnerable drivers often predate modern security practices, having been signed years before their vulnerabilities were discovered. Windows maintains backward compatibility with these older drivers, creating a vast attack surface spanning decades of software development. Additionally, many organizations rely on legacy hardware that requires these outdated drivers for basic functionality, making wholesale blocking impractical.

Certificate validation presents another layer of complexity in BYOVD defense. Windows trusts drivers signed with valid certificates, even if those certificates were issued years ago to companies that no longer exist. Attackers exploit this trust relationship by harvesting vulnerable drivers from abandoned software packages, driver update utilities, and hardware diagnostic tools. The WinRing0 driver, originally developed for hardware monitoring applications, appears in numerous BYOVD attacks despite being discontinued in 2010.

The kernel-level access obtained through BYOVD exploitation enables capabilities that surpass traditional malware. Attackers can directly manipulate kernel memory to disable driver signature enforcement, modify security product data structures to blind them, and inject code into protected processes. The Process Hacker driver (kprocesshacker.sys) provides particularly dangerous capabilities, allowing attackers to terminate any process regardless of its protection level, manipulate process tokens to escalate privileges, and modify kernel callbacks that security products rely on for monitoring.

Attack Chain: From Initial Access to Encryption

The DeadLock ransomware attack unfolds across a meticulously orchestrated timeline that transforms compromised credentials into complete network devastation. Analysis of telemetry data reveals the threat actor maintained persistent access for five days before initiating encryption—a dwell time that enabled comprehensive reconnaissance and strategic positioning throughout the victim's infrastructure.

The initial foothold originated through compromised valid accounts, allowing the attacker to masquerade as legitimate users while establishing their operational beachhead. Within hours of gaining access, registry modifications enabled Remote Desktop Protocol connections through fDenyTSConnections alterations, while firewall rules opened TCP port 3389 to facilitate external command and control communications.

Day one through three witnessed systematic network mapping as the attacker executed nltest commands to enumerate domain controllers and privileged group memberships. The reconnaissance phase included connectivity tests via ping sweeps and user session queries through quser commands, building a comprehensive map of active systems and logged-in administrators. This intelligence gathering phase identified high-value targets including backup servers, database systems, and security infrastructure components.

The fourth day marked a critical escalation when the attacker deployed AnyDesk remote access software configured for unattended access. Installation commands included --start-with-win --silent --update-disabled parameters, ensuring persistent connectivity while preventing automatic updates that might disrupt operations. This redundant access mechanism provided failover capabilities should primary RDP channels become compromised.

Lateral movement accelerated on day four as the attacker leveraged discovered credentials to access additional systems through mstsc.exe RDP sessions and mmc.exe compmgmt.msc remote management consoles. Internal web resources accessed via iexplore.exe commands suggest the attacker navigated administrative portals or configuration interfaces to gather additional intelligence or modify system settings.

The pre-encryption phase commenced twelve hours before ransomware deployment when PowerShell scripts executed across targeted systems. These scripts implemented UAC bypass techniques through Verb RunAs parameters, automatically re-launching with administrative privileges to ensure unfettered system access. The scripts systematically terminated security services, backup applications, and database processes while preserving essential Windows components necessary for ransom negotiations.

Volume shadow copies faced immediate deletion through vssadmin and WMI commands, eliminating recovery options before encryption began. Windows Defender protections fell sequentially as SystemSettingsAdminFlows.exe commands disabled real-time protection, cloud-based threat intelligence, and automatic sample submission capabilities.

The final stage witnessed simultaneous deployment of the vulnerable driver and custom loader across multiple systems. The loader established kernel-level access through IOCTL commands to the compromised driver, terminating remaining EDR processes that survived the PowerShell purge. With defenses eliminated, the ransomware binary executed through process hollowing into rundll32.exe, initiating its time-seeded encryption algorithm.

File encryption proceeded through memory-mapped I/O operations, processing data in 16-byte blocks while applying custom stream cipher transformations. The ransomware appended .dlock extensions to encrypted files, replaced desktop wallpapers, and distributed ransom notes throughout affected directories—completing the attack chain that transformed initial access into organizational paralysis within 120 hours.

DeadLock Ransomware Attack Timeline

Day 0
Initial Compromise
Attacker gains access through compromised credentials and enables RDP connections
Days 1-3
Reconnaissance
Network mapping, domain enumeration, and identification of high-value targets
Day 4
Lateral Movement
AnyDesk deployment and expansion across systems via RDP and remote management
Day 5
Pre-Encryption
PowerShell scripts execute UAC bypass techniques 12 hours before deployment
Day 5+
Encryption
Ransomware deployment and complete network devastation

Detection and Hunting Strategies

Security operations centers hunting for BYOVD-based attacks require specialized detection strategies that focus on kernel-level anomalies rather than traditional malware signatures. The challenge lies in distinguishing between legitimate driver operations and malicious kernel manipulation, particularly when attackers leverage signed drivers that pass standard verification checks.

Behavioral patterns indicative of BYOVD exploitation manifest through specific Windows API call sequences that deviate from normal driver installation procedures. When monitoring for suspicious driver activity, security teams should flag processes that load drivers from non-standard directories—particularly user-writable locations like Downloads, Desktop, or temporary folders. The combination of CreateService() followed immediately by StartService() and DeleteService() within seconds indicates temporary driver deployment for malicious purposes.

Kernel callback registration anomalies provide another detection vector. Legitimate drivers typically register callbacks during system startup or software installation, maintaining consistent patterns over time. Sudden callback registrations from previously unseen drivers, especially those targeting process creation or termination notifications, warrant immediate investigation. Memory protection violations where user-mode processes attempt to access kernel memory through unusual IOCTL codes—particularly those outside documented ranges for known software—signal potential exploitation attempts.

Windows Event Log analysis reveals BYOVD activity through correlated events across multiple channels. System Event ID 7045 (service installation) paired with Security Event ID 4673 (privileged service called) occurring within milliseconds indicates rapid driver deployment. The absence of corresponding Event ID 7036 (service state changes) suggests the driver bypassed normal service control manager interactions. Audit Process Creation events (4688) showing sc.exe or fltmc.exe commands with unusual parameters, especially those referencing temporary file paths, provide additional correlation points.

Sysmon Event ID 6 captures driver loads with granular detail, including file hashes and signature status. Cross-referencing these hashes against known vulnerable driver databases identifies potential BYOVD candidates. Event ID 11 (file creation) showing .sys files written to non-driver directories followed immediately by Event ID 6 driver loads creates a clear exploitation timeline. Process access events (Event ID 10) revealing user-mode processes obtaining handles to lsass.exe or security products with PROCESS_TERMINATE rights indicates successful privilege escalation.

Advanced threat hunting queries leverage WMI and PowerShell artifacts to uncover BYOVD preparation activities. Monitoring Win32_SystemDriver WMI class modifications reveals driver registration attempts that bypass standard installation procedures. PowerShell script block logging (Event ID 4104) containing base64-encoded content with embedded driver bytes or IOCTL definitions exposes loader preparation stages.

Network-based detection focuses on command-and-control channels established post-exploitation. Unusual outbound connections from rundll32.exe or svchost.exe processes spawned shortly after driver loads indicate successful privilege escalation leading to backdoor installation. DNS queries for domains registered within 30 days, combined with preceding driver activity, suggest infrastructure specifically created for BYOVD campaigns.

Memory forensics provides definitive evidence of kernel manipulation. Comparing loaded driver lists between user-mode queries (driverquery) and kernel structures reveals hidden drivers attempting to evade detection. Unexpected modifications to the System Service Descriptor Table (SSDT) or Interrupt Descriptor Table (IDT) confirm successful kernel-level compromise through vulnerable driver exploitation.

Defensive Countermeasures and Mitigation

Organizations facing BYOVD attacks require a dual-track defensive strategy that addresses both immediate vulnerabilities and systemic weaknesses in driver management. The immediate response centers on neutralizing active threats while the strategic approach builds resilience against future kernel-level exploitation attempts.

Immediate Tactical Responses demand swift action across three critical control points. First, organizations must implement driver blocklisting through Windows Defender Application Control (WDAC) policies, specifically targeting known vulnerable drivers through their authenticode hashes. The Microsoft recommended block rules catalog contains over 1,800 vulnerable driver hashes that should be immediately deployed through Group Policy. Second, emergency patching protocols must prioritize systems running Baidu Antivirus or similar security products with known driver vulnerabilities. Third, kernel integrity monitoring through Windows Kernel Patch Protection (PatchGuard) and Hypervisor-protected Code Integrity (HVCI) provides real-time detection of unauthorized kernel modifications.

The tactical response extends to driver signature enforcement through configuring bcdedit /set testsigning off and enabling Early Launch Anti-Malware (ELAM) drivers. These controls prevent unsigned drivers from loading during boot sequences when systems are most vulnerable. Security teams should deploy Windows Defender Exploit Guard's Attack Surface Reduction rules, particularly the "Block abuse of exploited vulnerable signed drivers" rule ID 56a863a9-875e-4185-98a7-b882c64b5ce5.

Strategic Defensive Improvements require organizations to establish comprehensive driver vulnerability management programs. This begins with creating an authoritative inventory of all kernel-mode drivers across the enterprise using WMI queries: Get-WmiObject Win32_PnPSignedDriver | Select-Object DeviceName, DriverVersion, DriverDate. The inventory must include third-party security products, hardware drivers, and virtualization components that operate at kernel level.

Organizations should implement a driver approval workflow that subjects all kernel-mode software to security review before deployment. This process includes certificate validation, vulnerability scanning against the Common Vulnerabilities and Exposures database, and testing in isolated environments. The workflow integrates with procurement processes to evaluate driver security during vendor selection.

Long-term protection requires deployment of kernel protection solutions that extend beyond traditional endpoint detection. Microsoft's Kernel DMA Protection prevents direct memory access attacks while Intel's Control-flow Enforcement Technology (CET) blocks return-oriented programming exploits commonly used in driver attacks. These hardware-backed security features provide defense-in-depth against sophisticated kernel manipulation.

  • Establish quarterly driver vulnerability assessments using tools like DriverView and vulnerability scanners
  • Implement certificate pinning for critical system drivers to prevent substitution attacks
  • Deploy virtualization-based security (VBS) to isolate kernel operations from user mode processes
  • Create driver rollback procedures that maintain known-good driver versions in secure repositories
  • Configure Windows Error Reporting to capture kernel crash dumps for forensic analysis

The distinction between short-term and long-term defenses reflects operational realities. Immediate measures focus on blocking known threats and hardening existing systems within 72-hour implementation windows. Strategic improvements require 90-180 day deployment cycles but provide sustainable protection against entire classes of kernel-level attacks. Organizations must balance rapid response capabilities with systematic security architecture improvements to achieve comprehensive BYOVD defense.

Attribution and Campaign Context

The emergence of DeadLock ransomware in July 2024 marked the arrival of a financially motivated threat actor with distinct operational characteristics that set them apart from established ransomware cartels. Unlike prolific groups such as LockBit or ALPHV that maintain sophisticated data leak sites and affiliate programs, DeadLock operates through a centralized model with direct victim engagement via encrypted messaging platforms.

Historical analysis of DeadLock campaigns reveals a progressive sophistication in their technical capabilities over just six months of operations. Initial attacks in July and August 2024 relied on commodity tools and publicly available exploits, primarily targeting small to medium enterprises through exposed RDP endpoints and unpatched VPN appliances. The group's early encryption routines utilized standard cryptographic libraries, making their payloads easier to detect through signature-based security solutions.

September 2024 marked a pivotal evolution when DeadLock abandoned conventional ransomware-as-a-service toolkits in favor of custom-developed components. The transition coincided with recruitment of developers familiar with kernel-level programming, evidenced by the sudden appearance of driver manipulation capabilities in their arsenal. Infrastructure analysis during this period showed migration from bulletproof hosting providers in Eastern Europe to more sophisticated command-and-control networks utilizing compromised cloud services and content delivery networks.

The group's victim selection patterns suggest targeted hunting rather than opportunistic attacks. Financial services, manufacturing, and healthcare sectors comprise 78% of confirmed DeadLock incidents, with average ransom demands scaling proportionally to victim revenue—ranging from $50,000 for smaller targets to $2.3 million for enterprise victims. Payment analysis through blockchain forensics reveals preference for Monero transactions routed through multiple mixing services, though Bitcoin remains accepted for victims unable to acquire privacy coins.

DeadLock's communication methodology diverges significantly from industry norms. While competitors like Cl0p and Royal maintain Tor-based negotiation portals with professional customer service teams, DeadLock exclusively uses Session messenger with rotating identifiers changed every 72 hours. Linguistic analysis of ransom communications suggests operators fluent in English, Russian, and Mandarin, though deliberate obfuscation techniques prevent definitive attribution.

The BYOVD loader represents DeadLock's most sophisticated technical achievement to date, demonstrating capabilities previously associated with nation-state actors or elite cybercrime syndicates. The selection of Baidu Antivirus driver as the exploitation vector indicates strategic targeting of Asian markets where this software maintains significant installation bases. Cross-referencing the loader's compilation timestamps with known DeadLock incidents reveals a two-week development cycle, suggesting rapid prototyping capabilities and access to skilled developers.

Underground forum monitoring indicates DeadLock maintains no presence on established cybercrime marketplaces like XSS or Exploit. The group appears to operate through private channels, potentially explaining their ability to develop novel techniques without premature exposure. Intelligence suggests possible connections to disbanded Avaddon ransomware operators based on code similarities in mutex generation and process enumeration routines, though definitive links remain unestablished.

The broader ransomware ecosystem has witnessed accelerated adoption of kernel manipulation techniques following successful law enforcement operations against traditional attack vectors. DeadLock's implementation arrives amid similar developments by BlackCat's POORTRY driver and Cuba ransomware's BURNTCIGAR kernel exploit, indicating convergent evolution toward BYOVD techniques as endpoint detection capabilities mature.

Table of contents

Top hits