Malspam Attack Uses Google DoubleClick Redirects to Deliver Fileless .NET Loader

Cybercriminals have found a new way to sneak malware past email security tools, and this time they are hiding behind a name that most systems trust without question.

A recent malspam campaign has been caught using Google’s own DoubleClick ad-tracking infrastructure to route victims toward a fileless .NET loader, a type of malware that runs almost entirely in memory and leaves very little trace behind for investigators.

Malspam, short for malicious spam, has been a go-to method for attackers for years. It typically involves sending emails with booby-trapped attachments or links designed to start an infection the moment someone clicks.

What sets this campaign apart is how cleverly the attackers disguised the early stages to avoid triggering alarms, leaning on real, high-reputation web services as cover throughout the delivery chain.

Researchers at Huntress identified this campaign in May 2026 after their SOC team responded to a .NET loader infection.

Huntress said in a report shared with Cyber Security News (CSN), the attack begins with a malspam email carrying a malicious HTML file named Bestellung_2026.html, which is German for “purchase order,” suggesting the attackers may have specifically targeted German-speaking businesses.

The HTML attachment contains a zero-second meta-refresh redirect that silently pushes the victim’s browser to a Google DoubleClick click-tracking URL on ad.doubleclick[.]net.

Since this is a legitimate, widely trusted Google-owned domain, most email gateways and URL-reputation filters do not flag it. By the time the victim reaches attacker-controlled infrastructure, the most suspicious part of the chain is already well behind them.

What follows is a personalized lure page that reads the victim’s email from the URL, pulls in the company logo live, and shows the viewer’s city and local time to feel convincing.

The victim sees a button to download what looks like a PDF, but clicking it delivers a ZIP archive containing the real payload instead.

Malspam Attack Uses Google DoubleClick Redirects

The ZIP contains a JScript file that serves as the first stage of a five-step infection chain. The script relocates itself to a stable directory, then decodes and drops an obfuscated PowerShell script.

The PowerShell stage downloads a .NET loader from a remote server, which runs entirely in memory using .NET reflection.

The loader injects itself into legitimate, Microsoft-signed system tools like InstallUtil.exe or MSBuild.exe, giving it cover under processes that Windows itself fully trusts.

At no point does the main payload write a recognizable malicious file to disk, making it extremely difficult for traditional antivirus tools to detect.

Defense Evasion and Persistence Techniques

Once inside a trusted process, the loader works to blind Windows’ built-in defenses. It patches both AMSI and ETW, the two main telemetry engines Windows relies on to spot suspicious behavior, at the native memory level.

Security tools that depend on those systems stop receiving useful signals before the attacker has even established persistence on the machine.

The loader then sets up persistence through Windows registry Run keys and scheduled tasks, using NVIDIA-themed folder names to blend in with what looks like routine driver activity.

It communicates to two command-and-control servers over a non-standard port using AES encryption, and can pull down additional payloads or execute commands entirely from memory.

Huntress recommends that organizations configure a Group Policy Object to force script file types like .js, .vbs, and .hta to open in Notepad by default rather than execute.

Deploying email authentication controls including SPF, DKIM, and DMARC, along with a gateway that sandboxes attachments before delivery, can stop this chain at the first stage.

Regular phishing awareness training also remains critical, since the human layer is still the most consistently exploited entry point in campaigns like this.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.