Spring Ring, le vishing sur Microsoft Teams qui vise le contrôle du domaine Windows

Un faux technicien du help desk ouvre une conversation sur Microsoft Teams, appelle la victime et la guide dans l’installation d’outils d’accès à distance. Derrière cette assistance simulée se trouve toutefois une opération offensive susceptible d’aller jusqu’au domain controller.

La campagne, baptisée Spring Ring par Palo Alto Networks et révélée le 2 septembre 2026, a ciblé au moins 150 utilisateurs appartenant à au moins 10 organisations. L’activité observée s’est déroulée entre janvier et avril.

Les attaquants ont combiné ingénierie sociale, logiciels légitimes d’assistance à distance, payloads PowerShell et techniques de relay NTLM. Dans le vecteur le plus avancé, ils ont tenté de contraindre un domain controller à s’authentifier auprès d’une infrastructure sous leur contrôle.

Le faux help desk s’invite directement dans Teams

L’attaque commence dans Microsoft Teams, une plateforme que de nombreux employés associent spontanément à des communications professionnelles fiables. Les attaquants créent des conversations en utilisant des noms affichés évoquant le help desk, le support informatique ou le personnel d’assistance.

La conversation est suivie d’un appel vocal. Le passage à la voix permet au faux technicien d’exercer une pression en temps réel, de répondre aux hésitations et d’accompagner la victime dans une séquence précise d’actions.

Les appels qui aboutissent durent généralement entre 10 et 15 minutes. Les opérateurs font également preuve de persévérance : ils répètent leurs tentatives de contact et, si nécessaire, laissent des messages vocaux.

L’objectif n’est pas de convaincre l’utilisateur d’effectuer un simple clic. La victime est amenée à exécuter des programmes, à installer des outils d’administration à distance ou à ouvrir des fichiers préparés spécialement pour son organisation.

Il s’agit d’un changement important par rapport au phishing traditionnel. L’employé ne doit plus seulement évaluer un message statique, mais prendre des décisions au cours d’un échange avec une personne qui se présente comme un collègue autorisé.

Selon un rapport de threat hunting de CrowdStrike cité dans l’analyse de la campagne, les attaques de vishing auraient doublé au premier semestre 2026. Cette donnée ne constitue toutefois pas une confirmation indépendante de Spring Ring.

Quick Assist et les logiciels RMM ouvrent le premier accès

Dans le premier scénario observé, le faux technicien convainc l’utilisateur de lancer Windows Quick Assist ou un logiciel RMM, c’est-à-dire un outil légitime de supervision et de gestion à distance des appareils.

Ces programmes sont normalement utilisés par les administrateurs pour fournir une assistance. Si la session est autorisée par la victime, l’attaquant peut toutefois prendre le contrôle de l’ordinateur sans nécessairement exploiter une vulnérabilité logicielle.

Après avoir obtenu l’accès, les opérateurs de Spring Ring effectuent une première reconnaissance de l’hôte et du domaine Windows. Ils cherchent ainsi à comprendre la configuration de l’appareil, le contexte de l’entreprise et les possibilités de poursuivre l’intrusion.

Lors de l’une des activités analysées, les attaquants ont tenté de télécharger un RAT écrit en PowerShell et obfusqué. Le payload aurait fourni des capacités d’accès à distance persistantes, mais la protection endpoint en a bloqué l’exécution.

Le nom du RAT n’a pas été communiqué. Aucun hash de fichier, domaine, adresse IP ou autre indicateur technique directement exploitable pour une recherche rétrospective n’est disponible.

Cette absence d’informations rend la détection comportementale d’autant plus importante. Se limiter à rechercher une signature précise de malware risque de laisser passer la phase initiale, menée au moyen d’outils autorisés et d’actions confirmées par l’utilisateur.

Du navigateur masqué à la tentative de relay NTLM

Le deuxième vecteur présente une chaîne technique plus élaborée. Les attaquants redirigent la victime vers des fichiers hébergés sur des infrastructures cloud et personnalisés en fonction de l’utilisateur et de l’organisation ciblée.

Les exécutables mettent en place un mécanisme de persistance et lancent une instance masquée de Microsoft Edge. Ils chargent ensuite latéralement une extension, effectuent une reconnaissance du réseau interne et génèrent du trafic d’authentification NTLM.

La phase la plus dangereuse consiste en une tentative de NTLM relay basée sur PetitPotam. Cette technique vise à inciter un système Windows, en l’occurrence le domain controller, à s’authentifier auprès d’une destination contrôlée par l’adversaire.

L’attaquant tente alors de relayer cette authentification vers un autre service afin d’obtenir des privilèges qu’il ne détient pas directement. Si l’opération réussit sur des systèmes et des configurations exposés, le contrôle peut s’étendre de l’endpoint initial à l’infrastructure des identités.

La cible finale est particulièrement sensible. Un domain controller gère les authentifications, les comptes, les stratégies et les relations de confiance de l’environnement Windows ; sa compromission peut ouvrir la voie au contrôle de l’ensemble du domaine.

Le service de managed detection de Unit 42, division de Palo Alto Networks, a bloqué la tentative de prise de contrôle de l’infrastructure. Rien n’indique donc que le domain controller observé ait effectivement été compromis.

Portée et limites des informations disponibles

Palo Alto Networks a recensé au moins 150 utilisateurs ciblés dans au moins 10 organisations. Aucun taux de réussite global n’a toutefois été communiqué ; il est donc impossible de déterminer combien de victimes ont exécuté les fichiers ou accordé l’accès à distance.

Les deux tentatives décrites en détail ont été stoppées : le RAT PowerShell par la protection endpoint et l’attaque contre le domaine par le service Unit 42. Cela ne prouve pas que tous les incidents associés à la campagne aient connu la même issue.

Les versions précises de Microsoft Teams, Windows, Quick Assist ou Edge concernées n’ont pas été indiquées. Spring Ring n’est pas présentée comme l’exploitation d’une faille dans une version donnée, mais comme l’abus de fonctionnalités légitimes combiné à des techniques d’ingénierie sociale et d’authentification Windows.

Par conséquent, aucun correctif spécifique ni aucune CVE associée à la campagne n’ont été signalés. La mise à jour des systèmes reste une mesure nécessaire, mais elle ne neutralise pas un appel au cours duquel l’utilisateur autorise volontairement une session à distance.

Les données disponibles proviennent de l’enquête menée par Palo Alto Networks. Aucune corroboration indépendante du même ensemble d’incidents n’a été fournie.

Comment reconnaître et contenir Spring Ring

La première contre-mesure consiste à dissocier la plateforme de contact de la vérification de l’identité. Une demande reçue via Teams ne doit pas être considérée comme authentique au seul motif qu’elle apparaît dans un environnement professionnel.

Lorsqu’un prétendu technicien demande de lancer Quick Assist, d’installer un RMM ou d’exécuter un fichier, l’employé doit interrompre la procédure et contacter le help desk via un numéro ou un portail déjà connu. Il ne doit pas utiliser les coordonnées fournies par son interlocuteur.

Les organisations peuvent également agir à plusieurs niveaux :

• limiter Quick Assist et les outils RMM aux utilisateurs, appareils et processus d’assistance autorisés ;
• consigner le lancement de sessions à distance inattendues et le corréler avec de nouveaux contacts reçus sur Teams ;
• détecter PowerShell obfusqué, les téléchargements anormaux, les navigateurs lancés en mode masqué et le sideload d’extensions ;
• contrôler les fichiers exécutables téléchargés depuis des services cloud, en particulier lorsqu’ils sont personnalisés ou transmis pendant un appel ;
• analyser les authentifications NTLM vers des destinations externes ou des systèmes non approuvés ;
• rechercher les comportements compatibles avec la coercition de l’authentification et le relay ;
• renforcer la supervision des domain controllers et des anomalies liées aux identités ;
• former le personnel au moyen de simulations vocales, et pas uniquement d’exercices de phishing par e-mail.

En l’absence de hash et d’adresses réseau publiques, les indicateurs les plus utiles sont comportementaux : contacts répétés provenant de faux comptes d’assistance, appels inattendus, lancement non autorisé d’un RMM, exécution de PowerShell et trafic NTLM inhabituel.

Les problèmes de disponibilité de Teams sont des incidents distincts

Le 4 septembre 2026, des problèmes opérationnels affectant Microsoft Teams ont également été signalés, mais aucun élément ne permet de les relier à Spring Ring.

L’incident TM1466820 peut empêcher l’ouverture du client de bureau Windows ou retarder de deux minutes le premier chargement. Microsoft a indiqué Teams sur le web, l’application mobile et les autres méthodes d’accès comme solutions temporaires.

Un problème distinct, identifié sous le nom TM1466659, concerne certains utilisateurs Mac qui ne peuvent pas participer à des appels ou à des réunions. Microsoft analysait les journaux et réévaluait la cause après une première hypothèse liée à une modification du code.

Il s’agit de dysfonctionnements de disponibilité, et non de signes de compromission. Rien n’indique qu’ils aient provoqué, facilité ou dissimulé les attaques de Spring Ring.

La distinction est essentielle : la campagne exploite la confiance accordée aux outils de collaboration, et non les dysfonctionnements signalés dans les clients. La défense doit donc porter à la fois sur les contrôles techniques et sur la vérification des processus d’assistance et des identités.