yamato-security/enablewindowslogsettingsDocumentation et scripts pour activer correctement les journaux d'événements Windows.
Ceci est un autre guide sur la configuration et la surveillance appropriées des journaux d'événements Windows, avec un accent sur la journalisation pour les règles sigma.
Ceci est un travail en cours, veuillez donc revenir périodiquement pour les mises à jour.
Zach Mathis (@yamatosecurity). À mesure que je poursuis mes recherches et mes tests, je prévois de mettre à jour ce document périodiquement, car il y a beaucoup de place pour l'amélioration (tant dans la documentation que dans la création de nouvelles règles de détection). Les PR sont les bienvenues et je vous ajouterai avec plaisir en tant que contributeur. Si vous trouvez des erreurs dans cette documentation, veuillez me le faire savoir et je les corrigerai dès que possible.
Si vous trouvez cela utile, merci de mettre une étoile sur GitHub, cela m'aidera probablement à rester motivé pour continuer à mettre à jour ce document.
La plupart des informations proviennent de la FAQ sur l'audit de sécurité avancé de Microsoft, des règles sigma, du Guide de journalisation des événements de l'ACSC et de mes propres recherches/tests. Je tiens à remercier tout particulièrement la communauté sigma d'avoir rendu la détection des menaces open source et gratuite au profit de tous les défenseurs.
Par défaut, Windows ne journalise pas de nombreux événements nécessaires à la détection d'activités malveillantes et aux investigations forensiques.
De plus, la taille maximale par défaut des fichiers d'événements n'est que de 20 Mo pour les journaux d'événements classiques (Security, System, Application), 15 Mo pour PowerShell et à peine 1 Mo pour presque tous les autres journaux, il y a donc de fortes chances que les preuves soient écrasées avec le temps.
Un simple script batch a été fourni dans ce dépôt pour permettre aux administrateurs système de configurer facilement leurs machines Windows afin de disposer des journaux nécessaires en cas d'incident. Pour les grands réseaux, vous voudrez probablement utiliser ce document comme référence et configurer vos points de terminaison avec la stratégie de groupe et/ou InTune.
Je recommande vivement d'améliorer les paramètres de journalisation des événements Windows par défaut et je fais de mon mieux pour fournir les informations les plus précises. Cependant, je n'assume aucune responsabilité en cas d'effets indésirables liés à une journalisation trop excessive ni quant à l'exactitude de tout ce qui se trouve dans ce dépôt. Il vous incombe de comprendre et de tester toutes les modifications que vous apportez à vos systèmes sur des machines de test avant de les déployer en production. Je recommande d'activer autant de journalisation que possible sur des machines de test qui reproduisent votre environnement pendant au moins une semaine, puis de vérifier s'il y a des événements qui génèrent trop de bruit ou s'il y a des événements que vous souhaitez mais qui ne sont pas générés.
Vous pouvez consulter le nombre total et le pourcentage d'ID d'événements dans un fichier evtx à l'aide de la commande de métriques d'ID d'événements de Hayabusa.
Exemple : hayabusa.exe eid-metrics -f path/to/Security.evtx
Process Creation (création de processus), qui suit les processus exécutés sur un système.
Actuellement, environ la moitié des règles de détection de Sigma reposent sur cet événement.
Cela peut être accompli en installant Sysmon (Event ID 1) ou en activant l'Event ID 4688 du journal de sécurité intégré.
Sysmon 1 fournira des informations détaillées telles que les empreintes (hashes) et les métadonnées de l'exécutable, c'est donc idéal, mais dans le cas où Sysmon ne peut pas être installé, il est possible d'utiliser les journaux intégrés Security 4688. Cependant, il est important que la journalisation de la ligne de commande soit également activée, car de nombreuses règles de détection en dépendent. Malheureusement, Security 4688 ne fournit pas d'informations aussi détaillées que les journaux de création de processus de Sysmon, donc toutes les règles Process Creation ne fonctionnent pas avec Security 4688.
Environ seulement 10~20 % des règles sigma peuvent être utilisées avec les paramètres d'audit Windows par défaut !
Ce n'est pas pratique à grande échelle, mais le moyen le plus simple d'activer/désactiver les journaux et de vérifier et/ou configurer leur taille maximale consiste à cliquer avec le bouton droit sur le journal dans l'Observateur d'événements et à ouvrir Propriétés.
Vous pouvez utiliser la commande intégrée wevtutil.
Exemple : wevtutil sl Security /ms:1073741824 pour augmenter la taille maximale du fichier du journal de sécurité à 1 Go.
Exemple :```powershell $sysmon = Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational $sysmon.MaximumSizeInBytes = 2048000000 #2GB $sysmon.SaveChanges()
## Option 4 : stratégie de groupe
Il est simple d'augmenter la taille maximale des journaux d'événements classiques tels que `Security`, `System` et `Application`, mais il faut malheureusement installer les modèles d'administration et/ou modifier directement le registre pour changer la taille maximale des autres journaux. Il peut être plus simple d'augmenter la taille maximale des fichiers avec un script batch ou PowerShell au démarrage.
# Script de configuration
Un script pour augmenter la taille maximale des fichiers et activer les journaux appropriés est fourni ici : [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/YamatoSecurityConfigureWinEventLogs.bat)
# Configuration des paramètres des journaux
## Journal Sysmon (1382 règles Sigma)
Fichier : `Microsoft-Windows-Sysmon%4Operational.evtx`
Paramètres par défaut : `Not installed`
Installer et configurer Sysmon est la meilleure chose à faire pour augmenter la visibilité sur les points de terminaison Windows, mais cela nécessite de la planification, des tests et de la maintenance.
C'est un vaste sujet en soi, donc il sort du cadre de ce document pour le moment.
Veuillez consulter les ressources suivantes :
* [TrustedSec Sysmon Community Guide](https://github.com/trustedsec/SysmonCommunityGuide)
* [Sysmon Modular](https://github.com/olafhartong/sysmon-modular)
* [Fork mis à jour par Florian Roth du fichier de configuration Sysmon de Swift On Security](https://github.com/Neo23x0/sysmon-config)
* [Fork mis à jour par Ion-storm du fichier de configuration Sysmon de Swift On Security](https://github.com/ion-storm/sysmon-config)
* [Fichier de configuration Sysmon de Cyb3rWard0g](https://github.com/OTRF/Blacksmith/blob/master/resources/configs/sysmon/sysmon.xml)
## Journal de sécurité (1045 règles Sigma (903 règles de création de processus + 142 autres règles))
Fichier : `Security.evtx`
Paramètres par défaut : `Partially enabled`
Le journal de sécurité est le plus complexe à configurer, c'est pourquoi j'ai créé un document séparé pour cela : [ConfiguringSecurityLogAuditPolicies.md](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/ConfiguringSecurityLogAuditPolicies.md)
## Journaux Powershell (175 règles Sigma)
Fichier : `Microsoft-Windows-PowerShell%4Operational.evtx`
### Journalisation des modules (30 règles Sigma)
L'activation de la journalisation des modules activera l'ID d'événement `4103`.
La journalisation des modules a l'avantage de pouvoir fonctionner sur des systèmes d'exploitation et versions de PowerShell plus anciens : PowerShell 3.0 (Win 7+).
Un autre avantage est qu'elle journalise à la fois la commande PowerShell exécutée et les résultats.
L'inconvénient est qu'elle générera un nombre extrêmement élevé d'événements.
Par exemple, si un attaquant exécute Mimikatz, cela créera 7 Mo de journaux avec plus de 2000 événements !
#### Activation de la journalisation des modules
Paramètres par défaut : `No Auditing`
##### Option 1 : activation via la stratégie de groupe
Dans l'éditeur de stratégie de groupe (`gpedit.msc`), ouvrez `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell` et activez `Turn on Module Logging`.
Dans le volet `Options`, cliquez sur le bouton `Show...` pour configurer les modules à journaliser.
Saisissez `*` dans la zone de texte `Value` pour enregistrer tous les modules.
##### Option 2 : activation via le registre```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames → * = *
Paramètres par défaut : On Win 10/2016+, if a PowerShell script is flagged as suspicious by AMSI, it will be logged with a level of Warning.
L'activation de la journalisation des blocs de script activera l'ID d'événement 4104. Si vous activez Log script block invocation start / stop events, les ID d'événement 4105 et 4106 seront également activés, mais cela n'est pas recommandé car cela ne fera que créer du bruit.
La journalisation des blocs de script est prise en charge par défaut dans PowerShell 5.0+ (Win 10+), mais vous pouvez l'activer sur des systèmes d'exploitation plus anciens (Win 7+) si vous installez .NET 4.5 et WMF 4.0+.
Malheureusement, la taille maximale d'un journal d'événements Windows unique est de 32 Ko, donc tout script PowerShell plus grand sera fragmenté en blocs de 32 Ko.
Si vous disposez du fichier PowerShell Operational.evtx d'origine, vous pouvez utiliser l'outil block-parser pour défragmenter ces journaux en un seul fichier texte facilement lisible.
Un bon point de la journalisation des blocs de script est que même si un script malveillant est obscurci avec XOR, Base 64, ROT13, etc..., le script décodé sera journalisé, ce qui rend l'analyse beaucoup plus facile.
Les journaux sont plus faciles à exploiter que la journalisation des modules, car si un attaquant exécute Mimikatz, seuls 5 Mo et 100 événements seront générés, contre 7 Mo et plus de 2000 événements.
Cependant, la sortie des commandes n'est pas enregistrée avec la journalisation des blocs de script.
Dans l'éditeur de stratégie de groupe, ouvrez Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell et activez Turn on PowerShell Script Block Logging.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1
Paramètres par défaut : No Auditing
Il est également possible d'enregistrer les journaux PowerShell dans des fichiers texte sur l'ordinateur local grâce aux journaux de transcription. Bien qu'un attaquant puisse généralement supprimer facilement les journaux de transcription pour des raisons d'anti-forensique, il peut y avoir des scénarios où l'attaquant efface tous les journaux d'événements mais ne cherche pas les journaux de transcription à supprimer. Par conséquent, il est recommandé d'activer également les journaux de transcription si possible. Par défaut, ils sont enregistrés dans le dossier Documents de l'utilisateur. Idéalement, les journaux de transcription devraient être enregistrés sur un partage réseau en écriture seule, mais cela peut être difficile à mettre en œuvre en pratique. Un avantage des journaux de transcription est qu'ils incluent l'horodatage et les métadonnées pour chaque commande et sont très efficaces en termes de stockage, avec moins de 6 Ko pour une exécution de Mimikatz. L'inconvénient est que les journaux de transcription n'enregistrent que ce qui apparaît dans le terminal PowerShell.
Dans l'éditeur de stratégie de groupe, ouvrez Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell et activez Turn on PowerShell Transcription.
Ensuite, spécifiez le répertoire de sortie.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)
### Références
* [Mandiant Blog: Greater Visibility Through PowerShell Logging](https://www.mandiant.com/resources/blog/greater-visibilityt)
## Journal Système (55 règles Sigma)
Fichier : `System.evtx`
Paramètres par défaut : `Enabled. 20 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Les logiciels malveillants installent souvent des services pour la persistance, l'élévation de privilèges locaux, etc... qui peuvent être retrouvés dans ce journal.
Il est également possible d'y détecter l'exploitation de diverses vulnérabilités.
> **Remarque : Un point particulier à surveiller dans le journal Système est que les paramètres des champs sont parfois traduits dans la langue locale, de sorte que les signatures qui n'utilisent que l'anglais peuvent ne pas détecter sur les systèmes non anglophones. Par exemple, sur un système anglais, dans les paramètres de l'EID 7045, il enregistrera `Enabled` tandis qu'en japonais, il pourrait enregistrer `有効`.**
> **Remarque : Tout comme le journal `Application`, plusieurs fournisseurs journalisent avec le même ID d'événement, vous devrez donc peut-être filtrer également sur le nom du fournisseur en plus du canal. Un exemple est l'ID d'événement `1` qui est utilisé par divers fournisseurs pour différents événements.**
ID d'événements importants :
| ID d'événement | Description | Règles Sigma | Règles Hayabusa | Niveau | Notes |
| :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | Veille/Hibernation du système | 0 | Pas encore. | Info | Fournisseur : `Power-Troubleshooter` |
| 1 | Heure système modifiée | 0 | Pas encore. | Info | Fournisseur : `Kernel-General` |
| 12 | Démarrage de l'OS | 0 | Pas encore. | Info | |
| 13 | Arrêt de l'OS | 0 | Pas encore. | Info | |
| 16 | Historique d'accès aux ruches de registre effacé | 2 | Pas encore. | High~Crit | Les dumpers de mots de passe peuvent effacer l'historique d'accès après avoir extrait les hashs de mots de passe de la clé de registre SAM. Cela se produit aussi normalement, il faut donc filtrer les faux positifs. |
| 55 | Système de fichiers NTFS corrompu | 1 | Non | High | Peut détecter des attaques contre les vulnérabilités NTFS. |
| 104 | Journal des événements système effacé | 1 | Oui | Med | |
| 6005 | Service de journal des événements démarré | 0 | Oui | Info | |
| 6006 | Service de journal des événements arrêté | 0 | Oui | Info | |
| 6008 | Arrêt inattendu | 0 | Oui | Info | |
| 6038 | NTLMv1 a été utilisé | 1 | Non | Low | |
| 7031 | Service en crash | 0 | Oui | Low | |
| 7034 | Service en crash | 0 | Oui | Low | |
| 7036 | Service démarré/arrêté | 2 | Oui | Info~High | Peut être utilisé pour détecter si quelqu'un arrête Defender, etc... |
| 7040 | Type de démarrage du service modifié | 0 | Oui | Info | Peut indiquer qu'un attaquant a désactivé un service. |
| 7045 | Installation d'un service | 37 | Oui | Info~Crit | C'est l'ID d'événement le plus important du journal Système, car les logiciels malveillants s'installent souvent en tant que service ou abusent des services. |
| 20001 | Nouveau périphérique PNP | 0 | Oui | Info~? | Le niveau dépendra de l'autorisation ou non des périphériques USB. Journalise uniquement la première fois qu'un périphérique est branché. Les événements de périphériques PNP non USB sont très bruyants et devraient probablement être filtrés. |
## Journal Application (16 règles Sigma)
Ce journal est surtout du bruit, mais vous pourrez peut-être y trouver des preuves importantes.
Certains logiciels antivirus tiers y journalisent.
Un point de vigilance concernant le journal Application est que différents éditeurs utilisent les mêmes ID d'événements pour des événements différents, vous devez donc filtrer non seulement sur les ID d'événements, mais aussi sur les noms de fournisseurs.
Fichier : `Application.evtx`
Paramètres par défaut : `Enabled. 20 MB`
Paramètres recommandés : `Enabled. 128 MB+`
ID d'événements importants :
| ID d'événement | Fournisseur | Description | Règles Sigma | Règles Hayabusa | Niveau | Notes |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | `Audit-CVE`, `Microsoft-Windows-Audit-CVE` | Tentative d'exploitation d'une vulnérabilité connue (CVE) | 1 | Non | Critical | Détecte les événements générés par les applications en mode utilisateur lorsqu'elles appellent l'API CveEventWrite lors d'une tentative d'exploitation d'une vulnérabilité connue. MS a commencé à utiliser ce journal en 2020/01 avec CVE-2020-0601 (une vulnérabilité de Windows CryptoAPI). Malheureusement, c'est à peu près le seul cas de CVE écrites dans ce journal. |
| 325 | `ESENT` | Base de données ESE créée | 2 | Non | Info~Crit | Détecte quand un processus crée une base de données ESE. Celle-ci est utilisée par diverses choses telles qu'Exchange, l'AD, les services de certificats, SRUM, etc... La base ESE la plus importante pour la sécurité est NTDS.dit, le fichier contenant les hashs de mots de passe de tous les utilisateurs du domaine, situé sur les contrôleurs de domaine. Il existe deux règles Sigma pour détecter le dump de NTDS.dit ; cela peut toutefois être un faux positif si un administrateur utilise ntdsutil pour les sauvegardes ou lorsque des clichés de volumes sont créés. |
| 326 | `ESENT` | Base de données ESE attachée | 1 | Non | Info~Crit | Peut permettre de détecter un accès à NTDS.dit. |
| 1000, 1001 | `Application Error`, `Windows Error Reporting` | Erreur d'application | 1 | Non | Info~High | |
| 1034, 11724 | `MsiInstaller` | Application désinstallée | 1 | Non | Info~Low | |
| 1040 | `MsiInstaller` | Installation d'une application | 1 | Non | Info~Med | |
| 33205 | `MSSQLSERVER` | Événement d'audit SQL | 6 | Non | Info~High | Peut détecter des backdoors MSSQL, des injections SQL/de commandes, etc... |
## Journal opérationnel Windows Defender (10 règles Sigma)
Fichier : `Microsoft-Windows-Windows Defender%4Operational.evtx`
Paramètres par défaut : `Enabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Vous pouvez y détecter non seulement les alertes Windows Defender (qui sont importantes à surveiller), mais aussi l'ajout d'exclusions, la désactivation de la protection contre les falsifications, la suppression de l'historique, etc...
## Journal opérationnel Bits-Client (6 règles Sigma)
Fichier : `Microsoft-Windows-Bits-Client%4Operational.evtx`
Paramètres par défaut : `Enabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Bitsadmin.exe est un [lolbin](https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/) populaire que les attaquants abusent pour télécharger et exécuter des logiciels malveillants.
Vous pourrez peut-être en trouver des preuves dans ce journal, même s'il y aura beaucoup de faux positifs à surveiller.
## Journal du pare-feu (6 règles Sigma)
Fichier : `Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx`
Paramètres par défaut : `Enabled? 1 MB`
Paramètres recommandés : `Enabled. 256 MB+`
Vous pouvez y trouver des preuves de règles de pare-feu ajoutées/modifiées/supprimées.
Les logiciels malveillants ajoutent souvent des règles de pare-feu pour s'assurer qu'ils peuvent communiquer avec leur serveur C2, ajoutent des règles proxy pour le déplacement latéral, etc...
## Journal opérationnel NTLM (3 règles Sigma)
Fichier : `Microsoft-Windows-NTLM%4Operational.evtx`
Paramètres par défaut : `Enabled but Auditing is disabled. 1 MB`
Il est recommandé d'activer ce journal si vous souhaitez désactiver l'authentification NTLM.
La désactivation de NTLM cassera très probablement certaines communications. Vous pouvez donc surveiller ce journal sur les contrôleurs de domaine (DC) et autres serveurs pour voir qui utilise encore NTLM et désactiver NTLM progressivement, en commençant par ces utilisateurs, avant de le désactiver globalement.
Il est possible de détecter l'utilisation de NTLM pour les connexions entrantes dans les événements d'ouverture de session tels que 4624, mais vous devez activer ce journal si vous souhaitez surveiller qui effectue des connexions NTLM sortantes.
Pour activer l'audit, dans la stratégie de groupe, ouvrez `Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options` et configurez les différents paramètres `Network security: Restrict NTLM:` appropriés.
Référence : [Farewell NTLM](https://www.scip.ch/en/?labs.20210909)
## Journaux Security-Mitigations KernelMode et UserMode (2 règles Sigma)
Fichiers : `Microsoft-Windows-Security-Mitigations%4KernelMode.evtx`, `Microsoft-Windows-Security-Mitigations%4UserMode.evtx`
Paramètres par défaut : `Enabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
À l'heure actuelle, il n'existe que 2 règles Sigma pour ces journaux, mais vous devriez probablement collecter et surveiller tous les journaux Exploit Protection, Network Protection, Controlled Folder Access et Attack Surface Reduction (environ 40+ ID d'événements).
Malheureusement, les journaux Attack Surface Reduction (anciennement WDEG(Windows Defender Exploit Guard) et EMET) sont répartis sur plusieurs journaux et nécessitent des requêtes XML complexes pour les rechercher.
Détails : [Understand and use attack surface reduction capabilities](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction?view=o365-worldwide)
## Journaux PrintService (2 règles Sigma)
Il est recommandé d'activer également le journal opérationnel pour détecter les attaquants du Print Spooler. (Ex : PrintNightmare, etc...)
### Admin (1 règle Sigma)
Fichier : `Microsoft-Windows-PrintService%4Admin.evtx`
Paramètres par défaut : `Enabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
### Opérationnel (1 règle Sigma)
Fichier : `Microsoft-Windows-PrintService%4Operational.evtx`
Paramètres par défaut : `Disabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
## Journal de sécurité SMBClient (2 règles Sigma)
Fichier : `Microsoft-Windows-SmbClient%4Security.evtx`
Paramètres par défaut : `Enabled. 8 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Utilisé pour tenter de détecter PrintNightmare (Suspicious Rejected SMB Guest Logon From IP) et des utilisateurs montant des partages cachés.
## Journaux AppLocker (1 règle Sigma)
Fichiers : `Microsoft-Windows-AppLocker%4MSI and Script.evtx`, `Microsoft-Windows-AppLocker%4EXE and DLL.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx`
Paramètres par défaut : `Enabled if AppLocker is enabled? 1 MB`
Paramètres recommandés : `Enabled. 256 MB+`
Il est important de s'assurer qu'il est activé et surveillé si vous utilisez AppLocker.
## Journal opérationnel CodeIntegrity (1 règle Sigma)
Fichier : `Microsoft-Windows-CodeIntegrity%4Operational.evtx`
Paramètres par défaut : `Enabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Consultez ce journal pour détecter les événements de chargement de pilotes bloqués par les contrôles d'intégrité du code de Windows, ce qui peut indiquer un pilote malveillant qui n'a pas réussi à se charger.
## Journal opérationnel Diagnosis-Scripted (1 règle Sigma)
Fichier : `Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx`
Paramètres par défaut : `Enabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Des preuves d'utilisation de packages diagcab à des fins d'exploitation peuvent être trouvées ici.
## Journal opérationnel DriverFrameworks-UserMode (1 règle Sigma)
Fichiers : `Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx`
Paramètres par défaut : `No Auditing. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Détecte les périphériques USB branchés.
## Journal opérationnel WMI-Activity (1 règle Sigma)
Fichier : `Microsoft-Windows-WMI-Activity%4Operational.evtx`
Paramètres par défaut : `Enabled on Win10/2016+. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Il est important de le surveiller, car les attaquants exploitent souvent WMI pour la persistance et le déplacement latéral.
## Journal opérationnel TerminalServices-LocalSessionManager (1 règle Sigma)
Fichier : `Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`
Paramètres par défaut : `Enabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Détecte quand ngrok, un outil de proxy inverse, transfère du trafic vers le port RDP local pour contourner les pare-feu.
Lien : [Bypassing Network Restrictions Through RDP Tunneling](https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling)
## Journal opérationnel TaskScheduler (1 règle Sigma)
Fichier : `Microsoft-Windows-TaskScheduler%4Operational.evtx`
Paramètres par défaut : `Disabled. 1 MB`
Paramètres recommandés : `Enabled. 128 MB+`
Les attaquants abusent souvent des tâches pour la persistance et le déplacement latéral, ce journal devrait donc être activé.