Les règles Sigma pour détecter dans les logs

1 Introduction

2 Anatomie d'une règle

Cette règle détecte certutil.exe, un outil Windows légitime de gestion des certificats, détourné pour télécharger un fichier (MITRE ATT&CK T1105, Ingress Tool Transfer). Les commentaires expliquent chaque champ.

proc_creation_win_certutil_download.yml

title: File Download via Certutil                # nom court et lisible
id: 3f2a8c1e-5b7d-4e9a-9c61-2d8f0a7b4c13         # UUIDv4 aléatoire, jamais réutilisé
status: experimental                             # experimental -> test -> stable
description: Detects certutil.exe used with the urlcache option to fetch a remote file, a classic living-off-the-land download technique.
references:
    - https://attack.mitre.org/techniques/T1105/
author: mlab Academy
date: 2026-10-21                                 # AAAA-MM-JJ
tags:                                            # tactique + technique MITRE ATT&CK
    - attack.command-and-control
    - attack.t1105
logsource:                                       # SUR QUELS journaux la règle s'applique
    category: process_creation
    product: windows
detection:                                       # CE QUE l'on cherche
    selection_img:                               # une liste = OU entre ses éléments
        - Image|endswith: '\certutil.exe'
        - OriginalFileName: 'CertUtil.exe'
    selection_cli:                               # les clés d'une map = ET
        CommandLine|contains|all:                # |all = toutes les valeurs doivent être présentes
            - 'urlcache'
            - 'http'
    condition: all of selection_*                # comment combiner les blocs nommés
falsepositives:
    - Administrators manually retrieving certificates or CRLs over HTTP
level: high                                      # informational, low, medium, high, critical

Les champs de métadonnées

logsource : quels journaux ?

logsource combine jusqu'à trois clés : product (windows, linux, aws, azure…), service (security, sysmon, powershell, cloudtrail…) et category (un type générique comme process_creation, network_connection, dns_query, file_event). Les catégories sont très pratiques : sous Windows, process_creation peut être alimentée par l'événement Sysmon 1, l'événement de sécurité 4688 ou un EDR. C'est le pipeline qui choisit la source interrogée.

detection : sélections, modificateurs et condition

Le bloc detection contient des identifiants de recherche nommés librement (selection, filter_admin…) et une condition qui les combine. Deux règles suffisent pour les lire toutes :

Les valeurs sont insensibles à la casse par défaut, et * / ? servent de jokers. Les modificateurs de champ, chaînés avec |, changent la façon de comparer :

La ligne condition accepte :

3 Exemples guidés

Étape 1 : un événement, un champ

La règle la plus simple possible : tous les échecs de connexion Windows (événement de sécurité 4625). Bien trop bruyante pour déclencher une alerte à elle seule, d'où le level: low, mais c'est une brique parfaite pour l'étape 4.

win_security_failed_logon.yml

title: Windows Failed Logon
id: 0c7a1f2e-3b4d-4e5f-8a6b-7c8d9e0f1a2b
status: test
description: Demo rule - matches every failed logon on a Windows host.
author: mlab Academy
date: 2026-10-21
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
    condition: selection
level: low

Étape 2 : deux sélections combinées

C'est la règle certutil de la section 2. selection_img identifie le binaire de deux façons, par son chemin et par OriginalFileName (lu dans l'en-tête PE, donc toujours valable si l'attaquant renomme certutil.exe en notepad.exe). selection_cli exige les deux mots-clés.

Étape 3 : comportement parent/enfant avec filtre

Un grand classique des documents piégés par macro : une application Office lance PowerShell avec une commande encodée. On ajoute un filtre pour un complément (fictif) approuvé : les filtres permettent d'adapter une règle à votre environnement sans l'affaiblir partout ailleurs.

proc_creation_win_office_spawn_encoded_powershell.yml

title: Encoded PowerShell Spawned by an Office Application
id: 9b1e4d27-6c3a-4f8e-b2d5-1a7c0e9f3b64
status: experimental
description: Detects Word, Excel or PowerPoint launching PowerShell with an encoded command, typical of malicious macro documents.
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://attack.mitre.org/techniques/T1204/002/
author: mlab Academy
date: 2026-10-21
modified: 2026-10-21
tags:
    - attack.execution
    - attack.t1059.001
    - attack.t1204.002
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\winword.exe'
            - '\excel.exe'
            - '\powerpnt.exe'
    selection_child:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
    selection_cli:
        CommandLine|contains|windash:
            - ' -enc '
            - ' -encodedcommand '
    filter_main_approved_addin:
        CommandLine|contains: 'C:\Program Files\Contoso\ApprovedAddin\'
    condition: all of selection_* and not 1 of filter_main_*
falsepositives:
    - Rare internal add-ins that legitimately call encoded PowerShell (add them to a filter)
level: high

Exercice : PowerShell accepte n'importe quel préfixe non ambigu d'un paramètre, donc -e, -ec ou -enco fonctionnent aussi. Comment étendre selection_cli sans détecter toutes les lignes de commande contenant « -e » ? (Indice : regardez comment les règles SigmaHQ s'y prennent.)

Étape 4 : une règle de corrélation (force brute)

Depuis la version 2.0 de la spécification, Sigma prend en charge les règles de corrélation, qui comptent ou relient les événements d'autres règles. On réutilise ici la règle de l'étape 1 (référencée par son name) pour alerter sur dix échecs depuis la même IP en cinq minutes. Les deux documents cohabitent dans le même fichier, séparés par ---.

win_security_failed_logon_bruteforce.yml

title: Windows Failed Logon
id: 0c7a1f2e-3b4d-4e5f-8a6b-7c8d9e0f1a2b
name: windows_failed_logon
status: test
description: Demo rule - matches every failed logon on a Windows host.
author: mlab Academy
date: 2026-10-21
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
    condition: selection
level: low
---
title: Many Failed Logons From One Source
id: 5e2d8b1a-7f4c-4a3e-9d6b-0c1f2a3b4c5d
status: experimental
description: Ten or more failed logons from the same source IP within five minutes.
author: mlab Academy
date: 2026-10-21
correlation:
    type: event_count
    rules:
        - windows_failed_logon
    group-by:
        - IpAddress
    timespan: 5m
    condition:
        gte: 10
level: medium

$ sigma convert -t splunk -p splunk_windows win_security_failed_logon_bruteforce.yml
source="WinEventLog:Security" EventCode=4625

| bin _time span=5m
| stats count as event_count by _time IpAddress

| search event_count >= 10

Autres types de corrélation : value_count (une même source qui essaie beaucoup de noms d'utilisateur différents, par exemple), temporal et temporal_ordered (plusieurs règles qui se déclenchent ensemble, ou dans un ordre donné). Tous les backends ne les gèrent pas encore.

4 Convertir les règles

La chaîne d'outils de référence est pySigma (une bibliothèque Python) et son interface en ligne de commande sigma-cli. L'ancien convertisseur sigmac est obsolète : un tutoriel qui l'utilise n'est plus à jour.

# Installer la CLI et les backends dont vous avez besoin
$ pip install sigma-cli
$ sigma plugin install splunk
$ sigma plugin install elasticsearch
$ sigma plugin install kusto

# Contrôler vos règles (syntaxe + bonnes pratiques)
$ sigma check rules/

# Voir les cibles et pipelines disponibles
$ sigma list targets
$ sigma list pipelines splunk

Une conversion nécessite toujours une cible (-t, le langage de requête) et le plus souvent un pipeline (-p, la correspondance des champs avec vos données). Voici la règle certutil convertie pour trois SIEM, sortie réelle de sigma-cli :

$ sigma convert -t splunk -p splunk_windows proc_creation_win_certutil_download.yml
Image="*\\certutil.exe" OR OriginalFileName="CertUtil.exe" CommandLine="*urlcache*" CommandLine="*http*"

$ sigma convert -t lucene -p ecs_windows proc_creation_win_certutil_download.yml
(process.executable.caseless:*\\certutil.exe OR process.pe.original_file_name:CertUtil.exe) AND (process.command_line:*urlcache* AND process.command_line:*http*)

$ sigma convert -t kusto -p microsoft_xdr proc_creation_win_certutil_download.yml
DeviceProcessEvents
| where (FolderPath endswith "\\certutil.exe" or ProcessVersionInfoOriginalFileName =~ "CertUtil.exe") and (ProcessCommandLine contains "urlcache" and ProcessCommandLine contains "http")

Le pipeline microsoft_xdr vise les tables d'advanced hunting (DeviceProcessEvents…), également disponibles dans Sentinel quand le connecteur Defender XDR est activé ; sentinel_asim vise plutôt les tables normalisées ASIM de Sentinel. Pour la règle de l'étape 3, le KQL ressemble à ceci. Remarquez comment |windash a décliné chaque option en cinq variantes :

DeviceProcessEvents
| where ((InitiatingProcessFolderPath endswith "\\winword.exe" or InitiatingProcessFolderPath endswith "\\excel.exe" or InitiatingProcessFolderPath endswith "\\powerpnt.exe") and (FolderPath endswith "\\powershell.exe" or FolderPath endswith "\\pwsh.exe") and (ProcessCommandLine contains " -enc " or ProcessCommandLine contains " /enc " or ProcessCommandLine contains " –enc " or ProcessCommandLine contains " —enc " or ProcessCommandLine contains " ―enc " or ProcessCommandLine contains " -encodedcommand " or ProcessCommandLine contains " /encodedcommand " or ProcessCommandLine contains " –encodedcommand " or ProcessCommandLine contains " —encodedcommand " or ProcessCommandLine contains " ―encodedcommand ")) and (not(ProcessCommandLine contains "C:\\Program Files\\Contoso\\ApprovedAddin\\"))

Pas de SIEM ? Appliquez Sigma directement aux journaux

Plusieurs outils gratuits appliquent des règles Sigma directement aux journaux d'événements Windows (.evtx), parfaits pour s'entraîner ou pour une réponse à incident sur une seule machine : Hayabusa (Yamato Security), Chainsaw (WithSecure) et Zircolite. Le convertisseur web sigconverter.io, basé sur pySigma, permet d'essayer des conversions sans rien installer.

5 Pièges courants

Conseils de performance

6 Aller plus loin

Où trouver des règles

Relier les points

Les tags Sigma rattachent chaque règle à MITRE ATT&CK, ce qui permet de dessiner une carte de couverture et de repérer les techniques que vous ne voyez pas. Le comportement observé dans une sandbox (arbre de processus, lignes de commande) est la meilleure matière première pour de nouvelles règles. Pour les indicateurs qui changent tous les jours, continuez à vous appuyer sur les IOC et les flux STIX/TAXII ; pour les fichiers, sur YARA ; pour le trafic réseau, sur Suricata et Snort.