Microsoft Defender Experts have documented an active threat campaign, first observed in late February 2026, in which malicious Visual Basic Script files are being distributed through WhatsApp messages to Windows users. Once a recipient executes the attachment, it triggers a carefully orchestrated, multi-stage infection chain designed to quietly establish persistence and open a durable remote access channel into the compromised system. The specific social engineering lures used to convince targets to run the scripts have not yet been publicly identified, though the delivery method itself — a seemingly innocuous file shared over a trusted messaging platform — represents a calculated abuse of user familiarity.

According to the Microsoft Defender Security Research Team, the campaign blends social engineering with living-off-the-land techniques, using renamed Windows system utilities to masquerade as normal system activity, fetching subsequent payloads from well-known cloud storage providers including AWS S3, Tencent Cloud, and Backblaze B2, and ultimately deploying malicious Microsoft Installer packages to maintain persistent control over victim machines.

The decision to route payload delivery through reputable cloud infrastructure is not incidental. Because network traffic to services like AWS, Tencent Cloud, and Backblaze appears indistinguishable from routine cloud access, security monitoring tools and network firewalls are far less likely to flag these connections as suspicious. This technique, combined with the weaponization of legitimate Windows binaries, creates a threat posture that is deliberately difficult to detect at both the host and network level.

Initial Access and Filesystem Manipulation

When a victim opens the malicious VBS file on a Windows desktop or the WhatsApp web client, the script immediately begins executing local operations. It creates hidden directories under C:\ProgramData — a location that is writable by standard user accounts and typically overlooked by cursory system inspections — and proceeds to stage renamed copies of legitimate Windows binaries within those directories. Specifically, curl.exe is disguised under the name netapi.dll, while bitsadmin.exe is repackaged as sc.exe. Both filenames are chosen to resemble genuine Windows system components, further reducing the likelihood of attracting human or automated scrutiny.

This abuse of binary renaming is a hallmark of Living Off the Land Binary and Script (LOLBAS) tradecraft. Rather than introducing foreign malware executables that endpoint detection tools could flag via signature matching, the attackers repurpose tools already trusted by the operating system. The PE (Portable Executable) headers of these renamed binaries still reflect their original identity — a discrepancy that, under careful inspection, can serve as an indicator of compromise, but which most users and many automated scans will never examine.

Cloud-Hosted Secondary Payloads

Once the renamed utilities are in position, they are invoked to download additional VBS scripts from attacker-controlled storage buckets hosted on AWS S3, Tencent Cloud, and Backblaze B2. Microsoft Defender customers hunting for related activity can query for DeviceFileEvents where the initiating process filename ends in .dll but whose VersionInfoOriginalFileName resolves to curl.exe, filtering for output files bearing .vbs or .msi extensions. This detection approach specifically exploits the metadata mismatch between the renamed binary and its true identity, providing a forensic path that purely name-based monitoring would miss entirely.

The retrieval of secondary scripts through curl.exe (operating as netapi.dll) means the download activity appears, to most network monitoring solutions, as ordinary HTTPS traffic originating from a Windows DLL. These secondary VBS files carry the logic for the next phase of the attack: privilege escalation, UAC manipulation, and the eventual deployment of malicious installer packages.

UAC Bypass and Privilege Escalation

Once the secondary payloads are in place, the malware moves aggressively against Windows security controls, beginning with User Account Control. It enters a persistent loop, continuously attempting to spawn cmd.exe with elevated privileges, retrying the operation until either UAC elevation succeeds or the process is externally terminated. Simultaneously, it modifies registry entries beneath HKLM\Software\Microsoft\Win and embeds persistence mechanisms designed to survive system reboots.

The specific UAC bypass technique leveraged in this campaign relies on registry manipulation rather than kernel exploits, making it a fileless operation in the traditional sense. By editing keys within HKLM — the local machine hive, which governs system-wide settings — the malware can alter how Windows handles elevation prompts for specific processes. This approach does not require the attacker to drop additional binaries, is reversible in memory, and leaves a relatively small forensic footprint compared to more intrusive privilege escalation methods.

MSI Package Deployment and Remote Access

The final stages of the campaign center on the deployment of malicious Microsoft Installer packages. MSI files are an effective vehicle for this purpose because they are not inherently treated as suspicious by most endpoint controls and can execute custom installation actions during the setup process. In this campaign, those custom actions carry the payload logic: installing backdoors, reinforcing elevated privilege, and establishing remote access tooling.

Among the software deployed through these MSI packages is AnyDesk, a commercially available remote desktop application. Because AnyDesk is a signed, widely used tool, its presence on a system does not automatically trigger security alerts. Attackers exploit precisely this legitimacy — once AnyDesk is installed and configured to accept inbound connections from attacker-controlled endpoints, the threat actors gain persistent, interactive access to the victim’s desktop environment. From that position, they are capable of exfiltrating sensitive data, executing additional malware, manipulating files, or pivoting laterally within a corporate network.

Detection Guidance and Defensive Posture

Organizations should deploy SIEM hunting queries targeting the execution of curl.exe or bitsadmin.exe from paths under C:\ProgramData, particularly where PE header metadata reveals a mismatch between the file’s apparent name and its true origin. Anomalous registry modifications under HKLM\Software\Microsoft\Win should be treated as high-priority indicators, and repeated looping attempts by cmd.exe to escalate privileges should prompt immediate endpoint isolation.

On the prevention side, Microsoft recommends blocking or restricting the execution of Windows Script Host processes — specifically wscript.exe, cscript.exe, and mshta.exe — when invoked from untrusted paths, and implementing traffic inspection policies for cloud storage services to detect payload retrieval even when the source domain enjoys an established reputation. Associating .vbs file extensions with a non-executing handler such as Notepad by default, rather than the Windows Script Host, would neutralize the initial delivery vector entirely for most casual users.

At its core, this campaign illustrates how the convergence of trusted communication platforms, legitimate system utilities, and reputable cloud infrastructure can be weaponized into a highly evasive attack chain — one where every individual component appears benign, but whose combination enables full system compromise with minimal forensic visibility.