Sous-système Windows pour Linux (WSL)

Présentation

Le sous-système Windows pour Linux exécute un espace utilisateur Linux sur Windows 10 et 11. WSL1 traduit les appels système Linux via un pilote noyau (lxss.sys / lxcore.sys) et stocke le système de fichiers Linux sous forme de fichiers NTFS ordinaires. WSL2 fait tourner un vrai noyau Linux dans une VM utilitaire Hyper-V légère, avec le système de fichiers de la distribution dans un disque virtuel ext4.vhdx. Pour l'enquêteur, une distribution WSL est un second système d'exploitation sur le même disque : son historique shell, ses clés SSH, ses tâches cron et ses outils déposés sont des artefacts Linux, et la plupart de la télémétrie Windows ne voit rien de ce qui s'y passe.

Emplacement

Ce que l'artefact prouve

• Installation : une sous-clé Lxss montre qu'une distribution a été enregistrée pour cet utilisateur, avec son nom et son emplacement de stockage.
• Exécution de WSL : les entrées Prefetch et Amcache de wsl.exe, bash.exe, wslhost.exe ou du lanceur de la distribution (ubuntu.exe, kali.exe) prouvent que WSL a été démarré, et quand.
• Activité Linux : .bash_history, /var/log, /tmp, /etc/passwd, crontabs et éléments SSH dans la distribution montrent ce qui a été fait côté Linux.
• Échanges de fichiers : des chemins comme \\wsl$\Ubuntu\home\... ou \\wsl.localhost\... dans les ShellBags, les fichiers LNK et les Jump Lists prouvent que des applications Windows ont parcouru le système de fichiers Linux. Côté Linux, /mnt/c/... dans l'historique shell montre le sens inverse.

Il ne fournit pas de preuve Windows commande par commande. Les processus Linux lancés sous WSL ne génèrent pas de Prefetch pour les binaires ELF, et sous WSL2 ils tournent dans une VM, hors de portée de la plupart de la télémétrie de processus Windows. L'absence d'historique Linux est aussi une preuve faible : HISTFILE peut être désactivé, et l'historique n'est écrit qu'à la fermeture propre du shell.

Champs clés

Horodatages

• LastWrite des sous-clés Lxss (FILETIME, UTC) : enregistrement ou dernière modification de configuration (conversion, changement d'utilisateur par défaut).
• Prefetch / Amcache des binaires WSL : premiers et derniers lancements en UTC.
• ext4.vhdx : la date de modification $SI correspond à peu près à la dernière écriture de la VM WSL2 dans la distribution.
• Dans la distribution : dates des inodes ext4 (atime, mtime, ctime et crtime) en epoch Unix, UTC. Sous WSL1, les dates Linux sont stockées dans des attributs étendus NTFS à côté des horodatages NTFS habituels : les deux jeux coexistent et peuvent diverger.

Rétention et effacement

Une distribution persiste jusqu'à wsl --unregister <nom>, qui supprime le rootfs ou ext4.vhdx sans confirmation ; la clé Lxss disparaît avec. Le VHDX supprimé peut parfois être récupéré dans l'espace non alloué ou dans les clichés instantanés, et la $MFT comme le journal USN conservent son nom et sa date de suppression. Désinstaller l'application Store supprime aussi le dossier du paquet. Les traces d'exécution côté Windows suivent la rétention habituelle du Prefetch et d'Amcache.

Collecte

# Distributions enregistrées pour l'utilisateur courant
Get-ChildItem 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss' |
  ForEach-Object { Get-ItemProperty $_.PsPath } |
  Select-Object PSChildName, DistributionName, BasePath, Flags, DefaultUid, PackageFamilyName
wsl --list --verbose

:: Arrêter la VM pour déverrouiller ext4.vhdx, puis le copier
wsl --shutdown
robocopy "%LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalState" E:\case\wsl ext4.vhdx /COPY:DAT

Sur une image de triage, collectez le NTUSER.DAT de chaque utilisateur, les dossiers LocalState et tout BasePath personnalisé. Pour WSL1, copier rootfs avec les outils Windows fait perdre les permissions Linux et les attributs étendus : préférez une image brute ou un collecteur qui comprend NTFS.

Outils d'analyse

• Registry Explorer / RegRipper pour la clé Lxss dans les ruches hors ligne.
• PECmd et AmcacheParser pour l'exécution des binaires WSL.
• Arsenal Image Mounter, qemu-nbd ou guestmount sous Linux pour monter ext4.vhdx en lecture seule ; The Sleuth Kit et Plaso (dfVFS) savent lire VHDX et ext4 directement.
• Une fois monté, traitez-le comme un système Linux : historiques shell, auth.log, crontabs, ~/.ssh, journaux du gestionnaire de paquets. Les fiches de linuxforensics.app détaillent ces artefacts.

Conseils d'investigation

• Sur un serveur ou un poste de la finance, toute clé Lxss mérite une question. Vérifiez si la fonctionnalité facultative WSL ou VirtualMachinePlatform a été activée récemment, et par qui.
• Un PackageFamilyName vide avec un BasePath inhabituel signifie un wsl --import d'une archive personnalisée : les attaquants s'en servent pour apporter une distribution préconfigurée, outils déjà installés.
• Les attaquants préfèrent WSL2 pour faire tourner des outils Linux (scanners, tunnels, outils de vol d'identifiants) hors de portée des hooks EDR Windows. Les connexions réseau de WSL2 semblent venir de l'adaptateur virtuel de la VM ; recoupez avec les journaux du pare-feu et SRUM pour wslhost.exe ou le processus vmmem / vmmemWSL.
• Cherchez les chemins \\wsl$ et \\wsl.localhost dans les artefacts Windows, et /mnt/c/Users/ dans l'historique Linux : c'est là que les données passent d'un monde à l'autre.
• Un DefaultUid à 0 signifie que la distribution se connecte en root, ce qui supprime les traces sudo de auth.log.