Registry Parser
← Tous les articles

Persistance via clés Run et l'astuce du débogueur IFEO

8 min de lecture

Il existe une matrice de référence fameuse listant quelque chose comme plus d'une centaine d'emplacements de persistance dans le Registre Windows. Mémoriser n'est pas le but. Le but est de trier les ennuyeux d'abord, parce que neuf fois sur dix l'attaquant a pris le chemin ennuyeux.

Cet article est le flux que je lance sur chaque appel "cet hôte est-il compromis" avant de me permettre d'être malin.

Chaque variante de clé Run, par ordre de priorité

Commencez ici. Ce sont les clés qui survivent aux redémarrages, se déclenchent sous le bon contexte utilisateur, et ne nécessitent aucun privilège au-delà d'écrire dans la clé elle-même. Elles attrapent la plupart des malwares opportunistes et une quantité surprenante de travail d'intrusion ciblée.

Machine-wide (ruche SOFTWARE) :

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run : se déclenche pour chaque utilisateur à la connexion, dans le contexte de cet utilisateur. La clé de persistance la plus courante de la planète.
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce : se déclenche une fois à la prochaine connexion puis se supprime. Courant pendant les processus d'installation ; les malwares persistants l'utilisent moins mais pas jamais.
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx : se déclenche avant Explorer, séquentiellement, peut chaîner des DLL. Moins courant ; quand présent, regardez attentivement.
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices et RunServicesOnce : clés héritées, ignorées sur Windows moderne mais toujours copiées par cargo-cult dans des malwares qui ciblent un large éventail d'hôtes.
  • HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run et consorts : les vues 32-bit-sur-64-bit des mêmes clés. Vérifiez toujours les deux. Le malware qui veut se cacher écrira dans la vue que l'outil de vérification standard ignore.

Per-user (NTUSER.DAT) :

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run : se déclenche à la connexion pour cet utilisateur. La persistance par utilisateur la plus courante.
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce : one-shot par utilisateur.
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Run : équivalent Run non documenté, occasionnellement utilisé.
  • HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load : valeur de chargement par utilisateur, rarement définie dans les installations légitimes.
  • HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run : sœur de Load, aussi rare en usage légitime.

Règle de triage : extrayez chaque valeur de chaque clé ci-dessus sur chaque NTUSER.DAT de l'hôte. Le contenu par défaut est bien connu. Tout ce qui ne correspond pas à un schéma fournisseur mérite un second regard. Le plugin run de RegRipper le fait pour vous en un coup.

L'astuce du débogueur IFEO

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ existe pour que les développeurs puissent attacher un débogueur à un exécutable par nom : créer une sous-clé nommée d'après le binaire cible, ajouter une valeur Debugger pointant vers le débogueur, et Windows lance le débogueur avec le binaire original en argument chaque fois que l'original est invoqué. Ce qui est dans la valeur Debugger tourne à la place du binaire original.

Trois abus classiques :

Backdoor sticky-keys. Définir Image File Execution Options\sethc.exe\Debugger à cmd.exe. Quand l'utilisateur appuie cinq fois sur Shift à l'écran de verrouillage ou de connexion RDP, Windows tente de lancer sethc.exe et lance à la place cmd.exe tournant en SYSTEM. Depuis un écran de verrouillage. C'est absurde que cela marche encore en 2026. Cela marche encore.

Utilman, OSK, Narrator, DisplaySwitch. Même astuce, binaire d'accessibilité différent. utilman.exe, osk.exe, magnify.exe, narrator.exe, displayswitch.exe. Les défenseurs qui ne vérifient que sethc manquent le reste.

Tuer un processus. Définir IFEO\<binaire_cible>\Debugger vers un chemin inexistant. Chaque fois que la cible tourne, elle échoue. Les malwares utilisent cela pour tuer les produits de sécurité par nom d'exe.

Parcourez chaque sous-clé. La liste des sous-clés IFEO légitimement définies dans une installation par défaut est courte. Tout ce qui pointe vers cmd.exe, powershell.exe, un binaire non signé, ou un chemin dans \AppData\ ou \Temp\ est malicieux jusqu'à preuve du contraire. Vérifiez aussi SilentProcessExit (HKLM\Software\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\<image>), qui peut lancer un autre processus quand celui nommé se termine.

Winlogon et la chaîne d'initialisation utilisateur

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon est la deuxième catégorie de persistance "ennuyeuse mais dévastatrice" :

  • Userinit : doit être C:\Windows\system32\userinit.exe,. Tout ce qui est ajouté après la virgule se déclenche à chaque connexion interactive. Vieille technique de persistance, encore en usage actif.
  • Shell : doit être explorer.exe. Remplacer ou ajouter à cela se déclenche à la connexion. Si shell est remplacé par un binaire malicieux, ce binaire est le shell. L'utilisateur n'a pas d'Explorer.
  • Notify : packages de notification pré-Vista. Doit être vide sur Windows moderne.
  • LegalNoticeCaption et LegalNoticeText : pas de la persistance, mais les attaquants les utilisent occasionnellement pour des messages narquois. Vérifiez quand même.

Les mêmes schémas s'appliquent à HKLM\Software\Wow6432Node\... pour les vues 32-bit.

Services tournant depuis des endroits où ils ne devraient pas

Les services sont le vecteur de persistance dominant sur les intrusions ciblées entreprise. La mécanique :

HKLM\System\CurrentControlSet\Services\<nom> est une sous-clé par service. Les valeurs qui comptent :

  • ImagePath : le binaire que le service exécute. Entre guillemets ou non ; relatif ou absolu ; pointant parfois vers svchost.exe avec un groupe -k.
  • ServiceDll : sous Parameters\, pour les services hébergés par svchost, la DLL qui est chargée dans le processus svchost.
  • Start : 2 est automatique, 3 est manuel, 4 est désactivé, 0 et 1 sont driver de démarrage et driver système.
  • Type : 0x10 est own-process, 0x20 est shared-process, 0x1 est driver noyau.

Règle de triage : extrayez ImagePath et ServiceDll pour chaque service. Filtrez sur les chemins hors des répertoires système standards. Tout ce qui est dans \AppData\, \Users\Public\, \Temp\, ou C:\ProgramData\<random>\ est hautement suspect. Les plugins svc et services de RegRipper font ce triage.

Astuce d'attaquant persistant : remplacer la ServiceDll d'un vrai service svchost que personne ne surveille par une DLL malicieuse. Le service apparaît dans services.msc comme le service légitime. Le binaire qui tourne est celui de l'attaquant. Recoupez ServiceDll contre la liste de bonnes valeurs connues, pas contre le nom d'affichage.

Tâches planifiées : la moitié registre

Les tâches planifiées vivent à deux endroits. La moitié XML est dans C:\Windows\System32\Tasks\<NomTâche>. La moitié registre est dans HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\<GUID> et les sous-clés parallèles Tree\ et Plain\.

Les attaquants manipulent parfois une moitié sans l'autre. La technique classique :

  1. Créer une tâche planifiée normalement.
  2. Supprimer l'entrée registre (ou le XML).
  3. La moitié qui reste peut encore faire tourner la tâche, selon la version Windows et comment le Task Scheduler met en cache.

Détection à deux côtés : analysez les deux moitiés et comparez. Toute tâche référencée dans une moitié mais pas dans l'autre est suspecte. RegRipper fait le côté registre. Le côté XML est simple à parcourir.

Aussi : Microsoft\Windows NT\CurrentVersion\Schedule\CompatibilityAdapter\Signatures\ porte les hashs des XML de tâches. Les incohérences entre le hash enregistré et le XML réel indiquent une manipulation.

Redirection du dossier de démarrage

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders et User Shell Folders définissent où vit le dossier Démarrage. Le défaut pointe vers C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp. Si un attaquant le réécrit pour pointer vers un répertoire accessible en écriture sous \AppData\ ou C:\Users\Public\, chaque binaire dans ce répertoire tourne à la connexion. Rare en pratique car cela nécessite l'écriture dans SOFTWARE, mais dévastateur quand présent et la plupart des vérificateurs d'autoruns le manquent. Pareil pour Common Startup et les équivalents par utilisateur.

Un flux de détection qui marche

Pour un hôte que vous suspectez compromis :

  1. Acquérir toutes les ruches. SYSTEM, SOFTWARE, chaque NTUSER.DAT, chaque UsrClass.dat, plus .LOG1 et .LOG2 pour chaque. Incluez les profils non connectés récemment.
  2. Lancer autoruns hors ligne. autoruns de Sysinternals peut cibler un registre hors ligne via autorunsc.exe -e contre une ruche montée. La sortie est verbeuse mais le tri par colonne et l'option "vérifier les signatures" font la première passe pour vous.
  3. Parcourir les clés Run manuellement. Même avec autoruns, parcourez-les avec un outil qui montre les valeurs brutes. Autoruns cache les choses qu'il considère bénignes.
  4. Parcours IFEO. Extrayez chaque sous-clé sous Image File Execution Options\. Vérifiez les valeurs Debugger, GlobalFlag, et MitigationOptions.
  5. Parcours services. Extrayez chaque Services\<nom>\ImagePath et ServiceDll. Recoupez avec la liste de services Windows connus.
  6. Parcours tâches planifiées. Analysez les deux moitiés (registre et XML). Comparez les incohérences.
  7. Comparer avec snapshots VSS. Si l'une des clés de persistance ci-dessus a changé dans le dernier jour ou semaine par rapport à un snapshot, ce changement est votre piste.
  8. Pivoter vers les artefacts fichier. Pour tout binaire référencé par une valeur de persistance, cherchez son enregistrement AmCache, son entrée Prefetch, ses horodatages MFT, son entrée Shimcache. La clé de persistance est la piste ; les artefacts fichier sont la corroboration.
  9. Pivoter vers EVTX. Les événements de création de processus (Security 4688 si activé, Sysmon 1 si installé) corroborent quand la persistance s'est déclenchée.

Le diff VSS est l'étape de la plus haute valeur. Une persistance qui apparaît dans la ruche vivante mais pas dans un snapshot d'il y a deux jours est votre incident, avec la plage horaire réduite entre les snapshots.

Ce que les attaquants font, et ce qui survit

L'attaquant avisé écrit une valeur Run, exécute la charge utile, supprime la valeur. Le LastWrite de la clé reflète la suppression. La valeur précédente vit dans les journaux de transactions si la suppression était récente, dans les snapshots VSS si ceux-ci tournaient, et dans les cellules non allouées de la ruche elle-même, récupérables via yarp ou le plugin del de RegRipper. Les attaquants qui réduisent la ruche avec reg unload et forcent un flush peuvent parfois purger ces cellules. La plupart ne s'en embêtent pas.

Pour aller plus loin

La détection de persistance est davantage un exercice de checklist que de créativité. Faites la checklist, trouvez les choses ennuyeuses, puis cherchez les astucieuses. Les choses ennuyeuses attrapent 90 % des incidents.