Le Groupe de Renseignement sur les Menaces de Google et Mandiant ont révélé le 22 avril les détails d'une attaque qui n'a exploité aucune vulnérabilité technique. Le groupe UNC6692 n'a piraté aucun serveur — il a simplement convaincu les employés d'ouvrir les portes d'eux-mêmes.
D'abord la panique, puis l'« aide »
Fin décembre 2025, les entreprises ciblées ont reçu un spam massif par email : les boîtes de réception des employés ont littéralement été bloquées par des milliers de messages. Pendant que la victime cherchait une issue au chaos, un message apparaissait dans Microsoft Teams d'un « collègue du support informatique » — proposant d'installer un correctif qui « arrêterait le spam ».
Le détail critique, facile à manquer : le message provenait d'un compte externe. Teams autorise par défaut ces contacts — et la plupart des employés ne remarquent pas l'indication « External ».
« UNC6692 s'est appuyée sur l'imitation des employés du helpdesk informatique, convainquant les victimes d'accepter des invitations de chat dans Teams à partir d'un compte en dehors de l'organisation ».
— Les chercheurs de Mandiant, JP Glab, Tufail Ahmed, Josh Kelley et Muhammad Umair
SNOW : pas un seul outil, mais une chaîne de montage
Le clic sur le lien menait à une fausse page « Mailbox Repair and Sync Utility » — et uniquement dans le navigateur Microsoft Edge (la page forçait le basculement vers celui-ci via un schéma URI). En cliquant sur le bouton « Health Check », on récupérait les identifiants de connexion et les envoyait vers un bucket S3 des attaquants.
Une fois entrés, un système modulaire de malveillance SNOW se déployait :
- SNOWBELT — extension malveillante pour navigateur Chromium, canal de porte dérobée permanent ;
- SNOWGLAZE — tuneleur Python construisant un pont WebSocket chiffré entre le réseau de la victime et le serveur C2 des attaquants ;
- SNOWBASIN — porte dérobée persistante avec la capacité d'exécuter des commandes via PowerShell, de capturer des captures d'écran et de télécharger des fichiers.
Après s'être implantés dans le système, les attaquants scannaient le réseau interne sur les ports 135, 445 et 3389, effectuaient un vidage de la mémoire du processus LSASS et extrayaient les fichiers NTDS.dit — essentiellement l'intégralité de la base de données des comptes Active Directory.
77 % des victimes — des cadres supérieurs
Selon les chercheurs, entre le 1er mars et le 1er avril 2026, environ 77 % des incidents enregistrés visaient des cadres supérieurs et des employés de haut niveau. La logique est simple : ce sont eux qui ont l'accès le plus large aux systèmes sensibles et le moins de temps pour vérifier chaque demande d'un « département informatique ».
La tactique du bombardement par email suivi d'une « aide » via Teams n'est pas nouvelle. Comme l'indique TechJuice, cette approche a été activement utilisée par les affiliés du groupe Black Basta, qui a cessé ses activités début 2025. UNC6692 a soit emprunté la méthode, soit en a hérité d'anciens participants.
Microsoft a corrigé — mais pas partout et pas automatiquement
En janvier 2026, Microsoft a lancé la capacité de bloquer les utilisateurs externes de Teams directement via le portail Defender, unifiant la gestion des accès dans une seule interface Tenant Allow/Block List. Auparavant, les administrateurs devaient basculer entre plusieurs panneaux de contrôle.
Le problème est que cette fonction n'est pas activée automatiquement : il faut Defender for Office 365 Plan 1 ou Plan 2, ainsi qu'une configuration séparée dans Teams Admin Center. Selon les estimations de Microsoft, plus de 320 millions de personnes utilisent Teams chaque mois — et une part importante de leurs organisations n'a toujours pas modifié les paramètres par défaut.
L'attaque d'UNC6692 n'a exploité aucune vulnérabilité technique — seulement le fait que Teams est ouvert aux contacts externes et que les employés font confiance aux messages dans un chat d'entreprise « sécurisé ». Si votre organisation n'a toujours pas limité les demandes externes dans Teams et n'a pas activé le blocage via Defender, la question n'est pas « si cela peut se produire », mais — quand exactement ce « technicien du support » arrivera-t-il ?
