Microsoft Threat Intelligence a révélé une campagne d’intrusion qui commence par un message ou un appel via Microsoft Teams provenant d’une partie externe usurpant l’identité d’employés du service informatique ou du centre d’assistance. L’attaquant tente de convaincre l’employé de passer outre les avertissements concernant le contact externe et de lui accorder un contrôle interactif de l’appareil via des outils tels que les sessions de support à distance ou Quick Assist, puis utilise PowerShell pour télécharger et installer silencieusement un paquet MSI malveillant.
Selon Microsoft, la campagne n’exploite pas de vulnérabilité technique dans Microsoft Teams, mais repose sur l’ingénierie sociale et la persuasion de l’utilisateur afin qu’il contourne les protections existantes. Sa dangerosité tient au fait que le point d’entrée ressemble à une procédure de support familière, tout en accordant à l’attaquant un accès interactif, soutenu par les identifiants de l’utilisateur, à un appareil situé au sein de l’organisation.
Une chaîne d’attaque utilisant des outils fiables
Après l’installation du paquet MSI, la campagne place un chargeur en texte brut et un fichier chiffré contenant un implant JavaScript dans le dossier LocalAppData. Si Node.js n’est pas installé sur l’appareil, le paquet télécharge une version portable légitime de l’environnement d’exécution depuis la distribution officielle de Node.js, puis l’utilise pour déchiffrer et exécuter l’implant.
Le processus est lancé via PowerShell, cmd.exe ou WScript, et utilise des mécanismes de persistance propres à chaque utilisateur, comme une valeur Run dans le registre ou un raccourci dans le dossier Startup nommé EdgeUpdate. L’implant communique avec le serveur de commande et de contrôle au moyen de requêtes HTTPS périodiques et aléatoires, et reçoit des tâches JavaScript capables d’exécuter des commandes, d’inspecter l’appareil, les logiciels de sécurité et l’environnement virtuel, ainsi que de capturer périodiquement des images du bureau.
Les échantillons analysés par Microsoft contenaient également une logique désactivée permettant d’interroger un nœud intelligent sur le réseau Ethereum afin d’obtenir une adresse mise à jour du serveur de commande et de contrôle. L’entreprise a précisé que le nœud ne stocke pas la charge utile malveillante et ne l’exécute pas, et que les échantillons récupérés utilisaient une adresse de secours fixe.
De l’appareil infecté aux systèmes d’identité
L’activité ne s’arrête pas à l’installation de l’implant. Les opérateurs ont utilisé des commandes natives et des requêtes ADSI pour recenser les comptes du domaine, les serveurs et les utilisateurs, puis ont exécuté des charges utiles supplémentaires via rundll32.exe. L’implant a ensuite commencé à établir des communications WinRM via le port TCP 5985 vers un grand nombre de systèmes joints au domaine, notamment des serveurs de fichiers, de bases de données et d’applications, ainsi que des contrôleurs de domaine et des autorités de certification.
Cette progression représente un passage concret de la tromperie d’un seul utilisateur à une tentative d’étendre le contrôle au sein de l’organisation. Le contenu ne prouve pas que la campagne a effectivement déployé des rançongiciels ou volé des données, mais il indique que la reconnaissance et le déplacement vers les systèmes d’identité sont cohérents avec des étapes précédant des objectifs ultérieurs tels que le vol de données, l’extorsion ou le déploiement d’un rançongiciel.
Pourquoi cette actualité est-elle importante ?
La campagne montre que la confiance accordée à un outil légitime peut devenir plus dangereuse qu’un fichier exécutable inconnu. La présence de Microsoft Teams, Node.js, Windows Installer et WinRM dans la chaîne ne signifie pas que ces outils sont malveillants, mais elle montre que le recours aux seules listes de programmes autorisés est insuffisant. L’indicateur le plus important est une succession comportementale inhabituelle : un contact externe urgent, suivi d’une session de support à distance, puis de l’exécution de PowerShell ou de cmd.exe, de l’installation d’un MSI ou du lancement de Node.js depuis un chemin accessible en écriture par l’utilisateur.
Microsoft recommande de vérifier toute demande de support externe via un canal interne connu, de limiter la collaboration externe dans Teams aux domaines de confiance, d’imposer l’authentification multifacteur et l’accès conditionnel, et de surveiller les outils de support à distance. L’entreprise propose également d’activer les règles de réduction de la surface d’attaque ainsi que la protection du réseau et du web, de limiter WinRM aux stations d’administration autorisées et de déclencher une alerte lorsqu’il est exécuté depuis le contexte d’un utilisateur ou d’un processus non administratif.
Les organisations qui découvrent des indicateurs associés à cette campagne doivent considérer l’appareil concerné comme un point d’accès potentiel au réseau et donner la priorité à l’enquête ainsi qu’à la rotation des identifiants auxquels il aurait pu permettre d’accéder, y compris, le cas échéant, ceux des administrateurs du domaine.