Persistance Windows : 10 Techniques Documentees et leurs Contre-mesures
Catalogue defensif de 10 mecanismes de persistance Windows avec requetes KQL pretes pour le hunting et mesures de hardening reproductibles dans tout SOC.
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 et livre des requetes KQL que votre Defender XDR ou Sentinel peut executer demain matin.
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. 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.
Les Scheduled Tasks (T1053.005) 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.
Les services Windows (T1543.003) 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. 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.
WMI Event Subscription (T1546.003) 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. 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.
Le COM hijacking (T1546.015) 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. AppInit_DLLs (T1546.010) et Image File Execution Options (T1546.012) appartiennent a la meme categorie d'abus de flux d'execution base sur le registre et meritent des requetes dediees. Ceux qui se demandent pourquoi l'evasion moderne passe encore par la doivent lire Evasion EDR pour la Recherche: Direct Syscalls Expliques sans Romance.
Startup folder, Logon Scripts (T1037), BITS Jobs (T1197) et Print Processors (T1547.012) ferment la liste pratique. BITS merite une attention particuliere car il survit au logoff et peut tirer des payloads via processus de confiance : bitsadmin /list /allusers /verbose en check hebdomadaire attrape deja 95% des cas. Les Print Processors sont revenus sur la carte apres PrintNightmare et surveiller HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments coute peu. 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.
Takeaway pratique : 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. La persistance ne se detecte pas avec une regle brillante, elle se detecte avec une discipline de revision. 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.