Une nouvelle famille de logiciels malveillants, baptisée TWINLOOT, attire l’attention par son approche originale : au lieu de communiquer “directement” avec ses serveurs de commande et contrôle, l’implant loge ses échanges au cœur de services Microsoft réputés légitimes. Selon les informations publiées par des chercheurs d’Ontinue, le cadre malveillant TWINLOOT SharePoint Teams utilise notamment SharePoint Online, l’API Microsoft Graph et l’infrastructure de relais de Microsoft Teams pour voler des identifiants et se déplacer d’un poste à l’autre.
L’objectif n’est pas seulement d’exécuter des commandes : l’implant cherche aussi à recueillir des mots de passe via des écrans de verrouillage factices, puis à utiliser ces informations pour opérer une “pivotation” vers d’autres systèmes internes. Le tout avec des mécanismes qui rendent la trace réseau plus difficile à distinguer des activités normales.
Un implant Python modulable et conçu pour passer inaperçu
TWINLOOT est décrit comme un implant Python modulaire, renforcé par des techniques d’obfuscation. Il a été conçu pour faire transiter l’ensemble de son infrastructure de commande et contrôle à travers des services Microsoft “de confiance”. Dans la pratique, ses flux de travail s’appuient sur plusieurs briques : SharePoint Online pour la tâche, Teams pour acheminer l’accès opérateur, et le navigateur Edge de la victime pour véhiculer certains échanges.
Les chercheurs expliquent que les requêtes vers l’API Graph sont portées par une exécution “headless” du navigateur Edge de la cible. Autrement dit, l’implant cherche à produire un trafic difficile à distinguer du comportement habituel d’un navigateur ou d’une application authentifiée.
SharePoint Online comme canal de consignes
Le premier axe de fonctionnement repose sur des “dead drops” (zones de dépôt) dans SharePoint Online. Les ordres à exécuter passent par des fichiers déposés côté SharePoint, consultés via l’API Microsoft Graph. L’implant interroge le stockage selon un rythme régulier : les chercheurs indiquent une vérification toutes les 15 secondes.
De cette manière, l’opérateur peut :
- recevoir des instructions à distance,
- exécuter des actions sur la machine compromise,
- rapatrier des données vers un espace contrôlé par l’attaquant.
Accès interactif via Teams TURN
Le deuxième canal vise un accès plus “manuel”, nécessaire pour piloter la session et faciliter le mouvement latéral. Ici, TWINLOOT s’appuie sur une logique de tunnel inverse de type SOCKS5. L’opérateur obtient un écouteur SOCKS5 sur sa propre machine, puis le trafic est renvoyé à travers le poste infecté.
Selon Ontinue, l’acheminement peut emprunter deux modes : une connexion directe via WebSocket sur TLS vers l’infrastructure de l’attaquant, ou le passage par le relais Teams TURN via des WebRTC DataChannels. Dans les deux cas, le résultat recherché est le même : depuis le réseau interne, les connexions sortent “comme si” elles provenaient d’un hôte compromis, ce qui peut réduire la suspicion.
Un navigateur headless utilisé comme transport
Un point technique central concerne le rôle du navigateur. Pour transporter les échanges liés à l’API Graph, TWINLOOT démarre une instance headless du navigateur Edge de la victime. Les chercheurs indiquent que l’implant exploite cette approche pour rendre les communications quasiment indiscernables d’un trafic légitime.
Autrement dit, au lieu de faire apparaître des flux “nets” propres à un malware, l’implant s’inscrit dans un scénario où les requêtes ressemblent davantage à celles d’un logiciel authentifié utilisant des services Microsoft.
Vol d’identifiants : écrans de verrouillage factices
Pour étendre l’attaque au-delà du premier poste, TWINLOOT inclut une fonctionnalité de récolte de mots de passe. Les chercheurs décrivent l’utilisation d’écrans de verrouillage falsifiés affichés à la demande de l’opérateur. L’écran factice déclenche une procédure de collecte : la commande associée “credz_waiting” provoque l’affichage du leurre.
Le comportement observé est trompeur mais exploitable : si l’utilisateur saisit un mot de passe, il n’est pas validé par rapport à la vraie authentification Windows. Quel que soit ce qui est entré, l’utilisateur voit un message d’erreur de type “mot de passe incorrect. Réessayez”. Cette boucle augmente la probabilité que la victime retente avec la bonne combinaison.
Une fois le mot de passe “capturé”, l’écran de verrouillage factice se ferme automatiquement. Les identifiants sont ensuite :
- chiffrés,
- téléversés via le canal SharePoint,
- puis réinjectés dans le mécanisme de pivot via le tunnel SOCKS5.
Pivoter vers d’autres machines grâce aux protocoles internes
Grâce aux identifiants récupérés, l’implant permet de viser des services internes sur des ports couramment utilisés en environnement Windows. Les chercheurs citent notamment les connexions vers :
- 445 (SMB),
- 3389 (RDP),
- 5985 (WinRM),
- 1433 (MSSQL).
En apparence, du point de vue du réseau, ces connexions peuvent ressembler à une activité normale provenant de l’hôte compromis. L’attaquant utilise ainsi le poste initial comme tremplin.
Persistance : quatre méthodes, dont un contournement via profil obligatoire
Pour rester opérationnel après redémarrage, TWINLOOT met en place de la persistance. Les chercheurs indiquent que la génération peut activer ou non ce mécanisme selon la configuration compilée. Quatre approches sont mentionnées :
- piratage de scriptlet COM de type TypeLib,
- manipulation de cache de tâches de style GhostTask,
- mise à jour à partir d’un manifest reobf.json,
- création furtive de clés de registre dans HKEY_CURRENT_USER via une technique s’appuyant sur l’outil open-source Swarmer.
Le dernier point est particulièrement marquant : au lieu de s’appuyer uniquement sur des clés usuelles, l’implant peut générer une ruche de profil Windows NTUSER.MAN hors ligne, de façon à ce que Windows la privilégie au chargement du profil utilisateur. Les chercheurs précisent l’usage d’API permettant de charger une ruche dans un espace isolé et de fabriquer une hive destinée à être lue par Windows.
Ontinue indique que cette méthode de persistance n’avait, à sa connaissance, pas encore été observée dans la nature.
Techniques similaires : l’essor de l’abus TURN
Les chercheurs ne présentent pas TWINLOOT comme un cas isolé. Ils relient l’évolution à une tendance : des attaquants indépendants adoptent des mécanismes d’abus basés sur des relais TURN pour masquer les échanges de commande et contrôle.
Le rapport rappelle par exemple qu’en juin 2026, un autre acteur (associé à la chaîne de menaces évoquée par Symantec/Carbon Black) avait décrit l’usage du relais TURN dans un RAT lié à un rançongiciel. Plus récemment, un malware reposant sur Rust, nommé msaRAT, aurait lui aussi employé la méthode TURN, mais avec un environnement tourné vers Twilio plutôt que Teams.
Les points communs se retrouvent dans la logique générale : utiliser une architecture où les communications passent par un relais, tout en s’appuyant sur un navigateur contrôlé (ou piloté via des interfaces de débogage) afin de réduire la visibilité du trafic.
Une campagne d’accès initial via ingénierie sociale
Quant à l’amorçage, les informations disponibles indiquent un scénario d’ingénierie sociale via Microsoft Teams. L’attaquant, se faisant passer pour un support informatique, aurait persuadé une cible d’exécuter une commande PowerShell. Cette commande déclenche le téléchargement d’une archive contenant l’environnement Python ainsi qu’un payload compilé d’environ 39 Mo, mentionné comme bootstrap-fat.pyc, qui sert de chargeur.
Ce mode d’accès met en évidence un risque courant dans les attaques ciblées : exploiter la confiance que les équipes portent aux canaux de communication internes, notamment quand l’attaquant se présente avec un rôle plausiblement légitime.
Ce que permet TWINLOOT au-delà du vol de credentials
Les capacités de l’implant ne se limitent pas à la récolte de mots de passe. Les chercheurs indiquent aussi des fonctions de reconnaissance et de découverte, des captures d’écran, ainsi qu’un mécanisme de repli si un dépôt basé sur Azure Blob Storage échoue.
Le rapport mentionne également que la partie liée à une “résolution” basée sur l’Ethereum ne semble pas utilisée dans la version observée, ce qui suggère une évolution en cours du framework.
Conclusion : surveiller les signaux “Microsoft” ne suffit plus
Le cas TWINLOOT met en lumière une réalité préoccupante : des outils malveillants peuvent tirer profit de l’écosystème Microsoft 365 en l’utilisant comme infrastructure d’exécution et de dissimulation. En combinant SharePoint Online pour les consignes, Teams TURN pour l’accès opérateur et un navigateur headless Edge pour le transport, l’implant vise à produire des traces qui ressemblent davantage à des activités légitimes.
Pour les équipes sécurité, l’enjeu est clair : il ne s’agit plus seulement de bloquer des signatures de malware, mais de renforcer la détection des comportements anormaux (relais, accès, exfiltration) même lorsqu’ils s’inscrivent dans des flux attendus vers des services Microsoft. En parallèle, la réduction de l’exposition à l’ingénierie sociale via Teams reste un levier essentiel pour limiter l’amorçage.
Source: https://thehackernews.com/2026/08/twinloot-abuses-sharepoint-and-teams-to.html
