Microsoft Avertit d'un Malware VBS via WhatsApp Contournant UAC

Partager
Microsoft Avertit d'un Malware VBS via WhatsApp Contournant UAC

Les faits

Qui sont les responsables ?

Une campagne malveillante décrite par Microsoft a été observée fin février 2026 et documentée publiquement en mars 2026 ¹. Les auteurs restent non identifiés à ce stade. L'attaque vise principalement des utilisateurs de WhatsApp, et cible aussi bien des particuliers que des entreprises de télécommunications, ce qui souligne la capacité des attaquants à toucher des chaînes de communication où la confiance est élevée ¹.

Qu'est-ce qui se passe ?

Les assaillants envoient par WhatsApp des fichiers VBS (Visual Basic Script) qui, une fois ouverts sur des postes Windows, exécutent une chaîne d'actions malveillantes comparable à un courriel piégé contenant une pièce jointe dangereuse. Les fichiers sont souvent nommés pour paraître légitimes - factures, messages vocaux, confirmations - et accompagnés d'un message incitatif.

Les étapes observées sont les suivantes :

  • Exécution via les moteurs Windows intégrés (wscript.exe / cscript.exe), évitant l'installation préalable d'un exécutable tiers.
  • Téléchargement de modules complémentaires depuis un serveur distant pour élargir les capacités initiales.
  • Tentatives de contournement des contrôles de sécurité pour obtenir des droits élevés, y compris des techniques d'escalade liées à UAC.
  • Mise en place de persistance et d'accès à distance pour maintenir la présence sur les systèmes compromis et permettre des opérations à distance ¹.

Quand et où cela se produit-il ?

La campagne a été repérée fin février 2026 et analysée par Microsoft en mars 2026 ¹. Les infections ciblent majoritairement des postes Windows 10 et 11 où les scripts VBS peuvent s'exécuter par défaut selon la configuration de la machine. Les victimes sont réparties internationalement, sans concentration géographique nette publiée à ce jour ¹.

Comment les attaquants agissent-ils ?

Les opérateurs combinent ingénierie sociale et tromperie technique. Ils envoient des messages brefs qui créent un sentiment d'urgence ou de curiosité pour augmenter les chances d'ouverture. Les fichiers utilisent des astuces visuelles telles que des double-extensions (par exemple 'facture.pdf.vbs') et des icônes détournées pour paraître inoffensifs. Une analogie utile : recevoir un colis soigné dont l'emballage inspire confiance mais qui contient un mécanisme caché.

Contexte

L'usage de plateformes de messagerie pour distribuer des logiciels malveillants n'est pas nouveau, mais cette campagne tire parti de la place dominante de WhatsApp dans les communications quotidiennes pour augmenter le taux de succès. Les victimes font davantage confiance aux fichiers reçus par leurs contacts, ce qui réduit la vigilance.

Les scripts VBS ont une longue histoire dans l'écosystème Windows. Leur longévité tient à la disponibilité native des interprètes et à la facilité d'automatisation qu'ils offrent. Depuis des années, les acteurs malveillants réutilisent ce vecteur en combinant obfuscation et étapes post-exploitation pour échapper aux défenses classiques.

Le contournement des contrôles d'élévation de privilèges, y compris des techniques d'UAC bypass, est également récurrent. Ce type d'attaque est conçu pour transformer une simple exécution de script en compromission étendue du système, avec création de comptes, installation d'outils et persistance ¹.

Précédents et tendances

On retrouve des motifs similaires dans des campagnes antérieures qui visaient la messagerie instantanée et les réseaux sociaux. La nouveauté ici est l'optimisation du parcours de l'utilisateur mobile - les attaquants comptent sur la rapidité et la fréquence des interactions via WhatsApp pour propager leur charge malveillante parmi des contacts de confiance. Les entreprises doivent tenir compte de cette évolution dans leurs stratégies de prévention et de détection.

Réactions et conséquences

Impact sur les organisations

Une compromission de ce type peut entraîner plusieurs impacts opérationnels et financiers : perte de données sensibles, compromission d'identifiants, accès non autorisé à des systèmes critiques et coût de réponse élevé pour les équipes de sécurité. Le coût d'une infection varie fortement en fonction de l'étendue et de la durée de la compromission; des estimations et retours d'expérience publiés indiquent que le coût peut aller de plusieurs milliers à plusieurs centaines de milliers d'euros selon la gravité ². Une détection tardive augmente fortement ces montants ².

Au-delà du prix direct, il y a le coût caché du temps passé par les équipes IT et sécurité pour enquêter et nettoyer, la perturbation des opérations et le risque réputationnel si des données client sont exposées.

Mesures prises par la communauté

Microsoft a diffusé des recommandations techniques pour limiter l'impact et détecter les comportements associés à cette campagne ¹. Les acteurs de la sécurité et les éditeurs d'antivirus ont mis à jour des signatures et des règles heuristiques pour détecter les schémas d'obfuscation et les tentatives d'UAC bypass. Les autorités nationales et équipes de réponse ont aussi publié des avis de bonnes pratiques et des actions prioritaires à mener ³.

Recommandations immédiates

Illustration cybersécurité

Voici des mesures opérationnelles à appliquer rapidement pour réduire la surface d'attaque et améliorer la détection :

  • Restreindre l'exécution de wscript.exe et cscript.exe pour les postes qui n'en ont pas besoin, via des politiques de groupe, AppLocker ou WDAC.
  • Effectuer des audits réguliers des clés de registre Run/RunOnce et des tâches planifiées pour détecter des entrées inédites ou suspectes.
  • Activer la journalisation avancée PowerShell (Module Logging et Script Block Logging) et déployer Sysmon pour surveiller création de processus, chargement de DLL et connexions réseau sortantes.
  • Mettre à jour et pousser les signatures antivirus et les règles EDR pour couvrir les techniques d'obfuscation observées et les patterns de persistance.
  • Former les collaborateurs à la vérification des pièces jointes, même si elles proviennent d'un contact connu: vérifier l'extension réelle, refuser d'ouvrir des fichiers exécutable-like et signaler toute pièce jointe inattendue.
  • Restreindre, sur les postes sensibles, l'installation et l'utilisation d'applications de messagerie non gérées et appliquer des solutions DLP ou proxy capables d'inspecter les téléchargements externes ³.

Observations opérationnelles pour la détection

Sur le plan technique, chercher des indicateurs d'activité plutôt que des signatures figées. Priorisez la corrélation des sources suivantes :

  • Logs Sysmon pour processus et réseau, afin d'identifier des lancements de wscript/cscript suivis de connexions réseau inhabituelles.
  • Journaux PowerShell détaillés pour repérer des blocs de script encodés ou des commandes Invoke-WebRequest/Net.WebClient.
  • Événements du Task Scheduler et modifications des clés Run/RunOnce dans le registre.
  • Flux réseau sortants vers IPs ou domaines récemment observés dans les analyses, corrélés avec des hachages de fichiers suspects.

En cas de compromission avérée, isoler la machine, collecter artefacts et journaux, mener une analyse forensique pour évaluer l'étendue, révoquer les identifiants compromis et envisager la réinstallation du système si la persistance ne peut pas être maîtrisée ³.

Points de vigilance pour les décideurs

La principale leçon pour les responsables est que la confiance implicite portée aux messages d'amis et collègues peut être exploitée pour franchir des défenses techniques. Les stratégies doivent combiner durcissement des endpoints, observation continue et culture de cybersécurité chez les utilisateurs. Investir dans la visibilité et l'automatisation des réponses réduit le temps moyen de détection et limite l'impact financier d'une attaque ².

Les équipes opérationnelles gagneront à prioriser les mesures de blocage de l'exécution non nécessaire des interprètes de scripts, la journalisation renforcée et les exercices de simulation d'attaque pour tester les process de réponse.

Selon Microsoft, la campagne exploite des capacités natives de Windows et des vecteurs simples mais efficaces, ce qui explique sa propagation rapide ¹. Les recommandations publiques et les retours d'expérience des autorités nationales offrent une feuille de route pour limiter la surface et accélérer la détection ³.


Questions fréquentes

Comment différencier un VBS légitime d'un dropper malveillant reçu via WhatsApp ?

Sur un poste Windows, vérifier la signature du fichier si elle existe, comparer le hachage avec des bases connues, et analyser le script dans un environnement isolé (sandbox) pour observer les appels réseau, les modifications de registre et les tâches planifiées. Les VBS malveillants contiennent souvent des blocs obfusqués, des appels à PowerShell encodé ou des téléchargements effectués par des commandes net/WebClient.

La désactivation de wscript.exe et cscript.exe suffit-elle pour se protéger ?

La désactivation réduit fortement le risque lié aux VBS, mais les attaquants peuvent porter la charge utile vers PowerShell ou des binaires signés mal utilisés. AppLocker ou WDAC avec règles basées sur signatures et chemins fournit une protection plus robuste et gérable en entreprise.

Quels logs surveiller en priorité pour détecter ce type d'attaque ?

Prioriser Sysmon (création de processus, chargement de DLL, connexions réseau), la journalisation PowerShell (Module Logging et Script Block Logging), les événements du Task Scheduler et la surveillance des clés Run/RunOnce dans le registre. Corréler ces sources avec les logs réseau pour repérer des téléchargements suspects.

Peut-on bloquer la menace côté WhatsApp ou opérateur mobile ?

WhatsApp chiffre les messages de bout en bout et ne peut pas inspecter le contenu côté serveur. Le blocage doit se faire en périphérie et sur les postes avec des solutions DLP, proxies capables d'inspecter les téléchargements, ou des politiques réseau limitant les applications non gérées sur des endpoints sensibles.

Sources

Lire la suite