# La rétro-ingénierie de code malveillant dans la CTI - Analyse de l’évolution d’une chaîne d’infection

Charles Meslay
charles.meslay@sekoia.io

Sekoia.io

**Résumé. Cet article a pour but de présenter le rôle de la rétro-ingénierie**
des codes malveillants dans le domaine du renseignement sur la menace
cyber ou Cyber Threat Intelligence (CTI). Après un bref rappel de ce
qu’est que la CTI, nous partirons d’un cas réel d’investigation autour de
la chaîne d’infection du code FlowCloud lié à un mode opératoire adverse
nommé « TA410 ». Cet article présentera les mécanismes de protection de
ce code : mécanismes anti-analyse et chiffrement des différentes étapes de
la chaîne d’infection. Les résultats de ces travaux seront ensuite utilisés
afin de créer une nouvelle règle de détection YARA qui permettra de
trouver un nouveau variant disposant de zéro de détection sur VirusTotal.

## 1 Introduction

**1.1** **Qu’est-ce que la CTI ?**

La Cyber Threat Intelligence (CTI) ou renseignement sur la menace
cyber correspond à l’étude des groupes d’attaquants informatique. Ce
domaine de recherche, multidisciplinaire, a pour but d’étudier les modes
opératoires adverses (MOA) dans le but de les détecter au plus tôt pour
se protéger de ceux-ci. La CTI s’articule autour de plusieurs domaines
d’expertise. Pour faciliter la compréhension, nous nous limitons ici à
uniquement trois d’entre eux.
Le premier n’est pas technique, mais lié à la connaissance stratégique.
Le but de ce domaine est d’étudier le contexte dans lequel sont effectuées
les attaques, qu’il s’agisse de campagnes étatiques ou cybercriminelles.
L’analyse des enjeux politiques entre pays peut ainsi permettre d’expliquer
certaines attaques et donc d’anticiper de futures opérations adverses. Cette
compétence intègre aussi une connaissance de l’organisation des groupes
d’attaquants. Cela peut aussi bien correspondre à l’étude de l’organisation
de groupes cybercriminels que l’organisation cyber d’un Etat.
Un deuxième domaine lié à la CTI est l’étude des groupes d’attaquants
via le suivi de leur infrastructure. Comme présenté lors de l’édition 2023


-----

2 La rétro-ingénierie de code malveillant dans la CTI

du SSTIC par Charles Hourtoule et Simon Msika [2], un MOA comme
Mustang Panda, réputé d’origine chinoise, peut être suivi via des spécificités dans la configuration de leurs serveurs : l’identification d’un motif dans
le certificat d’un serveur permet d’illuminer une partie de l’infrastructure
de l’attaquant. Ainsi, un suivi continu de cette infrastructure permettra
de détecter une compromission non pas via les traces laissées sur un poste
mais via les connexions réseaux.

Enfin, un dernier domaine est l’analyse des codes malveillants utilisés
par un MOA. Bien que les objectifs soient multiples, cette analyse permet
de documenter de façon précise les codes utilisés afin :

— d’en extraire des indicateurs de compromissions ;
— d’identifier des moyens de remédiations ;
— de rapprocher des menaces entre elles et ainsi de suivre une menace
dans le temps.

Cet article a pour but d’explorer ce dernier domaine. Nous tenterons
d’expliquer comment l’analyse de code via la rétro-ingénierie permet de
suivre l’évolution de codes malveillants via l’exemple du code FlowCloud
associé au mode opératoire TA410.

**1.2** **Présentation du MOA TA410 et de la chaîne d’infection**
**de FlowCloud**

TA410 est un MOA supposé d’origine chinoise actif depuis au moins
2019. Ce MOA a été pour la première fois documenté en 2020 par ProofPoint à l’occasion d’une campagne d’attaque contre des fournisseurs d’énergie aux États Unis [4]. La description de cette campagne par Proofpoint
fait état d’un implant nommé FlowCloud, qui donne un accès complet au
système compromis.

En avril 2022, les chercheurs d’ESET, ont décrit de façon détaillée
la chaîne d’infection et les fonctionnalités de FlowCloud [1]. La chaîne
d’infection est assez complexe mais est typique des chaines d’infection
habituellement rencontrées. Sans rentrer dans l’ensemble de la chaîne
d’infection, nous pouvons retenir que celle-ci commence par la création
d’un service qui exécutera une application vulnérable à du « DLL-sideloading » afin de charger une DLL malveillante. Cette DDL, nommée
XXXModule_dlcore0 charge une autre DLL qui elle-même déchiffre et
exécute un autre code qui chargera FlowCloud.


-----

C. Meslay 3

**1.3** **YARA, un outil de signature de code**

Dans les annexes de l’article de blog, ESET fournit des hashs de fichiers
qu’il est possible de récupérer sur VirusTotal ainsi que plusieurs « règles
YARA » dont une sur les techniques anti-analyses de FlowCloud. YARA
est un outil permettant d’effectuer des recherches dans des fichiers à partir
de règles dans lesquelles des recherches sur des motifs spécifiques sont
définis (qu’il s’agisse de chaînes de caractères ou directement basés sur
une suite d’octets). Des règles YARAs sont ainsi utilisées afin de « signer »
des codes (ou des sous-parties de codes).
Un des objectifs du travail de rétro-ingénierie est d’identifier des motifs
spécifiques aux maliciels afin de pouvoir les détecter et les classer.
C’est ce qui est fait ici par ESET en fournissant à la communauté une
règle YARA qui signe les mécanismes anti-analyse utilisés dans FlowCloud
(figure 1).

**Fig. 1. Règle YARA fournie par ESET Research**


-----

4 La rétro-ingénierie de code malveillant dans la CTI

Une règle YARA est généralement divisée en trois sections :
— la section condition est une expression booléenne qui définit la
logique de la règle en utilisant les variables définies dans la section
strings ;
— la section strings permet de définir des variables utilisables dans
la section condition ;
— la section meta permet de définir des metadonnées.
Cette règle vérifie la présence de deux choses :
— uint16(0) == 0x5a4d : qui correspond à la présence des octets
0x4d 0x5a au début du fichier. Il s’agit ici de vérifier la présence
de l’en-tête MZ spécifique aux fichiers PE sous Windows.
— la présence de la valeur $chunk_1 (via les mots clés
« all of them »). Cette variable contient une suite d’octets correspondant à une séquence particulière de code assembleur. L’auteur
de cette règle a précisé le sens de ces octets en commentaire.
L’intérêt de créer des règles YARA est multiple. Tout d’abord, d’un
point de vue détection, l’objectif est de pouvoir analyser les fichiers d’un
système au regard de ses règles afin d’identifier des codes malveillants.
Cela peut par exemple être utilisé par des EDR (« Endpoint Detection
Response » ou des antivirus). Un autre intérêt est de pouvoir suivre dans le
temps l’évolution des codes malveillants ou tenter de trouver de nouveaux
variants en soumettant ces règles à des bases de données de fichiers.
Il est important de noter que la création d’une règle YARA nécessite
toujours d’effectuer un compromis entre :
— définir des critères suffisamment précis pour être sûr qu’une règle
est spécifique à un code particulier, c’est à dire réduire au maximum
le nombre de faux positifs.
— être suffisamment générique afin de détecter, si possible, tous les
codes de cette famille, c’est à dire réduire au maximum le nombre
de faux négatifs.
Dans la suite de cet article nous montrerons la démarche que nous
avons adopté afin d’analyser des variants du chargeur de FlowCloud ainsi
que la création d’une règle YARA pertinente.

## 2 Suivi de la menace dans le temps via le chargeur de FlowCloud

L’article d’ESET contient des Indicateurs de Compromissions (« In_dicator Of Compromises » ou « IoC »). Parmis ces IoCs, des hashs de_


-----

C. Meslay 5

fichiers sont présents. L’un d’eux étant disponible sur VirusTotal,[1] nous
décidons de débuter notre investiguation par l’analyse de ce fichier.
Dans ce chapitre, nous présenterons les principales étapes de la rétroingénierie de ce code ainsi que d’autres variants connus dans le but de
comprendre les spécificités de ces codes. Nous pourrons ensuite en extraire
des motifs spécifiques pour créer notre propre règle YARA. Celle-ci sera
enfin utilisée pour tenter identifier de nouveaux variants.

**2.1** **Analyse du fichier initial**

Après avoir récupéré le fichier sur VirusTotal, nous pouvons procéder
à son analyse. Lors de l’ouverture du logiciel malveillant à l’intérieur d’un
outil tel que IDA Pro, on constate qu’il échoue à l’analyse. En effet, de
nombreuses portions de code sont considérés par IDA Pro comme des
données brutes (IDA Pro n’a pas réussi à désassembler ces octets, en gris
sur la figure 2) ou comme des instructions en dehors d’une fonction (IDA
Pro n’a pas été capable de reconstruire la fonction associée, en rouge sur
la figure 2).

**Fig. 2. Vue schématisée du résultat de la décompilation du maliciel par IDA Pro**

Comme nous allons le voir, l’analyse dans IDA Pro a échoué à cause
d’une technique d’obfuscation utilisée dans ce code. Cette technique antianalyse correspond à la portion de code signée par la règle YARA de la
figure 1. Plus précisément la technique d’obfuscation utilisée est visible
dans la figure 3.
Pour comprendre ce qu’il se passe ici, prenons le temps de comprendre
comment fonctionne IDA Pro. Le désassembleur d’IDA Pro traite tous
les octets les uns à la suite des autres. Ainsi, lorsqu’il arrive à l’adresse
0x100010B7, le désassembleur :
1. identifie que cette instruction est codée sur deux octets et qu’il
s’agit d’un saut conditionnel vers l’adresse 0x100010BA ;
2. désassemble l’instruction suivante, qui commence à l’adresse
0x100010B9 dont la taille est de deux octets. Cette instruction aura
pour effet d’effectuer un saut vers, elle aussi, l’adresse 0x100010BA.

[1 https://www.virustotal.com/gui/file/c0568d6c0aa6d019454c9613b1a9b0ef](https://www.virustotal.com/gui/file/c0568d6c0aa6d019454c9613b1a9b0ef)


-----

6 La rétro-ingénierie de code malveillant dans la CTI

**Fig. 3. Exemple du premier motif utilisé pour mettre en défaut IDA Pro**

Ici, nous voyons que le désassembleur, qui réalise une analyse séquentielle des octets, est mis en défaut puisque la prochaine instruction
exécutée est à l’adresse 0x100010BA qui est au milieu d’une instruction.
Cette technique est ainsi appelée, « Jump In The Middle ».

À partir de cette adresse, nous pouvons considérer le désassembleur
comme « désynchronisé » par rapport au flux d’exécution réel du programme : les instructions suivantes ne correspondent alors plus aux instructions réellement exécutées par le programme.

Dans ce cas, le travail du rétro-analyste est d’aider le désassembleur à
gérer cette situation. Pour cela, une solution est de supprimer l’instruction
à l’adresse 0x100010B9 et d’en créer une nouvelle à l’adresse 0x100010BA.
Cela permet de voir que cette nouvelle instruction est un saut inconditionnel, « jump eax » où la valeur de eax dépend du retour de la fonction
sub_10001d30.

**Fig. 4. Première passe de modifications pour corriger l’analyse effectuée par IDA**
Pro


-----

C. Meslay 7

Nous ne rentrerons pas dans le détail de la fonction sub_10001D30,
mais celle-ci est utilisée pour vérifier que la DLL ne s’exécute pas dans
une sandbox. L’exécution dans un débogeur permet de voir que la valeur
de retour, eax vaut :
— 1 si le code détecte un environnement d’analyse. Dans ce cas, le
jmp eax effectue un saut vers l’adresse 0x11, ce qui génère une
erreur.
— L’adresse de retour de la fonction sub_10001D30, c’est à dire
0x100010AF dans le cas présent. Le jmp eax effectuera donc un
saut vers l’adresse 0x100010AF+0x10=0x100010BF.
Nous pouvons alors simplifier le code en remplaçant certains octets
par la valeur 0x90 qui correspond à l’instruction « no operation » :
— les octets qui correspondent aux instructions de saut (« jge » ansi
que le premier octet du « jmp ») ;
— les trois octets à partir de l’adresse 0x100010BC car ces octets ne
sont jamais « exécutés ».
En résultat, nous obtenons la figure 5 qui est une version simplifiée
mais équivalente à ce qui est réellement exécuté.

**Fig. 5. Seconde passe de modifications pour corriger l’analyse effectuée par IDA**
Pro

Notons que la fonction sub_10001D50 est une autre anti-debug. Si le
résultat est 1, le processus se termine.
Dans cet exemple, nous avons manuellement aidé IDA Pro, mais ce
motif (ainsi que les fonctions anti-debug) est répété de multiples fois (32
fois dans cet exécutable). Il est alors nécessaire d’automatiser le processus
de suppression de ces motifs et des appels aux fonctions anti-debug. Dans
ce cas précis, il est possible de remplacer l’ensemble des octets de la


-----

8 La rétro-ingénierie de code malveillant dans la CTI

figure 5 par des octets « no operation ». En effet, le rôle de ces octets est
uniquement lié à de la détection d’environnement d’analyse.
En se basant sur l’exemple de plugin IDA Pro de Rolf Rolles,[2] il suffit
alors de modifier la fonction ev_ana_insn comme le montre la figure 6.

**Fig. 6. Adaptation de la fonction ev_ana_insn**

Ce script est assez simple : il vérifie que l’octet courant est le début
d’un bloc à supprimer. Si c’est le cas, nous remplaçons ce bloc par 37
instructions « no operation » (0x25 dans la figure 6). IDA Pro est alors
en capacité de reconstruire la fonction et de produire un code décompilé
automatiquement. Après quelques renommages de variables et fonctions,
retypages triviaux et l’ajout de quelques commentaires, on obtient le code
C présenté dans la figure 7.
Il est ainsi assez aisé d’identifier les principales étapes de cette fonction :

1. récupération du chemin actuel de l’exécutable ;

2. ouverture et lecture du fichier setlangloc.dat. Le contenu est
copié dans une zone mémoire nouvellement allouée ;

3. création d’un patch pour modifier certaines instructions dans ce
processus afin d’appeler le code à l’intérieur de setlangloc.dat ;

4. application ce patch.

La figure 8 présente les données du patch dans le segment rdata.
Une première piste identifiée pour créer une nouvelle règle YARA est
d’utiliser les données du patch. Ces octets pourront être utilisés pour créer
un nouveau motif de détection dans la notre règle YARA.

[2 https://github.com/RolfRolles/FinSpyVM/blob/master/FinSpyDeob.py](https://github.com/RolfRolles/FinSpyVM/blob/master/FinSpyDeob.py)


-----

C. Meslay 9

**Fig. 7. Résultat final suite à l’automatisation de la désobfuscation**

**Fig. 8. Octets du patch dans le segment rdata**

**2.2** **Analyse de variants**

À partir de la règle YARA sur le motif anti-analyse, deux autres
fichiers sont trouvés sur VirusTotal que nous nommerons « Variant A » [3]

et « Variant B ».[4]

Ces fichiers sont connus comme étant également liés à FlowCloud.
Dans le but d’améliorer notre signature, nous allons analyser ces fichiers
afin d’identifier leur caractéristiques et spécificités.

**Variant A. Ce variant présente de nombreuses similarités avec le chargeur**
initial de FlowCloud. Néanmoins, lors de son chargement dans IDA Pro,

[3 https://www.virustotal.com/gui/file/1e3baba3b7261eb9441fce16a1310532](https://www.virustotal.com/gui/file/1e3baba3b7261eb9441fce16a1310532)
[4 https://www.virustotal.com/gui/file/1c1ad9fd655ee80447f7bb38a570313b](https://www.virustotal.com/gui/file/1c1ad9fd655ee80447f7bb38a570313b)


-----

10 La rétro-ingénierie de code malveillant dans la CTI

et malgré le script précédemment créé, le désassemblage échoue. Nous
observons rapidement qu’un autre motif anti-analyse est présent, comme
le montre la figure 9.

**Fig. 9. Première nouvelle technique anti-analyse**

Cette technique consiste à sauvegarder la une valeur de eax sur la pile,
mettre eax à zéro puis restaurer la valeur de eax. La mise à zéro de eax
a pour effet que le saut conditionnel « jz » est pris. Le flux d’exécution
saute alors au milieu du « call » suivant.

**Fig. 10. Désobfuscation de la nouvelle technique anti-analyse**

La figure 10 présente le résultat après une correction manuelle de cette
obfuscation. Nous remarquons qu’elle est immédiatement suivie du motif
anti-analyse présenté précédemment. Nous pouvons donc mettre à jour
notre script de désobfuscation afin de prendre en compte cette nouvelle
technique.


-----

C. Meslay 11

Notons, qu’une autre technique d’obfsucation est présente. Celle-ci
n’empêche pas l’analyse par IDA Pro, mais a pour effet de rajouter
des variables au code obtenu après décompilation. Cette technique est
présentée dans la figure 11.

**Fig. 11. Deuxième nouvelle technique d’obfuscation**

Après avoir traité cette technique de la même façon que les précédentes
(en remplaçant toutes ces instructions par des « no operation » dans
notre plugin), nous pouvons recharger ce fichier dans IDA Pro. Nous
observons que le désassemblage est correctement effectué comme le montre
la figure 12.

**Fig. 12. Résultat de la décompilation du premier variant**


-----

12 La rétro-ingénierie de code malveillant dans la CTI

Comme précédemment, cette figure n’a fait l’objet que de quelques
renommages et ajouts de commentaires. Nous pouvons assez rapidement
observer que ce code est similaire au code obtenu dans la figure 7.

Néanmoins, bien que de nombreuses similarités existent, nous observons
trois différences avec le fichier initial :

— la première correspond au nom de fichier utilisé pour l’étape
suivante. Auparavant, celui-ci était récupéré via plusieurs appels de fonctions (GetModuleFileNameW, PathRemoveFileSpecW
et PathAppendW). Maintenant, ce nom de fichier est déchiffré dans
une fonction dédiée.
— La seconde différence correspond au chargement du contenu de
l’étape suivante. Dans le premier fichier, un simple memcpy était
utilisé pour copier le contenu du fichier. Dans ce nouveau variant,
une fonction est appelée afin de déchiffrer l’étape suivante : Cette
seconde fonction de déchiffrement prend en paramètre une graine
utilisée pour le calcul de la clé de déchiffrement. Comme la valeur
0xd3 est passée en paramètre de cette fonction, la valeur de la
clé est alors 0x7b. La figure 13 présente cette fonction chargée de
dériver la clé est d’appliquer le déchiffrement.

**Fig. 13. Fonction dérivant la clé et déchiffrant l’étape suivante**

— Enfin, une troisième différence correspond à l’application du patch.
Ici, l’application du patch est déportée dans une autre fonction. La


-----

C. Meslay 13

figure 14 présente cette fonction. Celle-ci correspond à ce qui était
effectué précédemment.

**Fig. 14. Fonction qui applique le patch**

**Variant B. Le deuxième variant est très proche du premier variant. Il**
dispose par exemple des mêmes fonctions de chiffrement et du même mécanisme de dérivation de clé. Cela nous indique qu’il peut être intéressant
de signer aussi ces mécanismes pour les inclure dans une règle YARA.
Un fait de comparaison intéressant entre ces trois versions est le nombre
d’occurences des motifs d’obfuscation. Les résultats sont présentés dans le
tableau 1

Fichier motif ESET motif obfuscation 1 motif obfuscation 2
Fichier initial 48 0 0
Variant A 69 136 136
Variant B 1 64 128

**Tableau 1. Nombre d’occurences des motifs dans chaque fichier**

Ces résultats montrent que le dernier variant ne dispose que d’une
seule occurence du motif initial signé par la règle YARA d’ESET. Une
hypothèse est que cette obfuscation a vocation à disparaitre dans les
prochaines versions. Cela peut donc inciter à réaliser une nouvelle règle
YARA dont la présence de ce motif est optionnelle.

|Fichier|motif ESET|motif obfuscation 1|motif obfuscation 2|
|---|---|---|---|
|Fichier initial|48|0|0|
|Variant A|69|136|136|
|Variant B|1|64|128|


-----

14 La rétro-ingénierie de code malveillant dans la CTI

**2.3** **Création de nouvelles signatures**

À ce stade, nous disposons d’une règle YARA qui se base uniquement
sur un motif anti-analyse. Or, comme nous avons pu le voir, toutes ces
variantes disposent de plusieurs similarités (fonctions cryptographiques)
mais aussi de deux nouvelles techniques anti-analyse.
Nous pouvons donc tenter de créer une nouvelle règle YARA basée sur
de nouvelles heuristiques :
— les mécanismes de déchiffrement (du nom du fichier et du contenu
de celui-ci)
— le mécanisme de dérivation de la clé pour le déchiffrement du
contenu du fichier
— les deux nouveaux motifs anti-analyse
— les octets du patch appliqué
Signer des algorithmes cryptographique peut être intéressant si l’implémantation est spécifique au code étudié. Dans le cas présent, le déchiffrement du contenu du fichier correspondant juste à une addition suivant
d’un xor ne semble pas opportun. En effet, cela pourrait mener à de
nombreux faux positifs.
Par contre, bien que nous n’ayons pas abordé cette partie dans cet
article par soucis de clarté, le déchiffrement du nom du fichier semble plus
spécifique. La figure 15 présente un extrait de cette fonction.

**Fig. 15. Extrait de la fonction de déchiffrement du nom du fichier**

De cet algorithme nous avons extrait les octets suivants :


1 $decryption_function = {8A C8 80 C1 26 32 D1 30 14 38}


Le mécanisme de dérivation des clés peut lui être signé par cette
variable :


1 $derivation_key = {6B 04 00 00 F7 ?? 81 c2 a8 01 00 00}


Enfin, nous avons les deux nouveaux motifs anti-analyses ainsi que les
octets du patch :


-----

C. Meslay 15


1 $new_pattern_1 = {50 33 c0 58 74 01 e8}

2 $new_pattern_2 = {89 44 24 fc 58 8D 64 24 fc 81 fc 00 10 00 00 77
_֒→_ 06 81 c4 ?? ?? ?? ?? 8B 44 24 FC}

3 $patch_bytes = {68 78 56 34 12 C3 90 90 90 90 90 00}


Au final, notre nouvelle règle YARA est présentée dans la figure 16.

**Fig. 16. Nouvelle règle YARA signant les variants**

Ici, notre objectif est de trouver de nouveaux fichiers. Nous décidons
donc de faire en sorte que cette règle soit assez laxiste. C’est pourquoi
nous décidons d’utiliser la directive « 2 of them » et non « all of them »
afin que cette règle vérifie les fichiers ne disposant que deux de ces cinq
motifs.

La création d’une règle YARA n’est pas une fin en soi. En effet, ces
règles doivent être capitalisées afin qu’elles soient confrontés aux nouveaux
fichiers soumis à détection. De plus, il est généralement conseillé de
confronter ces règles à des bases de données de fichiers existantes. Cette
dernière fonctionnalité est souvent appelée « RetroHunt »


-----

16 La rétro-ingénierie de code malveillant dans la CTI

**2.4** **Nouveau variant**

Cette nouvelle règle YARA nous a permis de récupérer un nouveau
fichier sur VirusTotal nommé msedgeupdate.dll,[5] téléversé en septembre
2023. En novembre 2023, lorsque nous avons réalisé cette investigation, ce
fichier n’était détecté par aucun antivirus (la dernière analyse effectuée
sur VirusTotal datant du 15 novembre 2023).
L’objectif de ce chapitre est donc d’analyser ce fichier pour s’avoir s’il
s’agit bien d’un nouveau variant ou pas et de s’assurer que notre règle est
bien pertinente.

**Analyse de msedgeupdate.dll. Tout d’abord, nous pouvons vérifier**
que ce fichier vérifie quatre des motifs créés :
— $decryption_function
— $patch_bytes
— $new_pattern_1
— $new_pattern_2
Le seul motif non présent dans cet implant
est celui relatif au mécanisme de dérivation de clé
($derivation_key = {6B 04 00 00 F7 ?? 81 c2 a8 01 00 00}).
Notons de plus que le motif identifié dans la règle YARA d’ESET n’est
pas présent.
Le tableau 2 est une mise à jour du tableau 1 prenant en compte ce
nouveau fichier.

Fichier Motif ESET $new_pattern_1 $new_pattern_2
Fichier initial 48 0 0
Variant A 69 136 136
Variant B 1 64 128
Nouveau fichier 0 280 280

**Tableau 2. Nombre d’occurences des motifs dans chaque fichier**

Notre plugin de désobfuscation nous permet de facilement supprimer
les mécanismes anti-analyse et de retrouver très rapidement une fonction
ressemblant à ce que nous avons observé précédemment. Celle-ci est
présentée dans la 17.
Contrairement aux précédents variants, nous pouvons voir que le nom
du fichier à charger n’est pas chiffré mais est issu du nom du fichier courant.

[5 https://www.virustotal.com/gui/file/c0a29416705997d796b94cdce648348d](https://www.virustotal.com/gui/file/c0a29416705997d796b94cdce648348d)

|Fichier|Motif ESET|$new_pattern_1|$new_pattern_2|
|---|---|---|---|
|Fichier initial|48|0|0|
|Variant A|69|136|136|
|Variant B|1|64|128|
|Nouveau fichier|0|280|280|


-----

C. Meslay 17

**Fig. 17. Fonction principale du nouveau fichier**

L’extension dll est remplacée par dat. Ainsi, le nom du fichier utilisé
pour l’étape d’après est msedgeupdate.dat. Notons que même si le nom
de fichier n’est pas chiffré, la fonction de déchiffrement est présente dans
la DLL. C’est pourquoi les octets de la variable $decryption_function
sont bien présents.
La fonction de déchiffrement du contenu du fichier est un peu différente.
Comme le montre la figure 18, contrairement aux variants précédents, le
mécanisme de dérivation de clé n’est plus présent. La clé (sur un octet)
est ainsi codée en dur et vaut 0x7b. Il est intéressant de noter cette
valeur correspond au résultat de l’algorithme de dérivation de clé utilisé
précédemment. Une hypothèse ici peut être que le compilateur a optimisé
le code en remplaçant l’algorithme de dérivation de clé par sa valeur finale.

**Fig. 18. Fonction de déchiffrement du nouveau variant**


-----

18 La rétro-ingénierie de code malveillant dans la CTI

La fonction relative au patch partage aussi des caractéristiques identiques avec les précédents fichiers, notamment la même séquence d’octets
(figure 19).

**Fig. 19. Fonction appliquant le patch au nouveau variant**

À ce stade, nous pouvons avoir une confiance élevée sur le fait qu’il
s’agit bien d’un nouveau variant associé à FlowCloud. Mais essayons d’aller
plus loin.

**Analyse** **de** **msedgeupdate.dat.** Nous avons vu que le fichier
msedgeupdate.dll a pour objet le chargement et le déchiffrement d’un
fichier nommé msedgeupdate.dat. Par chance, nous pouvons retrouver
sur VirusTotal un fichier nommé msedgeupdate.dat téléversé en même
temps que ce nouveau variant.[6]

Une première ouverture de ce fichier dans un éditeur de texte montre
que ce fichier semble être un fichier de données inintelligible. Cela est
cohérent avec notre analyse puisque l’étape précédente commençait par
déchiffrer ce fichier. Lorsque nous déchiffrons manuellement ce fichier nous
obtenons bien un shellcode qui s’autodéchiffre afin d’obtenir une nouvelle
DLL protégée par VMProtect.

[6 https://www.virustotal.com/gui/file/6d5bcb74a284d119dd32f7b09d37369f](https://www.virustotal.com/gui/file/6d5bcb74a284d119dd32f7b09d37369f)


-----

C. Meslay 19

Un élément intéressant ici, est que la fonction de déchiffrement dispose
du même mécanisme de dérivation de clé que précédemment. Ainsi, dans ce
nouveau fichier déchiffré nous retrouvons le seul motif de notre règle YARA
qui n’était pas présent dans le fichier msedgeupdate.dll. La figure 20
présente la fonction de déchiffrement avec l’algorithme de dérivation de la
clé précédemment utilisé.

**Fig. 20. Fonction de déchiffrement présente dans le fichier msedgeupdate.dat**
déchiffré

La dernière étape est plus compliquée à analyser du fait des protections
assurées par VMProtect. Néanmoins, nous avons une confiance très élevée
sur le fait que ce fichier est une nouvelle variante de la chaîne d’infection
de FlowCloud d’autant plus que :
— l’utilisation de VMProtect par FlowCloud est déjà documentée [3].
— le serveur de commande & contrôle (C2) avec lequel communiquait
l’implant disposait de similarités avec d’anciens C2 connus de
FlowCloud.

## 3 Conclusion

En conclusion, cet article avait pour but de présenter la CTI sous
l’angle de la création de règles YARA via la rétro-ingénierie de logiciel
malveillant. Bien que la création de règles YARA n’est pas l’unique but du
travail d’un analyste CTI, il n’en reste pas moins un élément de base dans
le suivi des MOA permettant le suivi de leurs codes et de leur évolution
dans le temps. L’exemple pris avait pour but de proposer une approche
pas à pas de l’étude d’un code et de la création d’une règle YARA. Enfin,
nous espérons avoir intéressé le lecteur via l’analyse d’exemples réels d’une
famille de codes malveillants.


-----

20 La rétro-ingénierie de code malveillant dans la CTI

## Références

1. ESET Alexandre Côté Cyr, Matthieu Faou. A lookback under the TA410 umbrella :
[Its cyberespionage TTPs and activity. 2022. https://www.welivesecurity.com/](https://www.welivesecurity.com/2022/04/27/lookback-ta410-umbrella-cyberespionage-ttps-activity/)
[2022/04/27/lookback-ta410-umbrella-cyberespionage-ttps-activity/.](https://www.welivesecurity.com/2022/04/27/lookback-ta410-umbrella-cyberespionage-ttps-activity/)

2. Simon Msika Charles Hourtoule. Comment anticiper la menace : l’exemple de
Mustang Panda. SSTIC, 2023.

3. MACNICA Hiroshi Takeuchi. USB flows in the Great River : classic tradecraft is still
alive. 2023. [https://www.virusbulletin.com/conference/vb2023/abstracts/](https://www.virusbulletin.com/conference/vb2023/abstracts/usb-flows-great-river-classic-tradecraft-still-alive/)
[usb-flows-great-river-classic-tradecraft-still-alive/.](https://www.virusbulletin.com/conference/vb2023/abstracts/usb-flows-great-river-classic-tradecraft-still-alive/)

4. Michael Raggi and the ProofPoint Threat Insight Team. LookBack Forges
Ahead : Continued Targeting of the United States’ Utilities Sector Reveals
Additional Adversary TTPs. 2019. [https://www.proofpoint.com/us/threat-](https://www.proofpoint.com/us/threat-insight/post/lookback-forges-ahead-continued-targeting-united-states-utilities-sector-reveals)
[insight/post/lookback-forges-ahead-continued-targeting-united-states-](https://www.proofpoint.com/us/threat-insight/post/lookback-forges-ahead-continued-targeting-united-states-utilities-sector-reveals)
[utilities-sector-reveals.](https://www.proofpoint.com/us/threat-insight/post/lookback-forges-ahead-continued-targeting-united-states-utilities-sector-reveals)


-----