Tax Season Malvertising: ScreenConnect + BYOVD via Huawei Drivers
Just caught the latest report on a massive malvertising campaign active since January. Threat actors are weaponizing Google Ads for tax-related searches to serve rogue ConnectWise ScreenConnect installers.
The kicker isn't just the initial access via the fake RMM installer; it's the persistence mechanism. The payload drops a tool called HwAudKiller, which employs a Bring Your Own Vulnerable Driver (BYOVD) attack. Specifically, it loads a vulnerable Huawei driver to kernel-level code execution to blind EDR solutions.
Since the driver is signed, it passes standard authenticity checks, making this a significant bypass. If you support RMM tools or have users searching for tax docs, you might want to hunt for this specific driver load.
Here is a KQL query for Defender/Sentinel to hunt for the suspicious driver activity often associated with HwAudKiller:
DeviceImageLoadEvents
| where Timestamp > ago(30d)
| where FileName has "hw_audio_sdi.sys" or InitiatingProcessFolderPath has "HwAudKiller"
| project DeviceName, FolderPath, SHA256, Signer, InitiatingProcessAccountName
Given the prevalence of BYOVD lately, are folks seeing success with Vulnerable Driver Blocklists (Microsoft's ASR rules), or are we still relying too heavily on HVCI/VBS?
We've been enforcing the Vulnerable Driver Blocklist (Driver Blocklist for Windows) via Group Policy for about six months now. It catches a lot of these older Huawei and ASUS drivers being repurposed for attacks like this. However, the cat-and-mouse game is exhausting—there's always a new driver discovered before it hits the blocklist.
As an MSP, this terrifies me. Tax season is already a nightmare for phishing support tickets. If users are seeing fake tax ads and downloading rogue ScreenConnect agents, it's game over if we don't have MFA on the RMM access itself. We're strictly blocking non-business browsing on admin workstations until April.
The BYOVD technique is effective because it exploits the trust model. The Huawei driver vulnerability is old, but still works because vendors can't force-revoke certificates easily enough. If you can't enable VBS/HVCI due to performance hits on legacy hardware, you should be aggressively auditing driver loads via Sysmon Event ID 6.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access