Mouvement latéral

Du poste compromis au contrôle de la cible suivante

Une fois un premier accès obtenu — via phishing, une application vulnérable ou une session de bas privilège récupérée en énumération — le pentest change de nature. L'objectif n'est plus de casser un mot de passe mais de rejouer un secret déjà en votre possession pour atteindre d'autres machines du domaine, sans jamais avoir besoin de le déchiffrer. C'est le principe même du mouvement latéral en environnement Active Directory : les protocoles d'authentification Windows acceptent des formes de secret dérivées (hash NTLM, ticket Kerberos) comme preuve d'identité, exactement au même titre qu'un mot de passe en clair.

Ce chapitre traite des deux familles de rejeu — Pass-the-Hash et Pass-the-Ticket / Overpass-the-Hash — puis des trois vecteurs d'exécution distante les plus utilisés en engagement : WinRM, RDP et les partages d'administration SMB. Il se termine sur ce qu'un défenseur observe réellement dans ses journaux, parce qu'un pentester qui ne sait pas ce qu'il laisse comme trace ne peut pas conseiller correctement son client sur la détection.

Ce chapitre suppose acquis le fonctionnement de Kerberos (TGT, TGS, chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire des tickets) vu dans un chapitre précédent. Si les notions de clé de session, de PAC ou de KDC vous sont encore floues, revenez-y avant de poursuivre : le Pass-the-Ticket n'a de sens qu'une fois ce socle posé.

Pass-the-Hash : rejouer le hash NTLM sans le casser

Le mécanisme

L'authentification NTLM (encore active par défaut dans la plupart des domaines, même Kerberos-first) repose sur un échange défi-réponse : le client chiffre un défi envoyé par le serveur avec une clé dérivée du hash NT du mot de passe. Le serveur — ou plus précisément le contrôleur de domaine via Netlogon — vérifie cette réponse. Le point essentiel : le mot de passe en clair n'intervient jamais dans ce calcul, seul le hash NT compte. Si vous disposez du hash NT d'un compte, peu importe que vous connaissiez le mot de passe d'origine, vous pouvez produire une réponse NTLM valide.

Le hash NT se récupère de plusieurs façons en post-exploitation : dump de la base SAM locale, extraction mémoire de LSASS (Mimikatz sekurlsa::logonpasswords), ou dump NTDS.dit si vous contrôlez déjà un contrôleur de domaine. Une fois ce hash en poche pour un compte disposant de droits d'administration locale sur d'autres machines — typiquement un compte de service ou un administrateur local partagé — le mouvement latéral devient direct.

# Extraction des hashs en mémoire (nécessite privilège local admin)
mimikatz # sekurlsa::logonpasswords

# Pass-the-Hash avec Impacket vers un partage admin
psexec.py -hashes :b4b9b02e6f09a9bd760f388b67351e2b corp.local/administrateur@10.10.10.20

# Pass-the-Hash avec CrackMapExec pour valider le hash sur tout le sous-réseau
crackmapexec smb 10.10.10.0/24 -u administrateur -H b4b9b02e6f09a9bd760f388b67351e2b

Sur un parc de postes déployés depuis la même image, le compte administrateur local partage souvent le même mot de passe — donc le même hash NT — sur des dizaines de machines. Un seul dump LSASS sur un poste compromis suffit alors à obtenir un accès administrateur local sur l'ensemble du parc, sans jamais connaître le mot de passe en clair. C'est l'un des scénarios de mouvement latéral les plus rapides à démontrer dans un rapport, et l'un des plus simples à corriger avec LAPS.

Les limites du Pass-the-Hash

Le NTLM pur ne fonctionne que là où NTLM est accepté. Plusieurs facteurs le bloquent ou le rendent moins pertinent :

• Signature SMB obligatoire — si activée sur la cible, elle n'empêche pas le PtH lui-même mais complique certains outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire qui reposent sur des sessions SMB non signées
• Restricted Admin Mode sur RDP — modifie la sémantique du rejeu, traité plus loin
• Comptes dans le groupe Protected Users — interdisent explicitement l'authentification NTLM pour ces comptes, forçant Kerberos
• UAC à distance (LocalAccountTokenFilterPolicy) — un compte administrateur local non-RID 500 perd ses privilèges élevés lors d'une connexion réseau, sauf configuration explicite contraire

Le Pass-the-Hash reste néanmoins l'un des vecteurs les plus fiables en engagement, ces durcissements étant rarement homogènes sur un parc.

Pass-the-Ticket et Overpass-the-Hash : rester dans l'écosystème Kerberos

Le Pass-the-Ticket (PtT) consiste à extraire un ticket Kerberos existant — TGT ou TGS — depuis la mémoire d'une machine compromise, puis à l'injecter dans votre propre session pour l'utiliser comme s'il vous appartenait. Contrairement au Pass-the-Hash, aucune clé n'est rejouée : c'est le ticket lui-même, déjà émis et signé par le KDC, qui est transporté et réutilisé.

# Extraction des tickets présents en mémoire
mimikatz # sekurlsa::tickets /export

# Injection d'un ticket dans la session courante
mimikatz # kerberos::ptt ticket_administrateur.kirbi

# Équivalent avec Rubeus
Rubeus.exe ptt /ticket:ticket.kirbi

L'Overpass-the-Hash (Pass-the-Key) est une variante hybride : au lieu de rejouer un hash NTLM sur un protocole NTLM, on l'utilise — ou la clé Kerberos dérivée — pour demander un vrai TGT auprès du KDC, comme une authentification légitime. L'intérêt est de sortir du NTLM, souvent plus surveillé, pour opérer entièrement en Kerberos, perçu à tort comme intrinsèquement plus sûr par certains SOC.

# Demande d'un TGT à partir du hash NT (Overpass-the-Hash)
Rubeus.exe asktgt /user:administrateur /rc4:b4b9b02e6f09a9bd760f388b67351e2b /domain:corp.local /ptt

Un TGT volé reste valable jusqu'à son expiration (10 heures par défaut, renouvelable jusqu'à 7 jours) — une fenêtre bien plus longue qu'une session RDP interactive. À l'inverse, un ticket injecté dans une session disparaît si la machine hébergeant cette session redémarre ou si le processus dans lequel il a été injecté se termine. Documentez systématiquement l'heure d'extraction et la portée du ticket dans vos notes d'engagement : un TGT domain admin oublié dans une session est un risque opérationnel, pas seulement une preuve de concept.

Trois vecteurs d'exécution distante

Une fois le secret en main — hash ou ticket — encore faut-il l'utiliser pour exécuter du code sur la cible. Trois vecteurs dominent très largement les engagements Windows.

WinRM (PowerShell Remoting)

WinRM écoute sur les portsportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire 5985 (HTTP) et 5986 (HTTPSHTTPSRéseauxHTTP sécurisé par TLS : chiffre les échanges entre client et serveur et authentifie le serveur via un certificat.Voir dans le glossaire) et permet l'exécution de commandes PowerShell distantes. C'est le vecteur natif le plus discret côté outillage, car il ne dépose aucun binaire sur la cible — tout passe par un shell PowerShell distant.

# Connexion legacy PowerShell (nécessite d'être déjà admin local, ou credentials valides)
Enter-PSSession -ComputerName srv-app01 -Credential $cred

# Evil-WinRM, outil de référence en pentest, supporte le Pass-the-Hash
evil-winrm -i 10.10.10.20 -u administrateur -H b4b9b02e6f09a9bd760f388b67351e2b

WinRM requiert que le compte utilisé appartienne au groupe local Remote Management Users ou aux administrateurs locaux. C'est souvent le vecteur préféré une fois un accès administratif confirmé, car il offre un vrai shell interactif avec un minimum de bruit sur disque.

RDP et le mode Restricted Admin

Le RDP classique exige un mot de passe en clair au moment de la connexion — un hash NTLM seul ne suffit pas via une session interactive standard. Le Restricted Admin Mode, introduit pour limiter l'exposition des identifiants en clair sur les serveurs de rebond, change cette donne : il permet une connexion RDP en rejouant directement un hash, sans jamais exposer le mot de passe, au prix d'une session qui n'a pas accès aux ressources réseau avec les identifiants du compte (comportement en "network-only" côté cible).

# Connexion RDP native avec Restricted Admin (nécessite l'option activée côté cible)
mstsc.exe /restrictedadmin

# Pass-the-Hash direct sur RDP via xfreerdp
xfreerdp /u:administrateur /pth:b4b9b02e6f09a9bd760f388b67351e2b /v:10.10.10.20

Le mode Restricted Admin doit être explicitement activé côté cible via la clé de registre DisableRestrictedAdmin sous HKLM\System\CurrentControlSet\Control\Lsa. Beaucoup d'administrateurs l'activent pour des raisons de commodité opérationnelle (accès rapide aux serveurs de rebond) sans mesurer qu'ils ouvrent une voie de Pass-the-Hash direct sur un protocole habituellement perçu comme nécessitant un mot de passe.

Partages d'administration (ADMIN$, C$) et exécution distante SMB

Les partages administratifs activés par défaut sur tout poste Windows (ADMIN$, C$, IPC$) permettent, combinés à un accès administrateur, l'exécution de code à distance via plusieurs mécanismes classiques :

wmiexec est souvent préféré en engagement car il évite la création d'un service Windows, plus facilement repérable, au prix d'un shell semi-interactif (chaque commande est une nouvelle exécution WMI, sans état de shell persistant).

Comparatif des trois vecteurs

Ce que le Blue Team observe

Le mouvement latéral, quel que soit le vecteur, laisse des traces relativement stables dans les journaux Windows et dans Sysmon. Un pentester compétent restitue systématiquement ces éléments dans son rapport, car ils orientent directement les règles de détection du client.

• Event ID 4624 (connexion réussie) avec Logon Type 3 (réseau, typique de SMB/WinRM) ou Type 10 (RDP interactif à distance) — le champ Logon Process et le nom du poste source sont déterminants pour corréler plusieurs connexions vers des machines différentes en peu de temps
• Event ID 4648 (connexion avec identifiants explicites) — très révélateur d'un Pass-the-Hash ou d'un runas avec des credentials différents de la session courante
• Event ID 4672 (privilèges spéciaux assignés à la nouvelle session) — accompagne quasi systématiquement une connexion administrative
• Event ID 4768/4769 côté contrôleur de domaine — délivrance de TGT/TGS, utile pour repérer un Overpass-the-Hash ou un Pass-the-Ticket massif
• Event ID 7045 — création d'un nouveau service, signature quasi certaine de psexec/smbexec
• Sysmon Event ID 1 (création de process), 3 (connexion réseau sortante), 10 (accès à un process, typique d'un dump LSASS) — indispensables si l'EDR ou Sysmon est déployé, ce qui devient la norme en 2026

Aucun de ces événements n'est individuellement suspect : une connexion Type 3 ou un Event 4648 se produit des milliers de fois par jour dans un domaine normal. C'est la corrélation — un même compte se connectant en Type 3 vers dix machines différentes en trois minutes, ou un compte de service se connectant soudain en RDP interactif — qui constitue un signal exploitable. Un rapport de pentest qui recommande "activer la journalisation" sans préciser quelle corrélation détecter n'apporte pas grand-chose au client.

Contre-mesures à recommander

Aucune de ces techniques ne se corrige par un correctif unique ; il s'agit de réduire la surface et la portée du rejeu :

• LAPS (Local Administrator Password Solution) — élimine la réutilisation d'un mot de passe administrateur local identique sur tout le parc, neutralisant l'essentiel des scénarios de Pass-the-Hash "à grande échelle"
• Groupe Protected Users — force Kerberos AES-only pour les comptes sensibles, interdit NTLM et le cache de credentials en mémoire pour ces comptes
• Credential Guard — isole les secrets LSASS dans un conteneur virtualisé inaccessible même à un processus SYSTEM classique, rendant les extractions Mimikatz classiques inopérantes
• Tiering d'administration (modèle en niveaux) — un administrateur Tier 0 (contrôleurs de domaine) ne doit jamais s'authentifier sur un poste Tier 2 (postes utilisateurs), coupant la chaîne de compromission qui permet à un hash volé sur un poste de mener jusqu'au domaine
• Restriction du Restricted Admin Mode — désactiver la clé de registre correspondante si l'usage n'est pas justifié opérationnellement

Checklist opérationnelle pour l'engagement

1. Confirmer la nature exacte du secret obtenu (hash NT, TGT, TGS) et sa portée (quel compte, quels droits)
2. Tester la validité du secret sur un sous-réseau ciblé avant tout déploiement massif (éviter le bruit inutile)
3. Choisir le vecteur le plus discret compatible avec l'objectif (WinRM en priorité si un shell complet suffit)
4. Noter systématiquement heure, cible et méthode de chaque mouvement latéral pour la reconstitution du rapport
5. Vérifier si LAPS, Protected Users ou Credential Guard sont en place avant de conclure à une faisabilité générale
6. Documenter les événements générés (4624, 4648, 7045…) pour appuyer les recommandations de détection

Ce qu'il faut retenir

Le mouvement latéral ne repose pas sur une vulnérabilité logicielle mais sur une propriété fondamentale des protocoles d'authentification Windows : un secret dérivé (hash, ticket) suffit à prouver une identité, sans jamais nécessiter le mot de passe d'origine. Cette section a couvert le rejeu de ce secret (Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash) et ses trois vecteurs d'exécution les plus courants. Le chapitre suivant s'appuiera sur ces accès obtenus pour aborder l'élévation vers le contrôle du domaine.