Domaine légitime comme leurre : la campagne malspam qui déploie DesckVB RAT avec redirections et évasion de sécurité

Les chercheurs en cybersécurité ont identifié une campagne de malspam qui profite de la réputation d'un domaine légitime pour se mettre entre l'utilisateur et l'infrastructure de l'agresseur, et ainsi livrer un Trojan (.NET) à distance appelé DesckVB RAT. Au lieu d'envoyer des liens directs à des serveurs malveillants, les attaquants commencent par un fichier HTML attaché qui redirige à travers le système de suivi de clic de Google DoubleClick et, à partir de là, relie d'autres redirections qui intègrent l'adresse e-mail de la victime encodée dans Base64 pour construire une page de tromperie très convaincante. La conséquence technique et pratique est que de nombreux outils de sécurité font implicitement confiance à la légitimité de domaines comme DoubleClick et peuvent donner moins d'alarme à ces chaînes de redirection.

Le flux d'infection est conçu pour échapper aux contrôles de base : un ZIP téléchargé depuis la page de tromperie contient un chargeur JavaScript qui décompresse et exécute un script PowerShell ; ce script télécharge un . Le chargeur NET qui agit comme stage, fait anti-analyse, désactive ou dégrade les contrôles de sécurité, établit la persistance et finalement injecte la RAT dans les processus de signature Microsoft en utilisant une technique de maintien de processus. Le malware modifie également l'environnement pour aveugler la télémétrie Windows en parkingant AMSI et ETW au niveau de l'API, configure les exclusions dans Microsoft Defender et utilise les sockets TCP bruts pour communiquer avec son serveur de commande et de contrôle. C'est une chaîne complète conçue pour rester silencieuse et persistante, avec des capacités d'exfiltration, une exécution à distance et un déploiement de charge supplémentaire.

Au-delà de la mécanique, l'aspect stratégique est ce qui rend cette campagne dangereuse : en utilisant un redirectionnaire légitime et un modèle automatiquement personnalisé avec le courrier et l'adresse de marque de la victime, les opérateurs n'ont pas besoin de créer des oignons portatifs pour chaque cible. Cela réduit les coûts et multiplie la portée de l'opération, augmentant le risque pour les organisations de toute taille. En outre, l'utilisation de techniques telles que l'injection dans les processus signés et le blindage AMSI/ETW complique la détection traditionnelle basée sur les signatures et les alertes statiques.

Les mesures défensives devraient combiner prévention, détection et réaction. Sur le front de l'email, implémenter et assurer la configuration correcte de l'authentification envoyée avec SPF, DKIM et DMARC réduit la probabilité de spoofing; le guide de référence DMARC est un bon point de départ à https: / / dmarg.org /. De plus, les voies postales qui sandbox attache et liens avant de les livrer ajoutent une couche critique qui peut bloquer les paquets ZIP contenant des chargeurs JavaScript ou HTA malveillants.

Dans les terminaux et les réseaux, il convient d'appliquer les principes de la liste blanche des applications (AppLocker, WDAC), les politiques de restriction pour l'exécution des scripts (force que .vbs, .hta et .js soient ouverts dans les éditeurs de texte utilisant GPO, comme l'ont recommandé plusieurs équipes de réponse), et le contrôle d'évacuation avec l'inspection TLS pour détecter les communications C2. Les solutions EDR modernes qui surveillent le comportement - par exemple, les API utilisées pour les manipulations de mémoire, les Crochets sur AmsiScanBuffer ou les modifications ETW - sont cruciales car des techniques telles que le "process holding" sont mieux détectées par des anomalies comportementales que par des signatures statiques (vous pouvez voir la catégorisation des techniques d'injection à la base MITRE ATT & CK en https: / / attack.mitre.org / techniques / T1055 /).

Il est également important d'implémenter des détections spécifiques : alertes sur la création des touches Run/RunOnce, placement des exécutables sur les dossiers de démarrage, appels aux API qui park AMSI / ETW, processus Windows qui chargent des processus de code inhabituels ou de frai avec des arguments PowerShell encodés dans Base64. Il est essentiel d'avoir des manuels d'intervention qui comprennent l'isolement de l'hôte, la capture de la mémoire et l'analyse médico-légale pour identifier les stades et le C2 pour contenir un tel engagement avant qu'il ne prospère.

Pour les utilisateurs finaux et les administrateurs : n'ouvrez pas .html, .zip ou des fichiers exécutables à partir de courriels non sollicités; vérifiez et envoyez des rapports internes lorsqu'il y a le moins de soupçons; et réduisez les privilèges de compte pour limiter ce qu'un RAT peut faire s'il est exécuté. La combinaison du contrôle du courrier, des politiques de mise en œuvre, du suivi du comportement et des plans de réponse rapide est la défense la plus efficace pour les campagnes qui exploitent la confiance dans les services légitimes et automatisent la tromperie.

Si vous souhaitez approfondir la façon dont fonctionne la protection au niveau Windows contre les injections et les balayages anti-malwares, la documentation technique sur AMSI et les API connexes offre un contexte utile pour les équipes de défense: https: / / learn.microsoft.com / fr-us / windows / win32 / api / amsi /. La mise en œuvre de ces recommandations réduit la superficie exploitée par les campagnes qui comptent sur des domaines réputés pour cacher leur infrastructure malveillante.