Persistance Windows : 10 Techniques Documentees et leurs Contre-mesures

La persistance n'est pas la partie glamour d'un engagement, mais c'est ce qui separe un adversaire qui perd l'acces au premier redemarrage de celui qui revient trois semaines plus tard quand l'equipe a oublie l'alerte. Chez Basilisk OffSec, nous menons des exercices contre des clients ou plus de 70% des detections devenues incidents reels ont commence par des mecanismes triviaux : cles Run, scheduled tasks aux noms fantaisistes, services avec chemins non quotes. Ce catalogue ne vise pas a apprendre a cacher des implants. Il documente dix techniques reelles que nous voyons chaque semaine, mappe chacune sur son ID MITRE ATT&CK et livre des requetes KQL que votre Defender XDR ou Sentinel peut executer demain matin, avec la contre-mesure qui ferme chaque porte.

1. Cles de registre d'execution automatique (T1547.001)

La premiere famille a couvrir est celle des cles de registre d'execution automatique. HKCU\Software\Microsoft\Windows\CurrentVersion\Run reste le T1547.001 le plus exploite dans les campagnes commodity, non parce que les attaquants sont paresseux mais parce que ca marche dans tout profil sans elevation. Une requete simple comme DeviceRegistryEvents | where RegistryKey has "CurrentVersion\\Run" and InitiatingProcessFileName !in ("explorer.exe","msiexec.exe") attrape 80% des cas une fois la baseline faite par hostname. La contre-mesure est une baseline par utilisateur plus AppLocker ou WDAC bloquant l'execution depuis les chemins inscriptibles par l'utilisateur, pour qu'une valeur Run ecrite ne puisse pas se lancer. Pour comprendre le contexte offensif de ces chemins, relisez Initial Access Simule: Macros, LNK et ISO dans un Lab Windows 11 Isole car la plupart des macros vus en lab finissent par ecrire exactement dans ces cles.

2. Scheduled Tasks (T1053.005)

Les Scheduled Tasks sont la deuxieme technique la plus abusee et la plus sous-rapportee. Le defi n'est pas de detecter la creation de la tache, c'est de filtrer le bruit : un Windows 11 corporate cree environ 40 taches legitimes durant les cycles d'update. La requete qui nous sert le mieux est DeviceProcessEvents | where FileName == "schtasks.exe" and ProcessCommandLine has_any ("/create","/change") | where InitiatingProcessParentFileName !in (~"msiexec.exe",~"trustedinstaller.exe") combinee avec un enrichissement Get-ScheduledTask filtrant Author vide ou sans signature. En parallele, surveiller l'evenement 4698 dans Security log et parcourir TaskCache\Tree dans le registre attrape les taches cachees invisibles a schtasks /query. La contre-mesure est d'alerter sur la creation de taches hors fenetres de changement et de refuser l'enregistrement de taches aux non-admins via GPO.

3. Services Windows (T1543.003)

Les services Windows restent le vecteur prefere quand l'attaquant a deja SYSTEM. Le focus du blue team doit etre sur trois signaux : creation de service pointant vers un binaire non signe, ImagePath dans des dossiers world-writable comme ProgramData ou Public, et le classique unquoted service path. Un bon hunt commence par DeviceEvents | where ActionType == "ServiceInstalled" | where FolderPath !startswith "C:\\Windows\\" and FolderPath !startswith "C:\\Program Files". Pour eviter la confusion avec les installations legitimes, faites un join avec la table des certificats et eliminez tout ce qui est signe par un signataire corporate connu. La contre-mesure est de quoter chaque chemin de service, restreindre SeCreateServicePrivilege et imposer le code-signing. Ce schema fait echo a la detection baseline-driven que nous avons couverte dans Hunting des Living-off-the-Land Binaries sous Windows avec KQL.

4. WMI Event Subscription (T1546.003)

WMI Event Subscription est ou les choses deviennent serieuses. C'est silencieux, ca survit au reboot et ca apparait rarement dans les playbooks juniors. La recette : surveiller __EventFilter, __EventConsumer et __FilterToConsumerBinding dans la classe root\subscription. Dans Defender, DeviceEvents | where ActionType == "WmiBindEventFilterToConsumer" fonctionne, mais dans les environnements sans MDE il faut Sysmon avec les evenements 19, 20 et 21 actives. Combinez avec Get-WmiObject -Namespace root\subscription -Class __EventConsumer en execution hebdomadaire comme controle de conformite ; un CommandLineEventConsumer ou ActiveScriptEventConsumer sur un endpoint n'est presque jamais legitime. Les techniques de mouvement lateral qui terminent en persistance WMI sont bien illustrees dans Mouvement Lateral en Lab: SMB, WMI et WinRM avec Focus Detection.

5. COM Hijacking (T1546.015)

Le COM hijacking exploite la precedence de HKCU sur HKLM pour les CLSIDs. L'attaquant enregistre un InProcServer32 sous HKCU pointant vers une DLL controlee, et tout processus chargeant ce CLSID en session utilisateur execute le code. Pour traquer, concentrez-vous sur les ecritures inattendues dans HKCU\Software\Classes\CLSID\*\InProcServer32 ou la valeur par defaut ne resout pas vers une DLL signee Microsoft. La contre-mesure est de faire la baseline des CLSIDs que chaque hote surcharge legitimement dans HKCU (generalement aucun) et d'alerter sur toute entree nouvelle, car une image corporate propre ne remplit presque jamais cette cle.

6. AppInit_DLLs et Image File Execution Options (T1546.010 / T1546.012)

AppInit_DLLs et Image File Execution Options appartiennent a la meme categorie d'abus de flux d'execution base sur le registre et meritent des requetes dediees. AppInit_DLLs charge une DLL dans tout processus liant user32.dll, et Windows moderne le desactive sous Secure Boot, donc sa seule activation est un signal d'alerte : alertez sur toute ecriture dans HKLM\...\Windows\AppInit_DLLs. L'abus d'IFEO pose une valeur Debugger sous la cle d'un executable cible, si bien que lancer par exemple sethc.exe execute le binaire de l'attaquant ; traquez les ecritures des valeurs Debugger et GlobalFlag et correlez avec des processus enfants inattendus. Ceux qui se demandent pourquoi l'evasion moderne passe encore par la doivent lire Evasion EDR pour la Recherche: Direct Syscalls Expliques sans Romance.

7. Startup folder et Logon Scripts (T1037)

Le Startup folder et les Logon Scripts ferment le trio classique de l'espace utilisateur. Un raccourci depose dans le Startup folder par utilisateur ou pour tous s'execute au logon sans elevation, et la valeur de registre UserInitMprLogonScript sous HKCU\Environment execute un script a chaque logon en passant sous la plupart des jeux de regles par defaut. Traquez les evenements de creation de fichier dans les deux chemins Startup ou le processus ecrivain n'est pas un installeur connu, et alertez sur toute valeur dans UserInitMprLogonScript, vide sur un hote propre. La contre-mesure est une ACL verrouillee du Startup folder et un audit GPO des valeurs de registre de logon-script.

8. BITS Jobs (T1197)

BITS merite une attention particuliere car il survit au logoff et peut tirer des payloads via un processus de confiance : bitsadmin /list /allusers /verbose en check hebdomadaire attrape deja 95% des cas, et le log Microsoft-Windows-Bits-Client/Operational enregistre la creation de jobs et les commandes notify. La variante dangereuse pose un SetNotifyCmdLine pour que BITS lui-meme lance le payload a la fin du transfert, ce qui ressemble a de l'activite svchost pour un analyste distrait. La contre-mesure est de surveiller le canal operationnel BITS pour les jobs avec une notify command line et de plafonner la duree de vie des jobs par politique pour qu'un transfert bloque ne roder pas pendant des semaines.

9. Print Processors et autres extensions d'autostart (T1547.012)

Les Print Processors sont revenus sur la carte apres PrintNightmare et surveiller HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments coute peu : une nouvelle DLL de print processor chargee par spoolsv.exe depuis un chemin non standard est un signal a haute confiance. La meme famille d'autostart de boot et logon (T1547) inclut la manipulation de Winlogon Shell et Userinit, les LSA Security Support Providers et les DLL helper de Netsh ; chacune est une unique valeur de registre qui ne devrait jamais changer sur un hote gere, donc une requete de conformite comparant les valeurs actuelles a une golden image les attrape toutes d'un coup. La contre-mesure est partout la meme : connaitre la bonne valeur, alerter sur l'ecart.

10. Transformer les detections en programme

La dixieme technique est celle qui relie les neuf autres : operationnaliser la detection comme un programme reproductible plutot qu'un tas de regles. Empilez les dix requetes ci-dessus dans une watchlist unique dans Sentinel, configurez une baseline de 14 jours par hote avant d'alerter et revisez les hits dans une fenetre hebdomadaire de threat hunting. Pour correler avec le cycle offensif complet, Adversary Emulation avec Caldera et MITRE ATT&CK en Lab d'Entreprise et Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue montrent comment transformer ces detections en exercices continus avec le red team, pour que chaque regle soit exercee, tunee et re-validee a intervalle plutot que de pourrir.

Prioriser les dix par prevalence et cout

Les dix techniques ne meritent pas le meme effort le premier jour, et un programme qui tente de faire bouillir l'ocean cale avant de livrer quoi que ce soit. Classez-les par prevalence contre cout de detection : cles Run et scheduled tasks sont a haute prevalence et faible cout, donc elles viennent en premier ; services Windows et BITS sont a prevalence moyenne et peu couteux a interroger, donc en deuxieme ; WMI Event Subscription, COM hijacking et la famille IFEO ou AppInit sont moins prevalents mais d'impact bien plus eleve quand ils apparaissent, car ils signalent un operateur plus capable, donc en troisieme mais a ne pas sauter. Les Print Processors et les valeurs d'autostart Winlogon ou Userinit sont rares mais trivialement peu couteux comme comparaison a une golden image, donc integrez-les au meme balayage hebdomadaire de conformite. Mappez chaque technique selon que la prevention, la detection ou les deux sont realistes sur votre flotte, car certaines, comme les unquoted service paths, se corrigent mieux une fois que surveillees pour toujours, tandis que d'autres, comme les souscriptions WMI, ne peuvent qu'etre detectees et revues. Un autre facteur decisif est l'endroit ou vit la persistance : la meme technique sur un kiosque est un indice de faible priorite, sur un controleur de domaine ou un hote de signature de code c'est une alerte du plus haut niveau, donc ponderez chaque detection par la criticite de l'actif. Publier cet ordre en matrice d'une page garde le programme honnete.

FAQ

Quelle technique une petite equipe devrait-elle detecter en premier? Les cles Run et les scheduled tasks, dans cet ordre, car elles couvrent la majorite de la persistance commodity et les requetes sont peu couteuses ; rendez ces deux propres avant de toucher aux souscriptions WMI. Ai-je besoin de Sysmon si je fais deja tourner Defender for Endpoint? Pour la plupart MDE suffit, mais WMI Event Subscription (evenements 19-21) et une partie de la visibilite sur les ecritures de registre sont plus fortes avec Sysmon, donc faites tourner Sysmon sur vos hotes joyau-de-la-couronne et a haut risque meme si la flotte repose sur MDE seul. La couverture est un spectre, et vous depensez Sysmon la ou le rayon d'impact est le plus grand.

Checklist et conclusion

Takeaway pratique : la persistance ne se detecte pas avec une regle brillante, elle se detecte avec une discipline de revision. Parcourez la checklist pour chacune des dix : canal de telemetrie collecte, requete KQL ecrite et versionnee, baseline par hote etablie, contre-mesure deployee, et la regle validee avec Atomic Red Team pour l'avoir vue se declencher. Commencez demain en executant les deux premieres requetes (Run keys et schtasks) dans votre environnement de production en mode lecture seule, comptez les hits, et vous decouvrirez de la persistance legitime que personne n'avait documentee. C'est le vrai point de depart du programme, et tout ce qui suit est de l'iteration disciplinee.