L’usurpation d’identité de Microsoft Teams et des tactiques d’ingénierie sociale sont utilisées dans une campagne en cours pour diffuser une charge malveillante furtive connue sous le nom d’A0Backdoor.
Des chercheurs de BlueVoyant rapportent que l’opération combine des techniques d’ingénierie sociale, des installateurs malveillants et des communications furtives de commande et de contrôle (C2) afin d’obtenir un accès persistant aux réseaux ciblés.
« Le chargeur du malware utilise des techniques d’évasion des environnements de bac à sable, et le canal de commande et de contrôle semble avoir migré vers un canal furtif fondé sur les échanges de courrier DNS, qui limite le trafic des terminaux aux résolveurs récursifs de confiance », ont déclaré les chercheurs.
Chaîne d’attaque par usurpation d’identité sur Teams
L’activité semble principalement cibler des organisations des secteurs de la finance et de la santé, et correspond étroitement à des tactiques précédemment associées au groupe d’acteurs malveillants Blitz Brigantine, également suivi sous le nom de Storm-1811.
Ce groupe est lié à des opérations de ransomware telles que Black Basta et Cactus, et est connu pour recourir à l’ingénierie sociale afin d’obtenir un accès initial avant de déployer des malwares ou de lancer des attaques de ransomware ultérieures.
Dans cette campagne, les attaquants obtiennent d’abord un accès grâce à des techniques d’ingénierie sociale qui usurpent l’identité de membres du personnel informatique interne.
Après avoir convaincu les victimes d’accorder l’accès — souvent au moyen d’outils d’assistance à distance comme Quick Assist — les attaquants déploient des packages d’installation MSI malveillants conçus pour se faire passer pour des mises à jour légitimes de logiciels liés à Teams.
Ces installateurs utilisent fréquemment des noms tels que Update.msi ou UpdateFX.msi et sont conçus pour se fondre dans les flux de travail habituels des entreprises.
Malware diffusé par chargement latéral de DLL
Une fois exécutés, les installateurs déposent des fichiers dans des répertoires couramment associés aux services Microsoft, notamment des emplacements liés aux modules complémentaires de Teams ou à la fonctionnalité Cross Device.
Les packages comprennent généralement un mélange de binaires légitimes signés par Microsoft et de fichiers DLL contrôlés par les attaquants.
Cette combinaison permet une technique connue sous le nom de chargement latéral de DLL, dans laquelle une application de confiance charge une bibliothèque malveillante placée dans le même répertoire, ce qui permet au code de l’attaquant de s’exécuter tout en semblant provenir d’un composant Microsoft légitime.
Au cœur de la chaîne d’infection se trouve une DLL malveillante nommée hostfxr.dll, qui usurpe l’identité d’un composant d’hébergement .NET légitime de Microsoft.
Au lieu d’assurer sa fonction attendue, cette DLL agit comme un chargeur chargé de déchiffrer et d’exécuter le malware dissimulé dans le fichier.
La version malveillante est conçue pour ressembler étroitement au composant légitime afin d’éviter les soupçons tout en étant chargée par un exécutable de confiance.
Le chargeur utilise l’obfuscation et des techniques anti-analyse
Le chargeur intègre plusieurs techniques anti-analyse destinées à ralentir ou à perturber les investigations de sécurité.
L’une d’elles consiste à appeler de manière répétée l’API CreateThread de Windows afin de générer un grand nombre de threads.
Si ce comportement a peu d’effet lors d’une exécution normale, il peut saturer les outils de débogage et ralentir l’analyse dynamique, voire provoquer le plantage des environnements de débogage.
La DLL malveillante contient également des données de charge utile chiffrées intégrées dans sa section .data.
Lors de l’exécution, le chargeur déchiffre ces données au moyen d’un algorithme personnalisé qui dérive sa clé de la chaîne ASCII crossdeviceservice.exe, correspondant au nom de l’exécutable légitime utilisé dans la chaîne de chargement latéral.
Une fois déchiffrée, la charge utile est écrite en mémoire et exécutée sous forme de shellcode.
Ce shellcode introduit des couches supplémentaires d’obfuscation et de logique de contrôle.
Nombre de ses chaînes et composants fonctionnels restent chiffrés jusqu’à l’exécution, empêchant les analystes d’identifier son comportement par analyse statique.
Le shellcode crée d’abord un mutex lié au binaire en cours d’exécution afin de garantir qu’une seule instance du malware s’exécute sur un système à un moment donné.
Le malware intègre également un mécanisme d’exécution fondé sur le temps.
Il calcule l’heure actuelle du système et la divise en fenêtres d’exécution d’environ 55 heures.
Si le malware s’exécute en dehors de la plage horaire prévue, les valeurs cryptographiques utilisées pour déchiffrer la charge utile changent, empêchant le malware intégré de s’exécuter correctement.
Cette technique contribue à réduire la probabilité que des chercheurs ou des systèmes d’analyse automatisés déclenchent la charge utile.
En outre, le shellcode tente de détecter les environnements de bac à sable ou virtualisés.
Il interroge les tables du micrologiciel système et recherche des indicateurs tels que QEMU, une plateforme de virtualisation utilisée dans les environnements d’analyse.
Si de tels indicateurs sont détectés, le malware modifie sa logique de génération de clé, empêchant le déchiffrement correct de la charge utile et dissimulant ainsi efficacement ses véritables fonctionnalités.
Une fois ces vérifications terminées, le shellcode déchiffre et exécute la charge utile finale, A0Backdoor.
A0Backdoor utilise le tunneling DNS pour ses communications de commande et de contrôle
A0Backdoor est lui-même conçu pour fonctionner furtivement après son exécution. Comme aux étapes précédentes de la chaîne d’infection, il ne déchiffre ses fonctionnalités essentielles qu’en mémoire, ce qui contribue à dissimuler son comportement aux outils d’analyse de sécurité traditionnels.
Une fois actif, le backdoor commence à dresser l’empreinte du système compromis en recueillant des informations d’identification au moyen d’API Windows telles que GetComputerNameW, GetUserNameExW, et DeviceIoControl.
Ces données permettent aux attaquants d’identifier précisément les systèmes infectés.
Au lieu d’établir des connexions directes avec l’infrastructure des attaquants, le malware utilise une technique furtive de tunneling DNS pour ses communications de commande et de contrôle (C2).
L’hôte infecté envoie à des résolveurs DNS publics des requêtes DNS spécialement conçues contenant des métadonnées système encodées.
Ces résolveurs interrogent ensuite, au nom du système infecté, les serveurs DNS faisant autorité contrôlés par les attaquants.
Les attaquants répondent avec des enregistrements DNS MX contenant des données de commande encodées dans le champ du nom d’hôte. Le malware extrait et décode ces données pour recevoir les instructions des opérateurs.
Comme le terminal infecté ne communique qu’avec des résolveurs DNS publics de confiance, au lieu de contacter directement l’infrastructure des attaquants, l’activité peut se fondre dans le trafic réseau normal.
Cette méthode de communication indirecte rend le canal C2 plus difficile à détecter pour les défenseurs.
Comment les entreprises peuvent réduire leur surface d’attaque
Les entreprises peuvent réduire les risques liés à ces campagnes en renforçant les contrôles de sécurité sur les terminaux, les plateformes collaboratives et la surveillance des réseaux.
- Restreindre et surveiller les outils d’assistance à distance en limitant Quick Assist et les utilitaires similaires au personnel autorisé du support informatique, en exigeant une authentification et la journalisation des sessions, et en déclenchant des alertes lors de sessions à distance initiées depuis des sources inconnues ou externes.
- Mettre en place des listes d’autorisation d’applications afin d’empêcher l’exécution de fichiers exécutables ou de DLL non autorisés — en particulier ceux situés dans des répertoires accessibles en écriture par les utilisateurs, comme AppData —.
- Surveiller le chargement latéral de DLL et les activités suspectes sur les fichiers en détectant les exécutables Microsoft qui chargent des bibliothèques inattendues ou non signées et en inspectant les répertoires tels que les modules complémentaires de Teams ou les chemins AppData liés à Microsoft.
- Renforcer la sécurité des plateformes collaboratives en limitant autant que possible les communications Microsoft Teams externes, en appliquant des politiques d’accès conditionnel et en exigeant des procédures de vérification avant que les utilisateurs n’acceptent des demandes d’assistance à distance.
- Améliorer la sécurité DNS en surveillant les journaux pour repérer les sous-domaines à forte entropie, les requêtes inhabituelles d’enregistrements MX ou un nombre excessif de requêtes DNS uniques pouvant indiquer une activité de tunneling DNS.
- Utiliser des outils EDR pour identifier l’exécution suspecte en mémoire, l’injection de processus, la création inhabituelle de threads et d’autres comportements associés aux chargeurs de malware et à l’exécution de shellcode.
- Tester régulièrement les plans de réponse aux incidents et utiliser des outils de simulation d’attaque.
Ensemble, ces mesures aident les entreprises à renforcer leur résilience opérationnelle, à détecter plus tôt les activités suspectes et à limiter l’ampleur potentielle des dégâts si un attaquant obtient un accès.
Quand les outils légitimes deviennent des vecteurs d’attaque
Cette campagne illustre une tendance plus large selon laquelle les attaquants combinent l’ingénierie sociale et des outils d’entreprise légitimes pour obtenir un accès initial.
En usurpant l’identité de membres du personnel informatique via des plateformes collaboratives comme Microsoft Teams et en utilisant des utilitaires d’assistance à distance intégrés, les attaquants peuvent contourner les défenses principalement axées sur la détection des logiciels malveillants.
L’utilisation de communications de commande et de contrôle fondées sur le DNS montre également comment les attaquants adaptent leur infrastructure pour se fondre dans l’activité réseau normale, plutôt que de s’appuyer sur des connexions directes à des serveurs suspects.
Ces tactiques soulignent le besoin croissant de solutions zero trust, qui exigent une vérification continue des utilisateurs et des appareils avant d’accorder l’accès.