DesckVB RAT Campaign Routes Phishing Lures Through Google's DoubleClick Domain
Attackers are bouncing victims off a Google-owned ad redirect before landing them on attacker infrastructure — a trick that buys cover from filters trained to trust doubleclick.net.
A malspam operation is using Google's DoubleClick ad-tech domain as a redirect waypoint to push a remote access trojan called DesckVB RAT, according to researchers tracking the campaign.
The trick is simple and effective. The phishing lure doesn't link directly to attacker-controlled infrastructure. It links to a DoubleClick URL that then bounces the victim onward. Many secure email gateways and URL reputation services treat doubleclick.net as benign because it's Google-owned and ubiquitous in legitimate ad traffic.
That's the whole point.
DoubleClick supports open redirect-style click-tracking parameters as part of normal ad serving. Abuse of that behavior is not new (Google has dealt with similar redirector complaints for years), but it remains an underrated detection gap on the inbound side. If your URL sandbox unwraps the first hop and stops there, the malicious destination never gets scored.
The payload
The final stage is DesckVB RAT, a Visual Basic-based remote access trojan. Capabilities reported in the campaign include the standard RAT feature set: command execution, file exfiltration, credential theft, and persistence on the host. The delivery chain leans on social-engineering lures consistent with commodity malspam — invoices, shipping notices, that tier of bait.
No formal CVE is involved here. This is abuse of legitimate infrastructure, not exploitation of a flaw. Which makes it harder to "patch" in any meaningful sense.
What defenders should actually do
Two concrete moves worth making this week:
- Force full URL unwrapping in your mail gateway. If your tooling stops at the first redirect because the host is on an allowlist, that allowlist is now a liability. Recursive resolution against the terminal destination is the only setting that matters.
- Hunt for outbound DoubleClick traffic from non-browser processes. Office apps,
wscript.exe,cscript.exe, or freshly spawned LOLBins reachingdoubleclick.netis not normal user behavior. It's a high-signal anomaly.
Block-listing doubleclick.net outright is not realistic for most environments — it will break a meaningful slice of legitimate web traffic. The defense has to be context-aware.
The broader pattern
Abusing trusted infrastructure for the first hop is the dominant evasion pattern of the last two years. We've seen it with Cloudflare Workers, with *.windows.net storage blobs, with Google Sites, with Notion and Telegraph pages. DoubleClick is a logical addition to that list and probably won't be the last Google property to show up in a phishing chain.
The lesson for SOC teams hasn't changed. Domain reputation is a hint, not a verdict. Treat any redirect chain that terminates outside the brand it claims to represent as suspect, regardless of how clean the intermediate hops look.
