En bref

  • HOLLOWGRAPH est un implant Windows .NET qui utilise la Microsoft Graph API pour dissimuler son canal C2 dans des événements de calendrier Microsoft 365 datés en 2050, invisibles pour l'utilisateur.
  • Découvert par Group-IB, le malware a infecté 12 systèmes ciblant des entités israéliennes depuis le 3 juin 2026, avec un lien de haute confiance au framework Cavern.
  • La détection exige une surveillance spécifique des accès Microsoft Graph API sur les ressources de calendrier — hors portée de la plupart des EDR traditionnels.

Un agenda Microsoft 365 transformé en infrastructure d'espionnage

Parmi les techniques d'évasion les plus redoutables en matière de malware, l'abus de services cloud légitimes comme canal de commande et contrôle occupe une place de choix. Utiliser l'infrastructure d'un éditeur de confiance comme Microsoft comme relais C2 présente un avantage décisif pour l'attaquant : le trafic réseau généré est indiscernable du trafic professionnel légitime, et les outils de filtrage réseau traditionnels ne peuvent le bloquer sans interrompre l'activité de l'entreprise. HOLLOWGRAPH, le malware analysé par Group-IB en juillet 2026, pousse cette technique à un niveau de sophistication supérieur en choisissant les événements de calendrier Microsoft 365 comme support de communication, un vecteur jusqu'ici largement inexploré.

HOLLOWGRAPH est un implant Windows compilé en .NET NativeAOT, un format de compilation qui génère du code natif et rend l'analyse par décompilation significativement plus difficile qu'un assembly .NET standard. Le malware se présente sous forme de DLL et ne supporte que deux commandes opérationnelles : get et send. Cette minimalité fonctionnelle est délibérée : elle réduit la surface de détection comportementale tout en assurant les fonctions essentielles d'un implant de reconnaissance — exfiltration de fichiers depuis la machine compromise via la commande send, et réception de nouvelles instructions depuis l'opérateur via la commande get.

Le mécanisme C2 est le cœur de l'ingéniosité de HOLLOWGRAPH. Pour recevoir ses instructions, le malware interroge via la Microsoft Graph API un événement de calendrier que l'opérateur a préalablement créé dans une boîte aux lettres Exchange compromise. L'événement est délibérément planifié à une date impossible à atteindre en navigation calendaire normale : le 13 mai 2050. À cette date, les instructions pour l'implant sont encodées dans une pièce jointe de l'événement. La probabilité qu'un utilisateur humain scrolle jusqu'à cette date dans son calendrier, et remarque un événement suspect, est pratiquement nulle, conférant à ce mécanisme une durabilité remarquable dans les environnements compromis.

Le schéma de chiffrement des communications combine RSA et AES-256-GCM. Les instructions reçues et les données exfiltrées sont chiffrées avec AES-256-GCM, et la clé AES est elle-même chiffrée avec la clé publique RSA de l'opérateur intégrée dans l'implant. Ce schéma hybride standard garantit la confidentialité des communications même si le trafic Microsoft Graph est intercepté ou logué par des outils de surveillance réseau intermédiaires. Pour l'exfiltration, le malware utilise la même infrastructure : les fichiers volés sont encodés et attachés à des événements de calendrier que l'opérateur récupère depuis son tenant Microsoft contrôlé.

Un mécanisme annexe de communication utilise le DNS tunneling pour le rafraîchissement des tokens d'authentification OAuth utilisés pour accéder à la Microsoft Graph API. Cette couche supplémentaire ajoute de la résilience : si les communications Graph API sont temporairement bloquées ou si le token expire, l'implant peut renouveler ses credentials via des requêtes DNS, un protocole que rares sont les organisations à filtrer ou surveiller de manière granulaire. La combinaison de ces deux canaux, Graph API pour les communications principales et DNS tunneling pour la gestion des credentials, constitue une architecture C2 redoutablement résiliente et difficile à couper sans impacter les activités légitimes.

La découverte de HOLLOWGRAPH a été réalisée par les chercheurs de Group-IB lors de l'investigation d'un incident dans une organisation israélienne. L'analyse des artefacts et des IOCs a permis d'identifier 12 systèmes infectés, avec les premières communications observées le 3 juin 2026. Les chercheurs ont établi avec un niveau de confiance élevé un lien entre HOLLOWGRAPH et le framework de backdoor Cavern, un outil précédemment associé à des opérations d'espionnage ciblées dans la région Moyen-Orient. La nature hautement ciblée de la campagne, limitée à des entités israéliennes spécifiques, suggère un acteur de type APT à motivation géopolitique plutôt qu'un groupe à motivation financière.

Sur le plan de la détection, HOLLOWGRAPH présente un défi particulier pour les équipes de sécurité. Le trafic vers les endpoints de la Microsoft Graph API est par définition légitime dans tout environnement Microsoft 365, et bloquer ces communications reviendrait à désactiver des centaines d'applications cloud d'entreprise. Les solutions EDR traditionnelles qui s'appuient sur la détection de comportements réseau suspects peinent à distinguer un implant communiquant via Graph API d'un client Outlook, Teams ou SharePoint standard. La détection requiert une approche complémentaire : surveillance fine des modèles d'accès à la Graph API au niveau applicatif, notamment les patterns d'accès aux ressources de calendrier depuis des processus inhabituels ou non enregistrés comme applications Microsoft 365 légitimes.

L'analyse de l'implant révèle également un soin particulier apporté à la persistance sur les systèmes Windows. HOLLOWGRAPH utilise des mécanismes de persistance implémentés avec précaution pour éviter les patterns détectables par les solutions de monitoring de registre. Le malware s'appuie sur des DLL chargées dans des processus légitimes, rendant son identification dans les listes de processus difficile sans une analyse approfondie des modules injectés. L'ensemble de ces caractéristiques, compilation NativeAOT, C2 via Graph API, chiffrement hybride, persistance discrète, témoigne d'un niveau d'investissement en développement significatif et d'une équipe technique hautement qualifiée.

Living Off Trusted Sites : la tendance de fond qui redéfinit la détection

HOLLOWGRAPH s'inscrit dans une tendance lourde de l'évolution des techniques APT : le « Living Off Trusted Sites » (LOTS), par analogie avec le « Living Off the Land » (LOTL) qui consiste à utiliser des outils légitimes déjà présents sur les systèmes cibles. Le LOTS consiste à utiliser des services cloud légitimes, stockage, messagerie, calendriers, dépôts de code, comme relais pour les communications malveillantes. GitHub, OneDrive, Google Drive, Telegram et désormais les calendriers Microsoft 365 ont tous été documentés comme vecteurs C2 ces dernières années. HOLLOWGRAPH représente l'une des implémentations les plus sophistiquées de cette approche, notamment par le choix du calendrier et par le recours à une date de 2050 comme mécanisme de dissimulation.

Pour les organisations utilisant Microsoft 365, c'est-à-dire la grande majorité des entreprises mondiales, la découverte de HOLLOWGRAPH illustre une réalité inconfortable : l'infrastructure cloud de productivité est désormais un terrain de jeu pour les attaquants sophistiqués. Les équipes de sécurité ne peuvent plus se contenter de surveiller le périmètre réseau ou les endpoints classiques ; elles doivent étendre leur monitoring aux plans de données des services SaaS eux-mêmes. Microsoft Sentinel, les APIs de log de Microsoft 365, Defender for Cloud Apps et les outils de CASB deviennent des composantes essentielles de la détection dans ce contexte élargi.

L'attribution à Cavern et le ciblage d'entités israéliennes placent HOLLOWGRAPH dans le contexte des opérations d'espionnage étatiques ou para-étatiques qui ciblent le Moyen-Orient. Plusieurs groupes APT régionaux ont ces dernières années développé des capacités sophistiquées d'espionnage cyber, tirant parti de la prolifération des outils offensifs commerciaux et open source. La sophistication technique de HOLLOWGRAPH suggère un investissement en développement significatif. Il convient néanmoins de noter que des techniques similaires pourraient être réutilisées par d'autres acteurs ayant accès à ces méthodes, élargissant potentiellement la menace au-delà du contexte géopolitique actuel.

Pour les équipes de sécurité, la leçon principale est celle-ci : dans un monde où l'ensemble des communications professionnelles transite par des services cloud, la confiance implicite accordée à ces services par les outils de sécurité traditionnels constitue une vulnérabilité structurelle. Les solutions EDR doivent être complétées par des capacités de surveillance du plan de données SaaS, et les logs Microsoft 365, notamment l'Unified Audit Log, doivent être intégrés dans les SIEM et analysés avec le même niveau d'attention que les logs systèmes et réseau traditionnels.

Ce qu'il faut retenir

  • Activer et centraliser les logs d'audit Microsoft 365 (Unified Audit Log) dans votre SIEM, et créer des alertes sur les accès à la Graph API depuis des processus ou applications non enregistrés.
  • Surveiller les accès aux ressources de calendrier via la Graph API, notamment les lectures d'événements à des dates très éloignées (post-2040) qui constituent un indicateur spécifique à HOLLOWGRAPH.
  • Les EDR seuls ne suffisent plus face aux techniques LOTS : l'extension du monitoring au plan de données SaaS est devenue une nécessité opérationnelle.

Comment détecter HOLLOWGRAPH dans mon environnement Microsoft 365 ?

Recherchez dans l'Unified Audit Log de Microsoft 365 des accès aux opérations CalendarRead ou CalendarWrite via la Graph API initiés par des applications inconnues ou non enregistrées dans votre tenant. Des accès à des événements de calendrier planifiés à des dates très éloignées, autour de 2050, constituent un indicateur comportemental spécifique à HOLLOWGRAPH. Côté endpoint, recherchez des DLL inconnues chargées dans des processus Windows légitimes avec des connexions sortantes vers graph.microsoft.com. Les IOCs publiés par Group-IB doivent être immédiatement intégrés dans les règles de détection de votre SIEM et de vos solutions EDR.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact