A VBScript campaign distributed through WhatsApp deploying RMM software

Analysis of a VBScript Campaign Distributed Through WhatsApp Deploying RMM Software

A Kaspersky researcher analyzes a global malicious campaign that distributes VBS scripts via WhatsApp, delivering a UEMS RMM agent through a multi-stage infection chain.

In June 2026, we observed a malware campaign distributing malicious VBScript files through direct messages in WhatsApp. The campaign affected users across multiple countries and territories, including Malaysia, Brazil, India, Mexico, Singapore, UK, Spain, Taiwan, Australia, Russia, and Vietnam, with the highest number of victims observed in Malaysia. At the time of writing this article, the campaign is still active.

Analysis shows that the campaign primarily targets users of WhatsApp Desktop and WhatsApp Web. The threat actor uses deceptive file names masquerading as business and financial documents to persuade recipients to download and execute the attachment. Once executed, the VBScript initiates a multi-stage infection chain that ultimately results in the installation of legitimate Remote Monitoring and Management (RMM) software, enabling remote access to the victim’s system.

We came across a number of social media posts reporting that the malware was being distributed by the users’ contacts. The messages contained only the malicious attachment and did not include any accompanying text. One account sent the same attachment to multiple contacts from their list. Based on evidence collected from multiple victims through social media reports and submitted samples, we can conclude that the threat actor had gained access to several WhatsApp accounts and used them to distribute the malicious VBScript files to contacts on the compromised users’ contact lists. At the time of writing, the exact method used to compromise these WhatsApp accounts remains unknown.

Social Engineering Through Financial-Themed File Names

Analysis of the samples revealed that the threat actor relied heavily on social engineering through the use of deceptive file names designed to appear as legitimate business and financial documents. The file names frequently referenced invoices, account statements, debt notices, payment records, and bank statements. Examples of file names include:

• Financial Reports.vbs
• Debt confirmation.vbs
• Statement of Debt(30K).vbs
• Outstanding Payment List.vbs
• Account Statement.vbs
• Debt Statement.vbs
• Billing Statement (2).vbs
• Promissory_Note(b).vbs

Several file names were also localized into different languages, including Portuguese, French, German, and Malay. Examples include:

• Extrato de Conciliação.vbs
• Aviso de dívida.vbs
• Le formulaire de demande le plus récent.vbs
• Bitte füllen Sie das Formular für Umsatzsteuer-Nullsatz-Verkäufe aus.vbs
• Penyata bank.vbs
• Sila semak bil anda.vbs

The use of multiple languages further suggests that the campaign may be targeting victims across different geographic regions.

In addition, the VBScript samples contain extensive comments and metadata intended to mimic legitimate Microsoft Windows Update components. Many of these comments are written in Chinese and include references to Windows Update modules, certificate validation, system integrity checks, and deployment-related functionality. The screenshot below shows an example of the Windows Update–themed comments and Chinese-language annotations embedded within one of the analyzed scripts.

Delivery of the Initial VBScript File

Analysis of telemetry collected from the systems where the malware was executed, conducted together with the dynamic analysis of the sample, showed that the VBScript is launched through Windows Script Host (WScript.exe), which subsequently retrieves and executes additional VBScript components required for the later stages of the attack.

Two user interactions are needed to initiate the infection chain. When the user first clicks the attachment in either WhatsApp Desktop or WhatsApp Web, it is downloaded to their machine. To launch the app, they need to open it. In WhatsApp Desktop, the malware is executed directly within the application by clicking once more the file icon or by choosing the option "Open" in the chat.

The process tree analysis shows that WScript.exe is spawned by WhatsApp.Root.exe. The executed script was observed within WhatsApp Desktop’s attachment storage directory, with the following command line:

"C:\Windows\System32\WScript.exe" "C:\Users\<user>\AppData\Local\Packages\5319275A.WhatsAppDesktop_cv1g1gvanyjgm\LocalState\Sessions\<session>\Transfers\<file>\financial reports(s).vbs"

This process relationship confirms that the malicious VBScript was executed directly from the WhatsApp Desktop client.

In contrast, when the attachment is accessed through WhatsApp Web, to launch the malware, the user should open the downloaded file from the Downloads folder or through the browser’s download history. In the first case, the malware’s parent process will be explorer.exe, while in the second, it will be executed by the browser where the web app was opened.

Technical Analysis

Stage 1: Initial VBScript Execution

The first stage of the infection chain is a VBS or VBE file delivered through WhatsApp. Although multiple variants of the scripts were observed, their core functionality remains consistent: the script creates a working directory under C:\Users\Public\Documents\, downloads two additional VBScript payloads from a remote infrastructure, and executes them using Windows Script Host.

Across the observed variants, the working directory is created using randomized names such as Temp_ or MSUpdate_. Some variants also configure the directory and downloaded files with hidden and system attributes, likely to reduce visibility to the user during execution.

The scripts employ several obfuscation techniques, including string concatenation, encoded VBScript, randomized variable names, and large amounts of junk content. One notable variant employs even heavier obfuscation than the other samples. The script reconstructs object names, file paths, utilities, and URLs through character-by-character string concatenation.

Several variants copy curl.exe and bitsadmin.exe into the working directory and rename them using DLL-like filenames before downloading additional VBS files. The downloaded files are commonly staged using misleading file extensions before execution. For example, some variants download files using PDF or TXT extensions and then change them to VBS before launching them with wscript.exe. Other variants download the secondary VBScript payloads directly.

Despite differences in infrastructure, file names, and obfuscation methods, all observed variants ultimately perform the same function: downloading and executing two secondary VBScript payloads that continue the infection chain.

Stage 2: Execution of Secondary VBScript Payloads

Following execution, the Stage 1 VBScript downloads and launches two additional VBScript files from attacker-controlled infrastructure. One script attempts to modify Windows User Account Control (UAC) settings, while the other downloads and executes a ZIP archive containing the installation package for RMM software.

VBS Script 1: UAC Configuration Modification

First Stage 2 scripts were observed attempting to modify Windows UAC behavior. As shown in the figure above, the script repeatedly executes an elevated registry modification command targeting the following registry key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin

The command is launched using the ShellExecute method with the runas verb, causing Windows to request administrative privileges before the registry change can be applied. Its goal is to set the ConsentPromptBehaviorAdmin registry key value to 0, thus enabling administrative actions without displaying a consent prompt to the user. The script attempts to apply this registry change in a loop with short delays between executions, likely to increase the chances that the setting will be successfully modified if administrative privileges are granted by the victim.

VBS Script 2: ZIP Download and Script Execution

The second VBS script downloads a ZIP file, extracts it, and executes a script to start the RMM installation. Similar to the Stage 1 downloader, the Stage 2 downloader creates its own working directory under C:\Users\Public\Documents\, commonly using randomized folder names such as Sys, Data, or a random numeric value. In most cases, the hidden attribute is assigned to this folder.

The script then downloads a ZIP archive from attacker-controlled infrastructure, extracts its contents, and executes an embedded setup1.vbs script. Similar to the Stage 1 downloader, the variants leverage multiple download mechanisms, including curl, bitsadmin, certutil, PowerShell, and direct HTTP requests.

Following a successful download, the archive is extracted using the Shell.Application COM interface. Most variants invoke the CopyHere method with flags intended to suppress user prompts and allow extraction to proceed without user interaction. The extracted setup1.vbs script is then launched through wscript.exe to proceed with the next stage of the infection chain.

Also, one variant additionally attempts to remove Zone.Identifier alternate data streams from extracted files prior to execution, likely to reduce security warnings associated with files downloaded from the Internet.

Stage 3: Installation of Remote Monitoring and Management Software

Besides the setup1.vbs script, the ZIP archive downloaded during Stage 2 contains a preconfigured ManageEngine Endpoint Central deployment package. Inside the archive are the files required to install and register the Endpoint Central agent, including the MSI installer, configuration files, certificates, and installation scripts.

The table below summarizes the purpose of each file contained within the deployment package:

ManageEngine Endpoint Central is a legitimate enterprise management platform commonly used for software deployment, system administration, and remote support. Its remote administration capabilities make it attractive for abuse by threat actors seeking persistent access to compromised systems.

One interesting variant attempted to disguise the package as an income tax–related document. Instead of containing a legitimate tax document, the archive contained a VBScript file named "Income Tax Return Form.vbs" and accompanied by an instruction file designed to persuade the victim to open it. Analysis showed that the VBScript contained functionality similar to setup1.vbs, ultimately performing the same Endpoint Central installation process.

As discussed in Stage 2, the downloader ultimately executes a VBScript file named setup1.vbs. The script first verifies that the required installation files are present in the extracted folder and then attempts to relaunch itself with administrative privileges using the Windows runas mechanism before proceeding with the installation. Once elevated, setup1.vbs silently installs the bundled ManageEngine Endpoint Central agent using msiexec.exe, applying the supplied configuration and certificate files. The installation is performed silently, preventing the user from seeing the Endpoint Central installation interface.

Analysis of the embedded DCAgentServerInfo.json configuration file revealed the following Endpoint Central management servers:

• 202.61.160[.]208
• 202.61.160[.]202
• 202.61.160[.]201
• 202.61.160[.]160
• 202.61.160[.]137
• 38.55.151[.]63

Notably, 202.61.160[.]201 had previously been observed as command-and-control infrastructure associated with ValleyRAT and Gh0st RAT activity. Although the overlap raises the possibility of the VBS campaign being linked to the operator of these known malware families, the available evidence is insufficient to confidently attribute the campaign to a known threat actor.

Victimology and Attribution

Based on our telemetry, infections were observed across several countries and territories, including Malaysia, Brazil, India, Mexico, Singapore, UK, Spain, Taiwan, Australia, Russia, and Vietnam, with 80% of the victims located in Malaysia. The campaign primarily relied on malicious VBScript attachments distributed through WhatsApp and appeared to target individual users rather than specific organizations or industries. At the time of the analysis, no evidence suggested a focused targeting strategy, instead indicating a broad, opportunistic campaign aimed at consumers.

We were unable to confidently attribute this activity to a known threat actor or intrusion set. However, several artifacts observed throughout the campaign point to a possible Chinese-speaking threat actor. Multiple VBScript samples contained comments, module descriptions, and execution notes written in simplified Chinese characters. These comments appeared consistently across different variants, suggesting that the scripts were likely developed or maintained by a Chinese-speaking operator.

We also identified infrastructure overlaps with IP addresses previously associated with ValleyRAT and Gh0st RAT activity. While these overlaps may indicate infrastructure reuse or shared hosting resources, they are not sufficient to establish a direct connection to any known threat actor. Based on the available evidence, we assess with low confidence that the campaign was conducted by a Chinese-speaking operator.