Mouvement latéral RDP : les artefacts du poste source

En bref. Dans un mouvement latéral RDP, la machine depuis laquelle l'attaquant s'est connecté conserve beaucoup de choses : le cache bitmap (ce que l'écran distant affichait), le journal Microsoft-Windows-TerminalServices-RDPClient/Operational (événement 1024, avec le nom de la cible), les clés de registre Terminal Server Client (cibles, UsernameHint, liste MRU), Default.rdp et les traces d'exécution de mstsc.exe. Le cache n'a aucun horodatage : ce sont ces artefacts qui permettent de le dater et de le rattacher à une cible. Côté cible, le journal Security (4624 type d'ouverture de session 10, 4778/4779) et l'événement RemoteConnectionManager 1149 confirment l'autre extrémité.

Cet article complète le guide de l'analyse forensique du cache bitmap RDP. Il s'en tient volontairement à un petit nombre d'identifiants d'événements et de clés bien connus.

Source et cible : qui conserve quoi

C'est souvent le côté source qui survit. Un attaquant qui nettoie la cible laisse les artefacts côté client sur la machine d'où il venait, à moins de nettoyer celle-là aussi.

Artefacts du poste source

Le cache bitmap

C:\Users\<user>\AppData\Local\Microsoft\Terminal Server Client\Cache\, par compte. Il montre le contenu de l'écran côté distant : consoles, fenêtres de dossiers, outils. Il ne dit ni quand ni où. La collecte est traitée dans emplacement et acquisition du cache bitmap RDP.

Les horodatages NTFS des fichiers du cache

Les fichiers du cache sont des fichiers ordinaires, datés par le système de fichiers :

• Les horodatages $STANDARD_INFORMATION et $FILE_NAME dans la $MFT : création et dernière écriture de chaque bcache*.bmc et Cache*.bin.
• $UsnJrnl : les enregistrements de création, d'écriture et de fermeture de ces fichiers, si le journal couvre encore la période.

Traitez-les comme des bornes. Une date de dernière écriture indique que le client a écrit dans le fichier à ce moment-là ; elle ne dit pas quelles tuiles ont été écrites alors, et un fichier utilisé sur plusieurs sessions ne conserve que ses dates les plus récentes. Les parseurs de MFT et de journal USN lisent ces données.

Le journal d'événements du client RDP

Le journal RDPClient Operational, Microsoft-Windows-TerminalServices-RDPClient/Operational, se trouve sur le poste source. L'événement 1024 indique que le client tente de se connecter à un serveur et donne le nom de la cible. Vous obtenez ainsi une heure et une cible à mettre en regard du cache.

Il enregistre une tentative, pas une ouverture de session réussie. Associez-le aux journaux de la cible quand vous les avez. Pour l'analyse des journaux d'événements : parseur EVTX.

Les clés de registre Terminal Server Client

Dans le NTUSER.DAT de l'utilisateur, sous Terminal Server Client :

Elles donnent les cibles et les comptes, par utilisateur. La date de dernière écriture d'une clé de registre peut aider à ordonner les événements, mais elle reflète la dernière modification de la clé, pas chaque connexion. Le parseur de registre lit ces ruches.

Default.rdp

Default.rdp, dans le dossier Documents de l'utilisateur, contient les paramètres de la dernière connexion faite avec les réglages par défaut du client. Parmi d'autres paramètres, il peut indiquer si la mise en cache bitmap persistante était activée (bitmapcachepersistenable:i:1), ce qui vous dit si vous devez vous attendre à trouver un cache.

L'exécution de mstsc.exe

Les traces d'exécution de mstsc.exe placent le client sur la chronologie : le fichier Prefetch de mstsc.exe (parseur Prefetch) et la jump list du client Bureau à distance (parseur de jump lists), qui peut lister les cibles récentes.

Artefacts de l'hôte cible

Quand la cible est disponible, confirmez l'autre extrémité :

Nous gardons cette liste courte à dessein. Bien d'autres identifiants d'événements apparaissent dans les analyses RDP ; ils varient selon la version et la configuration, et ils ne sont pas nécessaires pour dater un cache.

Tout assembler : dater le cache

Une méthode qui fonctionne :

1. Attribuer le cache. Relevez le compte dans le chemin (Users\<name>\). C'est lui qui a lancé le client.
2. Lister les cibles de ce compte. Sous-clés Servers et liste MRU du registre, Default.rdp, jump list.
3. Construire la chronologie des connexions. Heures et cibles des événements 1024 du journal du client RDP, heures d'exécution de mstsc.exe dans le Prefetch.
4. Borner le cache. Dates de création et de dernière écriture de chaque fichier du cache ; enregistrements USN s'ils sont disponibles.
5. Lire les tuiles. Cherchez tout ce qui relie le contenu à une cible ou à une heure : titres de fenêtres avec un nom d'hôte, horloge de la barre des tâches, dates dans des listes de fichiers, durées de transfert.
6. Recouper sur la cible. 4624 type 10, 4778/4779, 1149 pour le même compte et la même période.

Un exemple avec les données d'exemple

L'outil fournit un cas synthétique et fictif (FIN-WKS-07, 2026-09-14) qui suit ce schéma. Le cache collecté sur le poste source, profil svc_backup, contient :

• dans Cache0000.bin, une console intitulée FIN-WKS-07 - console (svc_backup) avec une commande rclone.exe copy C:\Users\Public\data E:\exfil, une fenêtre de dossier ouverte sur E:\exfil et une horloge de barre des tâches indiquant 10:52 ;
• dans bcache22.bmc, une vue antérieure (vers 10:14 à l'horloge) avec tar -xf tools.zip -C C:\ProgramData\Intel et un reste d'emplacement correspondant à la barre de titre d'un éditeur ouvert sur creds.txt.

Le titre de la fenêtre nomme la cible ; les horloges donnent des heures de l'écran distant. Sur un cas réel, vous chercheriez ensuite des événements 1024 nommant cet hôte autour de ces heures, une clé Servers\FIN-WKS-07 dans la ruche de svc_backup, et des ouvertures de session 4624 type 10 pour ce compte sur la cible. Présentez les valeurs des horloges comme ce que l'écran affichait, et les heures des journaux comme la chronologie.

Ce qu'il faut écrire dans le rapport

Laissez les indices de triage de l'outil hors des conclusions : « type console » est une raison de lire une tuile en premier, pas un constat.

Questions fréquentes

Quelle machine conserve les traces d'une connexion RDP sortante ?

Le poste source, c'est-à-dire la machine où le client Bureau à distance s'est exécuté. On y trouve le cache bitmap, le journal d'événements du client RDP, les clés de registre Terminal Server Client et les traces d'exécution de mstsc.exe. L'hôte cible conserve les enregistrements d'ouverture de session et de session.

Le cache bitmap peut-il indiquer de quel serveur provient une tuile ?

Non. Les tuiles ne portent ni nom d'hôte ni heure. Rattachez-les à une cible grâce au journal du client RDP, aux clés de registre Terminal Server Client et aux journaux de l'hôte cible, ainsi qu'à tout ce qui est visible dans les tuiles elles-mêmes, comme un titre de fenêtre.

L'événement 1024 prouve-t-il qu'une session a été établie ?

Non. L'événement 1024 du journal RDPClient Operational indique que le client tentait de se connecter à un serveur, avec le nom de la cible. Confirmez l'ouverture de session sur la cible (Security 4624 avec le type d'ouverture de session 10, ou RemoteConnectionManager 1149) lorsque ces journaux existent.

Articles liés

• Reconstruire des écrans RDP à partir des tuiles du cache
• Analyser le cache bitmap RDP dans votre navigateur
• Emplacement et acquisition du cache bitmap RDP