← Back to Cybersecurity News Center
Severity
HIGH
CVSS
9.5
Priority
0.358
Executive Summary
An active malvertising campaign, running since January 2026, targets employees searching for tax-related software by serving fraudulent Google Ads that deliver trojanized ConnectWise ScreenConnect installers. Once installed, attackers disable endpoint security tools at the kernel level and establish persistent remote access, with post-compromise behavior consistent with ransomware staging or credential sale to access brokers. Organizations using ConnectWise ScreenConnect, particularly those downloading it via search ads, are at elevated risk of full environment compromise and potential ransomware deployment.
Technical Analysis
Campaign active since January 2026.
Delivery vector: Google Ads targeting tax-season search queries, using dual commercial cloaking services to bypass ad-platform policy enforcement (MITRE T1583.008 , T1036 ).
Lure: trojanized ConnectWise ScreenConnect installer (T1195 , T1036.005 ).
Post-installation, the threat actor loads HWAuidoOs2Ec.sys, a signed but vulnerable Huawei audio driver, via Bring Your Own Vulnerable Driver (BYOVD) technique (T1068 , T1562.001 , CWE-693, CWE-114, CWE-269). The driver achieves kernel-mode execution to terminate EDR processes including Microsoft Defender, Kaspersky, and SentinelOne. No CVE has been assigned to this driver vulnerability as of the report date (2026-03-04); the vulnerability appears to represent a previously unknown issue in the Huawei driver ecosystem, with CVE assignment pending if formally reported to MITRE. With EDR neutralized, actors perform LSASS credential dumping (T1003.001 ), may inject payloads into legitimate processes for evasion (T1055 ), perform lateral movement and network reconnaissance via NetExec (T1021 ), and deploy stacked RMM tools including FleetDeck Agent for persistent access (T1219 , T1543 ). Post-compromise behavior consistent with pre-ransomware staging or initial access brokering. At least 60 victim instances reported by initial sources; independent victim count verification pending. Attribution: Unknown; no confirmed threat group attribution at this time. Confidence: medium, primary source is The Hacker News (2026-03-04, T3); independent corroboration from CISA, NVD, or a second authoritative source has not been confirmed. MITRE techniques mapped: T1566 , T1219 , T1566.002 , T1036 , T1003.001 , T1055 , T1078 , T1195 , T1583.001 , T1021 , T1070.004 , T1068 , T1583.008 , T1543 , T1562.001 , T1036.005 .
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to senior leadership and external IR firm immediately if any host shows LSASS access attempts, EDR kill events, lateral movement to file servers, or disabled backup systems; otherwise escalate to CISO if more than 5 hosts affected or any trojanized ScreenConnect installer confirmed.
Step 1, Immediate: Verify any ConnectWise ScreenConnect installation sourced from search ads; compare installer hash against official ConnectWise release hashes available at https://docs.connectwise.com/ConnectWise_Control_Documentation/On-premises/Installation,_update,_and_licensing/Secure_installer_verification or from your ConnectWise account portal; isolate any host where the installer cannot be verified.
Preparation
NIST 800-61r3 §2.1 (preparation, malware prevention)
NIST IR-4(1) — Automated incident handling
CIS 2.4 — Software inventory
CIS 7.1 — Address unauthorized software
Compensating Control
Without EDR: (1) Export all installed ScreenConnect versions via PowerShell: Get-WmiObject Win32_Product | Where-Object {$_.Name -like '*ScreenConnect*'} | Select-Object Name, Version, InstallDate; (2) Download official ScreenConnect release hashes from ConnectWise release notes; (3) Compute SHA-256 of each installer in %ProgramFiles% using: certutil -hashfile '<path>' SHA256; (4) Compare against official list; (5) Isolate non-matching hosts to VLAN without internet access pending verification.
Preserve Evidence
Before isolation: capture (a) file system hash of ScreenConnect installation directory (%ProgramFiles%/ConnectWise/ScreenConnect/); (b) registry keys HKLM\Software\ConnectWise\ScreenConnect and HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\*ScreenConnect* (export via reg export); (c) Process execution history via Windows Event Log 4688 (filtered for ScreenConnect exe launch); (d) file metadata and timestamps via Get-ChildItem -Recurse | Select-Object FullName, CreationTime, LastWriteTime; (e) browser download history from %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\History (if Chrome present).
Step 2, Immediate: Block HWAuidoOs2Ec.sys from loading via Windows Defender Application Control (WDAC) or equivalent driver blocklist policy; verify whether the driver appears in your environment using EDR telemetry or 'sc query' and kernel driver enumeration.
Containment
NIST 800-61r3 §3.2 (containment, malware eradication)
NIST SI-7(15) — Information System Monitoring (driver integrity)
CIS 6.2 — Application and Kernel Driver Control
NIST IR-4(2) — Malware incident handling
Compensating Control
Without WDAC or enterprise driver blocklist: (1) Enumerate loaded drivers via: driverquery /v or Get-WindowsDriver -Online | Where-Object {$_.ProviderName -like '*Huawei*'} or $_.FileName -like '*HWAuid*'}; (2) Query Services Control Manager for Huawei-signed drivers: sc query | findstr /i 'hwaud'; (3) Check kernel memory via WinDbg or OSChaos.exe (free tool) for HWAuidoOs2Ec.sys in loaded module list; (4) Disable via: sc stop HWAudioDecode (where HWAudioDecode is the service name) and sc config HWAudioDecode start= disabled; (5) Rename driver file in %SystemRoot%\System32\drivers\ to .sys.blocked and reboot to prevent load on next startup.
Preserve Evidence
Before blocking: capture (a) full kernel module list via Get-Process | Select-Object -ExpandProperty Modules (memory snapshot); (b) driver signing information via sigcheck.exe <path to .sys file> (Sysinternals tool); (c) driver file properties: Get-ChildItem -Path 'C:\Windows\System32\drivers\HWAuid*' -Force | Select-Object FullName, CreationTime, LastWriteTime; (d) Service Control Manager configuration: reg export HKLM\System\CurrentControlSet\Services <filename>; (e) Windows Event Log 7045 (service installation events, 48-72 hours back) to identify when driver was installed.
Step 3, Detection: Hunt for FleetDeck Agent installations not authorized by IT; audit all active RMM tools on endpoints for unauthorized or stacked instances; review NetExec execution artifacts in process logs.
Detection & Analysis
NIST 800-61r3 §3.1 (detection and analysis, malware detection)
NIST SI-4(4) — System Monitoring (unauthorized software)
CIS 7.1 — Address unauthorized software
CIS 7.9 — Deny or restrict remote access
Compensating Control
Without EDR: (1) Query all installed software via: Get-WmiObject Win32_Product | Select-Object Name, InstallDate, Version and cross-reference against IT-approved RMM list (create baseline); (2) Hunt for FleetDeck: Get-ChildItem -Path 'C:\Program Files*' -Recurse -Filter '*FleetDeck*' -ErrorAction SilentlyContinue; (3) Check running processes: Get-Process | Where-Object {$_.ProcessName -like '*FleetDeck*' -or $_.ProcessName -like '*NetExec*'}; (4) Audit Scheduled Tasks for suspicious RMM startup: Get-ScheduledTask | Where-Object {$_.TaskName -like '*Fleet*' -or $_.TaskName -like '*remote*'} | Get-ScheduledTaskInfo; (5) Search for NetExec in running processes and command-line history via Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4688} | Where-Object {$_.Message -like '*NetExec*'}.
Preserve Evidence
Before remediation: capture (a) full Windows Event Log 4688 (process creation) for 7 days: wevtutil export-log Security <filename>.evtx; (b) registry hive for uninstall keys: reg export HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall <filename>; (c) list of running processes and their command lines: Get-CimInstance Win32_Process | Select-Object ProcessId, Name, CommandLine > processes.csv; (d) Scheduled Tasks: Get-ScheduledTask | Get-ScheduledTaskInfo | Export-Csv tasks.csv; (e) network connections from RMM processes: Get-NetTCPConnection -State Established | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess | ConvertTo-Csv > netconns.csv.
Step 4, Detection: Search LSASS access events in EDR and Windows Security Event Log (Event ID 10 in Sysmon, Event ID 4656/4663 for LSASS handle requests); treat any LSASS access from an unrecognized process as a confirmed indicator requiring immediate escalation.
Detection & Analysis
NIST 800-61r3 §3.1 (detection and analysis, indicator identification)
NIST AC-2(7) — Access Control (LSASS credential access prevention)
CIS 6.1 — Audit detailed process monitoring
CIS 5.3 — Configure logging for authentication
Compensating Control
Without EDR: (1) Enable Sysmon (free tool by Sysinternals) with focus on Event 10 (ProcessAccess) and deploy config file targeting LSASS (download SwiftOnSecurity Sysmon config); (2) Export Sysmon logs: wevtutil export-log 'Microsoft-Windows-Sysmon/Operational' sysmon.evtx and query: Get-WinEvent -FilterHashtable @{Path='sysmon.evtx'; ID=10} | Where-Object {$_.Message -like '*LSASS*'}; (3) Alternatively, enable Windows Security Event Log 4656/4663 via Group Policy: gpedit.msc > Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access > Audit File System; (4) Query: Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4656} | Where-Object {$_.Message -like '*lsass.exe*'} | Select-Object TimeCreated, Message; (5) Correlate source process (SubjectProcessId in event) with suspicious process list from Step 3.
Preserve Evidence
Before investigation: capture (a) Sysmon Event Log 10 (ProcessAccess) for 30 days minimum: wevtutil export-log 'Microsoft-Windows-Sysmon/Operational' <filename>.evtx; (b) Windows Security Event Logs 4656/4663 (file object access): wevtutil export-log Security <filename>.evtx; (c) LSASS memory dump (use volatility or local memory acquisition): rundll32 C:\Windows\System32\comsvcs.dll MiniDump <LSASS PID> <output>.dmp (note PID is 4 or query Get-Process lsass | Select-Object Id); (d) loaded DLLs in LSASS: Get-Process lsass | Select-Object -ExpandProperty Modules | Export-Csv lsass_modules.csv; (e) registry hives for credential storage artifacts: reg save HKLM\Security security.hive and reg save HKLM\SAM sam.hive.
Step 5, Assessment: Inventory all ConnectWise ScreenConnect deployments; confirm installation sources for all instances; cross-reference against official ConnectWise release hashes; identify any hosts where EDR was restarted unexpectedly or shows a gap in telemetry coverage.
Detection & Analysis
NIST 800-61r3 §3.1 (detection and analysis, scope identification)
NIST IR-4(6) — Incident handling (insider threat and supply chain)
CIS 2.4 — Address unauthorized software
CIS 13.5 — Maintain an up-to-date inventory of services
Compensating Control
Without EDR: (1) Query all endpoints via Active Directory or SCCM for installed ScreenConnect: Get-ADComputer -Filter * | ForEach-Object {Get-WmiObject -ComputerName $_.Name -Query "select * from Win32_Product where Name like '%ScreenConnect%'" -ErrorAction SilentlyContinue}; (2) Create deployment inventory with: hostname, install date, version, installation path, and installer source (from Control Panel uninstall metadata); (3) Check EDR/antivirus service restart logs: Get-WinEvent -FilterHashtable @{LogName='System'; ID=7040} (service state change) | Where-Object {$_.Message -like '*Defender*' -or $_.Message -like '*Kaspersky*' -or $_.Message -like '*SentinelOne*'}; (4) Identify telemetry gaps by checking EDR agent status and last report time; (5) Cross-reference hash inventory from Step 1 against official ConnectWise release notes via https://docs.connectwise.com/ConnectWise_Control_Documentation/On-Premise/Release_notes (verify against 3+ recent releases).
Preserve Evidence
Before assessment: capture (a) software inventory report from SCCM or manual scan (WMI query output above); (b) installation event logs from all endpoints: Get-WinEvent -FilterHashtable @{LogName='System'; ID=7045} (Service Control Manager service installation, 90-day history); (c) uninstall registry entries: Export from HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall on all hosts; (d) EDR agent service status and version: Get-Service -Name '*Defender*' -ErrorAction SilentlyContinue | Select-Object Name, Status, DisplayName and Get-MpComputerStatus; (e) EDR telemetry gaps (no events in 24+ hours): correlate with EDR agent restart logs and System Event Log 7034 (service crashed) and 7045 (service installed/modified).
Step 6, Communication: Notify security leadership and IT asset owners of the BYOVD driver risk; if pre-ransomware staging is suspected on any host, escalate to incident response and consider engaging external IR support before broader notification.
Containment
NIST 800-61r3 §3.2.2 (incident response notification and communication)
NIST IR-2(2) — Incident reporting (senior management notification)
CIS 17.1 — Communicate incident response plan
Compensating Control
Without formal IR program: (1) Identify escalation contacts: Chief Information Security Officer (CISO), VP of IT, IT Security Manager, and legal/compliance lead; (2) Prepare concise escalation brief with: attack vector (malvertising + trojanized installer), indicators present on this environment (HWAuidoOs2Ec.sys confirmed or suspected), number of affected hosts, and risk to ransomware (EDR kill capability); (3) If ransomware staging suspected (indicators: lateral movement to file servers, disabled backups, mass file enumeration, persistence mechanisms), immediately engage: (a) external Incident Response firm (IR retainer or on-demand), (b) FBI Cyber Division (via IC3.gov or local FBI field office), (c) cyber insurance carrier (notify within policy timeframe); (4) If only driver + RMM confirmed (no staging), notify CISO and proceed with containment; broader endpoint notification can wait until Step 7 mitigation is deployed.
Preserve Evidence
Before escalation: compile (a) confirmed indicator count: number of hosts with HWAuidoOs2Ec.sys, unauthorized RMM instances, EDR kill events, LSASS access attempts (from Steps 2–4); (b) timeline: installation date of trojanized ScreenConnect, EDR restart events, first RMM execution; (c) affected user count and departments; (d) backup status check: confirm backup system availability and test restore capability (may be compromised); (e) network segmentation status: whether affected hosts have access to high-value targets (domain controller, file servers, backup systems).
Step 7, Long-term: Add HWAuidoOs2Ec.sys to your organization's driver blocklist; review and tighten WDAC or AppLocker policy to prevent unsigned or newly identified vulnerable drivers; evaluate whether your vulnerable driver blocklist is current against the Microsoft Recommended Driver Block Rules and supplement with threat-intelligence-sourced additions.
Recovery
NIST 800-61r3 §3.4 (post-incident activity, process improvements)
NIST SI-7(15) — Information System Monitoring (driver integrity)
CIS 6.2 — Application and Kernel Driver Control
NIST CA-7(1) — Continuous Monitoring
Compensating Control
Without enterprise device management: (1) Download Microsoft Recommended Driver Block Rules from Microsoft: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules (verify URL and download latest version); (2) Create WDAC policy via: New-CIPolicy -DriverFilesPath 'C:\path\to\blocked\drivers' -Level FileName -Fallback Hash; deploy via Group Policy or direct binary (convert to WDAC XML); (3) If WDAC not available, use AppLocker fallback: Create AppLocker rule to block driver execution by file path or hash (gpedit.msc > Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker > Rules for DLLs and Executables); (4) Integrate threat intel: subscribe to CISA alerts (https://www.cisa.gov/news-and-updates) and KnownDrivers.com curated blocklist; (5) Update quarterly: monthly review of new BYOVD exploits and add to blocklist; audit enforcement logs monthly via Get-AppLockerFileInformation.
Preserve Evidence
Post-recovery (ongoing): maintain (a) driver blocklist version and deployment date; (b) WDAC policy version and audit logs (Microsoft-Windows-CodeIntegrity/Operational); (c) monthly AppLocker enforcement reports (Group Policy event logs); (d) threat intelligence feed subscription records (dates of alerts processed); (e) policy test results (verify blocked driver cannot load on non-production test host).
Recovery Guidance
After eradication: (1) Rebuild or restore affected hosts from clean backups dated before January 2026 (campaign start); verify backup integrity and isolation during recovery. (2) Re-baseline EDR/antivirus deployment and confirm telemetry flow for 72 hours post-recovery. (3) Conduct threat hunt on high-value targets (domain controllers, file servers) for lateral movement artifacts (credential dumping, unusual logons, file access) using Windows Event Log 4769/4770 (Kerberos), 4624/4625 (logon success/failure), and 5140 (network share access).
Key Forensic Artifacts
Windows Event Log Security 4688 (process creation, 30+ days historical for NetExec/FleetDeck/ScreenConnect execution)
Windows Event Log System 7045 (service installation, HWAuidoOs2Ec.sys driver load events)
Sysmon Event Log 10 (ProcessAccess to LSASS, 30+ days)
Windows Event Log Security 4656/4663 (LSASS handle requests and file object access)
File system artifacts: %ProgramFiles%/ConnectWise/ScreenConnect/, %SystemRoot%/System32/drivers/HWAuid*.sys, %ProgramFiles%/*FleetDeck*, %ProgramFiles%/*NetExec*; capture file hashes, creation/modification timestamps, and digital signatures
Registry hives: HKLM\Software\ConnectWise, HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall, HKLM\System\CurrentControlSet\Services (driver configuration)
Browser download history and cache: %USERPROFILE%/AppData/Local/Google/Chrome/User Data/Default/History (malvertising link tracking)
Network connections: netstat -ano output and Get-NetTCPConnection (identify command-and-control callbacks from ScreenConnect/RMM/NetExec)
LSASS memory dump and loaded module list (for credential dumping and further malware analysis)
Detection Guidance
Driver load events: Monitor for HWAuidoOs2Ec.sys in Sysmon Event ID 6 (driver loaded) and Windows Event ID 7045 (new service installed). Any appearance of this driver on a production host is a high-confidence indicator of BYOVD activity. EDR process termination: Look for unexpected termination or service-stop events targeting security tool processes (MsMpEng.exe, SentinelAgent.exe, avp.exe). A gap in EDR telemetry on a host that was previously reporting is itself a detection signal. LSASS access: Sysmon Event ID 10 targeting lsass.exe from non-system processes; Windows Security Event IDs 4656 and 4663 for LSASS object access; review for mimikatz-style access rights (0x1010, 0x1038). RMM tool presence: Audit installed services and running processes for FleetDeck Agent and ConnectWise ScreenConnect; flag any RMM tool not present in your authorized software inventory. Network reconnaissance: Hunt for NetExec (nxc.exe; successor to legacy CrackMapExec) execution in process creation logs (Sysmon Event ID 1, Windows Event ID 4688); correlate with SMB enumeration traffic (Event ID 4624 type 3 lateral logons). Ad-delivered installer lure: If proxy or DNS logs are available, look for download events from domains mimicking ConnectWise branding that are not connectwise.com or screenconnect.com. Behavioral chain: The sequence of
new ScreenConnect install, driver load of HWAuidoOs2Ec.sys, EDR process termination, LSASS access is a high-confidence kill-chain indicator; any two of these four in sequence on the same host warrants immediate investigation.
Indicators of Compromise (4)
Type Value Context Confidence
DRIVER
HWAuidoOs2Ec.sys
Signed but vulnerable Huawei audio driver used as BYOVD vector to achieve kernel-mode execution and terminate EDR processes. Newly identified; not previously documented in vulnerable driver lists as of 2026-03-04.
medium
PROCESS
FleetDeck Agent
RMM tool deployed post-EDR neutralization for persistent access. Presence outside authorized IT deployments is a high-suspicion indicator in this campaign context.
medium
PROCESS
nxc.exe / crackmapexec.exe (NetExec)
Used for network reconnaissance and lateral movement following credential dumping. Execution in non-pentest environments is anomalous.
medium
SOFTWARE
Trojanized ConnectWise ScreenConnect installer
Delivered via fraudulent Google Ads targeting tax-season search queries. Specific installer hashes not published in source as of report date; verify all ScreenConnect installs against official ConnectWise distribution hashes.
medium
Compliance Framework Mappings
T1566
T1219
T1566.002
T1036
T1003.001
T1055
+10
AT-2
CA-7
SC-7
SI-3
SI-4
SI-8
+14
164.308(a)(7)(ii)(A)
164.312(d)
MITRE ATT&CK Mapping
T1566
Phishing
initial-access
T1219
Remote Access Tools
command-and-control
T1036
Masquerading
defense-evasion
T1055
Process Injection
defense-evasion
T1078
Valid Accounts
defense-evasion
T1195
Supply Chain Compromise
initial-access
T1021
Remote Services
lateral-movement
T1068
Exploitation for Privilege Escalation
privilege-escalation
T1543
Create or Modify System Process
persistence
T1562.001
Disable or Modify Tools
defense-evasion
T1036.005
Match Legitimate Resource Name or Location
defense-evasion
Guidance Disclaimer
