WhatsApp VBS Campaign: UAC Bypass & Multi-Stage Infection Chain
Just saw the latest alert from Microsoft regarding a new campaign leveraging WhatsApp to distribute malicious VBS files. The activity, which started picking up in late February 2026, is a textbook example of attackers abusing trusted communication platforms for initial access.
The mechanics are concerning: once the user is social-engineered into running the script, it kicks off a multi-stage infection chain. The most notable part is the UAC bypass used to hijack the Windows environment, establishing persistence and enabling remote access without triggering the usual admin prompts.
Since the prompt mentions VBS files, we should be hunting for suspicious script execution patterns. If you aren't already blocking wscript.exe and cscript.exe for non-admin users, now might be the time to consider it. For detection, I'm currently using this KQL query in Sentinel to flag VBS execution initiated from non-standard parent processes:
DeviceProcessEvents
| where FileName in~ ("wscript.exe", "cscript.exe")
| where ProcessCommandLine contains ".vbs"
| where InitiatingProcessFileName !in~ ("explorer.exe", "cmd.exe", "powershell.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName
Has anyone else seen indicators of this campaign in their environment yet? If you've identified the specific UAC bypass technique they are using (e.g., environment variable manipulation or registry hijacking), please share the IOCs.
We spotted a similar spike last week. The UAC bypass in our samples was utilizing the eventvwr.exe path—the classic HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command registry modification.
We've pushed a constrained ASR rule to block Office apps from creating child processes, which stopped the execution, but it didn't stop the initial download. I'd recommend adding a PowerShell script to your login scripts that audits that specific registry key path.
From a pentester's perspective, this UAC bypass is easy to replicate because it relies on auto-elevating COM objects. It's tough to defend against without breaking legitimate admin tools.
One mitigation that worked for my clients without breaking workflow is enabling 'User Account Control: Only elevate executables that are signed and validated' via GPO. It won't catch everything, especially if the attacker signs the malware, but it filters out a lot of the junk VBS scripts.
Great points on the eventvwr vector. From a detection standpoint, since the VBS file often needs to manipulate the environment before the bypass, hunting for registry changes on that specific path usually gives the earliest warning. We’ve deployed a Sigma rule targeting this behavior alongside standard ASR rules. Here’s a quick KQL query I use in Sentinel to hunt for these specific mscfile modifications if you haven't set up alerting yet:
Registry
| where Hive has @"HKCU\Software\Classes\mscfile\shell\open\command"
| where ActionType == "RegistryValueSet"
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access