Mouvement latéral : traces RDP, PsExec, WMI et WinRM

Le mouvement latéral, c'est le moment où un poste compromis devient un incident à l'échelle du domaine. Ce guide passe en revue, technique par technique, les artefacts présents sur la machine source (d'où part l'attaquant) et sur la machine destination (où il arrive), pour prouver chaque rebond et les enchaîner dans un graphe. À la fin, vous saurez quels journaux ouvrir pour RDP, PsExec, SMB, WMI, WinRM, les tâches planifiées et DCOM, et quels indices trahissent l'usage de hashes volés ou d'identifiants explicites.

Si les journaux d'événements Windows ne vous sont pas familiers, commencez par la présentation des journaux d'événements et la référence des logon types : presque toutes les sections ci-dessous en dépendent.

Raisonner source contre destination

Chaque rebond a deux extrémités. La destination journalise le plus : une authentification (4624), une session, un service ou une création de processus. La source journalise moins, et surtout côté utilisateur : historique du client, Prefetch de l'outil lancé, usage d'identifiants explicites (4648). En ne regardant que les destinations, on peut dire « quelqu'un est entré depuis 10.1.2.3 » mais pas ce que cette machine a fait ensuite. En ne regardant que les sources, on rate les rebonds lancés par un outillage qui n'a jamais touché le disque.

Deux règles évitent les erreurs :

• Pivotez sur l'IP source et le logon ID. Le champ IpAddress d'un 4624 sur la destination indique la prochaine machine à collecter. Le TargetLogonId relie ce logon à tous les événements suivants de la même session.
• Vérifiez la politique d'audit. Plusieurs événements cités ici (4688 création de processus, 5140/5145 accès aux partages, 4698 création de tâche) n'existent que si la sous-catégorie d'audit correspondante était activée. L'absence de preuve est souvent une absence d'audit.

RDP

RDP est la technique la plus visible, car elle crée une session interactive avec ses propres événements de cycle de vie. La page connexions RDP détaille tous les champs.

Destination

• Security 4624, logon type 10 (RemoteInteractive). Une reconnexion à une session existante, ou un déverrouillage, donne un type 7. Avec Network Level Authentication, on voit souvent aussi un logon type 3 juste avant le type 10.
• Security 4778 / 4779 : session reconnectée / déconnectée, avec nom et adresse du client. Utile pour mesurer la durée réelle d'une session.
• TerminalServices-RemoteConnectionManager/Operational 1149 : authentification réseau réussie, avec utilisateur, domaine et IP source. Il est journalisé avant que la session existe : lisez-le comme « authentifié », pas « connecté ».
• TerminalServices-LocalSessionManager/Operational : 21 (ouverture de session), 22 (démarrage du shell), 24 (déconnexion), 25 (reconnexion), 23 (fermeture de session). C'est le 22 qui indique qu'un bureau a réellement été fourni.
• Les processus créés dans la session RDP (rdpclip.exe, tstheme.exe) et les artefacts d'activité habituels du compte sur cette machine.

Source

• NTUSER.DAT\Software\Microsoft\Terminal Server Client\Default contient MRU0 à MRU9, les serveurs saisis dans le client. ...\Servers\<host> contient UsernameHint, le compte utilisé pour cet hôte. Voir NTUSER.DAT pour la manipulation de la ruche.
• TerminalServices-RDPClient/Operational 1024 (le client tente de se connecter à un serveur nommé) et 1102 (le client initie une connexion multi-transport vers une IP).
• Documents\Default.rdp (caché) conserve les paramètres de la dernière connexion, dont full address.
• Le cache bitmap RDP, sous %LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache\, stocke des tuiles de ce que l'utilisateur a vu à l'écran distant. Une fois réassemblées, elles peuvent montrer le bureau de l'attaquant sur la destination.
• Prefetch et Jump Lists de mstsc.exe, et un 4648 si d'autres identifiants ont été saisis.

PsExec et l'exécution via service

PsExec copie un binaire de service sur le partage ADMIN$, crée un service via le Service Control Manager et dialogue avec lui par named pipes. psexec.py et smbexec.py d'Impacket, comme de nombreux frameworks de C2, suivent le même schéma avec d'autres noms.

Destination

• Security 4624 type 3 depuis l'IP source, en général accompagné d'un 4672 (privilèges spéciaux) puisque des droits d'administration sont nécessaires. Avec -u et des identifiants explicites, un logon distinct peut apparaître pour le compte sous lequel tourne le processus distant ; ne vous fiez pas à un type précis dans ce cas.
• Security 5140 / 5145 : accès à \\*\ADMIN$ et à PSEXESVC.exe dans ce partage (nécessite l'audit « Partage de fichiers » et « Partage de fichiers détaillé »).
• System 7045 : service installé, nommé PSEXESVC avec le chemin %SystemRoot%\PSEXESVC.exe par défaut. Avec -r <nom>, le nom du service et celui du binaire changent : cherchez la structure, pas le nom. Le 7036 enregistre le passage du service à l'état démarré puis arrêté.
• La clé du service sous HKLM\SYSTEM\CurrentControlSet\Services\ (voir services), normalement supprimée quand PsExec se termine proprement, mais parfois laissée après un plantage ou un kill.
• Prefetch de PSEXESVC.EXE (ou du binaire renommé) et de tout ce qui a été lancé à travers lui. Les processus enfants ont le binaire du service pour parent.

Source

• Prefetch de PsExec.exe / PsExec64.exe, et entrées Amcache et ShimCache pour le binaire.
• NTUSER.DAT\Software\Sysinternals\PsExec avec EulaAccepted, créée la première fois que l'utilisateur accepte le CLUF (l'option -accepteula l'écrit aussi).
• Un 4648 quand -u est utilisé, avec le nom du serveur cible.

SMB et partages administratifs

Monter C$ ou ADMIN$ précède souvent un PsExec, une copie d'outils ou la préparation d'une exfiltration.

• Destination : 4624 type 3, 4672 pour les administrateurs, 5140 (partage accédé) et 5145 (fichier du partage accédé), plus les journaux opérationnels Microsoft-Windows-SMBServer sur les versions récentes. Des nouveaux fichiers dans C:\Windows\ ou C:\Windows\Temp\ dont la date de création colle au logon sont la suite classique.
• Source : Prefetch de net.exe / net1.exe, entrées MountPoints2 dans NTUSER.DAT pour les partages montés via l'Explorateur, ShellBags si l'utilisateur a parcouru le partage, et 4648 si net use a reçu des identifiants.

WMI

Le WMI distant (wmic /node:, Invoke-WmiMethod, Invoke-CimMethod, wmiexec.py d'Impacket) appelle Win32_Process.Create sur la destination.

• Destination : 4624 type 3 avec 4672. L'indicateur clé, ce sont les processus lancés par WmiPrvSE.exe : un cmd.exe ou powershell.exe dont le parent est WmiPrvSE.exe mérite un examen (4688 ou Sysmon 1). Microsoft-Windows-WMI-Activity/Operational enregistre l'activité et les erreurs des providers (5857, 5858) ainsi que les abonnements permanents (5861), là où WMI bascule vers la persistance (voir le dépôt WMI). wmiexec.py redirige aussi volontiers sa sortie vers un fichier sur ADMIN$, donc le 5145 peut aider.
• Source : Prefetch de wmic.exe ou journaux PowerShell montrant les cmdlets WMI, et 4648 si des identifiants ont été fournis.

WinRM et PowerShell Remoting

Enter-PSSession, Invoke-Command et winrs passent tous par WinRM (TCP 5985/5986).

Destination

• 4624 type 3 pour le compte qui se connecte.
• wsmprovhost.exe héberge la session distante : tout ce qu'il lance est passé par le remoting. Le Prefetch de WSMPROVHOST.EXE permet de vérifier rapidement si le remoting a déjà servi sur la machine.
• Microsoft-Windows-WinRM/Operational : 91 (création d'un shell / traitement de requête), 168 (authentification de l'utilisateur), entre autres. Le libellé varie selon les versions : lisez le message plutôt que de vous fier au seul ID.
• PowerShell : Microsoft-Windows-PowerShell/Operational 4103 (module logging) et 4104 (script block logging, y compris les commandes distantes), et le journal classique Windows PowerShell avec les 400/403 où HostApplication ou HostName indique ServerRemoteHost. Voir les artefacts PowerShell.

Source

• Microsoft-Windows-WinRM/Operational 6 (création d'une session WSMan, avec le nom de la destination), puis les événements de connexion du même shell.
• Les 4103/4104 PowerShell côté source également, et ConsoleHost_history.txt dans le profil si les commandes ont été tapées à la main.
• 4648 si -Credential a été utilisé.

Tâches planifiées à distance

schtasks /create /s <host> ou l'API COM du planificateur enregistre une tâche sur la destination.

• Destination : 4624 type 3, 4698 (tâche créée), 4702 (modifiée), 4699 (supprimée), qui exigent l'audit « Autres événements d'accès aux objets ». Microsoft-Windows-TaskScheduler/Operational 106 (enregistrée), 140 (mise à jour), 141 (supprimée), 200/201 (action démarrée/terminée). Le XML de la tâche dans C:\Windows\System32\Tasks\ et les clés TaskCache restent après la rotation du journal. Détails sur la page tâches planifiées.
• Source : Prefetch de schtasks.exe et 4648 si des identifiants ont été fournis. Les attaquants créent, lancent et suppriment souvent la tâche en quelques secondes : cherchez des 4698 et 4699 rapprochés.

DCOM

Le mouvement latéral par DCOM détourne des objets comme MMC20.Application, ShellWindows ou ShellBrowserWindow pour exécuter des commandes à distance via RPC.

• Destination : 4624 type 3, puis une arborescence de processus inhabituelle : un shell lancé par mmc.exe (MMC20), par explorer.exe (ShellWindows / ShellBrowserWindow) ou par DllHost.exe pour d'autres objets. Sans audit de création de processus ni EDR, DCOM est difficile à prouver ; Prefetch et mémoire restent les solutions de repli.
• Source : en général seulement les journaux PowerShell ou l'outil qui a fait l'appel.

Indices sur les identifiants : identifiants explicites et pass-the-hash

• Le 4648 (logon avec identifiants explicites) est journalisé sur la machine où les identifiants sont utilisés, avec le compte et le serveur cibles. Sur une source, c'est l'une des meilleures traces de « cet utilisateur a contacté ce serveur avec ce compte ».
• Le 4624 type 9 (NewCredentials) avec le processus de logon seclogo est produit par runas /netonly, et aussi par les outils de pass-the-hash qui lancent un processus avec des identifiants injectés. L'identité locale reste la même ; l'identité réseau change.
• Sur les destinations, le pass-the-hash apparaît comme un 4624 type 3 en NTLM (AuthenticationPackageName = NTLM) là où l'on attendrait Kerberos. Le 4776 (validation d'identifiants) est journalisé sur le contrôleur de domaine pour les comptes du domaine, et sur la destination elle-même pour les comptes locaux.
• Un compte administrateur local réutilisé sur plusieurs machines (même mot de passe, même hash) est le facilitateur habituel. Une rafale de logons NTLM type 3 pour Administrator depuis une seule IP source mérite d'être mise en graphe.

Tableau de correspondance source / destination

MITRE ATT&CK classe ces techniques sous Lateral Movement (TA0008), pratique pour cartographier les constats dans un rapport.

Construire le graphe de mouvement latéral

Une enquête sur le mouvement latéral est un problème de graphe : les machines sont les nœuds, les rebonds authentifiés sont les arêtes. Construisez-le d'abord à partir des journaux des destinations, plus riches, puis confirmez les arêtes côté source.

1. Collecter les journaux Security, System, TerminalServices, WinRM, PowerShell, TaskScheduler et WMI-Activity de chaque machine du périmètre, plus le journal Security des contrôleurs de domaine. Une collecte de triage avec KAPE ou Velociraptor suffit ; voir acquisition et triage.
2. Normaliser le tout en CSV avec un seul parseur et un seul fuseau horaire (UTC).
3. Extraire les arêtes : pour chaque 4624 type 3/10 et chaque 4648, noter l'heure, l'IP ou le poste source, la machine de destination, le compte et le logon ID. Résoudre les IP en noms d'hôtes via les journaux DHCP ou le DNS, car les IP changent.
4. Filtrer le bruit : écarter les comptes machine, les bastions d'administration connus et les comptes de service expliqués, mais garder la liste de ce qui a été écarté.
5. Remonter depuis le patient zéro dans le temps, et depuis chaque destination vers sa source. Une arête visible des deux côtés est solide ; une arête vue d'un seul côté est une piste.

# Parser tous les journaux d'une collecte de triage avec EvtxECmd
EvtxECmd.exe -d C:\cases\HOST01\C\Windows\System32\winevt\Logs --csv C:\cases\out --csvf HOST01_evtx.csv

# Vérification rapide en live des logons réseau et RDP
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object { $_.Properties[8].Value -in 3,10 } |
  Select-Object TimeCreated,
    @{n='User';e={$_.Properties[5].Value}},
    @{n='LogonType';e={$_.Properties[8].Value}},
    @{n='SourceIP';e={$_.Properties[18].Value}}

Versez ensuite la liste d'arêtes dans un tableau croisé, un outil de graphe ou votre super timeline (voir construire une super timeline avec Plaso) pour placer les rebonds à côté des preuves d'exécution et de fichiers.

Outils

• EvtxECmd (Eric Zimmerman) : ses maps normalisent les champs clés de centaines d'event IDs, ce qui réduit l'extraction d'arêtes à un filtre sur un CSV.
• Hayabusa : triage rapide des EVTX à base de règles Sigma, avec des règles pour PsExec, RDP et WinRM et un mode de synthèse des logons.
• Chainsaw : chasse Sigma et recherche par mot-clé ou ID dans les EVTX, efficace pour balayer vite de nombreuses machines.
• Velociraptor : lancez la même chasse sur tout le parc, par exemple Windows.EventLogs.RDPAuth pour les logons RDP ou Windows.EventLogs.EvtxHunter pour des IDs arbitraires, et collectez les preuves en une passe.

# Hayabusa : timeline et synthèse des logons sur un dossier d'EVTX
hayabusa csv-timeline -d ./HOST01/Logs -o HOST01_hayabusa.csv
hayabusa logon-summary -d ./HOST01/Logs

# Chainsaw : chasse Sigma, puis recherche ciblée des installations de service
chainsaw hunt ./HOST01/Logs -s ./sigma/rules --mapping ./mappings/sigma-event-logs-all.yml --csv --output ./out
chainsaw search -t 'Event.System.EventID: =7045' ./HOST01/Logs

Les options de ces outils évoluent d'une version à l'autre : vérifiez --help sur la version utilisée.

Quand des captures réseau sont disponibles, PCAP Parser ouvre les fichiers pcap et pcapng côté client pour confirmer les conversations SMB, RDP, WinRM (5985/5986) et RPC entre les machines de votre graphe.

Erreurs fréquentes

• Prendre le 1149 pour un logon RDP réussi. Il prouve une authentification, pas un bureau livré. Confirmez avec le 4624 type 10 et les LSM 21/22.
• Chasser uniquement par nom d'outil. PSEXESVC se renomme trivialement avec -r, et Impacket utilise des noms aléatoires. Chassez les comportements : services installés depuis ADMIN$, shells sous WmiPrvSE.exe ou wsmprovhost.exe.
• Oublier le contrôleur de domaine. Les 4768/4769 (Kerberos) et 4776 (NTLM) sur les DC confirment des arêtes quand les journaux des machines ont tourné.
• Ignorer la rétention des journaux. Sur un serveur chargé, le journal Security peut ne couvrir que quelques heures. Vérifiez l'événement le plus ancien avant de conclure à l'absence d'activité.
• Faire confiance à WorkstationName plutôt qu'à IpAddress. Le nom de poste est fourni par le client et peut être falsifié ou vide.
• Supposer qu'un événement absent signifie aucune activité. Vérifiez d'abord la politique d'audit, et cherchez un effacement des journaux (1102 / 104), traité dans détecter l'anti-forensique.

Méthode pas à pas

1. Identifier la première machine compromise connue et la fenêtre temporelle.
2. Collecter journaux, ruches de registre et Prefetch sur cette machine et sur chaque machine où elle s'est authentifiée ; ajouter le journal Security des DC.
3. Vérifier la politique d'audit et la rétention des journaux sur chaque machine.
4. Extraire les arêtes de logon (4624 types 3/9/10/7, 4648, 4776) et résoudre les IP en noms d'hôtes.
5. Pour chaque arête, identifier la technique grâce aux artefacts de destination : 7045 (service), 4698 (tâche), enfants de WmiPrvSE.exe ou wsmprovhost.exe, événements TerminalServices.
6. Confirmer côté source : Prefetch, clés de registre du client, 4648, journaux PowerShell et WinRM.
7. Construire le graphe des machines, puis élargir le périmètre à chaque nouvelle source ou destination découverte.
8. Corréler avec les constats d'exécution et de persistance (voir traquer la persistance Windows) et documenter chaque arête avec ses preuves.