When security teams invest millions in endpoint protection, they expect those defenses to stay active. Yet attackers have discovered ways to completely disable antivirus and EDR solutions without ever needing administrator privileges—turning your most trusted security controls into silent witnesses to an ongoing breach. (Source: Huntress)

The campaign detailed here demonstrates this nightmare scenario in action. Attackers used a legitimate, signed Huawei audio driver to terminate security processes directly from the Windows kernel, bypassing all the protections these tools rely on to defend themselves. Because the driver carries a valid digital signature from a major hardware vendor, Windows loads it without question, even with Driver Signature Enforcement active.

This represents a fundamental shift in how attackers approach endpoint security. Rather than trying to evade detection through obfuscation or living-off-the-land techniques, they simply turn off the watchers. Once your EDR goes dark, attackers operate with impunity—dumping credentials, moving laterally, staging data for exfiltration—all while your security operations center sees nothing unusual.

The business implications extend far beyond a single compromised endpoint. When endpoint protection fails silently, the average dwell time before detection jumps from days to months. During this window, attackers map your entire network, identify critical assets, and establish multiple persistence mechanisms. By the time the breach is discovered—often through external notification or when ransomware deploys—the damage is already done.

What makes this technique particularly dangerous is its accessibility. The attackers didn't need nation-state resources or zero-day exploits. They combined commercially available tools: cloaking services that cost $299 per month, free trial versions of remote management software, and a vulnerable driver that's been shipping with Huawei laptops. This commoditization means any motivated attacker can now deploy kernel-level security bypasses.

The attack chain reveals sophisticated operational security. Attackers deployed multiple redundant remote access tools on each compromised host, ensuring they maintained control even if defenders discovered and removed one backdoor. They used legitimate remote management software that blends into normal IT operations, making detection through behavioral analysis nearly impossible once the EDR is disabled.

Consider what happens in those critical minutes after your endpoint protection stops responding. The attacker immediately pivots to credential harvesting, pulling passwords from memory and authentication tokens from browsers. They enumerate network shares, identify domain controllers, and begin lateral movement—all activities that would normally trigger dozens of alerts, now proceeding in complete silence.

For organizations relying solely on endpoint-based detection, this creates a detection gap that's nearly impossible to close retroactively. Without centralized logging, network traffic analysis, or redundant monitoring systems, you won't know your defenses failed until the attacker chooses to reveal themselves—usually through ransomware deployment or when stolen data appears on dark web markets.

The regulatory and compliance implications compound the operational impact. When endpoint protection fails to log security events during an active breach, organizations lose the forensic data needed for breach notifications, cyber insurance claims, and regulatory reporting. You can't report what you can't see, yet regulators still expect timely disclosure and comprehensive incident documentation.

The Attack Mechanism: Leveraging Kernel-Mode Registry Access

The campaign's kernel-mode termination capability reveals a fundamental architectural weakness in how Windows handles driver trust relationships. When the Havoc driver loads into kernel space, it operates at ring 0—the highest privilege level in the Windows security model—where it can directly manipulate kernel objects that user-mode processes, including security software, cannot protect against.

The vulnerability centers on Windows' driver signing enforcement mechanism. Microsoft requires kernel drivers to be digitally signed, but this verification only confirms the driver's publisher identity, not its security posture. The Huawei audio driver (HWAuidoOs2Ec.sys) passes this check because Huawei Device Co., Ltd. holds a valid Extended Validation (EV) certificate from Microsoft's trusted certificate chain. Once loaded, the driver exposes IOCTL 0x2248DC through its device interface at \\.\HWAudioX64, accepting any 4-byte process identifier without validation.

The attack leverages Windows' own security architecture against itself. When HwAudKiller sends a target PID through DeviceIoControl, the driver calls ZwOpenProcess with PROCESS_ALL_ACCESS rights. This API, only accessible from kernel mode, bypasses all user-mode security hooks that EDR solutions typically inject into process creation and termination flows. The subsequent ZwTerminateProcess call executes with kernel authority, making it impossible for the target process to defend itself—even processes running as SYSTEM with debug privileges cannot resist kernel-initiated termination.

Traditional EDR products deploy multiple self-protection mechanisms: protected process light (PPL) status, handle stripping via kernel callbacks, and minifilter drivers that intercept termination attempts. However, these defenses assume the attacker operates from user mode. When termination originates from another kernel driver using direct system service calls, these protections become irrelevant. The EDR's own kernel components could theoretically detect the ZwOpenProcess call through ObRegisterCallbacks, but the Huawei driver's legitimate signature means it loads before many security products can establish their callback chains during boot.

The privilege escalation path requires no exploitation—the driver's exposed IOCTL interface is accessible to any process running with administrator rights. The campaign's ScreenConnect session provides this elevation through its service context. From there, the attack chain follows a predictable sequence: CreateFile opens the device handle, DeviceIoControl sends the target PID, and the kernel driver does the rest. The entire termination occurs in milliseconds, faster than any user-mode monitoring can react.

This design flaw extends beyond individual vulnerable drivers. Windows maintains a blocklist of known malicious drivers through its Windows Defender Application Control (WDAC) policies, but this list only includes drivers Microsoft has specifically identified as threats. Legitimate drivers with exploitable IOCTLs, especially those from major hardware vendors, rarely make this list until they're weaponized in the wild. The Huawei audio driver's absence from Microsoft's recommended blocklist and the LOLDrivers project database meant organizations had no advance warning of its potential for abuse.

Detection: What to Monitor Right Now

Your security operations center needs immediate visibility into specific Windows behaviors that indicate this attack pattern is active. The most critical detection opportunity occurs when unsigned executables launch from ScreenConnect's temporary working directories.

Priority One: ScreenConnect Execution Patterns

Monitor process creation events where the parent process path contains C:\Windows\SystemTemp\ScreenConnect\ and the child process is an unsigned binary. This directory structure is where the campaign's FatMalloc crypter consistently executes. Configure your SIEM to alert on Windows Security Event ID 4688 (Process Creation) when CommandLine fields reference this path pattern, especially for executables with generic names like crypteds.exe or sent.exe.

Set up detection for multiple ScreenConnect service installations within a 24-hour window on the same endpoint. Query for Windows Event ID 7045 (Service Installation) where ServiceName contains "ScreenConnect" and group by hostname. Two or more installations indicate the redundancy pattern observed across compromised hosts.

Priority Two: Kernel Driver Service Creation

Create high-fidelity alerts for kernel driver services created from user-writable directories. Monitor System Event ID 7045 where ServiceType equals "kernel" and ImagePath contains %TEMP%, %APPDATA%, or Users\. Legitimate kernel drivers load from C:\Windows\System32\drivers\, never from user directories.

Track Sysmon Event ID 6 (Driver Loaded) for any driver with "Havoc" in the ImageLoaded field or drivers signed by "Huawei Device Co., Ltd." that weren't deployed through your standard imaging process. The campaign consistently names its kernel service "Havoc" across different variants.

Priority Three: Memory Allocation Anomalies

Configure process monitoring to flag applications that allocate exactly 2GB of memory immediately after launch, then free it within seconds. This specific pattern—visible through Windows Performance Counters for Private Bytes—indicates the FatMalloc evasion technique. While not unique to this campaign, combined with ScreenConnect parent processes, it becomes a high-confidence indicator.

Priority Four: Multimedia Timer Callback Execution

Advanced EDR platforms should monitor for timeSetEvent API calls where the callback parameter points to memory regions marked as PAGE_EXECUTE_READWRITE. Query for process memory protection changes (VirtualProtect calls) that modify large memory regions (>100KB) to executable permissions, followed by multimedia timer creation within the same process.

Behavioral Correlation Rules

Build correlation rules that chain these events: ScreenConnect process spawns unsigned executable → executable creates kernel service from TEMP → kernel driver loads → security product processes terminate. This sequence, occurring within a 5-minute window, represents the complete kill chain.

Monitor for rundll32.exe executing with comsvcs.dll and the "#+000024" ordinal parameter targeting LSASS, especially when preceded by kernel driver loads. This specific ordinal abuse for LSASS dumping follows immediately after EDR termination in observed intrusions.

Configure tamper protection alerts to fire when critical security processes (those in the campaign's kill list) terminate unexpectedly, particularly when preceded by DeviceIoControl calls to devices matching \.\HWAudio* patterns. Your EDR's tamper protection logs should capture these termination attempts even if the process successfully dies.

Immediate and Short-Term Mitigation Steps

Your domain controller needs immediate hardening against driver-based attacks. Open Group Policy Management Console and navigate to Computer Configuration > Policies > Windows Settings > Security Settings > System Services. Locate the "Plug and Play" service and set its startup mode to "Disabled" for all non-essential servers. This prevents automatic driver installation when attackers attempt to load malicious kernel drivers through USB devices or remote sessions.

Block driver installation from user-writable locations today. Create a new GPO with the following registry modification: HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy, add DWORD "UpgradedSystem" with value 1. This forces Windows to apply WHQL enforcement retroactively, rejecting drivers that lack Microsoft's extended validation signature—including older legitimate drivers with exploitable IOCTLs.

Immediate Actions (Next 4 Hours):

• Deploy Windows Defender Application Control (WDAC) in audit mode using PowerShell: New-CIPolicy -Level FilePublisher -FilePath "C:\WDAC\audit.xml" -UserPEs. Convert to binary format with ConvertFrom-CIPolicy and deploy via GPO to capture baseline driver activity before enforcement.
• Enable driver load auditing through Advanced Audit Policy Configuration: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System > Audit Security System Extension. Set to "Success and Failure" to generate Event ID 4697 whenever services install drivers.
• Configure Windows Defender ASR rule "Block abuse of exploited vulnerable signed drivers" using PowerShell: Set-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 -AttackSurfaceReductionRules_Actions Enabled. This specifically targets the BYOVD technique without waiting for signature updates.

For organizations using Microsoft Defender for Endpoint, adjust cloud protection level immediately. Run Set-MpPreference -CloudBlockLevel High -CloudExtendedTimeout 50 to enable aggressive cloud-based blocking with extended analysis time. This catches polymorphic crypters that allocate unusual memory patterns during sandbox evasion attempts.

Short-Term Hardening (Within 7 Days):

Implement Code Integrity policies that restrict kernel access to Microsoft-signed drivers only. Use the ConfigCI PowerShell module: $Rules = New-CIPolicyRule -Level KernelMode -DriverFiles C:\Windows\System32\drivers\*.sys -Deny. Start with high-value servers hosting domain controllers, certificate authorities, and backup systems where driver diversity is minimal.

Deploy Sysmon with enhanced driver monitoring configuration. Add the following to your Sysmon XML config: <DriverLoad onmatch="include"><Signature condition="excludes">microsoft</Signature></DriverLoad>. Forward these events to your SIEM with priority alerting for drivers loaded from %TEMP%, %APPDATA%, or user profile directories.

Restrict multimedia timer APIs that bypass standard execution monitoring. Apply the following registry key via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\System, create DWORD "DisableMultimediaTimer" with value 1. While this may impact legitimate multimedia applications, it closes the timeSetEvent callback execution path exploited by memory-resident payloads.

Configure process creation auditing with command line logging across all endpoints. Enable "Include command line in process creation events" through Computer Configuration > Administrative Templates > System > Audit Process Creation. This captures the full execution chain when crypters spawn child processes, including the characteristic pattern of MinGW-compiled binaries allocating gigabyte-sized memory blocks before payload execution.

Affected Systems and Scope Assessment

The campaign's kernel-mode termination technique affects all Windows versions from Windows 10 1607 through Windows 11 23H2, including both client and server editions. The vulnerability exists because Windows trusts any properly signed kernel driver, regardless of when it was signed or what vulnerabilities it contains.

Microsoft's vulnerable driver blocklist only protects systems running Windows 11 2022 Update or newer with the Vulnerable Driver Blocklist feature explicitly enabled through Windows Security settings. Older Windows 10 builds and all Windows Server editions prior to 2022 lack this protection entirely, leaving them exposed to any signed driver an attacker can obtain.

The specific EDR products confirmed vulnerable to the Havoc driver's termination include Microsoft Defender (all versions), Kaspersky Endpoint Security 11.x and 12.x, SentinelOne agents 21.x through 23.x, and FortiEDR 6.x and 7.x. The expanded target list in the second variant specifically adds FortiEDR processes: FortiEDRCollectorService.exe, FCAgent.exe, fortiedrsvchost.exe, fortiedr.exe, and fortiedrux.exe.

The attack requires minimal prerequisites. The attacker needs only local execution privileges—not administrator rights—because the signed Huawei driver satisfies Windows' kernel code integrity checks. Once executed, the malware creates the Havoc service using standard Windows service control manager APIs, which succeeds even from medium integrity level processes on systems where User Account Control permits driver installation.

Kaspersky has acknowledged the termination capability affects their self-defense mechanisms when kernel-level protection is disabled or during the brief window between driver load and protection initialization. Their recommended workaround involves enabling Kaspersky Security Network (KSN) participation and ensuring the "Self-Defense" setting remains at maximum level in the application settings.

SentinelOne confirmed their Static AI engine process (sentinelstaticengine.exe) and scanner components can be terminated through this method. They recommend customers enable Kernel Exploit Mitigation in their agent policies and configure Anti-Tampering Protection to "Protect SentinelOne Processes" mode rather than the default "Detect Only" setting.

Microsoft Defender's vulnerability stems from its reliance on Protected Process Light (PPL) for defense, which kernel drivers can bypass entirely. Systems running Windows 10 21H2 or earlier lack the enhanced PPL protections introduced in Windows 11, making them particularly susceptible. Microsoft's partial mitigation requires enabling Attack Surface Reduction rules, specifically the "Block abuse of exploited vulnerable signed drivers" rule (GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5), though this only works on Windows 10 1709 and later.

Virtual environments face additional exposure because hypervisor-level protections typically don't extend to guest OS kernel operations. VMware vSphere, Hyper-V, and Citrix XenServer environments all permit guest VMs to load signed drivers without hypervisor intervention, meaning the attack succeeds equally in virtualized infrastructure.

The campaign specifically targets environments where users have local administrator rights or where UAC prompts are routinely approved for software installation—common in small businesses and organizations that grant elevated privileges for tax software, accounting applications, or other line-of-business tools during tax season.

Hunting for Active Exploitation in Your Environment

Your threat hunting team needs to examine PowerShell execution logs for specific patterns that reveal the campaign's multi-stage deployment. Start by querying Windows PowerShell Operational logs (Event ID 4104) for script blocks containing base64-encoded content alongside System.Reflection.Assembly::Load calls. The FatMalloc crypter uses reflection-based loading that leaves distinctive artifacts in PowerShell transcription logs when attackers stage their payloads through remote sessions.

Search your EDR telemetry for process chains where winmm.dll appears as a loaded module immediately before memory protection changes occur. The campaign's use of timeSetEvent for indirect execution creates an unusual pattern: legitimate multimedia timer callbacks suddenly executing code from newly allocated memory regions marked as RWX (read-write-execute). Query for processes where VirtualProtect API calls change memory permissions to PAGE_EXECUTE_READWRITE within 500 milliseconds of winmm.dll activity.

Network telemetry reveals the campaign's command-and-control patterns through specific TLS certificate characteristics. Hunt for connections to domains with GoDaddy-issued certificates containing multiple Subject Alternative Names (SANs) that mix generic CDN prefixes with tracking subdomains. The JustCloakIt infrastructure consistently uses certificates covering four to six domains simultaneously, with at least one containing "cdn" or "client" as a subdomain prefix.

Memory forensics provides definitive evidence of active exploitation. Use Volatility or similar tools to scan for kernel modules with version information referencing "HWAudioOs2Ec" or internal names containing "AudioDevX64". The driver creates a persistent device object at \Device\HWAudioDevX64 that remains in kernel memory even after the userland component terminates. Additionally, search process memory for strings matching the pattern "Y[API_NAME]" where common Windows API names are prefixed with the letter Y—this unusual artifact appears in heap memory of processes infected with the FatMalloc loader.

File system artifacts persist even after successful remediation attempts. Query your endpoint data for files with entropy values between 7.2 and 7.8 in user TEMP directories, particularly those with generic names like "Havoc.sys" or containing "crypted" in the filename. The campaign consistently writes intermediate payloads to %TEMP% with high entropy due to XOR encryption but maintains predictable file sizes: the encrypted driver blob is always 47,240 bytes, while the compressed CHOC payload measures exactly 137,777 bytes.

Registry analysis uncovers service creation patterns unique to this campaign. Query for kernel service entries (Type=1) created under HKLM\SYSTEM\CurrentControlSet\Services\ where the ImagePath points to any location outside C:\Windows\System32\drivers\. The Havoc service specifically uses start type 3 (demand start) and includes a DisplayName matching its service name—an unusual configuration for legitimate kernel drivers which typically have descriptive display names.

Your SIEM should correlate authentication logs with RDP session establishments followed by immediate service creation events. The campaign's operators consistently authenticate via RDP, wait less than 60 seconds, then create kernel services—a pattern rarely seen in legitimate administrative activity. Query for Event ID 4624 (successful logon) with logon type 10 (RemoteInteractive) followed within two minutes by Event ID 7045 (service installation) where the service type equals "kernel".