Cavern choisit son canal de commande par une requête DNS et se fond dans Google Apps Script et les calendriers Microsoft 365

Début juillet 2026. Check Point Research documente publiquement Cavern (aussi écrit Cav3rn), un framework de commande et de contrôle (command-and-control, C2) utilisé dans des attaques contre des entités israéliennes. Décembre 2025. Kaspersky commence à suivre le même groupe d’activité. 17 août 2026. L’éditeur publie une analyse qui révèle un module inédit : le malware interroge le DNS à chaque transaction pour choisir entre un canal HTTPS direct et un relais Google Apps Script.

L’information compte pour une raison précise. Un C2 qui se déplace en DNS et se fait héberger par les services légitimes de Google et de Microsoft ne laisse plus d’infrastructure dédiée à bloquer. La détection par liste noire d’indicateurs — domaines, adresses IP — perd une partie de sa prise.

Un framework qui ne ressemble plus à un C2

Cavern est décrit comme un assemblage de plusieurs pièces mobiles : un Agent et un assortiment de modules qui travaillent de concert pour l’exploitation post-compromission, tout en minimisant la visibilité forensique et en assurant un accès persistant.

Les modules documentés couvrent les opérations sur fichiers, l’énumération de bases SQL, la reconnaissance Active Directory, le brute-force LDAP, la reconnaissance réseau, ainsi que des tunnels SOCKS5 et WebSocket. Autrement dit, une boîte à outils d’espionnage complète. Kaspersky la rattache à Cavern Manticore, un groupe affilié au ministère iranien du Renseignement (MOIS), qui partage des recoupements avec MuddyWater et avec le sous-groupe d’OilRig connu sous le nom de Lyceum.

Ce qui change, c’est l’architecture. Kaspersky situe le basculement vers une conception modulaire et extensible à plugins vers fin avril 2026, et la relie à OilRig (APT34) avec une confiance faible. Sans réutilisation de code ni chevauchement d’infrastructure, mais sur la base d’indices concordants : l’usage de services hébergés par Microsoft pour le C2, la présence d’un mécanisme de secours pour obtenir des jetons OAuth de remplacement, et l’emploi d’infrastructures compromises appartenant à des entités des régions visées.

Le DNS comme aiguillage

Le cœur de la nouvelle publication tient en un module : GoogleService.dll. Il lit un fichier de configuration sur disque — conf.json — puis effectue une requête DNS de type A pour décider, pour chaque transaction, s’il passe par un canal HTTPS direct ou par un relais Google Apps Script.

Le détail technique a son importance. En mode Google, le module envoie ses requêtes au déploiement Apps Script, qui les transmet au serveur contrôlé par l’attaquant. En mode HTTPS direct, il contacte l’adresse configurée sans passer par le relais. Et la même infrastructure DNS peut valider et remplacer l’identifiant du déploiement du relais — ce qui permet à l’opérateur de faire tourner son canal Google à volonté.

C’est exactement le schéma qui neutralise une défense fondée sur le blocage de domaines. Le domaine principal associé à l’activité, studiotikva[.]com, a été enregistré en février 2024, a expiré en février 2026, puis a été ré-enregistré trois mois plus tard. Pendant les trous, le relais Google continue de faire le travail, et l’opérateur n’a qu’à mettre à jour un enregistrement DNS pour changer d’adresse de repli.

Un second composant, rnp.dll, joue le rôle de courtier inter-composants : il découvre et charge les DLL, route les messages entre modules et prend en charge les mises à niveau à chaud. L’ensemble forme une plateforme que son auteur peut étendre sans tout redéployer.

HOLLOWGRAPH, ou le calendrier comme boîte morte

Deux rapports successifs de Group-IB et Kaspersky documentent un module distinct, HOLLOWGRAPH, qui abuse de l’API Microsoft Graph pour transformer le calendrier Microsoft 365 d’une boîte aux lettres compromise en boîte morte bidirectionnelle (dead-drop).

Le principe est simple. L’implant traite le calendrier de la victime comme un point de dépôt : les opérateurs y déposent leurs instructions sous forme d’événements, et l’implant exfiltre les fichiers volés en créant ses propres événements, avec des pièces jointes chiffrées. Pour ne pas attirer l’attention du propriétaire de la boîte, chaque événement est daté très loin dans le futur — le 13 mai 2050 — avec la charge utile attachée en fichier.

En parallèle, le malware utilise le tunneling DNS pour rafraîchir les identifiants Microsoft Entra ID (ex-Azure AD) qui servent à s’authentifier auprès de l’API Graph, puis écrit les nouvelles valeurs dans un fichier texte sur le disque. HOLLOWGRAPH, compilé en .NET NativeAOT, a été détecté pour la première fois dans la nature le 7 juin 2026.

La leçon est la même que pour GoogleService.dll : le trafic de commande ressemble à s’y méprendre à de l’activité légitime d’un utilisateur qui consulte son agenda.

Cette convergence n’est pas un cas isolé. La même publication de DarkAtlas documente le retour d’APT42 avec TAMECAT, un framework de surveillance modulaire déployé via des fichiers LNK déguisés en PDF lors de campagnes d’hameçonnage ciblant le secteur de l’énergie nucléaire, observées jusqu’en mai 2026. Le groupe iranien accélère par ailleurs ses opérations avec de l’IA générative : développement d’outillage spécialisé, traduction, recherche de techniques d’exploitation, identification d’adresses officielles. Le tableau d’ensemble est cohérent : les acteurs étatiques iraniens industrialisent l’abus des services légitimes et de l’automatisation, ce qui érode un peu plus la détection fondée sur les seuls indicateurs.

Ce que cela change pour la détection réseau

Le point que Kaspersky formule explicitement mérite d’être cité : en abusant de services légitimes — hier les événements de calendrier Outlook, aujourd’hui Google Apps Script — le framework mélange son trafic C2 au trafic normal de l’entreprise, ce qui complique la détection réseau.

Pour un RSSI ou un SOC, cela déplace le curseur. Les indicateurs de compromission (IoC) restent utiles pour corréler une fois l’attaque documentée, mais ils arrivent après coup. Ce qu’il faut surveiller en amont, ce sont les comportements :

• des requêtes DNS inhabituelles vers des domaines à faible réputation, ou des réponses A-record qui pilotent un choix de canal ;
• du trafic HTTPS sortant vers des déploiements Google Apps Script ou des points de terminaison Microsoft Graph non standards ;
• des événements de calendrier créés en masse, datés dans un futur lointain, ou porteurs de pièces jointes inhabituelles ;
• l’apparition de DLL inconnues et de fichiers de configuration (conf.json) sur des postes de travail.

La réponse technique passe moins par un nouvel outil que par une posture : journaliser et corréler le DNS résolu en interne, et traiter les abus de services cloud légitimes comme un signal de première classe plutôt qu’un bruit de fond.

Verdict

Si vous opérez un SOC qui s’appuie encore sur des listes noires d’IoC, l’affaire Cavern est un argument pour rééquilibrer vos budgets vers la détection comportementale : requêtes DNS anormales, tunnels sur services légitimes, événements de calendrier suspects. Le framework change de canal et d’hébergeur plus vite que vos listes ne se mettent à jour.

Si vous êtes dans une organisation ciblée par des acteurs étatiques — secteur public, défense, énergie, télécoms — traitez l’abus de Microsoft 365 et de Google Workspace comme un vecteur C2 plausible, et passez en revue vos journaux DNS ainsi que vos applications Apps Script déployées.

Le signal de fond : les C2 de niveau étatique n’ont plus besoin d’infrastructure dédiée. Ils empruntent les canaux que votre politique de sécurité autorise par défaut. La détection doit suivre le même chemin — du domaine vers le comportement.

Références

• The Hacker News — Cavern C2 Uses DNS and Google Apps Script to Blend Into Legitimate Traffic, 17 août 2026
• Kaspersky Securelist — Project Cav3rn continues: Google Apps Script relay and modular upgrades, consulté le 18 août 2026
• Group-IB — HOLLOWGRAPH abuses Microsoft 365 calendars as a C2 dead-drop, consulté le 18 août 2026
• Kaspersky Securelist — Project Cav3rn: cyberespionage framework using Outlook and DNS, consulté le 18 août 2026