WhatsApp DMs Are Delivering VBScript Droppers That Install Legitimate RMM Tools on Victims' Machines

An active malware campaign is abusing WhatsApp Desktop and the browser-based WhatsApp Web client to deliver VBScript droppers that silently install commercial Remote Monitoring and Management (RMM) tools on victim endpoints across at least nine countries.

What Is Happening

Researchers at Kaspersky documented the campaign, which reaches targets through direct messages containing VBScript file attachments. When a recipient opens the file, it executes and sideloads a legitimate, vendor-signed RMM binary onto the host machine. The attacker then has persistent, authenticated remote access — without ever deploying a single piece of traditional malware.

Affected users span Malaysia, Brazil, India, Mexico, Singapore, the United Kingdom, Spain, Taiwan, and Australia. Both the desktop client and the web interface are being used as delivery channels. The targeting is wide and appears opportunistic rather than industry-specific.

Why Signed RMM Tools Are Such a Dangerous Payload

RMM software is not malware. Products in this category are licensed to managed service providers and IT departments worldwide. The binaries are digitally signed by their vendors. The network traffic they generate blends with ordinary IT operations traffic. Most endpoint detection and response platforms, antivirus engines, and network proxies treat RMM agent activity as benign by design.

That is exactly the problem. CISA, the NSA, and MS-ISAC flagged this precise threat pattern in a joint advisory published January 25, 2023, warning that threat actors were using legitimate RMM software to maintain persistence and move laterally after initial compromise. That advisory remains the operative federal guidance on the threat class. The challenge has not gone away — it has migrated to new delivery vectors.

The Verizon 2024 Data Breach Investigations Report found that the human element — phishing, pretexting, misuse — contributed to 68 percent of breaches analyzed. A WhatsApp message asking someone to open a file is a social-engineering problem before it is a technical one.

The Encryption Blind Spot

WhatsApp's end-to-end encryption is a feature users rightly value. It is also why enterprise gateway inspection cannot catch these attachments in transit. The payload arrives on the endpoint already decrypted, inside a trusted messaging application. Detection has to happen at execution time — on the device itself — after the VBScript runs.

That is a narrow window. Organizations that allow WhatsApp Desktop on managed endpoints without compensating controls are, in effect, providing attackers a delivery channel that bypasses perimeter defenses entirely.

The Disclosure Dimension

For publicly traded U.S. companies, a confirmed RMM-based intrusion originating from this campaign may trigger reporting obligations under the SEC's final cybersecurity disclosure rule (17 CFR §229.106), which has been in effect since December 18, 2023. Under that rule, registrants must disclose material cyber incidents on Form 8-K Item 1.05 within four business days of a materiality determination. The rule does not carve out exceptions based on how initial access was obtained — a scripted dropper over a consumer messaging app counts the same as a phishing email.

EU-regulated organizations face a parallel obligation. NIS2 Article 23 requires an early warning to the relevant CSIRT within 24 hours of becoming aware of a significant incident. Member-state transposition is uneven, but the obligation is live in jurisdictions that have completed implementation. Organizations operating across both regulatory regimes need to be ready to assess materiality fast.

Meta had not published a dedicated security advisory tied to this specific abuse pattern at the time of writing. WhatsApp's current guidance directs users to the in-app reporting flow.

Which Controls Failed — and Why It Matters

This campaign exposes a compounding failure across three control categories. First, scripting execution policy. VBScript files sent over a consumer messaging channel and executed from a user profile directory represent an elementary attack pattern — one that application allowlisting and script-execution restrictions are designed to block. Many organizations have not enforced those policies on endpoints where WhatsApp Desktop is permitted, treating the application as a productivity tool rather than an ingestion surface.

Second, RMM inventory hygiene. If an organization does not maintain an approved list of RMM agents and alert on any installation outside that list, it has no way to distinguish an attacker's tool from a legitimate one. The signed binary looks identical. The only differentiator is whether IT authorized it.

Third, and most directly relevant to the social-engineering vector: user awareness. The initial action — opening an unsolicited file attachment sent over a consumer messaging platform — is a human decision. Training employees to treat unexpected file attachments from messaging apps with the same suspicion they would apply to email attachments is not optional. Organizations that have invested in security-awareness training programs report measurably lower rates of user-initiated malicious execution, because the employee becomes the last line of defense when technical controls cannot see the payload in transit.

What Defenders Should Do Right Now

Mitigation is unglamorous but specific:

• Block or alert on VBScript execution from user profile directories. This is where dropped files land. A policy that prevents script execution from %APPDATA%, %TEMP%, and similar paths stops a wide class of droppers, not just this one.
• Maintain an approved RMM agent inventory. Any RMM binary installed outside that list should trigger an immediate alert. Endpoint detection tools that support application control can enforce this automatically.
• Treat WhatsApp Desktop as an untrusted file-ingestion surface. Consumer messaging apps are not subject to the same attachment-scanning controls as corporate email. Policy should reflect that reality — either by blocking file attachments from non-corporate messaging clients or by sandboxing execution.
• Review disclosure readiness. Legal and security teams should walk through the SEC 8-K materiality checklist against a hypothetical RMM-based compromise now, before one occurs. The four-business-day clock starts at materiality determination, not at containment.
• Test detection coverage. Run an internal tabletop or purple-team exercise using a signed RMM agent as the simulated payload. Most organizations discover gaps they did not know existed.

The campaign is ongoing. The countries affected suggest the operators are not constrained by geography. Any organization with employees who have WhatsApp Desktop installed on a managed endpoint — or who use WhatsApp Web on a work browser — sits within the target population.

For organizations benchmarking their controls against published frameworks, NIST SP 800-53 control families SA-10 (developer configuration management) and SI-3 (malicious code protection) address the RMM-detection gap directly. A practical starting point for mapping your current posture to those controls is available at train2secure.com/standards.

The question is not whether a signed RMM binary can be made to look benign. It already does. The question is whether your detection stack, your policies, and your people are configured to catch the delivery mechanism before it gets that far.