Sicherheitsfilter arbeiten mit Vertrauenslisten. Domains wie doubleclick.net stehen auf jeder dieser Listen — jahrelang aufgebaut, kaum je hinterfragt. Genau das macht sie zum attraktiven Hebel für Angreifer. Huntress-Forscher haben jetzt eine aktive Malspam-Kampagne dokumentiert, die diesen blinden Fleck systematisch ausnutzt: Mit einem manipulierten DoubleClick-Redirect als Zwischenstation landet am Ende der Infection Chain ein vollwertiger Remote-Access-Trojaner auf dem Zielsystem.
DoubleClick als Vertrauens-Leihgabe
Der Angriff beginnt klassisch: eine E-Mail mit HTML-Anhang, der eine vermeintliche Rechnung oder Bestellung imitiert. Der eigentlich interessante Teil steckt im Link, den diese HTML-Datei beim Öffnen aufruft — kein verdächtiger Hoster, sondern googleads.g.doubleclick.net. Über einen Base64-kodierten URL-Parameter leitet DoubleClick von dort auf die eigentliche Phishing-Seite weiter. Für den Sicherheitsfilter sieht es aus wie ein legitimer Werbe-Redirect von Google.
Auf der Phishing-Seite wartet ein personalisiertes Kit, das Firmennamen und Branding des Empfängers einblendet — offenbar aus öffentlich zugänglichen Informationen zusammengebaut. Der Nutzer wird zum Download eines ZIP-Archivs verleitet. Darin: eine JavaScript-Datei, die eine PowerShell-Stage nachlädt. Die PowerShell lädt einen .NET-Loader, der per Process Hollowing einen legitim wirkenden Windows-Prozess als Hülle nutzt und darin den DesckVB RAT injiziert.
Das Muster — vertrauenswürdige Domain als Redirect-Relay — ist nicht neu. CDN-Domains, Cloud-Storage-Buckets, GitHub Raw Content: alles schon als Sprungbrett missbraucht worden. DoubleClick ist nur die aktuell bequemste Variante, weil Googles Infrastruktur in quasi keiner Blockliste auftaucht und HTTPS-Zertifikate selbstverständlich dabei sind.
Was DesckVB auf dem System anrichtet
Ist der RAT einmal im Prozess verankert, arbeitet er sich systematisch durch die Windows-Verteidigungslinien. Er legt Ausnahmen im Windows Defender an, patcht AMSI (Antimalware Scan Interface) und ETW (Event Tracing for Windows) im laufenden Prozess — beides Mechanismen, auf die viele EDR-Lösungen aufbauen. Persistenz sichert er über Registry-Einträge und Startup-Ordner. Die Kommunikation läuft über eine TCP-basierte C2-Verbindung.
Bei einem meiner KMU-Kunden sah ich kürzlich genau diese Konstellation: Windows Defender als einziger Endpunktschutz, ausgehend keine Firewall-Filterung auf Applikationsebene. Die Annahme war, dass der Defender plus E-Mail-Filter ausreicht. Für Kampagnen, die über Google-Infrastruktur routen, ist das eine riskante Wette.
Huntress weist darauf hin, dass Defender-Ausnahmen über Gruppenrichtlinien (GPO) gesperrt werden können — Standardnutzer sollten diese nicht selbst setzen dürfen. Ergänzend empfehlen die Forscher DMARC, DKIM und SPF auf der E-Mail-Seite sowie Sandbox-Analyse für eingehende Anhänge. Die konkrete Analyse der Kampagne ist bei The Hacker News dokumentiert, die sich auf Huntress-Forschungsdaten stützt.
Einen einzelnen Patch für diesen Angriffsweg gibt es nicht — das ist das Unbequeme daran. Solange Redirect-Mechanismen legitimer Dienste offen sind, lassen sie sich als Tarnung missbrauchen. Die Abwehr steckt im Schichtensystem: restriktive Makro- und Script-Richtlinien, kein Defender-Tuning durch Standardnutzer, ausgehende Filterung auf Prozessebene. Wer nur auf Signatur-basierte Filter vertraut, darf sich über den nächsten vertrauenswürdigen Redirect nicht wundern.
