A new malspam campaign is piggybacking on Google’s DoubleClick advertising domain to deliver a .NET-based remote access trojan — and the clever use of a trusted Google URL helps it slip past most security tools before a victim ever touches attacker-controlled infrastructure.
How the Attack Chain Works
It starts with a phishing email containing an HTML attachment. Open it, and the file silently redirects the victim’s browser through a Google DoubleClick Campaign Manager click-tracking URL. That’s the trick: because DoubleClick is a legitimate Google-owned domain that’s whitelisted almost everywhere, security tools largely let it pass without raising alarms.
From DoubleClick, the victim hits a redirector that reads the Base64-encoded email address from the URL and dynamically generates a personalized landing page. No need for attackers to handcraft lures for each target — the kit pulls in company branding and location details on the fly. The victim sees a “Download PDF” button. Clicking it drops a ZIP file instead, and that’s where the real infection begins.
A JavaScript loader inside the ZIP pulls down a PowerShell script, which fetches the .NET loader from an external server. The stager checks if it’s being analyzed in a sandbox, disables the machine’s security controls, sets up persistence, and then injects the final RAT payload into Microsoft-signed processes using process hollowing. Once running, the trojan configures Microsoft Defender exclusions, patches AMSI and ETW to blind detection tools, establishes a C2 channel over raw TCP sockets, and begins system reconnaissance.
Why This Matters
The technique isn’t entirely new, but the scalability is. Campaigns that abuse well-known cloud and ad infrastructure for delivery have been rising steadily, and defenders face the hard truth that blocking Google-owned domains isn’t practical. The dynamic personalization element — where the phishing page adapts to each victim’s email and company — means attackers can run wide-area campaigns without the per-target overhead that used to make mass phishing less effective.
The process hollowing into Microsoft-signed binaries is also a pattern worth watching. It’s a proven technique, but combined with AMSI/ETW patching and Defender exclusion tampering, it shows operators who know exactly how to neutralize the built-in security stack on Windows machines.
What to Do About It
Start with the obvious: restrict HTML file attachments at the email gateway. Most organizations shouldn’t be receiving executable-marked content as email attachments at all. Beyond that, monitor outbound connections from Microsoft-signed processes to unfamiliar IP addresses — especially raw TCP connections that don’t match normal application behavior. Endpoint detection rules that watch for Defender exclusion changes, AMSI/ETW patching, and process hollowing into signed binaries will catch the post-exploitation stage even if the initial delivery succeeds.
If you haven’t reviewed your mail filtering rules for unusual file extensions recently, now’s a good time.
