Un analyste malware travaille sur des fichiers que le SOC, le CSIRT ou l'équipe CTI lui transmettent. Il identifie le packer, ouvre le binaire dans IDA Pro ou Ghidra, le fait tourner pas à pas dans x64dbg, retrouve la configuration chiffrée et livre des IOC et des règles YARA. Les questions d'entretien d'analyste malware partent de cette suite de gestes concrets plus que d'une liste d'outils.
Le titre de reverse engineer recouvre deux métiers voisins. L'analyse de malware sert la détection et la réponse à incident. La recherche de vulnérabilités, que beaucoup d'annonces rangent sous le même intitulé, vise à trouver et exploiter des failles dans des logiciels ou des équipements, avec du fuzzing et des preuves de concept. Les deux partagent l'assembleur, pas le reste du quotidien. Le poste visé doit être clair avant la première question.
Les CV mettent souvent en avant des CTF et des crackmes. C'est une bonne base, mais un échantillon réel ajoute des packers maison, de l'anti-débogage et une demande pressée du CSIRT. Un rapport déjà écrit, ou un billet public, commenté par le candidat, apporte davantage. Le PDF prévoit un cas de 20 minutes sur un chargeur inconnu.
Désassembleurs, débogueurs et sandbox de l'analyste malware
Assembleur x86/x64 et ARM
La base du poste. L'analyste lit le code machine désassemblé, reconnaît les conventions d'appel, les boucles et les routines de chiffrement. Le x86/x64 couvre la plupart des échantillons Windows. L'ARM et le MIPS arrivent avec les malwares pour objets connectés et les bibliothèques natives Android.
IDA Pro
Le désassembleur commercial de Hex-Rays, avec son décompilateur. Il reste très présent dans les équipes, souvent avec des scripts IDAPython. Hex-Rays a publié la version 9.5 fin octobre 2026. Ce qui compte en entretien, c'est la façon de typer, renommer et automatiser, plus que la version.
Ghidra
Le désassembleur et décompilateur open source publié par la NSA, passé en version 12.x. Beaucoup d'analystes l'utilisent à côté d'IDA ou à sa place, avec des scripts en Java ou en Python. Un profil à l'aise sur l'un apprend l'autre en quelques semaines.
Binary Ninja
Une plateforme d'analyse binaire plus récente, appréciée pour son API et ses représentations intermédiaires. On la croise surtout chez les profils qui écrivent beaucoup d'outillage. Elle n'est presque jamais un critère bloquant.
x64dbg et WinDbg
Les débogueurs Windows. x64dbg sert à exécuter l'échantillon pas à pas, poser des points d'arrêt sur les API, dépaqueter et dumper la mémoire avec Scylla. WinDbg devient nécessaire dès qu'il faut regarder un pilote ou un dump noyau.
Sandbox et laboratoire
Une sandbox comme CAPE exécute l'échantillon et rend son comportement, ses fichiers, son trafic et ses dumps mémoire. Le reste du labo se compose de VM isolées avec instantanés et de services simulés (INetSim, FakeNet-NG). La personne doit expliquer comment elle isole ce labo du réseau.
Formats PE, ELF et .NET
Les formats des exécutables Windows et Linux, plus les assemblies .NET qui se décompilent avec dnSpyEx ou ILSpy. Les en-têtes, les sections, les imports et les callbacks TLS donnent les premiers indices au triage.
YARA et YARA-X
Le langage de règles qui décrit une famille par ses chaînes et ses motifs d'octets. Le projet YARA est passé en mode maintenance et VirusTotal pousse YARA-X, réécrit en Rust, qui accepte la quasi-totalité des règles existantes. L'analyste livre ces règles au SOC et à la CTI.
capa, FLOSS et Python
capa et FLOSS, deux outils open source de l'équipe FLARE, listent les capacités d'un binaire et retrouvent ses chaînes cachées. Python sert à tout le reste, de l'extracteur de configuration avec pefile au script de déchiffrement des chaînes.
Le poste existe surtout chez les éditeurs de solutions de sécurité, dans les CERT internes des grands groupes et chez les prestataires de réponse à incident, avec des niveaux confirmé à expert. Les annonces mélangent souvent analyse de malware et recherche de vulnérabilités sous le titre de reverse engineer, alors que la seconde demande du fuzzing et de l'écriture d'exploits. Le volume de candidats est faible et beaucoup viennent de l'analyse SOC ou du CTF. La certification GIAC GREM atteste une formation suivie. Le niveau réel se voit sur un binaire ouvert en direct.
Les savoir-faire à contrôler chez un reverse engineer
- Lecture d'assembleur x86/x64 et ARM
- Analyse statique avec IDA ou Ghidra
- Analyse dynamique et débogage
- Dépaquetage et désobfuscation
- Extraction de configuration et IOC
- Règles YARA et rapport exploitable
Questions techniques pour un analyste malware
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Dans IDA, une boucle applique un XOR avec une clé de 16 octets sur un buffer, puis le code appelle VirtualProtect avec PAGE_EXECUTE_READWRITE et saute dans ce buffer. Qu'en concluez-vous, et que faites-vous ensuite ?
Une bonne réponseLe programme déchiffre une deuxième charge en mémoire puis l'exécute. La personne explique qu'elle peut récupérer cette charge de deux façons, en analyse dynamique (laisser le déchiffrement se faire au débogueur puis extraire la zone) ou en statique (reproduire l'algorithme avec la clé retrouvée). Elle cherche d'où vient la clé (en dur, dérivée, reçue du réseau) et ce que contient la charge, afin de poursuivre l'analyse sur le bon étage.
Signal d'alerte« C'est chiffré, je regarde en sandbox ce que ça fait », sans chercher à récupérer la charge. Ou une analyse qui s'arrête au premier niveau sans voir qu'il existe un deuxième étage.
Question 2 · confirmé
L'échantillon a une section à l'entropie proche de 8, cinq imports à peine et un point d'entrée dans la dernière section. Comment le dépaquetez-vous ?
Une bonne réponseLes trois signes indiquent un packer. La personne l'identifie d'abord (Detect It Easy, signatures connues), utilise l'outil standard quand il s'agit d'un packer public, et sinon explique sa méthode au débogueur : suivre le code jusqu'au moment où le programme d'origine est reconstitué en mémoire, l'extraire, puis reconstruire la table d'imports (Scylla). Elle cite aussi le dump mémoire de la sandbox comme raccourci, et sait dire combien de temps elle s'accorde avant de changer d'approche.
Signal d'alerteAnalyser le code packé tel quel dans le désassembleur pendant des heures. Ou confondre compression et chiffrement sans savoir ce que mesure l'entropie.
Question 3 · confirmé
Le fichier ne fait rien en sandbox : aucune connexion, aucun fichier créé. Quelles hypothèses formulez-vous, et comment poursuivez-vous l'analyse ?
Une bonne réponseLa personne cite les grandes familles de protections anti-analyse : détection de débogueur, mesures de temps et attentes longues, détection de machine virtuelle, conditions d'environnement (langue, interaction utilisateur, argument attendu), ou simple dépendance à un serveur hors ligne. Elle les repère en statique, choisit entre rendre l'environnement d'analyse plus réaliste et neutraliser le contrôle au débogueur (des plugins comme ScyllaHide existent pour cela), et note ces protections dans le rapport, car elles servent aussi à la détection.
Signal d'alerteConclure que le fichier est inoffensif. Ou relancer la même sandbox en espérant un autre résultat.
Question 4 · senior
On vous confie 300 variantes d'une même famille et le CTI veut, pour chacune, le C2, la clé et l'identifiant de campagne. Comment vous y prenez-vous ?
Une bonne réponseAnalyser une variante à fond pour trouver où dort la configuration (ressource, section .data, blob en fin de fichier) et comment elle est protégée (XOR, RC4, AES, base64). Écrire ensuite un extracteur Python avec pefile, qui retrouve la routine ou la clé par un motif d'octets plutôt que par une adresse fixe. Le passer sur les 300 fichiers, isoler ceux qui échouent pour repérer une nouvelle version, et sortir un JSON que la plateforme CTI peut importer.
Signal d'alerteLancer les 300 fichiers en sandbox et relever le trafic à la main. Ou un script qui dépend d'offsets codés en dur et casse à la première recompilation.
Question 5 · confirmé
Décrivez la règle YARA que vous écririez pour détecter cette famille sans déclencher sur des logiciels légitimes. Qu'y mettez-vous ?
Une bonne réponseDes séquences d'octets tirées du code propre à la famille, par exemple la routine de déchiffrement de la configuration avec des jokers sur les registres et les adresses, plus quelques chaînes rares. Des conditions qui resserrent : en-tête MZ, taille de fichier, nombre minimal de chaînes, au besoin le module pe. Pas d'adresse de C2 ni de hash, qui changent à chaque campagne. La règle est testée sur un corpus de logiciels sains et sur les échantillons connus. Un bon profil sait que YARA est en mode maintenance et que la plupart des règles passent telles quelles dans YARA-X.
Signal d'alerteUne règle sur une chaîne banale comme « http:// » ou sur un nom de domaine. Aucune idée de la façon de mesurer les faux positifs.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Analyste malware, les points qui reviennent
Analyste malware ou chercheur en vulnérabilités, quel profil pour quel besoin ?
L'analyste malware étudie des programmes malveillants pour aider le SOC et le CSIRT à détecter et à nettoyer. Le chercheur en vulnérabilités cherche des failles dans des logiciels sains, les exploite et écrit des preuves de concept, avec beaucoup de fuzzing. Les deux lisent l'assembleur et utilisent IDA ou Ghidra. Un besoin né d'incidents et de détection appelle le premier. L'audit de produits ou d'équipements appelle le second.
La certification GREM est-elle nécessaire ?
Non. La GIAC GREM, associée à la formation SANS FOR610, montre qu'une méthode a été apprise et validée par un examen. Beaucoup de bons analystes n'en ont pas et se sont formés sur des échantillons réels, des CTF ou dans une équipe de réponse à incident. Un rapport d'analyse publié, un dépôt de règles YARA ou un extracteur de configuration sur GitHub en disent souvent plus. La certification reste un indice, que confirme le travail sur un binaire.
Quel test technique est donné à un analyste malware ?
Un échantillon déjà connu de l'équipe, légèrement packé, à analyser en une à deux heures dans une VM fournie, sans connexion. Les questions sont fermées : persistance, C2, algorithme de la configuration, une règle YARA. Le candidat commente ensuite son travail à voix haute. Un vrai fichier client ou un échantillon actif non maîtrisé n'a pas sa place dans l'exercice, et les outils disponibles sont annoncés à l'avance pour ne pas pénaliser un profil Ghidra face à une licence IDA.
Faut-il imposer IDA Pro plutôt que Ghidra ?
Rarement. Les deux désassemblent et décompilent les mêmes architectures, et un analyste qui maîtrise l'un passe à l'autre en quelques semaines. Ce qui coûte du temps à apprendre, c'est la lecture de l'assembleur, le dépaquetage et l'écriture de scripts. Quand l'équipe a des années de scripts IDAPython ou de bases IDA partagées, la capacité à les lire suffit au départ. Le choix de l'outil se règle ensuite à l'arrivée.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
