TwinLoot transforme Microsoft 365 en centre de commande pour attaquer les réseaux d’entreprise

Un framework Python hébergé dans le cloud Microsoft

Les chercheurs de l’Ontinue Cyber Defense Center ont identifié TwinLoot, un framework malveillant modulaire écrit en Python qui transpose le modèle living off the land au cloud. Le système ne se contente pas d’utiliser les outils déjà présents sous Windows : il met en place son infrastructure de commande et de contrôle en détournant des services légitimes de Microsoft Azure et Microsoft 365.

La campagne était toujours active en juillet, lorsque les modules du malware ont été récupérés. L’activité a été détectée le 18 août 2026.

TwinLoot utilise SharePoint Online et les API Microsoft Graph pour échanger des commandes et des données, Microsoft Teams pour obtenir un accès interactif et Microsoft Edge pour rendre plus crédibles les communications générées depuis l’appareil compromis. Le trafic peut ainsi se fondre dans les activités habituelles des utilisateurs et des applications d’entreprise.

Les modules Python étaient protégés par PyArmor 9.2.5. Après déchiffrement de la configuration intégrée, les chercheurs ont découvert une architecture composée de plusieurs canaux opérationnels, conçus pour réduire la visibilité de l’attaquant et maintenir son contrôle après la compromission initiale.

SharePoint, Graph et Teams deviennent l’infrastructure C2

Le composant de commande et de contrôle utilise SharePoint Online comme point d’échange, selon le modèle du dead drop : l’attaquant dépose des commandes ou des données dans un espace cloud, puis le malware les récupère via des API Microsoft légitimes.

Les API Microsoft Graph jouent le rôle de canal applicatif. Au lieu de se connecter à un serveur suspect ou à un domaine de mauvaise réputation, TwinLoot interagit avec une infrastructure largement présente sur les réseaux d’entreprise.

Le framework intègre également l’infrastructure de relais TURN de Microsoft Teams. Cette technologie, normalement destinée à faciliter les communications interactives, est détournée pour maintenir une connexion opérationnelle avec le système infecté. Il en résulte un canal susceptible de se confondre avec le trafic généré par Teams, en particulier lorsque l’analyse ne met pas en corrélation les identités, les terminaux et les activités cloud.

Microsoft Edge contribue à dissimuler davantage les requêtes adressées aux API Graph. Le navigateur installé sur l’appareil de la victime sert à transporter les communications, tandis que l’automatisation du navigateur et l’utilisation éventuelle de composants headless compliquent la distinction entre une activité malveillante et celle d’une application d’entreprise.

Selon l’évaluation des chercheurs, TwinLoot est le premier framework qu’ils ont observé à réunir dans une même architecture le dead drop sur Microsoft 365, l’abus du relais TURN de Teams et le transport via navigateur.

Capacités : vol d’identifiants, exécution de commandes et pivot dans le réseau interne

TwinLoot comprend un module de vol des identifiants Windows. Le malware affiche un faux écran de verrouillage conçu pour ressembler à celui du système d’exploitation et demande à l’utilisateur de saisir son mot de passe.

La collecte a également lieu lorsque la tentative échoue. En cas d’identifiant erroné, la victime voit s’afficher un message correspondant à une erreur d’authentification classique et peut réessayer. Si la saisie suivante réussit, le comportement anormal peut passer inaperçu.

Cette logique permet de récupérer des mots de passe sans nécessairement produire de signaux facilement perceptibles par l’utilisateur. Les demandes d’authentification inattendues ou les écrans de verrouillage apparus en dehors du flux habituel doivent donc être vérifiés, surtout s’ils se répètent.

Le framework permet également d’exécuter des commandes arbitraires sur le système compromis. L’attaquant peut ainsi recueillir des informations, modifier le comportement du terminal et préparer d’autres opérations.

Le composant le plus important pour le mouvement latéral est un proxy interactif SOCKS5. Celui-ci achemine le trafic via le processus infecté et peut permettre d’atteindre des ressources du réseau interne qui ne sont pas directement exposées sur Internet. Un seul ordinateur compromis devient ainsi un point de pivot pour la reconnaissance, l’accès à d’autres systèmes et l’interaction avec des services d’entreprise.

Persistance sans privilèges administrateur

TwinLoot utilise également une technique de persistance baptisée par les chercheurs « Corrupting the Hive Mind ». Cette méthode crée hors ligne une ruche de profil obligatoire, ou mandatory profile hive, à l’aide d’API Windows légitimes.

La technique ne nécessite pas de privilèges administrateur et ne modifie pas directement le Registre lors de l’installation. Elle peut donc ne pas générer les événements habituellement associés à une modification du Registre ou à une opération d’élévation de privilèges.

Cela réduit l’efficacité de certaines règles de détection traditionnelles. Une organisation qui recherche uniquement les clés de Registre modifiées, les processus administratifs ou les activités exécutées avec des privilèges élevés pourrait ne pas détecter cette persistance.

Ontinue décrit ce comportement comme la première utilisation malveillante de cette méthode observée dans le cadre d’activités réelles. La persistance s’appuie sur des fonctionnalités natives du système d’exploitation et laisse une empreinte opérationnelle plus discrète que les techniques fondées sur des modifications visibles de la configuration.

Une préparation minutieuse, mais une attribution encore incertaine

L’architecture observée témoigne d’une préparation étalée sur sept semaines. Avant son utilisation opérationnelle, deux domaines expirés, une application Azure AD dédiée et un site SharePoint destiné à servir de dead drop auraient été préparés.

Un outil présenté initialement lors d’une conférence technologique a également été intégré au framework Python. Les domaines avaient été préparés plusieurs semaines avant le reste de l’infrastructure.

L’opération n’a pas été attribuée à un groupe précis. Le niveau d’intégration entre sécurité offensive, Python, identités cloud et services Microsoft rend plausible l’implication d’un opérateur professionnel ou d’un développeur possédant une expertise avancée de l’écosystème Azure et Microsoft 365.

Les versions des produits Microsoft concernés n’ont pas été communiquées, pas plus que les adresses IP, les domaines utilisés, les hachages ou d’autres indicateurs précis. Aucun identifiant CVE, score CVSS ou référencement dans le catalogue KEV de la CISA n’a été signalé ; aucune date d’ajout ni échéance de remédiation KEV n’est donc disponible.

Rechercher TwinLoot sans se fier uniquement aux indicateurs

Le trafic vers Microsoft 365 ne doit pas être considéré comme fiable par défaut. La défense doit se concentrer sur les écarts par rapport au comportement attendu des utilisateurs, des appareils, des applications et des services.

Les organisations devraient établir des bases de référence pour SharePoint, Teams et les API Graph, en tenant compte des volumes, de la fréquence, des horaires, des destinations et des modes d’accès. Des séquences inhabituelles d’appels Graph, surtout lorsqu’elles sont associées à un compte ou à un appareil qui n’en effectue habituellement pas, doivent faire l’objet d’une investigation.

Il est également nécessaire de contrôler les applications OAuth et les consentements accordés dans Azure AD. Des applications inattendues, des autorisations disproportionnées ou de nouvelles intégrations avec SharePoint et Graph peuvent révéler la préparation du canal C2.

La télémétrie de SharePoint et de Teams doit être corrélée avec celle des terminaux. Les sites, fichiers, sessions de relais et flux de communication inhabituels prennent surtout leur sens lorsqu’ils coïncident avec une utilisation atypique d’Edge, l’automatisation d’un navigateur, des scripts Python ou des modules protégés par PyArmor.

Les règles de détection doivent également couvrir les demandes d’authentification répétées, les écrans de verrouillage inattendus et les tentatives d’accès échouées suivies d’une authentification réussie. Dans le cas de TwinLoot, l’erreur saisie par l’utilisateur peut déjà avoir été collectée.

Enfin, il convient de rechercher les signaux compatibles avec un proxy SOCKS5, les connexions interactives non prévues et les accès à des ressources internes depuis des terminaux qui n’effectuent normalement aucune tâche d’administration ou de pivot. La corrélation entre les identités, le cloud et les terminaux est essentielle : analyser séparément ces trois niveaux laisse de larges possibilités à l’attaquant.