Rapports d'erreurs Windows (WER)

Présentation

Windows Error Reporting (WER) est le service qui prend en charge les plantages d'applications, les blocages et certains problèmes du noyau. Pour chaque événement, il crée un dossier de rapport contenant un fichier texte nommé Report.wer (et parfois des vidages mémoire et des métadonnées), puis écrit les entrées correspondantes dans le journal Application. Pour l'enquêteur, WER est une source discrète de preuves d'exécution : code d'exploitation, implants instables, outils de vol d'identifiants et outils offensifs plantent souvent, et le rapport survit à la suppression du binaire par l'attaquant.

Emplacement

Les dossiers de rapport portent le type d'événement et le nom de l'application, par exemple AppCrash_<nom de l'exe>_<hash>_<id>, AppHang_... ou Kernel_....

Ce que l'artefact prouve

• Exécution : l'application située à AppPath tournait au moment du plantage ou du blocage. Un rapport pour C:\Users\Public\x.exe prouve que ce fichier a existé et a été exécuté.
• Identité d'un binaire supprimé : sous Windows 10 et ultérieur, de nombreux rapports système contiennent le SHA-1 de l'exécutable dans TargetAppId, sous la même forme préfixée par 0000 que dans Amcache. Tous les rapports ne l'ont pas.
• Ce qui était chargé : LoadedModule[n] liste les DLL du processus, ce qui peut trahir un module injecté dans un hôte légitime.
• Heure de démarrage du processus : l'événement 1000 enregistre l'heure de démarrage et le PID de l'application fautive.
• L'artefact ne prouve pas que l'utilisateur a lancé le programme volontairement, et un programme qui n'a jamais planté ne laisse rien ici.

Champs clés

L'événement 1000 (Application Error) contient les noms et versions de l'application et du module fautifs, le code d'exception, le décalage de la faute, l'identifiant du processus, l'heure de démarrage de l'application, les chemins de l'application et du module, et un Report Id. L'événement 1001 (Windows Error Reporting) contient le compartiment d'erreur (fault bucket), le nom de l'événement, la signature du problème, les fichiers joints et le dossier où le rapport est stocké.

Horodatages

Rétention et effacement

• Valeurs par défaut documentées : MaxArchiveCount 1 000 rapports et MaxQueueCount 50 rapports ; les plus anciens sont supprimés au-delà.
• WER peut être désactivé avec Disabled = 1, l'archivage avec DisableArchive = 1 et la file d'attente avec DisableQueue = 1, sous la clé WER ou son équivalent de stratégie. Sur un poste de travail, chacun de ces réglages mérite une question.
• Le Nettoyage de disque propose de supprimer les fichiers de rapports d'erreurs, et un attaquant peut simplement vider les dossiers WER. Les suppressions restent parfois visibles dans le journal USN et la $MFT, et les événements Application 1000/1001 survivent aux fichiers jusqu'à la rotation du journal.
• LocalDumps (Windows Vista SP1 et suivants) est désactivé par défaut. Sous HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps (global ou par sous-clé <exe>), DumpFolder (par défaut %LOCALAPPDATA%\CrashDumps), DumpCount (10 par défaut) et DumpType (0 personnalisé, 1 mini, 2 complet) règlent les vidages conservés localement. Une sous-clé LocalDumps\lsass.exe avec DumpType 2 doit faire penser à un vol d'identifiants.

Collecte

• Cible KAPE : WER (les deux arborescences WER, CrashDumps et les *.dmp de C:\Windows).
• Velociraptor (Windows.Triage.Targets) : WER.
• Commandes natives : les dossiers sont lisibles par un administrateur ; robocopy conserve les horodatages. Exportez le journal Application pour les événements 1000/1001/1002 et la clé WER de la ruche SOFTWARE.

robocopy C:\ProgramData\Microsoft\Windows\WER E:\case\WER\System /E /COPY:DAT /DCOPY:T /B
wevtutil epl Application E:\case\Application.evtx
reg export "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting" E:\case\wer-config.reg
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000,1001,1002} | Format-List TimeCreated, Id, Message

Outils d'analyse

• Un éditeur de texte ou Get-Content : Report.wer est un simple texte Nom=Valeur en UTF-16.
• AppCrashView (NirSoft, gratuit) : liste les plantages à partir des fichiers de rapport WER d'un système en direct ou monté.
• EvtxECmd (Eric Zimmerman) : inclut une map pour l'événement Application 1001 (Windows Error Reporting).
• Velociraptor : l'artefact communautaire Windows.System.WindowsErrorReporting (artifact exchange) extrait EventTime, AppPath, OriginalFilename et le SHA-1 de TargetAppId.
• WinDbg : analyse les vidages joints à un rapport ou conservés par LocalDumps (voir vidages sur incident).

Conseils d'investigation

• Recherchez dans tous les Report.wer les valeurs AppPath situées dans des dossiers accessibles en écriture aux utilisateurs (\Temp\, \Downloads\, \Users\Public\, \ProgramData\) et les noms d'outils comme mimikatz, procdump, rclone ou psexec.
• Extrayez le SHA-1 de TargetAppId et cherchez-le dans Amcache et dans le renseignement sur la menace, même si le binaire a disparu.
• Comparez OriginalFilename au nom de fichier de AppPath : un svchost.exe dont le nom d'origine est mimikatz.exe est un outil renommé.
• Le plantage de lsass.exe, explorer.exe ou d'un navigateur avec un module inattendu dans LoadedModule peut révéler une injection ; vérifiez le chemin du module dans le Prefetch.
• Une rafale de plantages du même binaire au moment de l'intrusion correspond souvent à un exploit relancé plusieurs fois ; alignez EventTime sur les ouvertures de session des journaux d'événements.
• Un blocage ou une mise en quarantaine par Defender peut aussi tuer un processus : recoupez avec les journaux Microsoft Defender avant de conclure à un plantage.