Evasion via Trust: Analyzing the DoubleClick -> DesckVB RAT Pipeline
Heads up, everyone. Just reviewed the latest IOCs regarding the DesckVB RAT campaign. The actors are effectively laundering their C2 traffic through Google's DoubleClick infrastructure.
This is a clever evasion technique. Since doubleclick.net is categorized as "Trusted" or "Advertisement" by most legacy security controls, the initial request slips past URL filters. The victim's endpoint reaches out to the legitimate Google domain, which then redirects or proxies the traffic to the attacker's sinkhole. This renders simple IP/domain blocklists ineffective.
DesckVB itself is fairly standard VB-script based RAT, focusing on credential harvesting, but the delivery vector is the real headache here. It relies on the inherent trust security teams place in Big Tech domains.
We're hunting for this by correlating process lineage with network connections. If a non-browser process initiates a connection to DoubleClick, it's worth a look. Here is a quick Sigma-style logic I'm using to flag anomalous User-Agents hitting ad domains:
title: Suspicious Non-Browser Connection to DoubleClick
detection:
selection:
dest_url|contains: 'doubleclick.net'
image|contains:
- 'winword.exe'
- 'excel.exe'
- 'powershell.exe'
condition: selection
The big question is: How many of you are actually performing full SSL inspection on trusted domains like Google's? We're hesitating due to privacy/performance concerns, but gaps like this make it tempting.
We actually started decrypting Google traffic last year. It broke a few things initially (mostly Chrome auto-update), but the visibility is worth it. If you aren't doing SSL inspection, you're essentially flying blind on half your traffic. Just make sure you import the root certs properly or you'll kill user trust.
Interesting vector. We've blocked all ad/tracking domains at the DNS level using NextDNS for about two years now. It cuts down on noise significantly and stops these 'living off trusted land' attacks dead in their tracks. Users complained about broken sites for a week, but they got used to it.
Good catch on the process lineage. I'd also add a check for the length of the URL. DoubleClick redirection strings in these campaigns usually look distinct compared to standard ad tracking. You can try parsing the query parameters for Base64 blobs, which is how DesckVB usually passes the config.
Valid point on lineage, Raj. To expand on that, we specifically need to catch the browser-to-shell transition, which these loaders often trigger to establish the C2 tunnel. I've been using this simple KQL hunt to spot chrome.exe or msedge.exe spawning powershell.exe or cmd.exe, which is almost always malicious in this context:
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe")
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access