Programmes ScreenConnect : des chevaux de Troie qui installent plusieurs RAT simultanément

Auteurs : Ilia Dafchev, Eliad Kimhy

• Augmentation des abus de ScreenConnect : depuis mars 2025, Acronis TRU a observé une augmentation des attaques exploitant des programmes d'installation de ConnectWise ScreenConnect infectés par des chevaux de Troie pour obtenir un accès initial aux organisations américaines. Nous observons une tendance continue et durable dans l'utilisation abusive des outils RMM, qui continue d'attirer les attaquants, peut-être en raison de son efficacité.

• Programmes d'installation ClickOnce évasifs : les attaquants utilisent désormais un programme d'installation ClickOnce pour ScreenConnect, qui n'a pas de configuration intégrée et récupère plutôt les composants au moment de l'exécution. Cette évolution rend les méthodes traditionnelles de détection statique moins efficaces et complique la prévention, laissant aux défenseurs peu d'options fiables.

• Déploiement automatisé de deux RAT : immédiatement après l'installation de ScreenConnect, les attaquants utilisent ses fonctionnalités d'automatisation pour rapidement déployer deux chevaux de Troie d'accès à distance : le célèbre AsyncRAT et un RAT personnalisé basé sur PowerShell. Ce double déploiement peut servir de redondance, de test d'outil ou refléter une infrastructure partagée entre plusieurs acteurs malveillants.

• RAT PowerShell personnalisé : l'équipe TRU a découvert un nouveau RAT fait maison, non répertorié dans les référentiels open source, qui effectue une reconnaissance du système, exfiltre les données via Microsoft.XMLHTTP et utilise plusieurs techniques d'obfuscation. Sa base de code unique suggère qu'il a été développé par l'attaquant, potentiellement pour échapper à la détection basée sur la signature.

• Évolution des chaînes d'infection : deux semaines après la compromission, les attaquants ont mis à niveau leur chaîne d'infection pour utiliser des chargeurs par lots et VBS qui récupèrent et exécutent des assemblages .NET codés afin de déployer AsyncRAT, démontrant ainsi leur adaptabilité et l'évolution de leur infrastructure.

• Ingénierie sociale et réutilisation d'infrastructures : les programmes d'installation malveillants sont distribués à l'aide de noms de fichiers imitant des documents officiels ou financiers, probablement par phishing. Les cybermenaces réutilisent également des machines virtuelles Windows Serveur 2022 préconfigurées (avec des noms d'hôtes cohérents) dans le cadre de plusieurs campagnes, ce qui permet un redéploiement rapide et une rotation de l'infrastructure.

• Points à retenir pour la défense : les organisations doivent surveiller de près l'utilisation des outils RMM et examiner de près les déploiements de ScreenConnect.

Au cours des derniers mois, Acronis TRU (Threat Research Unit) a identifié plusieurs campagnes actives et en cours tirant parti des versions trojanisées de ConnectWise ScreenConnect pour obtenir un accès initial aux réseaux des victimes et compromettre les machines cibles. Nos recherches montrent que la fréquence de ces campagnes a augmenté depuis mars 2025 et qu'à l’heure actuelle, la plupart des entreprises victimes se trouvent aux États-Unis, bien qu'il n'y ait actuellement aucune indication de l'endroit où les acteurs malveillants sont basés.

Bien que l'utilisation de ConnectWise ScreenConnect pour établir un point d'ancrage initial ne soit pas un phénomène nouveau, ces campagnes récentes introduisent plusieurs changements, tels que le déploiement de plus petits programmes d'installation ClickOnce au lieu des programmes d'installation complets. Ces programmes d'installation ClickOnce sont plus évasifs que les programmes d'installation précédemment observés, car ils ne reposent plus sur une configuration intégrée, ce qui offre moins de possibilités de détection. Une fois installés, les attaquants sont en mesure de prendre le contrôle de la machine compromise, ce qui leur permet d'installer d'autres malwares, de voler des informations, d'établir une persistance et de se déplacer latéralement sur le réseau.

L'utilisation abusive de logiciels de surveillance et de gestion à distance (RMM, Remote Monitoring and Management) tels que ScreenConnect devient de plus en plus courante, ce qui s'ajoute à la liste croissante d'outils légitimes détournés à des fins malveillantes. Dans ces types d'attaques, les programmes d'installation ScreenConnect sont souvent signés et apparaissent comme des applications de confiance, mais accordent à l'attaquant un contrôle étendu sur la machine compromise.

Les équipes informatiques utilisent généralement ScreenConnect pour accéder à distance aux systèmes pour le support ou l'intervention sur incidents. Les acteurs malveillants peuvent utiliser le logiciel RMM comme une arme par de multiples moyens, allant de l'exploitation des vulnérabilités au piratage ou à l'utilisation abusive de solution légitime. Quel que soit le cas, le résultat final est un exécutable qui relie la machine de la victime à un serveur contrôlé par l'attaquant. Les attaquants peuvent attendre des jours, voire des semaines, avant de passer à l’action, c'est-à-dire tant que le logiciel RMM malveillant n'est pas détecté.

Cette recherche examine les campagnes récentes qui exploitent ScreenConnect pour l'accès initial et détaille le malware déployé après la compromission. Les équipes de sécurité peuvent utiliser les conclusions et les recommandations décrites ici pour renforcer les défenses et contrer des menaces similaires.

L'attaque commence par un exécutable malveillant nommé agreement_support-pdf.Client.exe, qui semble avoir été téléchargé via le navigateur Microsoft Edge. Ce fichier est un programme d'installation ClickOnce, déguisé en document de support légitime, une méthode d'ingénierie sociale souvent utilisée pour inciter les utilisateurs à exécuter un code non fiable. L'attaque est probablement née dans le cadre d'une campagne d'ingénierie sociale, probablement diffusée par phishing par e-mail, mais peut-être aussi par d'autres moyens.

Lors de l'exécution, le programme d'installation lance ScreenConnect.ClientSetup.exe, qui, une fois installé, connecte la machine infectée au serveur C2 des attaquants.

Comme mentionné, ces programmes d'installation diffèrent des attaques précédentes impliquant ScreenConnect en ce qu'ils utilisent un programme d'installation ClickOnce. Cette version du programme d'installation est de plus petite taille et n'a pas de configuration intégrée. Au lieu de cela, il se connecte directement au serveur ScreenConnect configuré, en téléchargeant les composants et les configurations nécessaires pour procéder à l'installation. Cela améliore considérablement l'évasivité des programmes d'installation. Dans les itérations précédentes de ces attaques, une solution de sécurité pouvait rechercher des phrases spécifiques trouvées dans la configuration intégrée afin de détecter et de bloquer les exécutions suspectes de ScreenConnect. Cela n'est cependant plus possible dans cette nouvelle version. Les deux seules méthodes de prévention fiables restantes seraient de mettre sur liste noire le domaine C2 (qui est difficile à connaître à l'avance), ou d'entièrement bloquer ScreenConnect.

Les chercheurs de TRU ont observé l’adresse malveillante via les paramètres d'installation présents dans le programme d'installation. Le programme d'installation a été exécuté avec les paramètres : e=Support&y=Guest&h=morco[.]rovider[.]net&p=8041 qui se connecte à un domaine contrôlé par l'attaquant, morco.rovider[.]net. Le domaine a été récemment enregistré et est hébergé sur un serveur privé virtuel (VPS) associé à stealthrdp[.]com. Il a également été observé qu'il distribuait d'autres échantillons malveillants, ce qui indique qu'il fait partie d'une infrastructure de campagne de malwares plus vaste.

Cette attaque exploite un type de programme d'installation sur site pour ScreenConnect. Étant donné que les installations sur site doivent être indépendantes de l'infrastructure cloud, ConnectWise fournit aux clients les moyens de configurer à la fois un serveur et des clients au sein de leur réseau, sans avoir à s'appuyer sur des composants cloud. Ce système comporte deux composants, un programme d'installation de serveur et un programme d'installation de client. Dans les applications légitimes, le programme d'installation de serveur est configuré avec une adresse et peut également créer des programmes d'installation pour les clients.

Dans cette attaque, les attaquants ont probablement obtenu une version piratée du programme d'installation du serveur, ce qui leur a permis de modifier l'adresse du serveur. Cette modification permet aux attaquants de créer des programmes d'installation qui se connectent à leur propre serveur ScreenConnect malveillant tout en apparaissant légitimes aux yeux des solutions de sécurité. La détection est difficile sans connaître l'adresse du serveur intégré.

Avec ScreenConnect installé et connecté au serveur C2 de l'attaquant, un modèle d'attaque complexe se déroule sur une période d'environ deux mois. Les chercheurs de TRU ont analysé la progression de l'attaque au fil du temps et ont découvert que l'attaquant déployait plusieurs RAT simultanément et les utilisait de manière interchangeable. L'un d’eux était un RAT basé sur PowerShell avec des fonctionnalités de base, tandis que les autres étaient des outils bien établis et largement utilisés, tels qu'AsyncRAT. Ce chevauchement ne permet pas de savoir si un seul attaquant est responsable ou si l'infrastructure est partagée entre plusieurs opérateurs, l'accès étant vendu à plusieurs personnes qui peuvent ne pas se connaître.

Au fur et à mesure de l'installation de ScreenConnect, deux charges actives sont déposées en quelques minutes. Cela est dû à la fonctionnalité de ScreenConnect qui permet aux administrateurs de définir des automatisations spécifiques, telles que l'exécution d'un script lorsque l'utilisateur se connecte pour la première fois au serveur. Cela permet à l'attaquant d'installer automatiquement un ensemble de différents RAT en quelques minutes après l'installation.

Pour sa première charge active malveillante, l'attaquant utilise ScreenConnect pour déposer et exécuter un fichier lot, BypaasaUpdate.bat. Ce fichier lot initial agit comme un téléchargeur et un réaffecteur pour toutes les étapes restantes de la première infection de la charge active, téléchargeant puis extrayant un fichier zip contenant :

• 1.txt : un fichier texte contenant AsyncRAT.

• Pe.txt : un fichier texte contenant un mécanisme de contournement et de persistance .NET AMSI.

• Skype.ps1 : un script PowerShell pour traiter et charger les fichiers txt ci-dessus en tant qu'assemblages .NET.

• b.bat : un fichier script utilisé pour exécuter le script PowerShell ci-dessus.

Une fois les fichiers extraits, b.bat est appelé en premier, ce qui exécute à son tour Skype.ps1. Skype.ps1 charge ensuite pe.txt et 1.txt en tant qu'assemblages .NET en mémoire.

Le dernier, 1.txt, est AsyncRAT, un cheval de Troie d'accès à distance (RAT) bien connu et populaire, largement utilisé par les testeurs de pénétration légitimes et les cybercriminels, tandis que le premier, pe.txt, est utilisé à la fois pour contourner l'AMSI (anti-malware scan interface, interface d'analyse anti-malware), permettant ainsi au script de continuer à exécuter des scripts malveillants, et pour établir la persistance.

La persistance est obtenue en créant un fichier supplémentaire appelé Microsoft.vbs, dont le seul but est de réexécuter Skype.ps1. Ensuite, une tâche planifiée est créée pour exécuter Microsoft.vbs, une seule fois, une minute plus tard. Lorsque la tâche s'exécute, Microsoft.vbs exécute à nouveau Skype.ps1, qui à son tour charge à nouveau AsyncRAT et pe.txt, ce qui définit une nouvelle tâche planifiée une minute plus tard, créant ainsi un mécanisme de persistance où AsyncRAT est rechargé en mémoire chaque minute, et l'ensemble du mécanisme de persistance est recréé.

Bien que cela signifie que Skype.ps1 tente de charger AsyncRAT en mémoire toutes les minutes, 1.txt (alias AsyncRAT) recherche un mutex spécifique, AsyncMutex_al026, pour voir si AsyncRAT est déjà en cours d'exécution, et si tel est le cas, il sort. De cette façon, AsyncRAT ne sera pas rechargé toutes les minutes, mais uniquement lorsqu'il n'est pas déjà en cours d'exécution.

Il convient également de noter que ce mécanisme de persistance est incroyablement bruyant. L'exécution d'un script PowerShell toutes les minutes laisse un nombre énorme de traces, ce que les attaquants corrigeront à une phase ultérieure de l'attaque.

Quelques minutes après le chargement et la configuration d'AsyncRAT, nous observons qu'un autre script est déposé et exécuté par ScreenConnect. Mais alors que le premier script a déposé un outil bien connu, AsyncRAT, ce deuxième script a déposé une nouvelle charge active surprenante : une sorte de RAT fait maison. Ce RAT est écrit sous forme de script PowerShell et fournit des fonctionnalités de base telles que l'exécution de programmes, le téléchargement et l'exécution de fichiers et un simple mécanisme de persistance. Il ne ressemble à aucun outil open source que nous avons vu dans le passé, et il a peut-être été écrit par le pirate.

Il s'agit très probablement d'une autre exécution automatique, ce qui soulève la question suivante : pourquoi déposer deux RAT sur la machine infectée ? Il n'y a pas de réponses claires, mais il y a quelques possibilités :

1.      Les attaquants pourraient agir avec une grande prudence. Si un outil est détecté, un autre peut être utilisé pour maintenir une porte dérobée. Ou peut-être que ce deuxième RAT est plus évasif que le premier.

2.      Les attaquants pourraient être en train de tester un nouvel outil qu'ils écrivent et ont décidé de déposer les deux.

3.      Plusieurs attaquants utilisent la même infrastructure (ou ont vendu l'accès à la même infrastructure).

Quelle que soit la raison, nous voyons une nouvelle adresse C2, et nous avons vu les deux RAT utilisés dans les semaines suivantes dans notre analyse de l'attaque.

La chaîne d'attaque semble également plus simple : elle commence par un fichier JavaScript, apparemment nommé d'après le port de l'adresse C2, qui est déposé dans un dossier temporaire. Le script exécute alors essentiellement l'ensemble du RAT en tant que commande PowerShell.

La commande elle-même, lorsqu'elle est désobfusquée, révèle un script qui agit comme une sorte de RAT fait maison, qui désactive l'AMSI, met en place un auditeur pour les commandes, effectue une reconnaissance initiale, établit la persistance et lance une boucle infinie qui agit comme un gestionnaire de commandes.

Le script effectue d'abord une reconnaissance du système, en collectant des informations concernant les noms d'antivirus en interrogeant WMI pour les solutions antivirus installées, ainsi que le nom et l'architecture du système d'exploitation, l'UUID, le nom de l'ordinateur et le nom d'utilisateur. Tout cela est ensuite balisé sur le C2 de l'attaquant, à l'aide de Microsoft.XMLHTTP, qui est également utilisé pour écouter les commandes. Il s'agit là d'une utilisation assez intéressante de cet objet COM, car il est plus couramment utilisé dans les scripts VBS. Il est possible que l'attaquant ait choisi d'utiliser cette commande plutôt que les commandes intégrées de PowerShell afin d'échapper à la détection, car de nombreuses solutions de sécurité rechercheront les commandes PowerShell qui établissent des communications Internet.

Le gestionnaire de commandes est composé d'une boucle qui envoie des requêtes POST au serveur C2 toutes les trois secondes et attend une réponse. La boucle exécute ensuite les commandes suivantes, en fonction de la réponse :

1.      RF (run file, fichier d’exécution) : cette commande permet à l'attaquant d'écrire un fichier binaire dans un dossier temporaire et de l'exécuter.

2.      TR : reçoit le code PowerShell de l'attaquant, l'écrit sur le disque sous forme de fichier .ps1 et l'exécute. Elle met par ailleurs en place un mécanisme de persistance à l'aide d'un script VBS. Le script VBS est configuré pour s'exécuter au démarrage via le dossier de démarrage et est utilisé pour lancer le script PowerShell. Il peut être utilisé pour mettre en place un certain nombre de backdoors supplémentaires, ou tout autre script que l'attaquant pourrait vouloir faire persister.

3.      Exc : permet au pirate d'écrire un script VBS dans un dossier temporaire et de l'exécuter.

4.      Sc : effectue une action similaire à la commande RF ; cette commande est toutefois utilisée pour écrire en texte brut et probablement utilisée pour écrire et exécuter des scripts.

5.      Cl : termine la boucle et ferme le script.

6.      Un : termine la boucle et ferme le script.

La persistance est établie en créant une copie de 8911.js (le fichier JavaScript qui lance à l'origine le script RAT) dans le dossier de démarrage sous le nom FirefoxUpdate.js.

Le script utilise plusieurs techniques d'obscurcissement pour échapper à la détection et entraver l'analyse. Les noms de variables et de fonctions sont délibérément longs, absurdes ou sans rapport avec leur objectif, tandis que l'exécution des commandes est cachée derrière des alias calculés dynamiquement. Les charges actives clés, telles que le script de persistance VBS, sont stockées sous forme de tableaux de codes de caractères et ne sont décodées qu'au moment de l'exécution, et le contournement AMSI est stocké sous forme d'assemblage .NET codé en base64. Le gestionnaire de commandes utilise des codes courts et cryptés (comme RF, TR, SC) au lieu de noms descriptifs, et les fichiers déposés reçoivent des noms aléatoires ou basés sur GUID.

Le script exploite des objets Windows intégrés tels que Microsoft.XMLHTTP pour la communication C2 et Microsoft.VisualBasic.Interaction pour la création d'objets, se fondant dans une activité légitime. Les données de reconnaissance du système sont exfiltrées via des en-têtes HTTP plutôt que des paramètres évidents, et les messages d'erreur sont supprimés pour éviter d'attirer l'attention. Ensemble, ces stratégies d'obfuscation en couches rendent le véritable comportement du script plus difficile à détecter et à prévenir automatiquement pour les solutions de sécurité.

Dans l'ensemble, ce script est assez intéressant à voir, d'autant plus que nous n'avons pas pu le trouver utilisé ailleurs. Alors que certaines parties du code semblent être réutilisées, ce RAT fait maison semble être principalement écrit par l'attaquant. Cela peut être un avantage pour l'attaquant, car il peut affiner l'outil en fonction de ses besoins et éviter la détection sur la base de modèles ou de signatures spécifiques et bien connus, alors que d'un autre côté, il peut manquer de certaines des fonctionnalités les plus avancées offertes par d'autres outils. Il s'agit, dans l'ensemble, d'une découverte intéressante, et cela soulève la question de savoir si plus d'un attaquant utilise la même infrastructure.

Deux semaines après la compromission initiale, les acteurs de la menace ont tiré parti de leur accès ScreenConnect pour déployer une nouvelle version d'AsyncRAT, ainsi qu'une chaîne d'infection repensée.

La chaîne d'infection mise à jour commence par un script de traitement par lots qui lance MicrosoftUpdate.vbs, un simple conteneur pour un PowerShell one liner qui fonctionne comme un chargeur. Ce script PowerShell télécharge deux fichiers, logs.ldr et logs.ldk, dans le répertoire C:\Users\Public.

Les deux fichiers, logs.ldk et logs.ldr, sont des assemblages .NET codés. Le script PowerShell décode et exécute d'abord logs.ldk, qui est une DLL .NET nommée Obfuscator.dll et sert un double objectif : établir la persistance et agir en tant que chargeur secondaire pour logs.ldr, la charge active AsyncRAT réelle.

La persistance est obtenue grâce à une tâche planifiée nommée « Skype Updater », configurée pour exécuter C:\Users\Public\Ab.vbs à l'ouverture de session de l'utilisateur. Ce script VBS reflète le comportement de MicrosoftUpdate.vbs, fonctionnant comme un wrapper qui appelle le chargeur basé sur PowerShell.

AsyncRAT (logs.ldr) est finalement décodé et chargé en mémoire via l'appel de méthode Obfuscator.dll [Obfuscator.A]::Main($f2) utilisé à l'intérieur du script powershell.

L'instance AsyncRAT nouvellement déployée présentait une configuration mise à jour. Elle a notamment utilisé une nouvelle chaîne mutex : « AsyncMutex_alosh20215 » et a communiqué avec le serveur de commande et de contrôle (C2) sur les ports suivants : 4501, 4502 et 4503.

L'infrastructure C2 est restée inchangée, toujours hébergée à 185.196.9.158.

Plusieurs jours après le déploiement de l'AsyncRAT mis à jour, nous avons observé qu'un RAT supplémentaire était livré via WMI. L'activité s'est produite quelques minutes seulement après l'exécution des scripts liés à AsyncRAT, et bien qu'une attribution définitive ne soit pas possible avec les preuves disponibles, la proximité temporelle suggère une forte probabilité que les deux soient liés.

Le processus WmiPrvSE.exe a été observé en train d'exécuter une commande PowerShell qui utilisait Invoke-WebRequest pour télécharger un script nommé NvContainerRecovery.ps1 dans le répertoire C:\Users\Public. Immédiatement après, le même processus WMI a de nouveau invoqué PowerShell pour exécuter le script téléchargé.

Le script NvContainerRecovery.ps1 établit d'abord la persistance en créant un script VBS dans le dossier Démarrage. Ce fichier VBS agit simplement comme un wrapper pour exécuter le même script PowerShell à chaque ouverture de session utilisateur.

Après la configuration de la persistance, le script PowerShell charge une DLL .NET implémentant le processus d'évidement. Cette méthode est utilisée pour injecter un autre assemblage .NET dans une instance générée de RegAsm.exe. L'assemblage injecté est responsable du déchiffrement et du chargement d’une charge active .NET finale, identifiée comme PureHVNC RAT.

L'instance PureHVNC est configurée pour se connecter à 169.156.208.185 sur le port 8020.

Une enquête sur l'infrastructure d'attaque révèle plusieurs domaines différents qui, selon nous, pourraient être utilisés par l'attaquant. Ceux-ci incluent, en plus de morco.rovider.net, deux autres domaines : gaza.rovider.net et lightc.rovider.net. Les deux sont liés aux installateurs ScreenConnect, avec des serveurs hébergés sur stealthrdp.com. Ils sont observés en relation avec XWorm et DCRat, ce qui peut indiquer une infrastructure d'attaque plus large que ce que nous avons observé jusqu'à présent.

Nous avons identifié de nombreux cas impliquant l'utilisation de programmes d'installation ScreenConnect qui se connectaient à des serveurs ScreenConnect sur site probablement piratés. La grande majorité de ces incidents se sont produits aux États-Unis, et les noms de fichiers des programmes d'installation suggèrent fortement une distribution par phishing ou d'autres techniques d'ingénierie sociale.

Les exécutables étaient généralement nommés pour apparaître comme des documents légitimes, susceptibles d'inciter les utilisateurs à les exécuter. En voici quelques exemples :

• Social_Security_Statement_Documents_386267.exe MD5: 2EECA7166487DDC0B4C36B718DF31C93

• ssa_view.exe MD5: C92D37BC45F6088458C70C1CF53C06F6

• Social-Security-Available-Statement-3025147.ClientSetup.exe MD5: BA261666A657BDE2E8E071EE6E7D5357

• agreement_support-pdf.Client.exe MD5: 34ED21AC2399CC08BD051A283FD59FCE

• SSADocumentViewer-nXpJ2.exe MD5: A58719D9DDE0179C25215637766C2AB0

• 2024 BUSINESS SCHEDULE COMPLETE ORGANIZERpdf.exe MD5: 316119C77032A24822A64C86C1E4B2A0

Ce modèle de dénomination indique une tentative claire d’usurper l'identité de documents officiels ou financiers, principalement sur le thème de la sécurité sociale ou des accords juridiques.

Dans ces cas, nous avons principalement observé le déploiement d’AsyncRAT et de Remcos RAT.

En ce qui concerne Remcos, nous avons identifié que l'acteur malveillant a réutilisé la même machine virtuelle dans plusieurs campagnes, bien qu'elle ait été hébergée à différentes adresses IP. Selon les résultats de Shodan, la machine virtuelle fonctionnait sous Windows Server 2022, avait le RDP activé et hébergeait un serveur ScreenConnect. Le nom d'hôte de la machine était cohérent entre les observations : WIN-BUNS25TD77J.

En recueillant des échantillons supplémentaires à partir de sources de renseignements sur les menaces, nous avons également découvert un autre nom d'hôte commun utilisé par diverses campagnes : COPY-OF-VM-2022. Il semble que les attaquants aient préconfiguré des machines virtuelles qu'ils hébergent à différentes adresses, ce qui leur permet de configurer rapidement et de modifier l'infrastructure.

Réseau :

• 169.156.208.185

• 185.196.9.158

• 185.196.8.100

• morco[.]rovider[.]net

• hxxps://eywordvailabom[.]com/sa/16-05.txt

• hxxps://systemwindowsupdate[.]com/alosh/logs.ldk

• hxxps://guilloton[.]fr/x.zip

Mutexes :

• AsyncMutex_al026

• AsyncMutex_alosh20215

Fichiers :

• agreement_support-pdf.Client

67A32455A94B3396AD956CBDDA81D8ED1CD3727315159E025299057118DEB6AC

• Skype.ps1

BB182B8545B8C825811C6D09C738C230FE54BC96ADF1F10A3683B7E5294B5289

• 1.txt

C260779FB1C9FF775739F6CF1853C9C33131ECF176737F6AF26B0AC60A6081DC

• Pe.txt

53AAD05571E86F22E2C75ED4FA6C8F553C3EBD58DCA8BE9FE8A143784AEF29D7

• BypaasaUpdate.bat

973A02FF597864E3920ED1041D24D629A0762CDE932EB69AEA066CD2235404F8

• Pe.txt décodé (correctif Amsi)

1DA9428DF9A04E6CA1D836D1E941B61E30B6AF952D24D7B451A8D1E906ECE0C0

• 1.txt décodé (AsyncRAT)

E7C482E66EFA99EA98E2C79BEB0A31C5120B73E4951A5F33133066B17E009DA1

• logs.ldr

A4BF71F97C3A2F3FDA496D204B5E744D6F1DA8D888ACE3867DA08D072AF01245

• logs.ldk

6FA549F446A541856784695DB808DE2E5C67DA271C64ECC966C7C0B02622D58B

• Logs.ldr (décodé)

10EEB21202E7EB055F9FAC37DAB96F86DFEB9F28C0510F33E4324D12087CACF2

• Logs.ldk (décodé)

6AE546DA4D6D78D4262F3A2FF5E4F58C345294383ED9FF5E4DAA52466FE79E2F

• Powershell RAT

B82E616E956A956FF5D9AFFCC13C907CF5054439FB5EE5A6F7AA5FFEE030DA56

• NvContainerRecovery.ps1

EF66D80511CD46C5173BF13E750C51114EE891E833F4F256A23E7DE4790ACC73

• PureHVNC RAT

068504CB4AC18D504247EF7A2C19A76B17A85E795B52E541FA8A49DE69B91F01