How Attackers Use Google DoubleClick to Deliver a .NET RAT Loader

Researchers at Huntress have documented a large-scale phishing email campaign in which attackers use the legitimate Google DoubleClick domain as an intermediate link in the redirect chain. This makes it possible to bypass email security tools, which are less likely to block traffic that passes through Google domains. The ultimate goal of the attack is to deliver a .NET loader with remote access trojan capabilities, able to exfiltrate data, execute commands, and download additional malicious modules. The campaign affects organizations regardless of industry, since the phishing pages are dynamically adapted to each victim.

Infection chain: from HTML attachment to full control

According to the researchers, the attack starts with a phishing email containing an HTML attachment. When opened, the file initiates a redirect via a meta-refresh tag to a URL of the Google DoubleClick Campaign Manager click-tracking system. The victim is then passed through an additional redirector that decodes the Base64-encoded email address of the victim and sends them to a landing page with a “Download PDF” button.

The key feature of the campaign is the automatic personalization of the phishing pages. As reported, the system dynamically pulls in the victim’s corporate branding and location data, generating a convincing page without having to create individual lures for every organization. This makes the operation scalable and cost‑effective for the attackers.

Clicking the download button delivers a ZIP archive containing a JavaScript-based loader. The subsequent chain looks as follows:

1. The JavaScript loader extracts and launches a PowerShell script
2. The PowerShell script downloads a .NET loader from an external server
3. The loader acts as a stager: it checks for the absence of an analysis environment, neutralizes defensive mechanisms, and establishes persistence
4. The final payload is launched using the process hollowing technique—injecting code into Microsoft-signed processes

Evasion techniques

According to Huntress, the malware uses a multi-layered approach to evading Windows security mechanisms:

• Patching AMSI at the native API level—disabling antivirus scanning of scripts and .NET assemblies
• Patching ETW at the native API level—“blinding” Windows telemetry until persistence is established
• Configuring Microsoft Defender exclusions to prevent detection of components
• Detecting analysis tools and sandboxes, then terminating execution and rebooting the machine

Persistence is achieved through registry entries in Run and RunOnce, as well as by placing the loader in the user’s startup folder. After launch, the trojan communicates with the command server over raw TCP sockets, performs system reconnaissance, and gives the attackers full control over the compromised machine—including data exfiltration, command execution, and deployment of additional modules.

Impact assessment

Using legitimate Google infrastructure as an intermediate link is not new, but remains an effective technique. Many email security solutions and web filters apply allowlists to domains owned by major technology companies, which creates a blind spot. Combined with automatic personalization of phishing pages, this significantly increases the likelihood of successful compromise.

Important caveat: the original Huntress analysis was revised after publication—the initial attribution of the final payload to DesckVB RAT was reconsidered, and it is now classified as a .NET loader. This reduces confidence in the precise identification of the ultimate malware and indicates the need for additional research.

Recommendations for defense

Huntress researchers propose a number of concrete measures that can break the infection chain at early stages:

• Group policies for scripts: configure GPO in Active Directory so that .vbs, .hta, and .js files open in Notepad by default. This blocks execution of the JavaScript loader—the first active link in the chain after the archive is downloaded
• Email authentication: implement DMARC, DKIM, and SPF records to reduce the likelihood of spoofed emails being delivered
• Attachment sandboxing: use a mail gateway that can analyze attachments and links in an isolated environment before they reach the user
• PowerShell monitoring: monitor for PowerShell processes launched from unusual parent processes, especially from script interpreters
• Process hollowing control: configure detection rules for cases where Microsoft-signed processes establish atypical TCP network connections

The most effective measure in this case is forcing script files to open in a text editor via group policy—this is the only action that can completely stop the infection chain at the very earliest stage, after the user has already downloaded the malicious archive. Organizations that have not yet implemented this control should prioritize its deployment alongside verifying correct DMARC, DKIM, and SPF settings for their email domains.