Une menace s'exécute uniquement en mémoire, sans aucun fichier sur le disque. Comment l'analysez-vous ?

Les menaces fileless sont conçues pour déjouer les réflexes centrés sur le disque des analystes plus faibles. L'examinateur vérifie si vous savez où vit réellement la preuve quand rien n'est copiable depuis le système de fichiers — et si vous agissez avant qu'elle ne s'évapore.

Pourquoi la capture et l'analyse mémoire sont correctes

Par définition, le code malveillant n'atterrit jamais sous forme de fichier sur le disque. Il s'exécute dans la mémoire des processus via des techniques comme l'injection de processus, le chargement réflectif de DLL ou les binaires living-off-the-land (LOLBins) tels que PowerShell et WMI. Le seul endroit où le trouver est la RAM ; vous acquérez donc une image mémoire de l'hôte affecté et l'analysez : traquez le code injecté dans des processus légitimes, les modules en mémoire sans fichier de support sur disque, les arbres de processus anormaux (par ex. Office lançant un interpréteur de script), les connexions réseau et les lignes de commande. Comme la mémoire est volatile, vous la capturez avant tout redémarrage — une extinction efface votre unique artefact. C'est exactement la raison d'être de l'analyse mémoire.

Pourquoi les autres options sont fausses

• Lancer un scan antivirus du disque et lui faire confiance. Un scan disque ne peut voir un code qui n'est pas sur disque. Un scan propre ici est une fausse réassurance — l'implant est dans la RAM, intact.
• Conclure que tout va bien car le disque est propre. C'est le piège que le malware est fait pour déclencher. « Disque propre » n'a aucun sens face à une menace fileless ; l'absence sur disque est la preuve de la technique, pas de la sécurité.
• Vérifier la corbeille. La corbeille contient des fichiers supprimés. Aucun fichier n'est impliqué, c'est donc un geste vain pendant que la preuve volatile s'écoule.

Ce que recherchent les examinateurs

Le signal senior, c'est de nommer l'ordre de collecte et l'ensemble des techniques : capturer la mémoire d'abord car elle est volatile, puis chercher injection, chargement réflectif et abus de LOLBins dans l'arbre de processus. Les bons candidats relient cela à la télémétrie EDR et à l'outillage de live response, et soulignent explicitement que redémarrer l'hôte pour le « réparer » détruirait l'unique preuve — une erreur qu'un junior sous pression commet souvent.