DesckVB RAT Campaign Abuses Google DoubleClick to Bypass Security Filters

In the highly competitive arena of modern cyber warfare, threat actors are continuously seeking ways to exploit the invisible layer of implicit trust that keeps the enterprise internet functioning. On June 3, 2026, cybersecurity researchers exposed a sophisticated, highly evasion-focused malspam campaign that embodies this predatory approach. By weaponizing Google’s legitimate, high-reputation DoubleClick ad-tracking infrastructure, attackers have unlocked a reliable path to bypass automated secure email gateways, delivering a modular and dangerous remote access trojan known as DesckVB RAT. This campaign, which has been quietly active since February 2026, represents a major evolution in real-time target personalization and multi-stage fileless execution. Its discovery demands immediate attention from security operations centers (SOCs) and security architects globally.

The DoubleClick Abuse: Living off the Trust of Ad Networks

At the core of this campaign lies a classic “Living off the Trust” technique. Traditionally, automated URL reputation engines and Secure Email Gateways (SEGs) rely heavily on domain reputation scores. Google’s DoubleClick infrastructure—specifically the Campaign Manager click-tracking host ad.doubleclick.net—is universally whitelisted. Since almost all automated security gatekeepers implicitly trust Google domains, any link routed through this infrastructure is waived through without triggering alarms.

The infection chain is initiated when a target receives a phishing email with a malicious HTML file attached. Upon opening this attachment, the local web browser executes a meta-refresh tag, which triggers an automated browser redirect directly to a customized DoubleClick click-tracking URL. Because the destination URL is hosted on Google’s trusted domain, the initial layer of email gateway security fails to detect any anomalies. Once the request reaches DoubleClick, Google’s legitimate tracking system registers the redirect parameter and forwards the victim’s browser to the actual threat actor-controlled infrastructure. By abusing this legitimate service, attackers successfully shield their primary malicious redirection nodes from domain reputation systems.

Dynamic Lures and the Scalable Personalization of Phishing

Once the victim is funneled through the DoubleClick redirect, they are pushed into a highly dynamic, server-side malspam kit. Rather than presenting a generic, easily discoverable landing page, this framework leverages real-time URL parameters to personalize the social engineering lure. The initial redirect URL contains a Base64-encoded string representing the victim’s email address. The landing page decodes this parameter on the fly.

Using the parsed email address, the script dynamically reconstructs the webpage in real time:

• It extracts the victim’s domain name to query external APIs and download relevant corporate logos, colors, and branding materials.
• It detects the target’s geographic location based on the incoming IP address to match localized language preferences and regional references.
• It presents a tailored, hyper-convincing portal featuring a fake PDF viewer that demands the download of a critical document.

This automated approach completely eliminates the need for attackers to handcraft and manage custom assets for individual target organizations. It dramatically reduces operational overhead, increases the credibility of the lure, and allows the campaign to scale exponentially with very low infrastructure costs.

The Sophisticated Multi-Stage Infection Chain of DesckVB RAT

When the target clicks the prominent “Download PDF” button on the dynamically generated portal, the web server delivers a ZIP archive rather than a static PDF file. Inside this ZIP file is an obfuscated JavaScript loader, which kickstarts a complex, fileless infection sequence designed to execute the DesckVB RAT without writing a malicious executable directly to the physical storage disk.

This multi-stage execution pipeline flows through five distinct technical phases:

1. The JavaScript Bootstrapper (Stage 1): The heavily obfuscated Windows Script Host (WSH) JavaScript file replicates its code into public directories (typically C:\Users\Public\). It then launches itself via the native Windows scripting tool wscript.exe with the //nologo flag, reconstructing a hidden PowerShell payload in memory.
2. The PowerShell Downloader (Stages 2/3): The executing PowerShell command bypasses local execution policies. It performs quick internet connectivity tests by pinging benign Google domains, then reaches out to external paste sites (such as pastee.dev) or compromised host platforms (such as meusitehostgator.com.br). To evade static network inspection, the target URL is encoded in Base64 and written in reverse order (e.g., 0/jWzXCALY/d/ved.eetsap//:sptth).
3. The .NET Reflective Loader (Stage 4): Rather than downloading a traditional PE binary, the PowerShell script retrieves decimal-encoded payload chunks. It reconstructs these chunks in memory as a compiled .NET Dynamic Link Library (DLL) and executes it directly using .NET reflection techniques via Assembly.Load(). This approach ensures the loader remains completely fileless and avoids disk-based signature scanners.
4. Defensive Telemetry Patching: Once loaded into memory, the .NET stager actively neutralizes local defensive systems. It locates the address of the Antimalware Scan Interface (AMSI) in amsi.dll and patches the AmsiScanBuffer function, rendering real-time script scanning useless. Simultaneously, it targets the Event Tracing for Windows (ETW) framework by patching the native EtwEventWrite API within ntdll.dll, blocking local system events from propagating to Endpoint Detection and Response (EDR) sensors.
5. Process Hollowing Injection (Stage 5): To achieve covert persistence, the loader avoids running an unsigned binary. Instead, it uses process hollowing. It spawns a legitimate, Microsoft-signed system process (such as InstallUtil.exe or MSBuild.exe) in a suspended state using CreateProcessA with the CREATE_SUSPENDED flag. It unmaps the original process memory, writes the malicious DesckVB RAT payload into the newly allocated space, updates the thread context, and calls ResumeThread to hide the malware behind a trusted operating system process.

Aggressive Anti-Analysis and Forensic Defiance

Modern malware analysis frameworks and automated malware sandboxes are major hurdles for attackers. To combat this, the .NET reflective loader utilized in the DesckVB RAT campaigns is equipped with aggressive environment checks. During initialization, the loader scans the system for indicators of virtual machines (such as VMware, VirtualBox, or QEMU), dynamic analysis debuggers, and sandbox environments.

If any virtualization or analysis tools are detected, the loader immediately terminates its execution. However, instead of stopping quietly, the malware is programmed to initiate an immediate and abrupt system reboot. This aggressive defensive posture is highly disruptive to security analysts. By forcing a reboot, the malware resets the volatile memory space of dynamic analysis sandboxes, wipes out temporary forensic artifacts, and shuts down active monitoring tools. This anti-triage tactic significantly complicates automated analysis pipelines, forcing threat hunters to rely on slow, manual static decompilation to understand the threat.

Inside the Arsenal: Command, Control, and Modular Capabilities

Once the final DesckVB RAT payload is active in memory, it establishes a persistent presence on the host system. It achieves persistence through multiple mechanisms, including the creation of registry keys under the Run and RunOnce paths, along with dropping a shortcut into the user’s local Windows Startup folder.

This remote access trojan is characterized by its stability, maturity, and a highly modular, plugin-based architecture. When connected to its command-and-control (C2) server, the RAT can selectively download and execute specific functional plugins based on the attacker’s objectives. This prevents security tools from analyzing the malware’s full capabilities upfront during initial compromise.

The analyzed core payload and its associated plugins support a broad range of malicious actions:

• Webcam Spying & Real-Time Monitoring: The RAT can silently activate local webcams, taking photos or streaming live feeds of the victim.
• Keylogging and Credential Theft: Monitoring keystrokes and local clipboards to capture passwords, MFA codes, and sensitive financial information.
• Arbitrary System Command Execution: Allowing the attacker to interact with the host command line, download secondary malware, or run local administrative scripts.
• Targeted Security Enumeration: Explicitly checking for installed antivirus solutions and endpoint monitoring agents to identify weak spots in defense.
• GPU Enumeration: Querying the system via Windows Management Instrumentation (WMI) to identify local graphics processing unit (GPU) models. This suggests the attackers may be profiling systems for potential cryptocurrency hijacking or cryptomining workflows.

The malware’s network communications are routed to Dynamic DNS (DDNS) domains over non-standard, custom-encrypted TCP ports. This design keeps domain registration costs virtually zero for the operators and allows them to quickly swap C2 IP addresses in response to IP-based blocking. Since the traffic does not use standard ports, typical web proxies and egress filtering configurations can easily miss this communication.

Hardening the Perimeter: Strategic Mitigations for Enterprise Defenders

Detecting and stopping the delivery of the DesckVB RAT requires a defense-in-depth approach. Relying solely on domain reputation or static antivirus signatures will not protect against an attack that abuses Google DoubleClick and runs entirely in memory. Security teams should implement the following recommendations to protect their infrastructure:

1. Enforce Email Security and Inbound HTML Restrictions

Since the initial vector relies on an HTML attachment, security gateways should be configured to quarantine or sandbox unsolicited inbound HTML files. Implementing strict SPF, DKIM, and DMARC verification is critical to prevent spoofed domains from bypassing initial inbound filters.

2. Restrict Windows Script Execution Policies

To neutralize the threat of malicious JavaScript loaders, administrators should change the default file handler association in Windows for script extensions (such as .js, .vbs, and .hta). Configuring these extensions to open in a basic text editor (like Notepad) by default prevents wscript.exe from executing them automatically if a user double-clicks them.

3. Optimize EDR Telemetry and Monitoring Rules

SOC analysts should set up specific alerts in their Endpoint Detection and Response (EDR) consoles to detect the structural steps of this execution chain. Key behaviors to monitor include:

• Instances of wscript.exe launching scripts from writable public folders like C:\Users\Public\ or C:\Users\AppData\Local\Temp\.
• PowerShell processes spawning with legacy or suspicious user-agents (such as legacy IE8 headers) or carrying out encoded commands with string reversal logic.
• The creation of unexpected suspended processes of Microsoft-signed tools (like InstallUtil.exe and MSBuild.exe), which is a clear indicator of process hollowing.
• Unauthorized modifications to Windows Defender exclusion paths or registry keys under the Run and RunOnce hives.

4. Egress and Port Filtering

Organizations should enforce strict egress port restrictions. Blocking outbound traffic over non-standard, unassigned TCP ports is a highly effective way to disrupt the custom C2 communication of the DesckVB RAT. Furthermore, implementing SSL/TLS decryption on enterprise firewalls allows deep packet inspection engines to flag the non-standard patterns of malicious traffic, even when it is wrapped in encryption.