Les chercheurs en cybersécurité observent une nouvelle étape dans l’évolution de Cavern C2, un cadre de commande et contrôle (C2) attribué à des acteurs soutenus par un État. L’enjeu : rendre la communication du malware plus difficile à distinguer d’activités ordinaires sur Internet, en combinant des mécanismes DNS et des services légitimes.
Selon des analyses publiées par Kaspersky et d’autres acteurs de la recherche, le système continue d’étendre ses capacités via des modules ajoutés au fil du temps. La dernière découverte met en lumière une logique de routage qui s’appuie sur des réponses d’enregistrements DNS de type A, puis alterne entre une communication en HTTPS direct et un relais utilisant Google Apps Script.
Une approche modulaire pour réduire la visibilité
Au cœur du dispositif, Cavern C2 fonctionne comme une architecture modulaire. Des composants de type “agent” et des modules spécialisés coopèrent pour fournir des fonctions post-exploitation adaptées aux objectifs de l’attaque. Cette conception vise notamment à limiter la trace laissée lors des opérations et à maintenir un accès durable.
Les capacités observées incluent des actions sur fichiers, l’énumération de bases de données SQL, la reconnaissance de l’environnement Active Directory, ainsi que des scénarios de force brute liés à LDAP. Le cadre peut aussi effectuer de la reconnaissance réseau et proposer des mécanismes de tunnel via SOCKS5 et WebSocket. En pratique, cette variété de modules permet à l’opérateur d’ajuster le comportement du malware plutôt que de suivre un schéma unique et facilement détectable.
DNS comme interrupteur : HTTPS direct ou relais Google
La nouveauté décrite par Kaspersky concerne un module de communication conçu pour choisir le mode de transmission à chaque transaction. L’idée est simple : exploiter des réponses DNS pour sélectionner dynamiquement la manière d’émettre les requêtes.
D’après l’analyse, le module interroge un enregistrement DNS A afin de décider :
- soit d’effectuer une communication HTTPS directe vers l’adresse configurée,
- soit d’utiliser un relai via Google Apps Script pour faire transiter les requêtes.
Ce système s’insère dans une stratégie plus large d’évasion : plutôt que d’attirer l’attention avec une communication réseau “typique” d’un C2, le malware s’appuie sur des briques qui peuvent paraître banales. Le DNS devient alors un élément central pour piloter le flux, tout en restant cohérent avec des usages Internet courants.
Le rapport indique aussi que la même infrastructure DNS peut servir à valider et remplacer un identifiant de déploiement lié au relais. Concrètement, cela permettrait à l’opérateur de faire évoluer le “canal Google” sans modifier l’ensemble du dispositif.
Google Apps Script pour masquer la chaîne d’acheminement
Lorsque le mode “Google” est sélectionné, le module envoie des requêtes vers le déploiement Apps Script. Celui-ci relaie ensuite les demandes vers un backend contrôlé par l’acteur malveillant.
À l’inverse, si le DNS indique l’option HTTPS directe, le malware contacte l’adresse configurée sans recourir au relais. Cette dualité donne au cadre de commande une flexibilité opérationnelle : il peut s’adapter à la situation réseau, aux contraintes, ou encore aux contrôles de sécurité en vigueur.
Dans l’ensemble, la logique recherchée par Cavern C2 reste la même : faire en sorte que la communication ressemble davantage à des échanges légitimes, réduisant le risque d’une détection basée uniquement sur des schémas de trafic.
Des intermédiaires internes pour charger, router et mettre à jour
Les chercheurs mentionnent également l’existence d’un composant jouant le rôle de “courtier” entre les parties du framework. Ce composant local aide à découvrir et charger des DLL, à router les messages entre les modules, et à supporter des mises à jour en exécution.
Cette couche interne renforce la modularité du système : au lieu de figer le comportement dans une seule base de code, Cavern C2 peut évoluer en ajoutant ou en remplaçant des briques fonctionnelles. L’ensemble est cohérent avec l’idée d’une architecture conçue pour durer et s’étendre au fil du temps.
Enfin, l’observation d’un domaine associé à l’activité, d’abord enregistré puis expiré puis réenregistré quelques mois plus tard, illustre aussi la volonté d’ajuster les éléments liés à la stratégie de déploiement.
Quand Microsoft 365 devient un canal de commande
Au-delà du module DNS/Google, d’autres rapports de suivi décrivent une extension différente du cadre : HOLLOWGRAPH. Cette fonctionnalité transforme des événements de calendrier Microsoft 365 en vecteurs de commande et d’exfiltration.
Le mécanisme exploite l’interface Microsoft Graph. L’implant considère le calendrier de la boîte aux lettres compromise comme un “point de dépôt” bidirectionnel : l’opérateur dépose des tâches sous forme d’événements, puis le code malveillant exfiltre des fichiers en créant à son tour des événements contenant des données chiffrées en pièces jointes.
Pour limiter les soupçons, les événements observés sont datés très loin dans le futur, autour du 13 mai 2050. L’objectif est d’éviter d’attirer l’attention de la personne victime, qui pourrait autrement repérer des invitations ou notifications incohérentes.
En parallèle, le même type de logique d’évasion s’appuie sur le tunneling DNS afin de rafraîchir des informations d’authentification nécessaires à l’accès à Microsoft Graph, notamment via des éléments liés à Microsoft Entra ID.
Ce que ces évolutions disent de l’intention des attaquants
Pris ensemble, ces éléments montrent une évolution continue du framework. Cavern C2 se dote de modules de communication capables de s’insérer dans des environnements et services légitimes : DNS pour piloter, Google Apps Script pour relayer, Microsoft 365 pour servir de canal applicatif.
Cette stratégie complexifie la détection fondée uniquement sur des contrôles “périmètre”. Les échanges malveillants peuvent sembler plus proches d’un trafic normal, notamment lorsqu’ils passent par des plateformes fréquemment utilisées par des organisations.
Les analyses citées soulignent que, compte tenu de la cadence de développement, de la conception modulaire et du rythme opérationnel, le cadre a de bonnes chances de continuer à s’étendre.
Conclusion
La dernière découverte autour de Cavern C2 illustre une tendance nette : s’appuyer sur des composants et services réputés “légitimes” pour masquer les communications d’un C2. En utilisant des requêtes DNS pour choisir entre HTTPS direct et relais via Google Apps Script, le malware rend ses échanges plus dynamiques et plus difficiles à distinguer d’un usage normal.
Ajoutez à cela l’usage de calendriers Microsoft 365 comme canal de commande et d’exfiltration, et l’on obtient un ensemble cohérent : une infrastructure adaptative, pensée pour évoluer, maintenir l’accès et contourner les mécanismes de détection traditionnels.
Source: https://thehackernews.com/2026/08/cavern-c2-uses-dns-and-google-apps.html
