Sigma Rules : Guide Complet d'Écriture et Déploiement de

# 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

# 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

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.

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

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.

Pour approfondir ce sujet, consultez notre outil open-source soar-playbooks qui facilite l'automatisation des playbooks de réponse.

Questions frequentes

Sources et références : MITRE ATT&CK · MITRE CAR

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

Analyse des impacts et recommandations

L'analyse des risques associés à cette problématique révèle des impacts potentiels significatifs sur la confidentialité, l'intégrité et la disponibilité des systèmes d'information. Les recommandations présentées s'appuient sur les référentiels de l'ANSSI et du NIST pour garantir une approche structurée de la remédiation.

Mise en œuvre opérationnelle

La mise en œuvre des mesures de sécurité décrites dans cet article nécessite une approche progressive, en commençant par les actions à gain rapide avant de déployer les contrôles plus complexes. Un plan d'action priorisé permet de maximiser la réduction du risque tout en respectant les contraintes opérationnelles de l'organisation.

Perspectives et évolutions

Le paysage des menaces évolue continuellement, rendant nécessaire une veille permanente et une adaptation régulière des stratégies de défense. Les tendances actuelles indiquent une sophistication croissante des techniques d'attaque et une nécessité d'automatisation accrue des processus de détection et de réponse.

Synthèse et recommandations clés

Les éléments présentés dans cette analyse mettent en lumière la nécessité d'une approche structurée face aux défis de cybersécurité actuels. La combinaison de mesures techniques, organisationnelles et humaines constitue le socle d'une posture de sécurité robuste capable de résister aux menaces les plus sophistiquées.