WhatsApp VBScript Vectors: Weaponizing ManageEngine RMM for Persistence
Just caught wind of the Kaspersky report regarding a new campaign targeting WhatsApp Web and Desktop users in regions like Malaysia, Brazil, and India. The attack vector is interesting—direct messages containing what appear to be legitimate documents (invoices, purchase orders) but are actually malicious VBScript files.
Once executed, these scripts don't drop a standard binary payload. Instead, they reach out to download and install a legitimate Remote Monitoring and Management (RMM) tool—specifically ManageEngine. This creates a "Living off the Land" scenario where the attackers leverage trusted admin software to maintain persistence and remote access without raising immediate red flags.
Since WhatsApp isn't typically part of the standard secure email gateway inspection, this bypasses a lot of traditional filtering. We need to shift our focus to endpoint behavior.
Here is a quick PowerShell snippet to hunt for suspicious parent-child process relationships involving the Windows Script Host:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {
$_.Message -match 'wscript\.exe' -or $_.Message -match 'cscript\.exe'
} | Select-Object TimeCreated, Message | Format-List
We're recommending blocking VBScript execution entirely via AppLocker or Software Restriction Policies, as it's rarely needed in modern enterprise environments. Additionally, if you don't use RMM software, block the ManageEngine installers.
Has anyone else started blocking WhatsApp Web at the proxy level to curb this, or are you relying solely on endpoint detection?
Blocking VBScript is a must. We deployed a GPO to disable wscript.exe and cscript.exe for non-admin users about a year ago when we saw a spike in Office macros dropping scripts. It broke a few legacy internal tools, but the security trade-off was worth it. For the RMM aspect, we allowlist specific RMM agents; anything unsigned or not from our internal repo gets auto-quarantined by the EDR.
This is a nightmare for MSPs. We use ManageEngine, so distinguishing between a legitimate deployment and a malicious one is tricky. We've set up strict geo-fencing on our RMM consoles—if a connection comes from a new ASN or country we don't operate in, the agent is flagged immediately. I'd also suggest checking for unexpected URLMonitor.exe or UEMS_Monitor.exe processes if you suspect a compromise.
Social engineering on WhatsApp is effective because the 'trust' bar is different than email. Users assume since it's on their phone or a personal chat tab, it's vetted. We've started training users to verify the sender via a secondary channel (like Teams or email) if they receive a 'work' document on WhatsApp, especially if it urges immediate action.
Solid advice. From an EDR perspective, since the payload is legitimate software, we focus on the source of the execution. You can hunt for anomalies where the RMM agent installer is spawned directly by wscript.exe rather than a standard deployment tool. Here’s a basic query to catch this behavior:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "wscript.exe"
| where FileName =~ "msiexec.exe"
| where ProcessCommandLine contains "ManageEngine"
Building on the EDR point, we found success using strict application whitelisting via Windows Defender Application Control (WDAC) rather than just script blocking. This stops the unauthorized RMM installer execution at the kernel level. To audit existing installations for anomalies, you can use this PowerShell command to check the service path and start mode:
Get-CimInstance Win32_Service | Where-Object { $_.Name -match "ManageEngine" } | Select-Object Name, PathName, StartMode
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access