Une alerte qui ne sonne pas, c’est souvent rassurant. Une machine qui n’envoie plus rien du tout, ça devrait l’être beaucoup moins.

Désactiver ou détourner le journal d’événements Windows est une technique classique pour travailler sans témoin. Dans ATT&CK v20, elle porte l’identifiant T1685.001, « Disable or Modify Windows Event Log », sous la nouvelle tactique Defense Impairment. (Si vous cherchez encore T1562.002 ou T1070.001, ces identifiants n’existent plus dans les données ATT&CK v20 embarquées par pySigma.)

La difficulté est évidente : une fois le journal coupé, il n’y a plus rien à lire. Tout se joue donc dans les quelques secondes qui précèdent le silence. J’ai voulu savoir ce qu’on voit réellement pendant ces secondes, et surtout quelle source le voit.

Huit simulations, huit façons de faire taire Windows

Le dossier defense_evasion/host d’OTRF Security-Datasets, sous licence MIT, contient huit simulations enregistrées sur ce thème. J’ai identifié l’action réelle de chacune en lisant les journaux, pas seulement le nom du jeu :

• trois désactivations du service EventLog (valeur de registre Start passée à 4), par reg.exe, par la cmdlet PowerShell Set-Service, et par un exécutable qui écrit directement dans le registre ;
• un wevtutil set-log qui déplace le fichier du journal Security vers un autre chemin ;
• deux Stop-Service EventLog -Force ;
• deux désactivations du service Network List (netprofm), avant redémarrage.

Pour chacune, j’ai cherché la trace de l’action dans six sources : les créations de processus (Sysmon 1), les blocs de script PowerShell (4104), les écritures de registre (Sysmon 13), l’audit de registre Windows (Security 4657), les changements de type de démarrage d’un service (System 7040), et les événements de journal effacé ou arrêté (System 104, Security 1100).

La meilleure source, le 4104, voit cinq actions sur huit. Aucune n’en voit plus. Et la plus attendue, Sysmon 1, n’en voit que deux.

Trois méthodes, trois traces différentes

Les trois premières lignes de la matrice font la même chose : passer le service EventLog en « désactivé ». Elles ne laissent pas du tout les mêmes traces.

Avec reg.exe, on voit la commande (Sysmon 1), l’écriture de registre (Sysmon 13) et l’événement d’audit 4657, qui donne même l’ancienne et la nouvelle valeur : Start 2->4, modifié par reg.exe. Mais aucun événement 7040. Le gestionnaire de services n’a pas été sollicité, il n’a donc rien à signaler.

Avec Set-Service, c’est l’inverse sur deux points. Pas de Sysmon 1 : la cmdlet s’exécute dans une session PowerShell déjà ouverte, sans créer de nouveau processus. Et le 4657 attribue la modification à services.exe, sous le compte SYSTEM, parce que c’est le gestionnaire de services qui écrit dans le registre. Le vrai responsable n’apparaît que dans le 4104 : Set-Service -Name EventLog -StartUpType Disabled. En contrepartie, cette méthode est la seule des trois à produire un 7040, avec un message on ne peut plus clair : « The start type of the Windows Event Log service was changed from auto start to disabled. »

Avec l’exécutable qui écrit directement dans le registre, il ne reste que le registre : Sysmon 13 et le 4657, qui nomme payload.exe comme auteur. Pas de commande lisible, pas de 7040.

La leçon : une règle sur le 7040 seul aurait vu une désactivation sur trois. Une règle sur la valeur de registre les voit toutes, quelle que soit la méthode. C’est un bon exemple de pourquoi on détecte un effet (la valeur écrite) plutôt qu’un moyen (une commande particulière).

Les règles, testées

Dans le dossier rules/ de SigmaHQ, je n’ai pas trouvé de règle qui cible précisément cette valeur Start. J’en ai donc écrit une :

title: Service Journal d'événements Windows désactivé via le registre
id: a8a67ff1-bf5a-4153-9b3d-9319886db7dd
status: experimental
description: |
  Détecte l'écriture de la valeur Start à 4 (désactivé) pour le service EventLog. Au prochain
  démarrage, plus aucun journal Windows n'est écrit. Couvre aussi les modifications directes du
  registre, qui ne produisent pas d'événement System 7040.
references:
  - https://attack.mitre.org/techniques/T1685/001/
author: PurpleLog
date: 2026-10-17
tags:
  - attack.defense-impairment
  - attack.t1685.001
logsource:
  category: registry_set
  product: windows
detection:
  selection:
    TargetObject|endswith: '\Services\EventLog\Start'
    Details: 'DWORD (0x00000004)'
  condition: selection
falsepositives:
  - Aucun cas légitime courant identifié ; une image disque ou un script de durcissement très particulier pourrait le faire
level: high

Et puisque le 4104 est la source qui voit le plus, une seconde règle sur les blocs de script qui arrêtent ou reconfigurent le service :

title: Arrêt ou désactivation du service EventLog dans un script PowerShell
id: f442b228-fa54-4e8d-b410-a8b81535915d
status: experimental
description: Détecte un bloc de script PowerShell (4104) qui arrête ou reconfigure le service EventLog avec Stop-Service ou Set-Service.
references:
  - https://attack.mitre.org/techniques/T1685/001/
author: PurpleLog
date: 2026-10-17
tags:
  - attack.defense-impairment
  - attack.t1685.001
logsource:
  product: windows
  category: ps_script
  definition: 'Nécessite le Script Block Logging'
detection:
  selection_cmdlet:
    ScriptBlockText|contains:
      - 'Stop-Service'
      - 'Set-Service'
  selection_target:
    ScriptBlockText|contains: 'EventLog'
  condition: all of selection_*
falsepositives:
  - Scripts d'administration qui redémarrent le service EventLog
level: high

Les deux passent sigma check sans avertissement. Je les ai exécutées, avec quatre règles SigmaHQ existantes sur le même thème, par la méthode de l’article sur les tests de règles : conversion en SQL et exécution sur 61 jeux OTRF, soit les huit simulations plus 53 autres jeux déjà utilisés sur ce blog, qui servent de terrain pour les faux positifs.

Mes deux règles se déclenchent chacune sur trois simulations, et sur aucun des 53 autres jeux. Les deux règles SigmaHQ sur wevtutil et sur le chemin du fichier .evtx attrapent le déplacement du journal Security. Ensemble, ces règles couvrent six simulations sur huit.

Trois limites à garder en tête. Le banc de test ne fait aucune correspondance de champs : une règle qui attend un nom de champ différent de celui du collecteur ne trouve rien, ce qui compte pour la suite. Le 4657 n’existe que si une liste de contrôle d’audit (SACL) est posée sur la clé de registre, ce qui n’est pas le cas par défaut. Et le 4104 suppose que le Script Block Logging est activé. Sur un parc où ni l’un ni l’autre ne l’est, il ne reste que Sysmon, s’il est déployé.

Les deux zéros, et ce qu’ils disent

Deux règles SigmaHQ ne se déclenchent nulle part, pour deux raisons différentes.

Celle sur l’effacement du journal Security (événements 517 et 1102) ne trouve rien parce qu’aucune des simulations n’efface ce journal. C’est un zéro attendu.

Celle sur l’événement 104 (un journal effacé) est plus intéressante, parce que des événements 104 existent bel et bien dans les données. La règle cherche un champ Provider_Name et utilise le champ Channel pour désigner le journal effacé. Or le collecteur utilisé par OTRF nomme la source SourceName, et son Channel désigne le journal où l’événement est écrit, ici System. Le nom du journal effacé n’existe que dans le texte du message. La règle est sans doute correcte dans un SIEM qui reçoit les journaux Windows bruts ; elle est aveugle sur ces données-là. C’est exactement la marche « alimentée » de l’article sur la matrice ATT&CK : une règle juste qui n’a pas les champs qu’elle attend.

Restent les deux simulations sur le service Network List. Aucune règle de ce test ne les attrape, et je ne détaillerai pas le mécanisme par lequel ce service affecte la journalisation : je ne l’ai pas vérifié. Leur seule trace visible est un 7040 sur ce service et le 4104 de la commande.

Détecter le silence lui-même

Toutes ces règles regardent les secondes qui précèdent. Il faut aussi regarder après : une machine qui envoyait des milliers d’événements par jour et qui n’envoie plus rien. Ça ne prouve rien à soi seul (machine éteinte, agent en panne, réseau coupé), mais c’est exactement le genre de silence qu’on ne remarque pas si personne ne le cherche.

// Machines qui envoyaient des événements Security et qui se sont tues
SecurityEvent
| where TimeGenerated > ago(7d)
| summarize Dernier = max(TimeGenerated), Volume = count() by Computer
| where Dernier < ago(2h) and Volume > 1000
| sort by Dernier asc

La requête passe le parseur KQL officiel de Microsoft avec le schéma documenté de SecurityEvent ; je ne l’ai pas exécutée sur un vrai workspace. Les seuils sont à adapter : deux heures et mille événements conviennent à un serveur bavard, pas à un poste nomade.

Ce que je retiens

Couper les journaux n’est pas une action unique, et aucune source ne voit toutes les variantes. Les deux sources qui portent le plus ici sont le Script Block Logging et la surveillance du registre, à condition que l’une et l’autre soient activées, ce qui ramène encore au même point que l’article sur les configurations Sysmon : la détection commence par ce qu’on a choisi de collecter.

Et le silence est un signal. Le chercher activement ne coûte qu’une requête.

Références

• OTRF, Security-Datasets, dossier datasets/atomic/windows/defense_evasion/host et dossiers déjà utilisés lateral_movement/host et credential_access/host (licence MIT)
• MITRE ATT&CK v20, T1685.001 Disable or Modify Windows Event Log
• SigmaHQ, dépôt sigma, commit c04ad420b46c, règles proc_creation_win_susp_eventlog_clear, registry_set_evtx_file_key_tamper, win_system_eventlog_cleared, win_security_audit_log_cleared (licence DRL 1.1)
• Microsoft, SecurityEvent