MSHTA, un ancien composant natif de Windows conçu pour exécuter des scripts VBScript et JavaScript, continue d’être exploité dans des campagnes malveillantes récentes. Bitdefender observe son utilisation croissante pour contourner les outils EDR et lancer des chaînes d’infection multi-étapes difficiles à détecter.
Alors que Microsoft poursuit le retrait progressif de VBScript et qu’Internet Explorer n’est plus supporté depuis 2022, certains composants historiques de Windows restent présents par défaut dans les environnements d’entreprise. C’est le cas de mshta.exe, l’exécutable associé à Microsoft HTML Application Host (MSHTA), encore utilisé dans plusieurs campagnes de malware récentes analysées par les équipes de recherche de Bitdefender Labs.
MSHTA permet d’exécuter des scripts VBScript ou JavaScript depuis des fichiers locaux ou distants. Historiquement utilisé pour certaines applications administratives Windows, l’outil est désormais fréquemment détourné dans des chaînes d’attaque reposant sur des composants légitimes du système d’exploitation.
MSHTA utilisé avec PowerShell, WScript et msiexec dans des chaînes multi-étapes
MSHTA appartient à la catégorie des LOLBINs (Living-off-the-Land binaries), c’est-à-dire des exécutables Microsoft légitimes utilisés par des attaquants pour éviter de déposer immédiatement un fichier malveillant identifiable sur le poste compromis. Selon Bitdefender, les campagnes observées utilisent MSHTA pour récupérer du contenu distant, exécuter des scripts en mémoire puis transférer l’exécution vers PowerShell, WScript, msiexec ou une charge malveillante finale. L’objectif consiste à réduire les traces laissées sur le disque et à s’appuyer sur des processus déjà autorisés dans de nombreux environnements Windows.
Les LOLBINs Windows compliquent la détection des malwares modernes
Les chercheurs de Bitdefender ont identifié l’utilisation de MSHTA dans des campagnes diffusant LummaStealer et Amatera, deux stealers spécialisés dans le vol d’identifiants, de données stockées dans les navigateurs ou encore de jetons de session. D’autres chaînes d’infection impliquent également CountLoader, Emmenhtal Loader, ClipBanker ou PurpleFox. Cette diversité d’usage complique la détection. MSHTA n’est plus associé à une famille de malware spécifique, mais devient un composant réutilisable dans des scénarios très différents, allant des campagnes opportunistes aux infections plus persistantes.
Les techniques ClickFix poussent parfois les utilisateurs à lancer eux-mêmes MSHTA
Les scénarios observés reposent souvent sur des mécanismes d’ingénierie sociale. Les victimes sont attirées via de faux téléchargements logiciels, des contenus piratés ou des sites optimisés pour les moteurs de recherche. Bitdefender évoque également des leurres de type ClickFix. Cette technique consiste à afficher une fausse vérification humaine demandant à l’utilisateur de copier puis exécuter une commande PowerShell ou MSHTA depuis le presse-papiers Windows.
Les faux téléchargements restent le principal point d’entrée
En quelques étapes, l’utilisateur déclenche lui-même l’exécution du composant Windows légitime, qui télécharge ensuite des scripts distants ou des charges additionnelles. Cette approche réduit fortement les indicateurs visibles pour les solutions de sécurité traditionnelles. Les attaques observées rappellent aussi les limites d’une protection uniquement centrée sur les fichiers malveillants. Les chaînes modernes combinent scripts, exécution mémoire, outils natifs Windows et téléchargements distants, parfois sans dépôt initial d’exécutable suspect.
Le retrait progressif de VBScript ne supprime pas immédiatement le risque
Microsoft a engagé la dépréciation progressive de VBScript, avec un retrait annoncé en plusieurs étapes. À ce stade, aucun calendrier public ne prévoit cependant la suppression de MSHTA de Windows. Pour les équipes sécurité, le sujet dépasse donc le seul composant MSHTA. Plusieurs entreprises conservent encore des scripts historiques reposant sur VBScript, WScript ou d’autres composants hérités du système Windows.
Dans les environnements où ces outils ne sont plus nécessaires, leur désactivation peut réduire la surface d’attaque exploitable. Cette approche suppose toutefois d’identifier les dépendances applicatives encore présentes dans les environnements de production. Les campagnes analysées montrent également l’importance des capacités de détection comportementale des EDR et XDR, notamment sur les enchaînements inhabituels impliquant MSHTA, PowerShell, scripts distants et exécution mémoire.
