Questions d'entretien Windows Internals

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.

LSASS stocke des identifiants et secrets en cache, donc un processus inattendu lisant sa mémoire est la signature d'un vol d'identifiants (par exemple un dump de type mimikatz). Triez le processus fautif et son parent, isolez l'hôte pour stopper le mouvement latéral, et renouvelez les identifiants susceptibles d'avoir été capturés — y compris les comptes privilégiés et de service. Cela n'a rien à voir avec le rendu graphique ou l'espace disque, et l'ignorer comme normal peut mener à une compromission de tout le domaine. Les distracteurs d'apparence anodine sont précisément la façon dont les analystes ratent une intrusion active.

Word engendrant un processus enfant juste après l'activation des macros est un schéma classique d'accès initial par document malveillant. Isolez l'hôte pour limiter la propagation, capturez les preuves volatiles, et enquêtez sur le processus engendré, son activité réseau et toute persistance. Demander à l'utilisateur de fermer le fichier ou réparer Office ne traite pas une charge utile en cours d'exécution qui a peut-être déjà tourné. Ne rien faire parce que le fichier est arrivé par e-mail est à l'envers — l'e-mail est précisément le vecteur de livraison de cette attaque. Confinez d'abord, puis enquêtez.

Un logiciel légitime exécute rarement PowerShell depuis %TEMP% via une tâche planifiée fraîchement créée — c'est une technique courante de persistance et d'exécution. Examinez la définition de la tâche, le script invoqué, le processus créateur et la chronologie, confinez l'hôte, et balayez l'environnement à la recherche du même motif. Les mises à jour ne ressemblent pas à cela, faire confiance aveuglément aux tâches planifiées ignore une TTP connue, et supprimer System32 casse le système d'exploitation sans rien faire contre la menace. Les trois premières options reflètent toutes un jugement dangereusement faible.

L'antivirus traditionnel compare les fichiers à des signatures de malwares connus et les bloque ou les met en quarantaine — efficace contre les menaces connues, faible contre les attaques nouvelles ou sans fichier. L'EDR enregistre en continu le comportement du poste (processus, réseau, registre, mémoire), utilise l'analyse comportementale pour détecter l'activité suspecte, et permet aux intervenants d'investiguer, de traquer et de contenir ou restaurer à distance. L'AV est de la prévention par signature ; l'EDR ajoute visibilité, détection et réponse.

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'ordre de volatilité classe les preuves selon leur vitesse de disparition, pour collecter les plus fragiles en premier. Grosso modo : registres/cache CPU, puis RAM et état d'exécution (processus, connexions réseau, ARP), puis fichiers temporaires/swap, puis disque, puis journalisation et données de supervision distantes, et enfin supports d'archivage et sauvegardes. On travaille aussi sur des copies forensiques, on les hashe, et on maintient une chaîne de possession pour que la preuve reste recevable.

Sous Windows, les hashes des comptes locaux (NTLM) résident dans la ruche SAM sous C:\Windows\System32\config\SAM, protégée tant que l'OS tourne ; les identifiants vivants se trouvent dans la mémoire de LSASS, et les hashes de domaine sont dans NTDS.dit sur un contrôleur de domaine. Sous Linux, les hashes sont dans /etc/shadow (lisible uniquement par root), tandis que /etc/passwd contient les métadonnées de compte. Les attaquants les volent pour casser les mots de passe hors ligne ou faire du pass-the-hash.

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.

Le journal Security est primordial : 4624 connexion réussie (avec type de connexion), 4625 connexion échouée, 4634/4647 déconnexion, 4672 privilèges spéciaux attribués, 4720 compte créé, 4688 création de processus (avec ligne de commande si activée), et 4768/4769 Kerberos. Ajoutez 7045 installation de service (journal System), 4698 tâche planifiée créée, et la journalisation des blocs de script PowerShell (4104). Le type de connexion et l'audit des lignes de commande sont ce qui rend ces journaux utiles.

Kerberos repose sur un centre de distribution de clés (KDC) de confiance. Le client s'authentifie une fois auprès du serveur d'authentification et obtient un ticket d'octroi de tickets (TGT) chiffré avec la clé du KDC. Pour atteindre un service, il présente le TGT au service d'octroi de tickets et reçoit un ticket de service chiffré avec la clé de ce service. Le service le déchiffre et lui fait confiance. Les mots de passe ne traversent jamais le réseau, et les tickets ont une durée limitée.

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.

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.

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.

Pour SMB, énumérez les partages, vérifiez l'accès anonyme/session null, listez les utilisateurs et identifiez la version pour les CVE connues. Pour SNMP, essayez les community strings par défaut comme « public » et parcourez la MIB pour extraire noms d'utilisateurs, processus en cours, logiciels installés et détails réseau.

Énumérez les privilèges actuels (whoami /priv), les services mal configurés (permissions faibles, chemins de service non quotés), AlwaysInstallElevated, les tâches planifiées, les identifiants stockés et les correctifs manquants. WinPEAS ou PowerUp automatisent le balayage ; les abus de privilèges de jetons comme SeImpersonate sont des gains fréquents à forte valeur.

Tout utilisateur du domaine authentifié peut demander un ticket de service Kerberos (TGS) pour n'importe quel compte ayant un SPN. Ce ticket est chiffré avec le hachage de mot de passe NTLM du compte de service ; vous l'extrayez et cassez le mot de passe hors ligne — aucun accès privilégié requis au départ, et c'est quasi silencieux.

Le pivoting transforme un hôte compromis en relais pour atteindre des segments internes vers lesquels votre machine ne peut pas router. Vous utilisez le port forwarding, un proxy SOCKS sur votre canal C2 (par ex. Chisel, le forwarding dynamique SSH) ou un routage par agent, puis vous lancez des outils à travers ce tunnel pour attaquer le sous-réseau suivant.

Énumérez les privilèges du compte et les mauvaises configurations de l'hôte : privilèges de jeton comme SeImpersonate, chemins de service non entre guillemets, permissions de service faibles, AlwaysInstallElevated et identifiants stockés. Puis abusez du plus fiable — l'usurpation de jeton (attaques Potato) est une voie courante vers SYSTEM.

La force brute cible un seul compte avec de nombreuses tentatives de mot de passe, on voit donc beaucoup d'échecs concentrés sur un même identifiant. Le password spray inverse la logique : un ou quelques mots de passe courants essayés sur de nombreux comptes, lentement et discrètement, de sorte que chaque compte ne voit que quelques échecs. Le signal de détection est le ratio comptes/échecs et le timing, pas le nombre brut d'échecs.

L'EDR est centré sur l'endpoint : il enregistre et répond à l'activité des processus, fichiers et réseau sur les hôtes. Le XDR étend cette corrélation à plusieurs domaines — endpoint, réseau, identité, e-mail, cloud — en une stack intégrée par un même éditeur. Le SIEM est la couche large d'agrégation de logs qui ingère des données de n'importe quelle source, y compris non liées à la sécurité, pour la détection, la recherche et la conformité.

Le mouvement latéral, c'est un attaquant qui utilise un point d'appui pour atteindre d'autres systèmes. Les signes incluent des logons réseau inattendus (type 3) et RDP (type 10), l'accès aux partages admin comme C$ et ADMIN$, des outils d'exécution distante tels que PsExec, WMI et WinRM, des motifs de pass-the-hash, et un compte normalement local qui s'authentifie soudain sur de nombreux hôtes.

4624 est un logon réussi, 4625 est un logon échoué, et 4688 est une création de processus. Dans une enquête, vous utilisez 4625 pour repérer les attaques d'identifiants, 4624 (avec son type de logon et sa source) pour confirmer un accès réussi et comment il s'est produit, et 4688 pour voir ce qui a réellement été exécuté, idéalement avec l'audit de ligne de commande activé.