Phishing EV : faux installateurs Teams déploient RMM

Introduction : pourquoi c’est important

Les acteurs malveillants se fondent de plus en plus dans les opérations IT légitimes en déployant des outils de Remote Monitoring and Management (RMM) disponibles dans le commerce. Cette campagne place la barre encore plus haut en utilisant une image de marque familière de « workplace apps » et la signature de code EV pour réduire la méfiance des utilisateurs et augmenter les taux d’exécution — ce qui en fait une voie d’accès initiale pragmatique dans les entreprises où les utilisateurs installent régulièrement des logiciels de réunion et de lecture de documents.

Nouveautés / principaux constats

Microsoft Defender Experts a observé plusieurs campagnes de phishing attribuées à un acteur non identifié. Les principales caractéristiques incluent :

• Appâts “réunions” et “documents” : des emails se faisaient passer pour des invitations à des réunions (Teams/Zoom/Google Meet), des factures, des documents financiers, des appels d’offres et des notifications organisationnelles.
• PDF contrefaits et pages de téléchargement usurpées : certains messages livraient de faux PDF avec un bouton « Open in Adobe » redirigeant les utilisateurs vers un site de téléchargement Adobe imité, incitant à une « mise à jour ».
• Exécutables déguisés : les charges utiles portaient des noms ressemblant à des installateurs de confiance, notamment msteams.exe, adobereader.exe, zoomworkspace.clientsetup.exe, invite.exe et trustconnectagent.exe.
• Abus de confiance via la signature EV : les droppers étaient signés numériquement avec un certificat EV délivré à TrustConnect Software PTY LTD, ce qui les aidait à paraître légitimes.
• Déploiement de portes dérobées RMM : l’exécution entraînait l’installation d’outils RMM tels que ScreenConnect, Tactical RMM et Mesh Agent, permettant un accès distant persistant.

Comment l’intrusion établit la persistance (points techniques)

Dans la chaîne centrée sur ScreenConnect, l’exécutable « workspace » :

• Se copiait dans C:\Program Files pour ressembler à une application légitimement installée.
• S’enregistrait comme service Windows pour assurer la persistance au démarrage.
• Créait un autorun supplémentaire via la clé Run :
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  • Nom de valeur : TrustConnectAgent
  • Cible : C:\Program Files\Adobe Acrobat Reader\AdobeReader.exe
• Établissait des connexions sortantes vers l’infrastructure de l’attaquant (notamment trustconnectsoftware[.]com).
• Utilisait PowerShell encodé pour télécharger des charges utiles additionnelles et invoquait msiexec.exe pour installer ScreenConnect à partir de fichiers MSI prépositionnés.

Microsoft a signalé des cas où le MSI semblait non signé, suivis de binaires ScreenConnect signés avec des certificats révoqués, un schéma souvent associé à des déploiements malveillants ou non autorisés.

Impact pour les administrateurs IT et les utilisateurs finaux

• Les utilisateurs sont ciblés via des workflows routiniers : rejoindre des réunions, examiner des factures et mettre à jour des applications « obsolètes ».
• Les équipes IT et sécurité peuvent voir l’activité de l’attaquant se confondre avec l’outillage d’administration normal, car les agents RMM peuvent ressembler à du support à distance autorisé.
• Le risque augmente après compromission : la persistance via services/autoruns et l’outillage RMM peut accélérer l’accès aux identifiants, la prise de contrôle à distance et le mouvement latéral.

Mesures à prendre / prochaines étapes

• Renforcer les voies d’installation logicielle : restreindre, lorsque possible, les installations initiées par les utilisateurs ; imposer l’allowlisting (p. ex. WDAC/App Control) pour les exécutables de type « installateur ».
• Auditer l’usage des RMM : inventorier les outils RMM approuvés et bloquer ou déclencher des alertes sur les agents non autorisés (ScreenConnect/Tactical RMM/Mesh) et sur toute création de service suspecte.
• Réévaluer les décisions de confiance liées à la signature de code : considérer « signed » comme un signal — pas une preuve. Ajouter une logique de détection pour les éditeurs nouveaux/rares et les binaires EV signés inhabituels.
• Rechercher des indicateurs de persistance : surveiller la clé Run TrustConnectAgent, les services inattendus et les schémas suspects associant msiexec.exe et PowerShell encodé.
• Renforcer la résilience au phishing : consolider les consignes utilisateurs autour des invites « update required » provenant d’emails/PDF et utiliser les protections Defender pour faire exploser/inspecter les pièces jointes et les liens.