Michel Elford

Michael is a cybersecurity professional that is passionate about 
malware analysis and reverse engineering.

Une analyse plus approfondie du fichier exécutable a permis de confirmer que le fichier était malveillant.

Dans cet article de blog, je vise à partager les résultats de l'enquête, dans le but de sensibiliser le public aux techniques qui peuvent être utilisées pour analyser efficacement les logiciels malveillants en général et analyser spécifiquement ASyncRAT.

Analyse ASyncRAT

Note: All malware analysis should be carried out in a sandboxed environment.

Voici la liste des outils qui ont été utilisés pour cette analyse :

• FlareVM
• PEStudio
• dnEspion
• Cyberchef
• Éboueur

En commençant l'analyse de la première étape du malware, la première étape a été de vérifier l'exécutable dans PEStudio, ce qui a confirmé que nous avions affaire à un fichier .NET . De plus, nous avons interprété l' entropie assez élevée comme un indicateur d'emballage de logiciels malveillants, où les logiciels malveillants ajoutent de la complexité pour rester non détectés par les solutions de sécurité.

Notre prochaine étape consistait à parcourir les chaînes du logiciel malveillant et à prendre note de tout élément étrange que nous pourrions vouloir approfondir un peu plus tard.

En examinant les chaînes, nous avons immédiatement identifié certaines chaînes qui semblent être obscurcies . En guise de note pour nous-mêmes, nous avons souligné que nous devrons peut-être déployer une « recherche et remplacement » plus tard.

Aller plus loin

Après avoir déterminé que le fichier a été écrit en .NET et noté les chaînes masquées, nous nous sommes ensuite tournés vers dnSpy , un débogueur .NET.

L'une des premières choses que nous avons remarquées était une différence de nommage. Le nom de l'exécutable sur l'hôte et le nom de l'exécutable affiché dans dnSpy sont complètement différents. La raison pour laquelle l'exécutable portant un nom complètement différent est intéressante est due au fait que de nombreux acteurs de la menace qui utilisent des logiciels malveillants les renomment afin qu'ils n'attirent pas autant l'attention et puissent être cachés sur l'hôte et exécutés silencieusement en arrière-plan afin que même si l'utilisateur remarque que quelque chose d'étrange se passe avec son système, il ignorera le fichier en pensant que c'est normal et ne déclenche aucune alarme avec l'utilisateur et son AV.

En parcourant le code, il existe une fonction de remplacement pour une chaîne que nous avions notée précédemment. Maintenant que nous sommes certains de ce qui remplace le modèle d'obscurcissement, nous pouvons vérifier quelles sont ces chaînes, ce qui pourrait éventuellement nous donner un indice sur ce qui se passe.

Tirer sur le fil

Pour analyser les chaînes masquées, nous avons utilisé CyberChef . Dans CyberChef, nous avons utilisé la fonctionnalité "Rechercher/Remplacer" pour exécuter la fonction de remplacement trouvée dans le code. Cela nous a permis de voir le texte clair de ce qui était obscurci, ce qui nous a permis de mieux comprendre ce qui se passait dans le code.

Le résultat final de l'exercice ci-dessus nous a donné la version désobfusquée des chaînes contenant "Load" et "Invoke". Cela montrait que quelque chose allait être chargé et exécuté ("invoqué") par le code contenu dans l'exécutable.

Si, à tout moment, vous n'êtes pas sûr des actions que ces méthodes effectuent, la meilleure chose à faire est de rechercher sur Google et de trouver des documents. Cela peut prendre du temps au début, mais c'est une partie importante de l'analyse des logiciels malveillants.

À ce stade de l'analyse, nous avions accumulé suffisamment de résultats pour commencer à esquisser la trajectoire du flux d'exécution du malware. Nous avions identifié que le logiciel malveillant chargeait et exécutait quelque chose, et que le logiciel malveillant était emballé et contenait des données exécutables que nous verrions dans la prochaine étape de l'analyse.

Chasse au caché

L'outil Garbage Man est utilisé pour l'analyse de tas - une technique qui permet aux analystes d'intervenir et d'observer pendant que le malware .NET se démêle.

L'analyse du logiciel malveillant dans Garbage Man a aidé à extraire les données cachées qui composaient le deuxième exécutable dans le premier exécutable.

Afin d'analyser plus en profondeur le logiciel malveillant, nous avons exécuté le logiciel malveillant d'origine trouvé sur l'hôte dans Garbage Man. Pour commencer, nous avons ajouté un délai de 300 ms avec 10 instantanés pris à des intervalles de 100 ms.

Nous avons ajouté le délai pour laisser le temps au processus de commencer à s'exécuter et ajouté les instantanés et les intervalles supplémentaires afin que nous puissions comparer la différence entre les intervalles si nécessaire.

Une fois que Garbage Man a exécuté le fichier, nous avions ces options :

• Parcourez le tas manuellement et examinez les chaînes et les valeurs contenues dans l'exécutable
• Utilisez la fonction de recherche pour parcourir tous les instantanés. Recherchez spécifiquement les octets qui commencent par la valeur de MZ - qui est l' en-tête PE pour les exécutables et les fichiers dll, puis classez-les par taille dans l'ordre décroissant. La fonction de recherche nous donne une liste de résultats, et nous pouvons enregistrer les fichiers binaires avec des en-têtes MZ et les enregistrer pour une analyse plus approfondie.

Deuxième étape

En fouillant dans notre stage2.exe, nous avons constaté que la vérification de ses chaînes mettait en évidence certaines API Win32 remarquables que les logiciels malveillants exploitent . Certaines API qui ont sauté étaient liées à des processus de manipulation [ T1055 ], en particulier dans ce cas, le creusement de processus [ T1055.012 ] - une technique contradictoire pour créer un processus légitime en pause, puis échanger sa mémoire avec des contenus malveillants.

Comme notre deuxième étape était à nouveau dans le monde .NET, nous avons utilisé dnSpy pour creuser un peu plus profondément. Lors de l'ouverture de l'exécutable, nous avons rencontré beaucoup d' informations que nous devions faire passer. Comme la première étape, la convention de dénomination de la deuxième étape était également suspecte.

En examinant la sortie de dnSpy, nous avons découvert une section complètement différente des autres parties du code car elle est obscurcie et remplit apparemment une fonction en mémoire - qui sont toutes deux des techniques utilisées pour échapper à la détection [ T1140 ] .

Nous avons une fois de plus utilisé Garbage Man pour observer sournoisement comment le logiciel malveillant se dénouait. Cependant, si vous souhaitez une technique alternative pour désobscurcir cette partie du code, vous pouvez utiliser de4dot qui peut également le présenter dans un format plus facile à lire.

Ensuite, dans Garbage Man, l'objectif était de récupérer la troisième étape cachée. Notre technique antérieure pourrait être déployée ici à nouveau, en exécutant le binaire et en recherchant les en-têtes MZ.

Nous avons trouvé un exécutable et l'avons enregistré sous "stage3.exe". Nous l'avons ensuite emballé et envoyé à PEstudio (il y a aussi des informations pour procexp.sys contenues dans ceci mais nous n'allons pas nous concentrer là-dessus pour le moment).

Troisième étape

Lors de la vérification de l'exécutable de troisième étape dans PEstudio, nous avons de nouveau observé qu'il s'agissait d'un fichier .NET et qu'il contenait des chaînes et des API suggérant qu'il tentait d'établir une connexion réseau avec une source externe, comme l'API Send . C'était un gros indice qu'il s'agissait d'un cheval de Troie d'accès à distance ; Je sens un RAT [ TA0011 ] !

Après avoir jeté un coup d'œil rapide aux chaînes de la troisième étape via PEstudio, nous sommes revenus à l'ancien dnSpy fiable. En parcourant la troisième étape, nous avons identifié que le cryptage AES était utilisé pour coder le port et l'adresse IP/domaine qui constituaient la commande et le contrôle (C2) de l'adversaire. Nous avions à coup sûr affaire à un RAT, et nous voulions rassembler les IoCs associés à ce chiffrement.

Nous définissons un point d'arrêt dans dnSpy où le décryptage AES a été effectué, puis exécutons le débogueur pour cela afin de trouver la chaîne décryptée. L'utilisation d'une technique « stop-start » avec des points d'arrêt dans un débogueur permet à un analyste de logiciels malveillants d'arrêter le logiciel malveillant à des moments opportuns pendant qu'il se décode ou se décrypte. Cela nous permet de comprendre ce que fait le logiciel malveillant pendant qu'il le fait.

Lorsque nous sommes arrivés à notre point d'arrêt, l'exécution du logiciel malveillant a été interrompue. Maintenant, nous avons délicatement laissé le malware progresser une étape à la fois en utilisant le bouton Step over. Nous l'avons fait jusqu'à ce que le logiciel malveillant entame finalement sa phase de décryptage, et nous avons d'abord reçu les ports utilisés par ce RAT.

Lorsque nous avons enjambé les différentes sections, nous avons pu voir que pour ce RAT, il utilisait les ports "6606, 7707, 8808" et, finalement, nous avons démêlé le RAT jusqu'à ce qu'il nous livre le serveur contradictoire auquel il a renvoyé : "109.206.241 [.]84 ».

Se défendre contre les RAT

Nos solutions varient, mais la première étape consiste à recommander de bloquer cette adresse IPv4 publique au niveau du pare-feu de l'organisation afin que le RAT ne puisse plus baliser.

Les conseils pour se défendre contre les RAT sont vraiment des conseils pour les logiciels malveillants en général :

• Le conseil principal est de former le personnel pour qu'il vérifie ce qu'il télécharge. Qu'il s'agisse d'une pièce jointe à un e-mail ou d'un site qui promet d'accélérer le fonctionnement de leur ordinateur s'ils exécutent quelque chose, la formation de sensibilisation à la sécurité est la meilleure et la première couche de défense que nous vous conseillons de privilégier.
• Tirez parti de la télémétrie du réseau pour essayer de surveiller les activités inattendues. Qu'il s'agisse d'un VPN, d'un pare-feu ou d'un netflow plus axé sur la sécurité, garder un œil sur le trafic entrant et sortant aidera à détecter les comportements anormaux. De plus, cultiver une liste de refus bien entretenue pour les adresses malveillantes nouvelles et émergentes ne peut être qu'une bonne chose.
• Les bons outils de sécurité sont les parfaits ennemis de nos adversaires. Déployez ce qui fonctionne pour votre organisation, veuillez simplement déployer quelque chose . Une machine sans aucune solution de sécurité est une machine qui présente un risque ingérable et inacceptable pour votre entreprise.

Big thanks to Matthew Brennan and Chad Hudson for help and guidance. 
Hopefully this writeup has helped show examples of some good tools and 
techniques that can be used to help decrypt and understand what is going on 
with other .NET executables in the future.