DesckVB RAT is Using Google DoubleClick to Bypass Your Email Filters

A new malspam campaign abuses Google's DoubleClick domain. Learn how it blinds Windows telemetry, evades analysis, and how Notepad can stop it.

DesckVB RAT is Using Google DoubleClick to Bypass Your Email Filters

5 min. read


Let's talk about the newest headache hitting the inbox. Threat actors are getting incredibly lazy with their payload delivery, but their evasion tactics are unfortunately brilliant. Security researchers at Huntress just broke down a massive new malspam campaign dropping the DesckVB Remote Access Trojan. The entire operation relies on abusing Google DoubleClick to walk right past your email security gateways.

Usually, a phishing email contains a link to a freshly registered, sketchy domain. Your secure email gateway scans the link, realizes it has zero reputation, and quarantines the message. The operators behind DesckVB RAT solved this problem by routing their initial lures through ad.doubleclick.net. Because DoubleClick is a massive, legitimate advertising infrastructure owned by Google, almost every security tool on the planet implicitly trusts it. The gateway sees the Google domain, assumes it is a standard marketing tracker, and delivers the malicious email straight to the user.

Once the user gets tricked into clicking that trusted link, the attack chain gets nasty. The DoubleClick URL automatically forwards the victim to a secondary redirector. This stage decodes the user's email address from the URL string and drops them onto the actual phishing landing page.


Here is where the threat actors save a ton of time. They are not handcrafting bespoke phishing kits for every target organization. The landing page builds itself on the fly. It reads the victim's email address, automatically scrapes the internet for their corporate logo, and slaps the company branding onto a fake "Download PDF" portal. It looks completely legitimate, and it scales infinitely with zero extra effort from the attackers.

If the user falls for the fake portal and clicks download, they get a ZIP file containing a JavaScript loader. That script is just the first domino in a completely fileless infection chain. The JavaScript writes a PowerShell script, which reaches out and pulls down a .NET staging payload.

This stager is specifically designed to frustrate anyone trying to analyze it. It actively checks for sandbox environments and common malware analysis tools. If it spots your debugger, it does not just quietly exit. It intentionally forces the machine to reboot to ruin your triage session.

Assuming it clears the sandbox check, the stager goes to war with Windows telemetry. It patches the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) directly at the native API level. It effectively blinds Defender and your EDR before the actual RAT even drops. Finally, it uses process hollowing to inject the DesckVB payload directly into a trusted, Microsoft-signed process like InstallUtil.exe or MSBuild.exe. The malware lives entirely in memory, communicating with its command and control servers over raw TCP sockets.

This is a masterclass in living off the land and abusing trusted infrastructure. It also proves that relying solely on URL reputation filters is a losing battle.

You need to step up your defense in depth to stop this chain before it reaches the memory injection phase. The easiest win is configuring a Group Policy Object to force high-risk script files like .js and .vbs to open in Notepad by default. If a user accidentally clicks the malicious JavaScript file inside the ZIP, it just opens as a harmless text document instead of executing the Windows Script Host. You should also verify your email gateway is actually sandboxing compressed attachments, rather than just scanning the initial URL. Stop trusting a link just because Google is hosting it.

Like more of this?
Visit 404+ on Twitter, Facebook and the Web at 404andmore.com