Questions d'entretien Malware Analyst / Reverse Engineer

Non. Le fichier de test EICAR est une chaîne ASCII délibérément inoffensive de 68 octets que tous les éditeurs d'antivirus s'accordent à détecter, afin de vérifier en toute sécurité la détection et les alertes sans manipuler de vrai malware. Une détection signifie que votre antivirus fonctionne — pas que vous êtes infecté. Ce n'est pas un virus et il ne fait rien s'il est exécuté. Confondre une détection de test EICAR avec une vraie infection est un piège classique en début de carrière.

Le SOC doit agir, alors livrez un contenu de détection structuré et exploitable : IOC réseau, hachages, artefacts hôte comme le mutex, et signatures comportementales ou YARA qu'il peut déployer pour traquer et bloquer. Un récit exhaustif des appels d'API n'est pas directement opérationnel. Un seul hachage est trivialement modifié par les attaquants. Une attribution spéculative n'aide pas le SOC à se défendre. Le but : des détections que le SOC peut déployer aujourd'hui.

Ne détonez que dans une VM jetable et isolée, avec des snapshots et un réseau contrôlé (par ex. services simulés ou egress étroitement surveillé), afin que le malware ne puisse atteindre ni la production ni Internet sans contrôle. L'antivirus de votre portable ne contiendra pas un malware actif de façon fiable. Un serveur de production met en danger de vrais systèmes. La machine d'un collègue ne fait que déplacer le danger. L'isolation et les snapshots réversibles sont le cœur d'un labo de malware sûr.

Le malware fileless vit dans la mémoire des processus (injection, chargement réflectif, LOLBins), donc acquérez et analysez une image mémoire pour trouver le code injecté, les modules suspects et les relations entre processus. Un scan antivirus du disque et un disque propre ne vous disent rien d'un implant en mémoire. La corbeille est hors sujet. L'analyse mémoire est le bon outil quand il n'y a pas de fichier à trier, et vous devez capturer avant tout redémarrage de l'hôte.

L'identification de la famille guide les décisions : à partir de la note, de l'extension et des IOC, vous pouvez signaler l'existence d'un décrypteur gratuit, les TTP typiques du groupe (y compris le vol de données pour extorsion) et le rayon d'impact probable, au profit de l'équipe IR. Reformater détruit les preuves et l'information de portée. La grammaire de la note n'est pas exploitable. Recommander de négocier est une décision métier et juridique, pas le premier geste de l'analyste. Identifiez d'abord, puis aidez l'IR.

Utilisez des services réseau simulés ou un egress étroitement surveillé et non attribuable, pour étudier le comportement du C2 sans révéler votre vraie IP à l'attaquant ni laisser l'hôte recevoir des commandes nuisibles. Interagir depuis l'IP de l'entreprise alerte l'opérateur et risque un vrai dommage. Ponter le sandbox au LAN invite à la propagation. Désactiver les logs jette les données d'analyse. Contrôlez le réseau pour observer sans exposer ni être instrumentalisé.

Le packing masque le vrai code, donc une entropie élevée plus des imports absents est un signe qu'il faut dépaqueter — détectez le packer et dumpez l'image dépaquetée depuis la mémoire une fois le loader exécuté, puis analysez la vraie charge utile. Des chaînes illisibles sont une preuve d'évasion, pas de bénignité. Conclure à un faux positif ou renommer l'extension ignore un échantillon activement obfusqué. L'obfuscation elle-même est un fort indicateur malveillant à investiguer.

Les malwares vérifient couramment les artefacts de VM/sandbox, les durées d'exécution courtes ou l'interaction utilisateur et restent dormants s'ils les détectent. Déguisez et durcissez la VM d'analyse, prolongez l'exécution ou passez sur bare metal, et extrayez le comportement depuis une image mémoire de l'hôte vivant. Supposer qu'il est cassé ou que l'hôte se trompe ignore un échantillon prouvé malveillant en conditions réelles. Un redémarrage ne change rien car la logique d'évasion se déclenche à chaque exécution.

Commencez par un triage statique dans un environnement isolé : calculez les empreintes, extrayez les chaînes, inspectez les en-têtes PE et les imports, et vérifiez la réputation, afin de comprendre l'échantillon avant de risquer l'exécution. L'exécuter sur votre propre poste peut vous infecter, vous et le réseau. Téléverser des échantillons clients avec des noms identifiants divulgue des données sensibles à des tiers. Le supprimer détruit la preuve et la possibilité de bâtir des détections.

La persistance est la façon dont un malware survit aux redémarrages et aux déconnexions. Les incontournables sous Windows sont les clés Run/RunOnce du registre (HKLM et HKCU), les tâches planifiées et les services Windows, plus les dossiers de démarrage, les abonnements aux événements WMI et le détournement de DLL. On les traque avec autoruns/Sysinternals, Sysmon et les journaux d'événements — en cherchant des binaires non signés, des chemins étranges comme %AppData% et des entrées créées juste après la compromission initiale.

L'injection de processus exécute le code de l'attaquant dans l'espace mémoire d'un processus légitime pour que l'activité se fonde dans la masse et hérite de la confiance de ce processus. Les techniques classiques incluent l'injection de DLL (CreateRemoteThread + LoadLibrary), le process hollowing (lancer un processus bénin suspendu, le démapper, y écrire du code malveillant) et l'injection d'APC. Les défenseurs la détectent via les hooks d'API de l'EDR, des relations parent/enfant ou des régions mémoire anormales (RWX, mémoire exécutable non adossée à un fichier) et les événements CreateRemoteThread de Sysmon.

L'analyse statique examine un échantillon sans l'exécuter — hashes, chaînes, imports, en-têtes et désassemblage — donc elle est sûre et couvre tout, mais elle est déjouée par le packing et l'obfuscation. L'analyse dynamique détone l'échantillon dans un bac à sable isolé et observe le comportement réel — fichiers, registre, processus, réseau — ce qui perce l'obfuscation mais ne révèle que ce qui s'exécute dans cette session et peut être contourné par des malwares conscients du bac à sable. Les analystes combinent les deux.

On classe selon ce que l'échantillon est conçu pour faire, observé à partir de son comportement et de ses capacités. Un dropper transporte et écrit une charge utile sur le disque ; un loader récupère ou injecte l'étape suivante, souvent uniquement en mémoire ; un RAT donne à un opérateur un contrôle distant interactif ; un wiper détruit les données ou les enregistrements d'amorçage sans intention de récupération ; un ransomware chiffre les fichiers et exige un paiement. Les vrais échantillons combinent souvent les rôles — un loader qui déploie un RAT — donc on décrit la chaîne de capacités plutôt que d'imposer une étiquette unique, et on associe chaque comportement aux techniques ATT&CK.

Un désassembleur comme Ghidra ou IDA vous donne la carte statique complète : références croisées, pseudocode décompilé et chaque chemin de code, qu'il s'exécute ou non. Un débogueur comme x64dbg vous permet d'exécuter l'échantillon sous contrôle — poser des points d'arrêt, inspecter registres et mémoire, observer le déchiffrement se produire, et suivre le chemin que le code prend réellement avec de vraies entrées. On lit la structure et l'intention statiquement, puis on attache le débogueur pour résoudre ce que l'analyse statique ne peut pas : chaînes déchiffrées au runtime, API résolues dynamiquement, charges utiles empaquetées, et quelle branche une condition prend. Les deux ensemble comblent leurs lacunes mutuelles.

Le beaconing de commande et contrôle, c'est l'implant qui appelle périodiquement la maison pour des instructions. On le reconnaît à des rappels sortants réguliers et de faible volume à intervalle à peu près fixe — souvent avec du jitter pour éviter de paraître mécanique — vers un petit ensemble de destinations, fréquemment via HTTP/HTTPS ou DNS avec des charges utiles encodées ou chiffrées et un User-Agent ou un motif d'URI distinctif. On extrait les indicateurs statiquement en tirant domaines, IP, URI et clés des chaînes et blocs de config, et dynamiquement en détonant l'échantillon contre un réseau factice et en capturant les vrais rappels, puis on associe le comportement à ATT&CK et on alimente les IOC dans la détection.

L'empaquetage compresse ou chiffre la vraie charge utile et y préfixe un stub qui la dépaquette en mémoire à l'exécution ; l'obfuscation transforme le code ou les données pour résister à la lecture et aux signatures. On détecte l'empaquetage à une entropie de section élevée proche de 8,0, une table d'imports minuscule ou réduite au stub, des noms de section inhabituels ou inscriptibles-exécutables comme UPX0, un point d'entrée hors de .text, une grande taille virtuelle face à une petite taille brute, et des détecteurs comme Detect It Easy ou PEiD. Aucun de ces signaux n'est concluant seul, donc les analystes en pèsent plusieurs ensemble et confirment en observant le dépaquetage à l'exécution.

Un fichier PE commence par l'en-tête DOS et son pointeur e_lfanew vers les en-têtes PE/NT, qui contiennent le File Header et l'Optional Header (point d'entrée, image base, sous-système). Il est divisé en sections — .text pour le code, .data, .rdata, .rsrc pour les ressources — chacune avec une adresse virtuelle et une taille brute. Lors du triage, on lit la table d'imports pour les API suspectes, la table des sections pour les noms étranges et l'entropie élevée qui suggèrent l'empaquetage, le timestamp et le rich header, les ressources embarquées et toute signature numérique. Les incohérences entre ces éléments en disent long avant même d'exécuter le fichier.

L'injection de processus exécute du code malveillant à l'intérieur d'un autre processus pour se cacher et hériter de sa confiance. L'injection distante classique alloue de la mémoire dans une cible avec VirtualAllocEx, écrit une charge utile via WriteProcessMemory, et l'exécute avec CreateRemoteThread. Les variantes incluent l'injection de DLL via LoadLibrary, le process hollowing qui démappe un processus légitime suspendu et remplace son image, l'injection APC qui met du code en file d'attente sur un thread, et le chargement réflexif ou mappé manuellement qui évite LoadLibrary entièrement. On les repère par les séquences d'API révélatrices, la mémoire RWX dans un processus normalement propre, les threads sans fichier de sauvegarde sur le disque et les anomalies parent-enfant.

Un laboratoire sécurisé isole le malware de tout ce qu'il pourrait endommager. Vous exécutez les échantillons dans des VM jetables sur un hyperviseur, prenez des snapshots propres pour pouvoir revenir en arrière après chaque détonation, et coupez tout accès réseau réel via un réseau host-only avec un Internet simulé (INetSim ou FakeNet) ou un segment isolé physiquement. Vous séparez la machine d'analyse d'une passerelle contrôlée, n'analysez jamais sur votre poste de travail quotidien, durcissez contre l'évasion de VM, manipulez les échantillons sous forme de zips protégés par mot de passe, et gardez l'outillage et les indicateurs hors de la VM de détonation. L'objectif est d'observer un comportement réel tout en garantissant que l'échantillon ne peut atteindre ni la production ni Internet.

Un malware conscient du sandbox vérifie s'il est observé avant de mal se comporter. Il cherche des artefacts de VM et d'hyperviseur (pilotes, préfixes MAC, clés de registre, CPUID), des outils d'analyse et débogueurs (noms de processus, IsDebuggerPresent, temporisation du pas-à-pas), et des signes d'un vrai utilisateur (peu de processus, aucun document récent, pas de mouvement de souris, faible uptime, petit disque). Il peut temporiser avec de longs sommeils ou ne se déclencher qu'à une date, une langue ou un domaine précis. Les analystes y font face en durcissant la VM pour la rendre réaliste, en neutralisant les vérifications par patch, en accélérant les sommeils, en simulant l'activité utilisateur, et en confirmant le comportement par désassemblage statique.

L'outillage statique lit l'échantillon au repos : PEStudio, CFF Explorer et pefile pour les en-têtes et imports, FLOSS et strings pour le texte embarqué, capa pour la cartographie des capacités, et Ghidra ou IDA pour le désassemblage. L'outillage dynamique l'observe s'exécuter dans une VM isolée : Procmon et Process Hacker pour l'activité hôte, Wireshark et INetSim ou FakeNet pour le réseau simulé, Regshot pour les diffs avant/après, et x64dbg pour le pas-à-pas contrôlé. Le workflow consiste à trier statiquement, détoner dynamiquement, puis revenir au désassembleur pour combler les lacunes comportementales.

La décompression récupère le code original que le packer a caché. Pour les packers connus, vous utilisez le décompresseur correspondant ou un émulateur. Pour les packers personnalisés, vous décompressez manuellement : exécutez l'échantillon dans un débogueur, laissez le stub décompresser la charge utile en mémoire, trouvez le moment où il saute vers le point d'entrée original (souvent en posant un point d'arrêt sur de la mémoire qui devient exécutable, ou sur le saut de queue), puis dumpez l'image du processus depuis la mémoire et reconstruisez la table d'adresses d'imports avec un outil comme Scylla ou PE-sieve. Le résultat est un PE exécutable ou analysable contenant la véritable charge utile.

Une règle YARA comporte un bloc meta, une section strings (motifs texte, hexa ou regex, avec jokers et sauts) et une condition qui combine ces correspondances par une logique booléenne et de comptage. Une règle efficace s'appuie sur un élément durable et distinctif — un stub de code unique, un nom de mutex, un marqueur de configuration ou une combinaison d'imports inhabituelle — plutôt que sur des valeurs qu'un attaquant change trivialement comme un seul hash ou une chaîne générique. On équilibre la spécificité face aux faux positifs, on teste contre un corpus propre, et on documente la règle pour que d'autres lui fassent confiance et la maintiennent.