Mouvement Lateral en Lab: SMB, WMI et WinRM avec Focus Detection

Le mouvement lateral n'est pas de la magie: c'est un attaquant qui reutilise des identifiants valides au sein de protocoles legitimes. Dans notre lab GOAD avec trois Windows Server 2019 et un Windows 10 joints au domaine sevenkingdoms.local, nous avons pivote d'un poste vers le DC en moins de huit minutes en utilisant uniquement SMB, WMI et WinRM. L'objectif ici n'est pas d'enchainer les pivots, mais de montrer ou chaque technique hurle dans les logs et comment ecrire la detection avant l'incident reel. C'est de la recherche defensive: chaque commande ci-dessous tourne contre des machines nous appartenant, et chaque technique se termine par la telemetrie et la regle Sigma qui l'attrape. Si votre environnement n'est pas pret, commencez par Pentest Active Directory : Kerberoasting Pas a Pas dans un Lab GOAD.

Montage du lab et le point de depart assumed-breach

Nous supposons une breche: l'operateur detient deja un identifiant valide, obtenu dans le lab par un empoisonnement LLMNR/NBT-NS avec Responder suivi d'un crack hors ligne. C'est realiste, car le mouvement lateral ne part presque jamais de zero; il part d'un seul mot de passe reutilise ou d'un hash capture. Notre topologie GOAD nous donne kingslanding (DC), winterfell et meereen comme serveurs membres, et un poste Windows 10 comme patient zero. Avant de toucher une technique, nous prenons un snapshot de chaque VM, activons un reseau host-only pour que rien ne fuite, et confirmons que le SIEM ingere. L'ingenierie de detection ne marche que si la telemetrie existe d'abord, donc le lab est construit telemetrie-d'abord et attaque-ensuite, toujours dans cet ordre.

Execution SMB: psexec et smbexec

Nous avons demarre avec le SMB classique via impacket-psexec et smbexec. Apres avoir capture un hash NTLM avec Responder, nous avons lance psexec.py sevenkingdoms.local/jaime@10.0.10.10 -hashes :aad3b... et obtenu SYSTEM. Le bruit est enorme: creation du service RemComSvc en Event ID 7045, ecriture du binaire dans ADMIN$ declenchant l'Event ID 5145 avec share name ADMIN$ et un RelativeTargetName se terminant par un .exe aleatoire. La regle Sigma reste courte: filtrer 7045 quand ServiceFileName correspond a huit caracteres alphanumeriques suivis de .exe attrape 90 pour cent des variantes de psexec sans aucune signature binaire. smbexec est plus discret sur la creation de service mais plus bavard sur le canal de commande, lance cmd.exe /Q /c et ecrit la sortie dans un fichier temporaire du share, que l'Event ID 5145 capture aussi.

Execution WMI: wmiexec et le parent WmiPrvSE

WMI deplace la surface de logging. Avec wmiexec.py d'impacket ou un Invoke-WmiMethod direct, le processus enfant nait de WmiPrvSE.exe et non de services.exe. Dans Sysmon cela apparait en Event ID 1 avec ParentImage=C:\Windows\System32\wbem\WmiPrvSE.exe et CommandLine contenant cmd.exe /Q /c qui est la signature standard de wmiexec. Couplez avec l'Event ID 3 (connexion reseau) sortant de la cible sur le port 445 pour exfiltrer la sortie, et la confiance monte. Comme aucun service n'est cree, la regle 7045 ne se declenche jamais ici, ce qui est exactement pourquoi les equipes qui ne surveillent que l'installation de service restent aveugles a WMI. Pour une chasse plus large des abus LOLBin, revoyez Hunting des Living-off-the-Land Binaries sous Windows avec KQL.

Execution WinRM: le chouchou de l'operateur

WinRM est le chouchou des operateurs modernes parce qu'il ressemble a du trafic admin legitime. Nous avons declenche Enter-PSSession -ComputerName dc01 -Credential $cred puis un Invoke-Command distant. Les indicateurs sont a trois endroits: Microsoft-Windows-WinRM/Operational Event ID 91 (session creee), Security Event ID 4624 avec LogonType 3 et AuthenticationPackage Negotiate, et Sysmon Event ID 1 avec ParentImage=wsmprovhost.exe. Une bonne regle Sigma correle wsmprovhost.exe comme parent de tout processus autre que conhost.exe ou csrss.exe dans une fenetre de cinq minutes, ce qui elimine le bruit de PowerShell DSC. WinRM voyage sur 5985/5986, donc une regle reseau sur ces ports depuis un hote qui n'a jamais parle WinRM ajoute un autre signal peu couteux.

Un quatrieme vecteur: DCOM et scheduled tasks

Deux vecteurs de plus completent tout lab honnete. L'execution DCOM via MMC20.Application ou ShellWindows lance des enfants depuis mmc.exe ou explorer.exe avec un parent reseau inattendu, et apparait rarement dans les sets de detection junior; traquez-la en correlant une connexion distante 135/DCOM avec un processus enfant anormal. Les scheduled tasks distantes via schtasks /create /s ou le pipe ATSVC laissent Security Event ID 4698 et une ecriture TaskCache. Nous ajoutons les deux au lab pour que la bibliotheque de detection ne penche pas vers les trois techniques vedettes, car un vrai intrus change de vecteur des que l'un devient bruyant, et un programme qui ne couvre que SMB entraine les attaquants a utiliser WMI.

Detecter la chaine, pas la technique

La partie que personne ne raconte: detecter une technique isolee est facile, detecter toute la chaine est ce qui compte. Nous avons construit un playbook Elastic qui enchaine hit Responder, puis crack du hash, puis premier logon Type 3 avec hash NT sur une machine jamais touchee par cet utilisateur, puis spawn de wsmprovhost ou WmiPrvSE en moins de dix minutes. Cette correlation temporelle a fait chuter les faux positifs de 40 alertes par jour a 2 par semaine dans notre lab simule. La lecon est que les regles atomiques noient les analystes, mais les regles sequencees avec fenetre temporelle font remonter la vraie attaque tout en supprimant l'admin qui utilise WinRM chaque matin legitimement. Si vous debutez avec Sigma et Elastic, Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection couvre le pipeline ELK plus sigmac que nous utilisons comme base.

Prerequis de telemetrie: des regles sans logs sont de la poesie

Rappel important: tout ceci suppose une telemetrie decente. Sans Sysmon avec config Olaf ou SwiftOnSecurity, sans PowerShell Script Block Logging actif (Event ID 4104) et sans collecte des canaux WinRM et WMI-Activity, vos regles Sigma deviennent de la poesie. Dans GOAD nous appliquons une GPO minimale qui active ces quatre points sur tous les hotes; c'est la meme base que nous recommandons dans Durcissement de Windows 11 pour Postes de Travail a Haut Risque pour les postes corporate. Telemetrie d'abord, regle ensuite, toujours dans cet ordre, sinon vous detectez l'attaquant par le silence des logs qui n'arrivent jamais. Confirmez l'ingestion avec un test known-good avant de faire confiance a une seule regle.

Pieges courants qui aveuglent la detection du mouvement lateral

Plusieurs pieges reviennent. Premier, faire la baseline contre une semaine bruyante: si vos admins ont lance un deploiement massif de logiciels durant la baseline, l'activite type psexec est whitelistee pour toujours. Deuxieme, matcher sur le nom du processus au lieu de la lignee du parent, ce que tout operateur bat en renommant le payload. Troisieme, ignorer le LogonType 9 (identifiants explicites) que produisent le pass-the-hash et runas /netonly, un signal bien plus propre qu'on ne le croit. Quatrieme, alerter seulement sur le premier saut et rater que le mouvement interessant est le deuxieme et le troisieme. Cinquieme, oublier que l'administration distante legitime est presque identique, donc chaque regle a besoin d'une allowlist de jump boxes et comptes admin connus, sinon elle sera tunee a mort en une semaine.

Checklist de detection et validation avec Atomic Red Team

Avant de declarer une technique couverte, parcourez une checklist: le canal de telemetrie est collecte, la regle Sigma existe et est versionnee, la regle se declenche sur l'attaque dans le lab, elle ne se declenche pas sur la baseline admin legitime, et elle est chainee a au moins un signal precedent. Validez chaque regle avec Atomic Red Team, par exemple T1047 pour WMI, T1021.002 pour les admin shares SMB et T1021.006 pour WinRM, puis confirmez que l'alerte arrive dans le SIEM avec la bonne severite. Une regle que vous n'avez jamais declenchee pour de vrai est une hypothese, pas une detection, et envoyer des hypotheses en production est la facon dont les programmes accumulent des angles morts silencieux.

Du lab a la production

Passer une regle du lab a la production est une discipline a part entiere. Deployez chaque nouvelle regle Sigma en mode audit ou alerte-seule pendant au moins un cycle metier complet, car le mouvement lateral legitime le plus bruyant, deploiements de correctifs, agents de sauvegarde, outils de support a distance et pipelines de deploiement automatises, n'apparait que lorsque de vrais utilisateurs et de vraies fenetres de changement sont impliques. Suivez le taux de vrais positifs et de faux positifs de chaque regle dans un tableur simple, tunez l'allowlist des jump boxes et comptes de service, et promouvez-la seulement ensuite vers une action de ticketing ou d'auto-reponse. Versionnez les regles dans un depot git pour que chaque changement soit revu et reversible, taguez chacune avec son ID de technique ATT&CK, et planifiez un re-test trimestriel contre Atomic Red Team pour qu'une mise a jour Windows qui modifie la lignee d'un processus ne casse pas votre couverture en silence. Mesurez aussi la latence de transfert des logs, car une regle correcte sur un canal qui arrive avec quinze minutes de retard offre a l'attaquant exactement la fenetre dont il a besoin. Une bibliotheque de detection est une base de code vivante, pas un livrable unique, et les equipes qui la traitent ainsi sont celles dont le SOC attrape vraiment le deuxieme et le troisieme saut.

FAQ

Puis-je detecter le mouvement lateral avec l'EDR seul et sauter Sysmon? Un bon EDR couvre l'essentiel, mais les canaux WMI et WinRM plus le Script Block Logging vous donnent des preuves que l'EDR resume parfois, et dans une breche vous voulez les evenements bruts pour la chronologie. Faites tourner les deux quand le budget le permet. Quelle technique est la plus dure a attraper? Dans notre lab, WMI est la moins detectee car aucun service n'est cree et WmiPrvSE est un processus legitime du quotidien, donc les equipes qui misent sur 7045 la ratent completement; c'est precisement pourquoi nous recommandons de commencer le travail de detection la plutot que sur le bruyant psexec que tout le monde attrape deja.

OPSEC du chercheur et un cycle pratique court

Enfin, OPSEC du chercheur: les labs de mouvement lateral generent des hashes, des tickets kerberos et des echantillons qui ne doivent pas fuir vers votre poste reel. Nous travaillons toujours en VMs isolees en reseau host-only, avec snapshots avant chaque execution, et nous ne reutilisons jamais de mots de passe entre lab et production personnelle. Pour une vision plus large de l'isolement des environnements de recherche, OPSEC pour Chercheurs en Securite: Modele de Menace Personnel presente le modele que nous avons adopte. Takeaway pratique: choisissez une technique cette semaine (nous suggerons WMI car la moins detectee), reproduisez-la dans GOAD, ecrivez la regle Sigma, validez avec Atomic Red Team T1047, puis seulement passez a la suivante. Cycle court, detection reelle, une technique entierement fermee avant d'ouvrir la suivante.