Anti-forensique Windows : détecter les traces qui subsistent

Les attaquants font le ménage, et ce ménage laisse presque toujours ses propres empreintes. À la fin de ce guide, vous saurez reconnaître les techniques anti-forensiques courantes sous Windows, les rattacher à MITRE ATT&CK, savoir précisément quels artefacts survivent à chacune, et mener une investigation qui traite l'absence de preuve comme un constat plutôt qu'une impasse.

Pourquoi l'anti-forensique échoue rarement à 100 %

L'anti-forensique sous Windows se heurte à un système qui enregistre la même activité à plusieurs endroits. Effacer un journal n'efface pas les autres, supprimer un fichier écrit dans le journal USN, et lancer un outil d'effacement crée des entrées Prefetch et Amcache pour cet outil. L'attaquant doit connaître chaque copie et la supprimer sans en créer de nouvelles. En pratique, il réussit rarement les deux.

Le tableau ci-dessous sert de fil conducteur pour la suite. Les identifiants proviennent de MITRE ATT&CK.

Effacement des journaux d'événements

C'est la technique la plus courante et la plus facile à détecter. Le service Event Log écrit un dernier enregistrement quand un journal est vidé :

• Journal Security effacé : événement 1102 dans Security, avec le nom du compte et l'identifiant de session de l'auteur.
• Tout autre journal effacé : événement 104 dans System (source Microsoft-Windows-Eventlog), avec le canal et le compte.

Les deux sont générés que l'effacement vienne de l'Observateur d'événements, de wevtutil cl, de PowerShell ou de l'API. Voir la fiche journaux d'événements Windows pour les autres ID utiles et notre guide sur les journaux d'événements pour la méthode complète.

# Rechercher les effacements sur un système vivant ou sur des .evtx exportés
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102}
Get-WinEvent -FilterHashtable @{LogName='System'; Id=104} |
  Select-Object TimeCreated, @{n='Detail';e={$_.Message}}

# Hors ligne, sur un dossier de journaux collectés
EvtxECmd.exe -d E:\Triage\C\Windows\System32\winevt\Logs --csv E:\Out --inc 1102,104,1100,4719

Un journal effacé commence souvent par un 1102 ou un 104 comme premier enregistrement, bien après le dernier démarrage. Cherchez aussi :

• Des trous dans EventRecordID au sein d'un journal non effacé. Les identifiants croissent de façon monotone : un saut suggère des enregistrements retirés par un outil qui modifie le fichier au lieu de le vider.
• L'événement 1100 dans Security, « Le service de journalisation des événements a été arrêté », en dehors d'une séquence d'arrêt normale.
• La commande d'effacement elle-même : wevtutil.exe dans Prefetch, 4688 (création de processus, si l'audit de ligne de commande est actif), Sysmon événement 1, ou la journalisation des blocs de script PowerShell (4104).

Désactiver la journalisation et la stratégie d'audit

Plus discret que l'effacement : empêcher les événements d'être écrits (T1562.002).

• Modification de la stratégie d'audit : auditpol /clear ou auditpol /set ... /success:disable produit l'événement 4719 « La stratégie d'audit système a été modifiée » dans Security, avec la sous-catégorie et le changement.
• Désactivation d'un canal : wevtutil sl <canal> /e:false passe Enabled à 0 pour ce canal. Vérifiez la configuration sous HKLM\SYSTEM\CurrentControlSet\Services\EventLog\ et HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\.
• Arrêt du service : le service Event Log s'arrête mal proprement, donc des outils comme Invoke-Phant0m tuent ses threads de travail. Le service reste « en cours d'exécution » mais n'écrit plus rien. Le signe : une période de silence simultanée dans tous les journaux alors que d'autres artefacts (USN, Prefetch, SRUM) montrent une machine active.
• Réduction de la taille : une valeur MaxSize soudain très faible fait tourner le journal très vite. Comparez avec la valeur par défaut et la GPO du domaine.

Timestomping

Le sujet est traité en détail dans le guide de forensique NTFS, donc en bref : le timestomping réécrit les horodatages $STANDARD_INFORMATION d'un fichier pour qu'il se fonde dans le décor. Cherchez une création $SI antérieure à la création $FILE_NAME, des fractions de seconde à .0000000 et un BASIC_INFO_CHANGE dans le journal USN proche de l'arrivée du fichier. La comparaison $SI contre $FN est une piste ; les enregistrements USN et $LogFile en sont la corroboration.

Suppression sécurisée et effacement

Une suppression simple laisse l'enregistrement $MFT et les clusters en place. Les outils de suppression sécurisée tentent d'y remédier, mais NTFS journalise leur travail.

SDelete

SDelete (Sysinternals) écrase le contenu du fichier, puis le renomme en général 26 fois, à chaque fois avec un nom de même longueur composé d'une seule lettre répétée (par exemple AAAAAAAA.AAA, puis BBBBBBBB.BBB, jusqu'à ZZZZZZZZ.ZZZ), avant de le supprimer. Dans le journal USN, cela se traduit par une rafale de paires RENAME_OLD_NAME / RENAME_NEW_NAME sur la même référence de fichier, suivie d'un FILE_DELETE. Le nom d'origine figure dans le premier RENAME_OLD_NAME.

Autres traces de SDelete :

• SDELETE.EXE ou SDELETE64.EXE dans Prefetch, Amcache et ShimCache.
• HKCU\Software\Sysinternals\SDelete avec EulaAccepted = 1 dans le NTUSER.DAT de l'utilisateur, ce qui rattache l'usage à un compte.

# Filtrer un CSV USN parsé pour repérer les rafales de renommage façon SDelete
Import-Csv E:\Out\usn.csv |
  Where-Object { $_.Name -match '^([A-Z])\1+(\.\1+)?$' -and $_.UpdateReasons -match 'Rename' } |
  Select-Object UpdateTimestamp, EntryNumber, Name, ParentPath, UpdateReasons

cipher /w, CCleaner et BleachBit

• cipher /w:C:\ écrase l'espace libre. C'est une LOLBin : cherchez-la dans Prefetch et les journaux de ligne de commande, ainsi qu'un dossier temporaire EFSTMPWP à la racine du volume dans le journal USN.
• CCleaner laisse une installation, des réglages sous HKCU\Software\Piriform\CCleaner (qui révèlent souvent ce que l'utilisateur a choisi de nettoyer), des entrées UserAssist et Prefetch.
• BleachBit est souvent lancé en version portable, mais produit tout de même des entrées Prefetch et Amcache, un BleachBit.ini à côté de l'exécutable, et une signature USN de nombreuses suppressions dans les chemins navigateur et temporaires en quelques secondes.

L'empreinte de l'outil de nettoyage est généralement plus facile à prouver que ce qu'il a supprimé. Rapportez les deux.

Suppression des clichés instantanés et des sauvegardes

Supprimer les clichés instantanés (VSS) (T1490) fait partie de tous les playbooks de rançongiciels, car les VSS permettent aux victimes, et aux enquêteurs, de récupérer d'anciennes versions des fichiers.

vssadmin delete shadows /all /quiet
wmic shadowcopy delete
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=401MB
wbadmin delete catalog -quiet
bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

À rechercher :

• vssadmin.exe, wmic.exe, wbadmin.exe et bcdedit.exe dans Prefetch, 4688 et Sysmon, avec leurs lignes de commande.
• L'événement 524 dans le journal Application (source Microsoft-Windows-Backup), qui indique la suppression du catalogue de sauvegarde lorsque les composants Windows Server Backup sont présents.
• Les démarrages et arrêts du service VSS (System 7036) autour de la suppression, et l'absence de tout cliché là où des points de restauration planifiés étaient attendus.
• Les suppressions via WMI (Win32_ShadowCopy) dans les journaux de blocs de script PowerShell.

Les données d'un cliché supprimé peuvent parfois être partiellement carvées depuis la zone de différences de System Volume Information, mais partez du principe qu'elles sont perdues.

Effacer les artefacts d'exécution et d'activité

• Prefetch : supprimer C:\Windows\Prefetch\*.pf apparaît comme un bloc de FILE_DELETE sur des .pf dans le journal USN. La désactivation passe EnablePrefetcher à 0 sous HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters. Un poste de travail avec un dossier Prefetch presque vide est suspect en soi.
• ShimCache : le cache est tenu en mémoire et écrit dans la ruche SYSTEM à l'arrêt, donc une falsification passe en général par la modification ou la suppression de la valeur AppCompatCache. Comparez avec les copies des clichés instantanés et les journaux de transactions de la ruche.
• Historique de commandes : supprimer ConsoleHost_history.txt (PSReadLine) retire la copie pratique, mais les événements 4104 et les enregistrements USN et MFT du fichier restent.
• Historique du navigateur : effacer l'historique de Chrome ou Edge supprime des lignes de la base SQLite History, mais les pages libres (freelist), le fichier -journal ou WAL, le cache, Favicons, les événements du client DNS et l'usage réseau dans SRUM conservent souvent des traces. Voir artefacts des navigateurs.
• Journal USN : fsutil usn deletejournal /d C: supprime le journal. Un $J qui démarre quelques minutes avant la collecte sur un système ancien, ou un identifiant de journal qui a changé, doit alerter ; fsutil.exe dans Prefetch le confirme.

Neutraliser Microsoft Defender

La neutralisation des défenses (T1562.001) visant Microsoft Defender est bruyante dans son propre journal Operational (Microsoft-Windows-Windows Defender/Operational).

# Commandes typiques à rechercher dans les journaux et l'historique PowerShell
Set-MpPreference -DisableRealtimeMonitoring $true
Add-MpPreference -ExclusionPath 'C:\ProgramData\svc'

Traces dans le registre : DisableAntiSpyware ou DisableRealtimeMonitoring sous HKLM\SOFTWARE\Policies\Microsoft\Windows Defender, et exclusions sous HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths, \Extensions et \Processes. Les versions récentes de la plateforme Defender ignorent DisableAntiSpyware, et la protection contre les falsifications bloque beaucoup de ces changements, mais la tentative compte : un chemin exclu pointe directement vers l'emplacement de la charge.

Cacher des fichiers et des données

• Attributs caché et système (attrib +h +s) : visibles dans les flags d'attributs de la $MFT et comme BASIC_INFO_CHANGE dans le journal USN.
• Flux de données alternatifs : ils cachent une charge derrière un fichier légitime. Ils apparaissent comme des attributs $DATA nommés supplémentaires dans la $MFT et comme NAMED_DATA_EXTEND ou STREAM_CHANGE dans le journal USN. Une exécution depuis un ADS peut aussi apparaître dans Prefetch, avec le nom du flux dans le chemin.

Living off the land

La plupart des techniques ci-dessus reposent sur des binaires natifs : wevtutil, auditpol, vssadmin, wmic, wbadmin, bcdedit, fsutil, cipher, attrib et PowerShell. Ils sont plus difficiles à bloquer, mais pas plus difficiles à retrouver : Prefetch, 4688, Sysmon et Amcache les enregistrent comme les autres. Plusieurs d'entre eux ne tournent presque jamais sur un poste normal, si bien que leur seule présence dans Prefetch pendant la fenêtre d'incident mérite une ligne dans la timeline.

L'absence de preuve est une preuve

L'anti-forensique crée des trous, et ces trous ont une forme. Les questions à se poser :

• Le journal Security commence-t-il après le dernier démarrage, avec un 1102 en premier enregistrement ?
• Le dossier Prefetch est-il presque vide sur un poste utilisé depuis des mois ?
• Le journal USN ne couvre-t-il que quelques heures alors que sa taille laisse attendre des semaines ?
• Tous les journaux d'événements se sont-ils tus pendant les mêmes deux heures alors que SRUM et le journal USN montrent de l'activité ?
• N'y a-t-il aucun cliché instantané sur un système configuré pour en créer ?

Un trou isolé reste un indice faible, car la rétention, une mauvaise configuration ou la rotation en créent aussi. Il devient solide quand il est brutal, aligné sur la fenêtre d'intrusion et concomitant de l'outil ou de la commande qui l'a causé.

Ce qui survit à chaque technique

Outils

• EvtxECmd et l'EVTX Parser du site pour les événements 1102, 104, 4719 et Defender.
• MFTECmd (ou l'USN Parser et le MFT Parser) pour les rafales de renommage, les indicateurs de timestomping et les suppressions.
• PECmd, AmcacheParser et AppCompatCacheParser pour l'exécution des outils de nettoyage eux-mêmes.
• Registry Explorer ou RECmd pour les clés Piriform, Sysinternals, exclusions Defender et canaux.
• Velociraptor pour chasser sur de nombreux postes, clichés instantanés compris, et trouver ceux dont les journaux ont été effacés.
• Hayabusa ou Chainsaw avec des règles Sigma pour signaler effacements et falsifications à grande échelle.

Erreurs fréquentes

• S'arrêter à « le journal a été effacé ». L'événement d'effacement donne une heure et un compte : servez-vous des deux pour pivoter.
• Ignorer les copies VSS et SIEM. Un Security.evtx effacé est souvent intact dans un cliché plus ancien ou dans les événements transférés.
• Surinterpréter un trou isolé. Vérifiez taille du journal, rétention et historique des démarrages avant de conclure à un acte délibéré.
• Oublier l'empreinte de l'outil. Le nettoyeur, l'effaceur ou le script est en soi une preuve d'intention.
• Lancer des outils qui nettoient pendant la réponse. Certains EDR et scripts de triage font tourner des journaux ou suppriment des fichiers temporaires : documentez tout ce que vous exécutez.

Méthode de travail

1. Préservez d'abord : collectez journaux d'événements, $MFT, $J, $LogFile, ruches de registre et clichés instantanés avant toute rotation. Voir acquisition et triage avec KAPE et Velociraptor.
2. Balayez les indicateurs explicites : 1102, 104, 1100, 4719, Defender 5001/5007/5013, événement de sauvegarde 524.
3. Vérifiez l'exécution d'outils anti-forensiques et de LOLBins dans Prefetch, Amcache, ShimCache, 4688 et Sysmon.
4. Parsez le journal USN pour y chercher les rafales de renommage SDelete, les suppressions massives dans Prefetch, les chemins navigateur et temporaires, et les BASIC_INFO_CHANGE sur les fichiers suspects.
5. Passez la $MFT en revue : indicateurs de timestomping, attributs cachés et ADS sur les fichiers d'intérêt.
6. Mesurez la couverture : premier et dernier enregistrement de chaque journal et de $J, nombre de fichiers Prefetch, liste des clichés. Documentez chaque trou brutal.
7. Récupérez ce qui a été supprimé : anciens journaux et ruches depuis les VSS, données SIEM, données undo du $LogFile, slack $I30 et enregistrements carvés.
8. Construisez une super timeline unique et rapportez à la fois les actions de nettoyage et ce qu'elles cherchaient à cacher, avec les identifiants ATT&CK.