Angreifer aus dem Umfeld iranischer Akteure passen ihre Command-and-Control-(C2)-Infrastruktur fortlaufend an. Ein aktueller Befund zeigt, wie Cavern-C2 DNS als Schaltzentrale dient: Mithilfe von DNS-A-Record-Antworten wählt das Schadprogramm pro Kommunikationsvorgang, ob es direkt per HTTPS arbeitet oder einen Google-Apps-Script-Relay als Zwischenstation nutzt. Ziel ist, die eigenen Aktivitäten mit normalem Netzwerkverkehr zu vermischen und damit klassische Erkennungsmechanismen zu umgehen.
Die Entdeckung knüpft an frühere Analysen an, die Cavern bereits als modularen Rahmen beschrieben haben. Neu ist vor allem eine zusätzliche Kommunikationskomponente namens GoogleService.dll, die legitim wirkende Dienste dafür nutzt, die Überwachung durch Security-Tools zu erschweren.
Was ist Cavern-C2 und warum ist die Tarnung so wichtig?
Cavern (auch Cav3rn) ist ein C2-Framework, das in Angriffen gegen Organisationen in Israel eingesetzt wurde. Laut Sicherheitsforschung besteht es aus mehreren Bausteinen: Ein Agent übernimmt Kernfunktionen, während weitere Module je nach Auftrag unterschiedliche Post-Exploitation-Aktivitäten ermöglichen. Dazu zählen unter anderem Dateiverarbeitung, Aufzählung von SQL-Datenbanken, Active-Directory-Reconnaissance, LDAP-Bruteforce, Netzwerkanalyse sowie Proxy- und Tunneling-Funktionen.
Ein zentrales Anliegen des Designs ist dabei nicht nur Funktionsumfang, sondern auch geringe Forensik-Sichtbarkeit. Die Architektur ist zudem darauf ausgelegt, fortlaufend erweiterbar zu bleiben, sodass neue Kommunikationswege leichter integriert werden können. Genau hier setzt der aktuelle Befund an: Die Angreifer verwenden Cavern-C2 DNS, um die Kommunikation dynamisch umzuschalten.
Die neue Kommunikationslogik: DNS A-Records als Schalter
In den laufenden Beobachtungen eines Threat-Clusters wurden bislang nicht dokumentierte Komponenten identifiziert, die die Kommunikationsfähigkeiten ausweiten. Die Kernidee des neu beschriebenen Moduls: Eine DNS-A-Record-Abfrage liefert eine Antwort, die entscheidet, welcher Kommunikationsweg für die jeweilige Transaktion genutzt wird.
Die Analyse beschreibt zwei Optionen:
- Direktes HTTPS: Wenn das DNS-Signal den direkten Pfad vorgibt, kontaktiert der Prozess die konfigurierte Adresse, ohne einen Relay zu verwenden.
- Google Apps Script Relay: Wenn der Relay-Modus gewählt wird, sendet das Modul Anfragen an die Apps-Script-Deployment-Instanz. Diese leitet die Daten anschließend an einen vom Angreifer kontrollierten Backend-Endpunkt weiter.
Für die Angreifer ergibt sich dadurch ein Vorteil: Die Kommunikation wirkt je nach Fall sehr unterschiedlich, bleibt aber in einer Logik verankert, die sich auf DNS stützt. Gleichzeitig kann die Angriffsseite über dieselbe DNS-Infrastruktur Details validieren und anpassen.
Google als Funktionsbaustein: Warum der Relay-Zugriff auffällt oder verschleiert
Google Apps Script ist für viele Organisationen ein legitimer Service. Indem Cavern-C2 DNS in manchen Fällen den Umweg über ein Apps-Script-Deployment nutzt, kann die C2-Kommunikation leichter in den Kontext „normaler“ Cloud-Interaktionen passen. Für viele Verteidigungsteams ist genau dieses „Kontext-Mischen“ entscheidend: Je weniger der Verkehr eindeutig nach Malware aussieht, desto schwerer wird die Erkennung über reine Netzwerk-Patterns.
Zusätzlich wird in der Analyse beschrieben, dass das Modul eine Konfigurationsdatei auf dem System liest, insbesondere conf.json. Erst daraus lässt sich ableiten, welche Parameter für DNS-Abfragen und nachgelagerte Kommunikation benötigt werden.
Damit nicht genug: Die Forscher nennen auch einen internen „Broker“ innerhalb des Frameworks. Dieses Bindeglied—rnp.dll—fungiert als lokale Brücke, lädt DLL-Komponenten, routet Nachrichten zwischen ihnen und unterstützt Laufzeit-Updates. In der Praxis erleichtert das eine modulare Weiterentwicklung, ohne dass alles komplett neu ausgerollt werden muss.
Wechsel der Kanäle und Domain-Entwicklung
Interessant ist außerdem, wie flexibel die Betreiber beim Kanalwechsel vorgehen. Die Befunde deuten darauf hin, dass die Angriffsseite denselben DNS-Ansatz nutzt, um den Relay-Deployment-Bezug zu ändern und so den „Google-Kanal“ rotieren zu können. Das macht statische Blocklisten und einfache Zuordnungslogiken weniger wirksam.
Auch die zugehörige Domain, die im Zusammenhang mit der Aktivität genannt wird (studiotikva[.]com), folgt einer auffälligen Dynamik: Sie soll zunächst im Februar 2024 registriert worden sein, dann im Februar 2026 abgelaufen und drei Monate später erneut registriert worden sein. Solche Verhaltensmuster sind ein Hinweis auf anpassungsfähige Infrastrukturplanung, die den Betrieb über Zeit hinweg absichert.
HOLLOWGRAPH: Microsoft 365 Kalender als verdeckter C2-Kanal
Nicht alle neuen Hinweise drehen sich um Google. In einem weiteren Schritt wurden Mechanismen beschrieben, die auf Microsoft 365 basieren. Das Modul HOLLOWGRAPH verwandelt Microsoft-365-Kalender in einen bidirektionalen „Dead-Drop“: Angreifer platzieren Tasking als Kalenderereignisse, während die Malware gestohlene Daten verschlüsselt über Anhänge in eigenen Ereignissen exfiltriert.
Damit die Aktivität für Nutzer möglichst unauffällig bleibt, wird in der Analyse erwähnt, dass jedes Ereignis sehr weit in die Zukunft datiert ist—konkret mit dem Datum 13. Mai 2050. Die Payloads hängen dabei als Dateien an den entsprechenden Ereignissen.
Für die Authentifizierung spielt zudem DNS-Tunneling eine Rolle: Das System soll damit Microsoft-Entra-ID-Zugangsdaten aktualisieren, die für die Kommunikation mit der Graph API benötigt werden. So bleibt die Implant-Logik arbeitsfähig, auch wenn sich Tokens im Betrieb ändern.
Wie sich Cavern-C2 erweitert: Modulprinzip statt starre Malware
Ein roter Faden in den Berichten ist der Übergang zu einer modularen, pluginbasierten Architektur. Laut Kaspersky soll diese Umstellung in den Zeitraum Ende April 2026 fallen. Danach wurde das Framework in der Lage beschrieben, zusätzliche Module nach Bedarf zu integrieren—wodurch sich auch Kommunikationswege vergleichsweise schnell erweitern lassen.
Als Indizien für eine mögliche Verbindung zu anderen iranisch verknüpften Gruppen werden dabei keine direkten Code-Reuse-Vorgänge genannt, sondern technische und operative Muster. Dazu zählen unter anderem der Einsatz von Microsoft-hosted Services für C2, das Vorhandensein eines zweiten Wiederherstellungsmechanismus zur Gewinnung ersetzender OAuth-Refresh-Tokens sowie kompromittierte Infrastruktur in Zielländern und Regionen.
Unabhängig von einer möglichen Zuordnung unterstreicht dieses Vorgehen vor allem: Angreifer investieren in Architektur, nicht nur in einzelne Payloads. Das macht die Verteidigung schwieriger, weil sich Details schneller ändern können als die Grundlogik.
Was bedeutet das für die Praxis der Verteidigung?
Die Befunde zeigen, dass klassische Perimeter-Ansätze allein oft nicht ausreichen. Wenn C2-Verkehr über legitime Dienste läuft oder sich per DNS-Logik tarnt, verschiebt sich der Schwerpunkt in Richtung Kontextanalyse: Welche Systeme senden zu ungewöhnlichen Zeiten? Passt das Kommunikationsmuster zu erwarteten Benutzer- oder Applikationsverhalten? Und lassen sich Prozessketten nachvollziehen, die zu solchen Aktivitäten führen?
Für Teams, die Microsoft-Umgebungen betreiben, wird die Lage zusätzlich komplex, weil Microsoft Graph API und Kalenderereignisse an sich „normal“ wirken können. Gleiches gilt im Google-Umfeld: Dienste wie Apps Script sind etabliert. Genau deshalb ist eine Kombination aus Endpoint-Sicht, Identitätsüberwachung und Netzwerk-/DNS-Analyse besonders relevant.
Schließlich hilft die Erkenntnis, dass Cavern-C2 DNS als Umschalter fungiert: Wer nur einen Kommunikationsmodus beobachtet, übersieht möglicherweise den anderen. Eine effektive Detektionsstrategie sollte daher mehrere Spuren zusammenführen—DNS-Antwortmuster, ungewöhnliche Service-Nutzung und verdächtige Datenflüsse über Cloud-Komponenten.
Fazit: Evolution geht weiter
Die aktuellen Erkenntnisse belegen, dass Cavern weiterentwickelt wird und dabei bewusst legitime Dienste als Tarnschicht nutzt. Besonders die Kombination aus Cavern-C2 DNS und einem dynamischen Wechsel zwischen direktem HTTPS und einem Google-Apps-Script-Relay zeigt, wie modular und anpassungsfähig das Framework ist.
Mit jedem neuen Modul wächst der Aufwand für Verteidiger, denn Erkennung muss nicht nur auf Malware-Signaturen, sondern vor allem auf Verhalten, Kontext und Identitäts- bzw. Kommunikationsketten basieren. Angesichts des beschriebenen Entwicklungstempos ist davon auszugehen, dass die Betreiber ihre Methoden weiter verfeinern werden.
Quelle: https://thehackernews.com/2026/08/cavern-c2-uses-dns-and-google-apps.html
