Aller au contenu
Hermes Codex

Analyse d'Artefact : Forensique des Services Bureau à Distance (RDS)

1. Composants architecturaux et surface d’attaque

Section intitulée « 1. Composants architecturaux et surface d’attaque »

Afin d’enquêter efficacement sur une ferme RDS, les analystes doivent comprendre ses rôles spécialisés. Les acteurs de la menace ciblent ces rôles de manière distincte selon les phases de la chaîne d’attaque (kill chain).

RD Gateway (La porte d'entrée)

exposée à l’Internet public, elle encapsule le trafic RDP (TCP 3389) à l’intérieur du HTTPS (TCP 443). Surface d’attaque : la cible principale absolue pour le Password Spraying et les campagnes de force brute.

RD Web Access (Accès Web)

un portail web basé sur IIS permettant aux utilisateurs de lancer des applications. Surface d’attaque : sensible aux exploits web traditionnels. Un pic d’erreurs ASP.NET (Événements 1307/1309 dans le journal Application) indique souvent un balayage actif de vulnérabilités web.

Hôte de session RD (Le hub de mouvement latéral)

le serveur “cheval de trait” où les utilisateurs se connectent réellement et exécutent des applications. Surface d’attaque : parce que des dizaines d’utilisateurs partagent le même espace mémoire, si un attaquant compromet un hôte de session, il peut vider la mémoire LSASS et récolter simultanément les identifiants de multiples cibles de haute valeur.

2. Télémétrie partie 1 : la passerelle (Journaux périmétriques)

Section intitulée « 2. Télémétrie partie 1 : la passerelle (Journaux périmétriques) »

La passerelle RD Gateway sert de source de vérité ultime pour l’accès externe. Ses journaux capturent l’adresse IP publique de l’attaquant avant que la connexion ne soit routée en interne.

Ces événements sont situés dans : Journaux des applications et des services > Microsoft > Windows > TerminalServices-Gateway > Operational.

  • Événement 302 : l’utilisateur a satisfait aux exigences d’autorisation de connexion (Autorisé).
  • Événement 303 : l’utilisateur a échoué à satisfaire aux exigences d’autorisation. Une tempête massive d’événements 303 est la signature définitive d’une attaque externe par force brute ou Password Spraying.
  • Événement 300 : l’utilisateur s’est connecté avec succès à la ressource cible interne (l’hôte de session).
  • Événement 200 : l’utilisateur s’est déconnecté de la ressource interne.

3. Télémétrie partie 2 : l’hôte de session (Journaux internes)

Section intitulée « 3. Télémétrie partie 2 : l’hôte de session (Journaux internes) »

Une fois que l’attaquant a passé la passerelle, son activité est consignée sur l’hôte de session.

Journaux de sécurité standards

Section intitulée « Journaux de sécurité standards »

Comme détaillé dans notre Guide de l’activité de connexion, les analystes doivent chasser l’Événement 4624 (Logon Type 10 - RemoteInteractive). Cela signifie une connexion RDP réussie sur l’hôte.

Journaux du Local Session Manager

Section intitulée « Journaux du Local Session Manager »

Pour une analyse granulaire du cycle de vie de la session, les analystes s’appuient sur : Journaux des applications et des services > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational.

  • Événement 21 : la connexion de session a réussi.
  • Événement 22 : notification de démarrage du shell reçue (le bureau Windows s’est chargé avec succès pour l’attaquant).
  • Événement 24 : session déconnectée (l’attaquant a fermé la fenêtre mais a laissé la session s’exécuter en arrière-plan).
  • Événement 25 : reconnexion de session réussie (l’attaquant est revenu sur une session existante).

4. Le piège DFIR : les disques de profil utilisateur (UPD)

Section intitulée « 4. Le piège DFIR : les disques de profil utilisateur (UPD) »

C’est l’un des écueils les plus courants pour les analystes forensiques juniors.

Dans les fermes RDS modernes, les administrateurs utilisent des disques de profil utilisateur (UPD - User Profile Disks) pour s’assurer que les paramètres d’un utilisateur le suivent sur les différents hôtes de session. Un UPD est un fichier de disque dur virtuel (.vhdx) stocké sur un partage réseau centralisé. Lorsque l’utilisateur se connecte, le .vhdx est monté dynamiquement pour devenir son répertoire C:\Users\<username>.

La conséquence forensique : Si un analyste acquiert une image forensique du disque physique C: de l’hôte de session, il ne trouvera absolument rien dans le répertoire de l’utilisateur compromis. La ruche NTUSER.DAT, les Shellbags et les artefacts UserAssist ne sont pas sur l’hôte de session ; ils sont verrouillés à l’intérieur du fichier .vhdx sur le serveur de fichiers distant.

La solution : les analystes doivent identifier le partage de fichiers central des UPD, copier le fichier UVHD-<SID-Utilisateur>.vhdx spécifique associé au compte compromis, le monter sur une station de travail forensique et extraire les artefacts directement depuis le disque virtuel.

5. Requêtes de Threat Hunting

Section intitulée « 5. Requêtes de Threat Hunting »
hunt_rds_password_spraying.kql
// Détecte les campagnes externes de Password Spraying ciblant la passerelle RD Gateway
// en utilisant l'Événement TerminalServices-Gateway 303 (Échec de l'autorisation)
Event
| where EventLog == "Microsoft-Windows-TerminalServices-Gateway/Operational"
| where EventID == 303
| parse EventData with * 'Username">' Username '</Data>' *
| parse EventData with * 'IpAddress">' SourceIP '</Data>' *
| summarize FailedAttempts = count(), UniqueUsers = dcount(Username) by SourceIP, bin(TimeGenerated, 10m)
// Seuil d'alerte : une seule IP externe tentant de se connecter à plus de 15 comptes uniques en 10 minutes
| where UniqueUsers > 15
| project TimeGenerated, SourceIP, FailedAttempts, UniqueUsers
| sort by TimeGenerated desc

Références et lectures complémentaires

Section intitulée « Références et lectures complémentaires »