Sigma Rules : Guide Complet d'Écriture et Déploiement de Règles de Détection

1. Introduction : le besoin d'un langage universel de détection

Chaque SIEM parle son propre langage : SPL pour Splunk, KQL pour Microsoft Sentinel, ES|QL pour Elastic, AQL pour QRadar. Cette fragmentation linguistique crée un problème fondamental pour les équipes de détection : une règle écrite pour un SIEM est inutilisable sur un autre. Quand une organisation change de SIEM -- ce qui arrive tous les 3 à 5 ans en moyenne -- elle doit réécrire manuellement l'intégralité de son corpus de détection. Sigma résout ce problème en proposant un format YAML universel qui peut être compilé vers n'importe quel SIEM.

Créé en 2017 par Florian Roth et Thomas Patzke, Sigma est devenu le standard de facto pour l'écriture de règles de détection portables. Le dépôt SigmaHQ sur GitHub contient aujourd'hui plus de 3 000 règles communautaires couvrant l'essentiel du framework MITRE ATT&CK. Sigma est à la détection ce que YARA est à l'analyse de malware et Snort/Suricata aux signatures réseau : un langage commun qui permet le partage et la réutilisation des connaissances de détection à l'échelle de la communauté.

Cet article est un guide complet pour maîtriser Sigma : de la syntaxe YAML fondamentale aux règles avancées avec corrélation temporelle, en passant par le système de modifiers, les backends pySigma et les exemples concrets de détection. Il est conçu comme le complément technique de notre article sur le Detection-as-Code, où Sigma joue le rôle de langage intermédiaire dans le pipeline CI/CD.

2. Anatomie d'une règle Sigma

2.1 Structure YAML complète

Une règle Sigma est un document YAML structuré en sections clairement définies. Chaque section a un rôle précis dans le processus de détection et de compilation. Voici la structure complète avec toutes les sections disponibles :

# Règle Sigma complète - Structure de référence
title: Mimikatz Credential Dumping via LSASS Access
id: 0d894093-71bc-43c3-a4b0-2a0e3e8f0425    # UUID unique
related:
  - id: 27a72a60-7e5e-47b1-9d17-909c9abafdcd
    type: derived                              # derived | obsoletes | merged | renamed | similar
status: stable                                # test | stable | experimental | deprecated | unsupported
description: |
  Détecte l'accès mémoire au processus LSASS avec des droits
  caractéristiques de Mimikatz (sekurlsa::logonpasswords).
  Couverture : T1003.001 - OS Credential Dumping: LSASS Memory.
references:
  - https://attack.mitre.org/techniques/T1003/001/
  - https://github.com/gentilkiwi/mimikatz
  - https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107
author: Ayi NEDJIMI, Florian Roth (original)
date: 2026-02-15
modified: 2026-02-28
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.s0002                              # Mimikatz software
  - detection.dfir
level: high                                   # informational | low | medium | high | critical
falsepositives:
  - Legitimate security tools scanning LSASS
  - Windows Defender real-time protection
  - Crash dump utilities (procdump for debugging)

logsource:
  category: process_access
  product: windows

detection:
  selection_target:
    TargetImage|endswith: '\lsass.exe'
  selection_access:
    GrantedAccess|contains:
      - '0x1010'
      - '0x1410'
      - '0x1438'
      - '0x143a'
      - '0x1fffff'
  filter_main_legitimate:
    SourceImage|endswith:
      - '\wmiprvse.exe'
      - '\taskmgr.exe'
      - '\procexp64.exe'
      - '\procexp.exe'
  filter_defender:
    SourceImage|contains: '\Microsoft\Windows Defender\'
    SourceImage|endswith: '\MsMpEng.exe'
  filter_crowdstrike:
    SourceImage|startswith: 'C:\Program Files\CrowdStrike\'
  condition: selection_target and selection_access and not 1 of filter_*

fields:
  - SourceImage
  - TargetImage
  - GrantedAccess
  - SourceProcessGUID
  - CallTrace

Analysons chaque section en détail pour comprendre les bonnes pratiques de rédaction.

2.2 Les métadonnées : identité et contexte

Les métadonnées constituent la carte d'identité de la règle. Le champ id est un UUID v4 unique qui identifie la règle de manière universelle -- il ne doit jamais être réutilisé, même si la règle est complètement réécrite. Le champ related permet de tracer les filiations entre règles (dérivée d'une autre, fusion de plusieurs règles, remplacement d'une règle obsolète).

Le champ status contrôle le cycle de vie. Les règles experimental sont en phase de test et peuvent générer des faux positifs. Les règles stable ont été validées en production. Les règles test sont en cours de développement. Le champ level indique la sévérité de l'alerte : critical pour les détections à très haute confiance nécessitant une réponse immédiate, high pour les détections fiables nécessitant une investigation, medium et low pour les indicateurs de compromission plus bruités.

Les tags suivent la convention ATT&CK : attack.tactic_name pour les tactiques, attack.tXXXX pour les techniques, et attack.sXXXX pour les logiciels. Ces tags sont exploités par les outils de couverture MITRE ATT&CK pour générer les matrices de détection, un élément central de l'approche Detection-as-Code.

2.3 La logsource : abstraction des sources de données

La section logsource est le mécanisme d'abstraction qui rend Sigma portable. Au lieu de spécifier un index Splunk ou un data stream Elastic, la règle déclare une catégorie logique de données. Le backend de compilation traduit ensuite cette catégorie en identifiant concret pour chaque SIEM.

Les trois champs de la logsource sont :

• category : le type d'événement -- process_creation, process_access, file_event, network_connection, registry_event, dns_query, image_load, etc. Les catégories sont standardisées dans la spécification Sigma.
• product : le système d'exploitation ou le produit source -- windows, linux, macos, azure, aws, gcp.
• service : le journal d'événements spécifique -- sysmon, security, system, powershell, dns-server, firewall.

La taxonomie des logsources est cruciale pour la portabilité. Les catégories les plus couramment utilisées sont :

Catégorie	Description	Source typique	Event IDs
process_creation	Création de processus	Sysmon EID 1, Security 4688	1, 4688
process_access	Accès mémoire inter-processus	Sysmon EID 10	10
file_event	Création/modification de fichiers	Sysmon EID 11	11
registry_event	Modification du registre	Sysmon EID 12/13/14	12, 13, 14
network_connection	Connexions réseau sortantes	Sysmon EID 3	3
dns_query	Requêtes DNS	Sysmon EID 22	22
image_load	Chargement de DLL	Sysmon EID 7	7
pipe_created	Création de named pipes	Sysmon EID 17/18	17, 18

3. Modifiers et conditions : la grammaire de la détection

3.1 Les modifiers de champs

Les modifiers sont des opérateurs appliqués aux noms de champs dans la section detection. Ils permettent de spécifier le type de comparaison à effectuer, offrant une flexibilité bien supérieure à la simple correspondance exacte. La syntaxe est FieldName|modifier1|modifier2: value. Les modifiers peuvent être chaînés.

Modifier	Description	Exemple
contains	Substring match (case insensitive)	CommandLine|contains: 'mimikatz'
startswith	Préfixe	Image|startswith: 'C:\Windows\Temp\'
endswith	Suffixe	Image|endswith: '\powershell.exe'
re	Expression régulière	CommandLine|re: '(?i)-enc\s+[A-Za-z0-9+/]+'
cidr	Notation CIDR réseau	DestinationIp|cidr: '10.0.0.0/8'
all	Toutes les valeurs doivent matcher (AND)	CommandLine|contains|all: ['net', 'user']
base64	Valeur encodée en Base64	CommandLine|base64: 'IEX'
base64offset	Base64 avec offset variable	CommandLine|base64offset: 'IEX'
windash	Normalise - et / pour les paramètres Windows	CommandLine|windash|contains: '-enc'
utf16	Encodage UTF-16 (Unicode)	CommandLine|utf16|contains: 'IEX'
wide	Alias pour utf16le	CommandLine|wide|base64: 'cmd'

Le chaînage de modifiers est un outil puissant. Par exemple, CommandLine|base64offset|contains: 'Invoke-Expression' cherche la chaîne "Invoke-Expression" dans toutes les variantes d'encodage Base64 possibles (offset 0, 1 et 2). Cette technique est particulièrement utile pour détecter les commandes PowerShell obfusquées, un vecteur courant dans les attaques par credentials.

3.2 La section detection : selections, filters et conditions

La section detection est le coeur de la règle. Elle se compose de named detection items (selections et filters) et d'une condition qui les combine logiquement.

Logique intra-item : au sein d'un detection item, les champs sont combinés en AND (toutes les conditions doivent être satisfaites), et les valeurs multiples d'un même champ sont combinées en OR (l'une des valeurs suffit). Cette convention est la clé de voûte de la syntaxe Sigma :

# AND entre champs, OR entre valeurs
detection:
  selection:
    EventID: 1                                # ET
    Image|endswith:                            # ET (l'image finit par l'un de :)
      - '\cmd.exe'                            # OU
      - '\powershell.exe'                     # OU
      - '\pwsh.exe'                           # OU
    ParentImage|endswith: '\winword.exe'       # ET
  # Résultat : EventID=1 AND (Image ends with cmd OR ps OR pwsh) AND Parent is winword

La condition combine les detection items nommés avec des opérateurs logiques :

# Exemples de conditions
condition: selection                           # Simplement le selection
condition: selection and not filter            # Selection moins le filtre
condition: selection1 or selection2            # L'un ou l'autre
condition: selection and not 1 of filter_*     # Wildcard sur les filtres
condition: all of selection_*                  # Tous les selections doivent matcher
condition: 1 of selection_*                    # Au moins un selection matche
condition: selection | count() > 5             # Aggregation : plus de 5 occurrences
condition: selection | count(SourceIP) > 10    # Plus de 10 IPs source distinctes

3.3 Le pattern de naming : selections et filters

La convention de nommage SigmaHQ recommande un pattern clair pour distinguer les types de detection items :

• selection_* : les critères positifs qui identifient le comportement suspect. Exemples : selection_target, selection_access, selection_cmdline.
• filter_main_* : les exclusions principales pour les faux positifs bien connus. Exemples : filter_main_defender, filter_main_svchost.
• filter_optional_* : les exclusions secondaires que l'utilisateur peut choisir d'activer ou non selon son environnement. Exemples : filter_optional_admin_tools.

Ce pattern permet d'utiliser la condition selection and not 1 of filter_main_* and not 1 of filter_optional_* pour combiner élégamment tous les filtres. Il facilite aussi la maintenance : ajouter un nouveau faux positif revient à ajouter un nouveau filter_main_xxx sans toucher à la condition.

4. Règles avancées : corrélation et agrégation

4.1 Règles d'agrégation

Les règles d'agrégation utilisent des fonctions statistiques dans la condition pour détecter des comportements qui ne sont anormaux que par leur volume ou fréquence. Un seul événement de connexion échouée n'est pas suspect, mais 50 connexions échouées en 5 minutes depuis le même compte constituent un indicateur de brute force.

# Détection de brute force par agrégation
title: Potential Brute Force Attack
id: 2b4b58b2-9f6c-4d2e-a0b7-6d8c9e5f1a2b
status: stable
description: >
  Détecte des tentatives de brute force en comptant les échecs
  d'authentification par compte source sur une fenêtre glissante.
level: medium
tags:
  - attack.credential_access
  - attack.t1110.001

logsource:
  product: windows
  service: security

detection:
  selection:
    EventID: 4625                              # Logon failure
  filter_machine_accounts:
    TargetUserName|endswith: '$'                # Exclure les comptes machine
  condition: selection and not filter_machine_accounts | count(TargetUserName) by SourceIP > 20
  timeframe: 5m

fields:
  - TargetUserName
  - SourceIP
  - LogonType
  - SubStatus

Les fonctions d'agrégation disponibles dans Sigma sont :

• count() : nombre total d'événements ou nombre de valeurs distinctes d'un champ
• min(field) / max(field) : valeur minimale/maximale d'un champ numérique
• avg(field) : moyenne d'un champ numérique
• sum(field) : somme d'un champ numérique
• near : corrélation temporelle entre événements (proximité dans le temps)

4.2 Corrélation temporelle avec near

La corrélation temporelle est la fonctionnalité la plus avancée de Sigma. Elle permet de détecter des séquences d'événements qui, pris individuellement, sont bénins, mais dont la combinaison dans une fenêtre de temps restreinte indique une attaque. C'est l'approche idéale pour détecter des techniques d'attaque multi-étapes comme le mouvement latéral.

# Corrélation : création de service suivi d'exécution PowerShell
title: Suspicious Service Creation Followed by PowerShell Execution
id: 3c5d69e3-af7d-5e3f-b1c8-7e9d0f6a2c3d
status: experimental
description: >
  Détecte la création d'un service Windows suivi dans les 60 secondes
  d'une exécution PowerShell encodée, indicatif de PSExec ou similaire.
level: high
tags:
  - attack.lateral_movement
  - attack.t1021.002
  - attack.execution
  - attack.t1059.001

logsource:
  product: windows
  service: system

detection:
  service_creation:
    EventID: 7045                              # Service installed
    ServiceFileName|contains:
      - 'cmd.exe'
      - 'powershell'
      - 'PSEXESVC'
  powershell_exec:
    EventID: 4104                              # PowerShell script block
    ScriptBlockText|contains:
      - 'Invoke-Command'
      - 'Enter-PSSession'
      - 'New-PSSession'
  condition: service_creation | near powershell_exec
  timeframe: 60s

4.3 Règles Sigma v2 : le format de corrélation étendu

La spécification Sigma v2 introduit un format de corrélation plus riche qui permet de référencer plusieurs règles Sigma distinctes et de définir des conditions de corrélation complexes entre elles. Ce format utilise le type correlation au lieu de rule :

# Corrélation Sigma v2 : chaîne d'attaque complète
title: Credential Dumping Attack Chain
type: correlation
id: 4d6e7af4-bg8e-6f4g-c2d9-8f0e1g7b3d4e
status: experimental
description: >
  Corrèle la reconnaissance (enum utilisateurs), l'accès LSASS
  et l'utilisation de credentials volés dans un mouvement latéral.

rules:
  - user_enum:
      id: "ref-user-enumeration-rule-uuid"
  - lsass_access:
      id: "ref-lsass-access-rule-uuid"
  - lateral_move:
      id: "ref-lateral-movement-rule-uuid"

group-by:
  - ComputerName

timespan: 30m
ordered: true                                  # L'ordre des événements compte

condition:
  gte: 2                                       # Au moins 2 des 3 événements

Ce format de corrélation est encore en phase d'adoption par les backends, mais il représente l'avenir de la détection comportementale multi-étapes dans Sigma. Il permet de modéliser des kill chains complètes et de générer des alertes de haute confiance basées sur la combinaison d'indicateurs faibles.

5. pySigma : la compilation multi-SIEM

5.1 Architecture de pySigma

pySigma est le successeur de l'outil legacy sigmac. Il offre une architecture modulaire basée sur trois composants principaux : les backends (qui génèrent la syntaxe native du SIEM cible), les processing pipelines (qui transforment les champs et les logsources), et le core (qui parse le YAML et orchestre la compilation). Cette modularité permet d'ajouter le support d'un nouveau SIEM en développant simplement un nouveau backend plugin.

5.2 Utilisation pratique de pySigma

L'utilisation de pySigma en ligne de commande ou en Python est directe. Voici les cas d'usage les plus courants :

# Installation de pySigma et des backends
pip install pySigma
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
pip install pySigma-backend-microsoft365defender
pip install pySigma-pipeline-sysmon
pip install pySigma-pipeline-windows

# Ligne de commande : sigma-cli
pip install sigma-cli

# Conversion simple : Sigma vers Splunk SPL
sigma convert -t splunk -p splunk_windows rules/credential-access/mimikatz-lsass-access.yml

# Conversion vers Elastic ES|QL avec pipeline ECS
sigma convert -t elasticsearch -p ecs_windows rules/credential-access/mimikatz-lsass-access.yml

# Conversion vers Sentinel KQL
sigma convert -t microsoft365defender rules/credential-access/mimikatz-lsass-access.yml

# Conversion en batch : toutes les règles d'un répertoire
sigma convert -t splunk -p splunk_windows --output splunk-rules/ rules/

# Utilisation en Python pour un pipeline personnalisé
from sigma.collection import SigmaCollection
from sigma.backends.splunk import SplunkBackend
from sigma.pipelines.splunk import splunk_windows_pipeline
from sigma.processing.pipeline import ProcessingPipeline

# Charger la règle
rule = SigmaCollection.from_yaml(open("rules/credential-access/mimikatz-lsass-access.yml"))

# Appliquer le pipeline et compiler
backend = SplunkBackend(processing_pipeline=splunk_windows_pipeline())
print(backend.convert_rule(rule[0]))

5.3 Gestion des champs non mappés

Un des défis majeurs de la compilation Sigma est la gestion des champs qui n'existent pas dans le schéma cible. Par exemple, un champ Sysmon comme CallTrace (disponible dans l'event ID 10) peut ne pas avoir d'équivalent dans ECS (Elastic Common Schema). pySigma gère ces cas via les field mapping errors : soit en laissant le nom de champ original (risque de requête invalide), soit en générant une erreur (safe), soit en appliquant un mapping best-effort.

La recommandation pour les environnements multi-SIEM : maintenir un mapping personnalisé qui documente les correspondances de champs spécifiques à votre configuration. Ce mapping est un fichier YAML séparé qui étend les pipelines officiels, une approche que nous détaillons dans notre article Detection-as-Code.

6. Exemples concrets : règles de détection opérationnelles

6.1 Détection de Mimikatz (Credential Access)

Mimikatz reste l'outil de credential dumping le plus utilisé, tant par les red teamers que par les attaquants réels. La détection robuste de Mimikatz nécessite une approche multi-couches, car les variantes obfusquées sont innombrables. Voici trois règles complémentaires qui couvrent différents indicateurs :

# Règle 1 : Détection par accès LSASS (comportementale)
title: Suspicious LSASS Access - Credential Dumping Indicators
id: 5d894093-71bc-43c3-a4b0-2a0e3e8f0425
status: stable
level: high
tags:
  - attack.credential_access
  - attack.t1003.001

logsource:
  category: process_access
  product: windows

detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'
      - '0x1410'
      - '0x1438'
      - '0x143a'
      - '0x1fffff'
  filter_system:
    SourceImage|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
    SourceImage|endswith:
      - '\wmiprvse.exe'
      - '\svchost.exe'
      - '\csrss.exe'
      - '\wininit.exe'
      - '\lsm.exe'
  filter_av:
    SourceImage|contains:
      - '\Windows Defender\'
      - '\CrowdStrike\'
      - '\SentinelOne\'
      - '\Carbon Black\'
  condition: selection and not 1 of filter_*

# Règle 2 : Détection par named pipe (Mimikatz spécifique)
title: Mimikatz Named Pipe Detection
id: 6e905104-82cd-54d4-b5c1-3b1f4f9g1536
status: stable
level: critical
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.s0002

logsource:
  category: pipe_created
  product: windows

detection:
  selection:
    PipeName:
      - '\mimikatz'
      - '\sekurlsa'
      - '\kiwi'
  condition: selection

# Règle 3 : Détection par ligne de commande (signatures textuelles)
title: Mimikatz Command Line Indicators
id: 7f016215-93de-65e5-c6d2-4c2g5g0h2647
status: stable
level: high
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.s0002

logsource:
  category: process_creation
  product: windows

detection:
  selection_cmdline:
    CommandLine|contains:
      - 'sekurlsa::'
      - 'kerberos::list'
      - 'crypto::certificates'
      - 'lsadump::'
      - 'privilege::debug'
      - 'token::elevate'
  selection_original_filename:
    OriginalFileName: 'mimikatz.exe'
  condition: 1 of selection_*

6.2 Détection de mouvement latéral (PsExec, WMI, WinRM)

Le mouvement latéral est une phase critique de la kill chain. Voici une règle de détection PsExec qui combine plusieurs indicateurs pour minimiser les faux positifs :

# Détection PsExec - multi-indicateur
title: PsExec Lateral Movement Detection
id: 8g127326-a4ef-76f6-d7e3-5d3h6h1i3758
status: stable
level: high
tags:
  - attack.lateral_movement
  - attack.t1021.002
  - attack.execution
  - attack.t1569.002

logsource:
  category: process_creation
  product: windows

detection:
  selection_service_name:
    ParentImage|endswith: '\services.exe'
    Image|endswith:
      - '\PSEXESVC.exe'
      - '\cmd.exe'
      - '\powershell.exe'
  selection_pipe:
    CommandLine|contains:
      - '\\\\127.0.0.1\\'
      - '\\\\localhost\\'
  selection_user_context:
    User|contains: 'NT AUTHORITY\SYSTEM'
    ParentImage|endswith: '\services.exe'
    IntegrityLevel: 'System'
  filter_legitimate_admin:
    CurrentDirectory|startswith: 'C:\Windows\system32\'
    CommandLine|contains: 'svchost'
  condition: (selection_service_name or selection_pipe or selection_user_context) and not filter_legitimate_admin

falsepositives:
  - Legitimate remote administration tools
  - Software deployment via SCCM/MECM

6.3 Détection de persistance (Registry Run Keys, Scheduled Tasks)

La persistance permet à un attaquant de maintenir son accès après un redémarrage. Les clés de registre Run/RunOnce sont le mécanisme de persistance le plus basique mais toujours efficace. Cette règle détecte les modifications suspectes, un vecteur souvent exploité après une compromission par phishing :

# Détection de persistance via Registry Run Keys
title: Suspicious Registry Run Key Modification
id: 9h238437-b5fg-87g7-e8f4-6e4i7i2j4869
status: stable
level: medium
tags:
  - attack.persistence
  - attack.t1547.001

logsource:
  category: registry_set
  product: windows

detection:
  selection_target:
    TargetObject|contains:
      - '\CurrentVersion\Run'
      - '\CurrentVersion\RunOnce'
      - '\CurrentVersion\RunServices'
      - '\CurrentVersion\Explorer\Shell Folders'
      - '\CurrentVersion\Explorer\User Shell Folders'
  selection_suspicious_value:
    Details|contains:
      - 'powershell'
      - 'cmd.exe /c'
      - 'mshta'
      - 'wscript'
      - 'cscript'
      - 'regsvr32'
      - 'rundll32'
      - 'C:\Users\Public'
      - 'C:\ProgramData'
      - '\AppData\Local\Temp'
      - 'http://'
      - 'https://'
  filter_installers:
    Image|endswith:
      - '\msiexec.exe'
      - '\setup.exe'
    Image|startswith: 'C:\Windows\Installer\'
  filter_updates:
    Image|contains:
      - '\Microsoft\EdgeUpdate\'
      - '\Google\Update\'
  condition: selection_target and selection_suspicious_value and not 1 of filter_*

falsepositives:
  - Legitimate software installation
  - Windows Update components

6.4 Détection d'exfiltration DNS (Data Exfiltration)

L'exfiltration de données via DNS est une technique furtive qui encode les données volées dans les requêtes DNS. Cette règle détecte les anomalies DNS caractéristiques de ce type d'exfiltration :

# Détection d'exfiltration via DNS tunneling
title: DNS Tunneling - Suspicious DNS Query Length
id: 0a349438-c6gh-98h8-f9g5-7f5j8j3k5970
status: experimental
level: high
tags:
  - attack.exfiltration
  - attack.t1048.003
  - attack.command_and_control
  - attack.t1071.004

logsource:
  category: dns_query
  product: windows

detection:
  selection_long_query:
    QueryName|re: '^[a-zA-Z0-9]{30,}\.'
  selection_high_entropy:
    QueryName|contains:
      - '.dnscat.'
      - '.tunnel.'
      - '.dns2tcp.'
  selection_subdomain_depth:
    QueryName|re: '([^.]+\.){5,}'
  filter_cdn:
    QueryName|endswith:
      - '.akamaiedge.net'
      - '.cloudfront.net'
      - '.googleapis.com'
      - '.windows.net'
      - '.azure.com'
  filter_internal:
    QueryName|endswith:
      - '.internal.corp'
      - '.ad.company.com'
  condition: (selection_long_query or selection_high_entropy or selection_subdomain_depth) and not 1 of filter_*

falsepositives:
  - CDN services with long subdomains
  - Anti-virus cloud lookups
  - Certificate validation queries

6.5 Détection de Kerberoasting (Credential Access)

Le Kerberoasting est une technique qui exploite les tickets de service Kerberos pour extraire des hashes de mots de passe craquables hors ligne. Cette règle détecte les demandes de tickets TGS anormales :

# Détection de Kerberoasting
title: Kerberoasting - Suspicious TGS Request
id: 1b450549-d7hi-09i9-g0h6-8g6k9k4l6081
status: stable
level: high
tags:
  - attack.credential_access
  - attack.t1558.003

logsource:
  product: windows
  service: security

detection:
  selection:
    EventID: 4769
    TicketEncryptionType:
      - '0x17'     # RC4-HMAC (vulnerable, preferred by attackers)
      - '0x18'     # RC4-HMAC-EXP
    TicketOptions: '0x40810000'
  filter_machine_accounts:
    ServiceName|endswith: '$'
  filter_service_accounts:
    ServiceName|startswith: 'krbtgt'
  filter_normal_encryption:
    TicketEncryptionType:
      - '0x11'     # AES128
      - '0x12'     # AES256
  condition: selection and not 1 of filter_*

falsepositives:
  - Legacy applications using RC4 encryption
  - Service accounts with older SPNs

7. Bonnes pratiques d'écriture de règles Sigma

7.1 Convention de nommage

Une convention de nommage cohérente facilite la maintenance et la recherche dans un dépôt de règles. Les recommandations du projet SigmaHQ sont :

• Titre : format "Objet - Action Spécifique" (ex: "Mimikatz - Process Creation Detection")
• Fichier : snake_case, préfixé par la catégorie (ex: proc_creation_win_mimikatz.yml)
• ID : UUID v4 unique, généré avec uuidgen ou python -c "import uuid; print(uuid.uuid4())"
• Tags : toujours inclure la tactique ATT&CK (attack.credential_access) et la technique (attack.t1003.001)
• Selections : nommage explicite (selection_process, selection_commandline, filter_legitimate)

7.2 Gestion des faux positifs

La gestion proactive des faux positifs est essentielle pour des règles opérationnelles. Voici les stratégies recommandées :

• Filtres spécifiques : plutôt que des exclusions larges (Image|endswith: '\svchost.exe'), utilisez des filtres multi-critères combinant processus + chemin + utilisateur
• Documentation : chaque filtre doit être accompagné d'un commentaire expliquant pourquoi il est nécessaire et quel scénario légitime il couvre
• Filtres séparés : utilisez des blocs filter_* distincts pour chaque type d'exclusion, ce qui facilite la revue et la suppression ciblée
• Section falsepositives : documentez toujours les sources de faux positifs connues pour aider les analystes SOC dans leur triage
• Test avant ajout : avant d'ajouter un filtre, vérifiez qu'il ne crée pas un blind spot exploitable par un attaquant

7.3 Niveaux de sévérité et statuts

Le choix du level et du status impacte directement le traitement opérationnel de l'alerte :

Pour les statuts, suivez la progression naturelle : experimental (nouvelle règle en test) → test (validée en lab, déployée en shadow mode) → stable (production, ratio FP acceptable) → deprecated (obsolète, remplacée ou plus pertinente).

7.4 Erreurs fréquentes à éviter

• Règle trop large : une condition selection sans filtres génère un volume d'alertes ingérable. Commencez restrictif et élargissez progressivement
• Dépendance aux chemins absolus : Image: 'C:\Users\admin\mimikatz.exe' ne détecte qu'un seul scénario. Utilisez Image|endswith ou OriginalFileName
• Oubli du case-insensitive : Sigma est case-insensitive par défaut pour les valeurs, mais attention aux regex personnalisées
• Filtre qui crée un blind spot : exclure powershell.exe pour réduire le bruit supprime aussi la détection d'attaques PowerShell légitimes
• Absence de tests : une règle non testée est une règle non fiable. Validez avec des données TP et TN avant le déploiement
• ID dupliqué : chaque règle doit avoir un UUID unique. Les collisions causent des problèmes de déploiement

8. Intégration dans un pipeline CI/CD

8.1 Validation automatique des règles

L'intégration de Sigma dans un pipeline CI/CD garantit la qualité et la cohérence des règles. Voici un workflow GitHub Actions complet pour valider, compiler et déployer des règles Sigma :

# .github/workflows/sigma-pipeline.yml
name: Sigma Rules Validation & Deployment

on:
  pull_request:
    paths: ['rules/sigma/**']
  push:
    branches: [main]
    paths: ['rules/sigma/**']

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: |
          pip install pySigma pySigma-backend-splunk \
                      pySigma-backend-elasticsearch \
                      pySigma-pipeline-sysmon \
                      pySigma-pipeline-windows \
                      yamllint pytest

      # Étape 1 : Lint YAML
      - name: YAML Lint
        run: yamllint -c .yamllint.yml rules/sigma/

      # Étape 2 : Validation Sigma (syntaxe + champs)
      - name: Validate Sigma rules
        run: sigma check rules/sigma/

      # Étape 3 : Vérifier les ID uniques
      - name: Check unique IDs
        run: |
          python -c "
          import yaml, glob, sys
          ids = {}
          for f in glob.glob('rules/sigma/**/*.yml', recursive=True):
              with open(f) as fh:
                  rule = yaml.safe_load(fh)
                  rid = rule.get('id', 'MISSING')
                  if rid in ids:
                      print(f'DUPLICATE ID {rid}: {ids[rid]} and {f}')
                      sys.exit(1)
                  ids[rid] = f
          print(f'All {len(ids)} rule IDs are unique.')
          "

      # Étape 4 : Compilation multi-SIEM
      - name: Compile to Splunk
        run: |
          sigma convert -t splunk -p sysmon \
            rules/sigma/ -o compiled/splunk/

      - name: Compile to Elastic
        run: |
          sigma convert -t elasticsearch -p ecs_windows \
            rules/sigma/ -o compiled/elastic/

      # Étape 5 : Tests
      - name: Run tests
        run: pytest tests/ -v

  deploy:
    needs: validate
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy compiled rules
        run: python scripts/deploy.py --target all
        env:
          SPLUNK_TOKEN: ${{ secrets.SPLUNK_HEC_TOKEN }}
          ELASTIC_API_KEY: ${{ secrets.ELASTIC_API_KEY }}

8.2 Sigma CLI : commandes essentielles

Le CLI sigma (fourni par pySigma) offre plusieurs commandes utiles pour le travail quotidien avec les règles :

# Valider une règle
sigma check rules/sigma/credential_access/mimikatz_execution.yml

# Convertir une règle pour Splunk avec le pipeline Sysmon
sigma convert -t splunk -p sysmon rules/sigma/credential_access/mimikatz_execution.yml

# Convertir pour Elastic avec le pipeline ECS Windows
sigma convert -t elasticsearch -p ecs_windows rules/sigma/credential_access/mimikatz_execution.yml

# Convertir pour Microsoft Sentinel (KQL)
sigma convert -t microsoft365defender rules/sigma/credential_access/mimikatz_execution.yml

# Convertir toutes les règles d'un répertoire
sigma convert -t splunk -p sysmon rules/sigma/ -o compiled/splunk/

# Lister les backends disponibles
sigma list backends

# Lister les pipelines disponibles
sigma list pipelines

Pour une approche complète de l'automatisation des règles de détection, consultez notre article sur le pipeline CI/CD Detection-as-Code.

9. Conclusion et ressources

Sigma s'est imposé comme le standard de facto pour l'écriture de règles de détection portables. Sa syntaxe YAML déclarative, ses modifiers puissants et l'écosystème pySigma permettent d'écrire une règle une seule fois et de la déployer sur n'importe quel SIEM. Les points clés à retenir :

• Maîtrisez la logsource : c'est l'abstraction qui rend vos règles portables
• Utilisez les modifiers (|contains, |endswith, |re) pour des détections précises
• Structurez vos détections avec le pattern selection + filter + condition
• Explorez les corrélations et agrégations pour détecter des comportements complexes
• Intégrez pySigma dans votre pipeline CI/CD pour automatiser la compilation et le déploiement
• Contribuez à SigmaHQ pour enrichir la base de règles communautaire