---
title: "Règles Sigma — Détection SOC"
domain: security
subdomain: soc
phase: 04-detection
type: snippet
tags: [soc, sigma, detection, SIEM, rules, Splunk, Elastic]
difficulty: advanced
status: stable
updated: "2025-05-13"
---
## Structure d'une règle Sigma

```yaml
title: Nom court et descriptif de la règle
id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  # UUID unique
status: stable | test | experimental | deprecated
description: >
  Description détaillée de ce que détecte la règle,
  contexte et TTPs couverts.
author: Nom Auteur
date: 2025/05/13
modified: 2025/05/13
references:
  - https://attack.mitre.org/techniques/T1059/001/
  - https://{{BLOG_REFERENCE_URL}}

logsource:
  category: process_creation     # ou network_connection, dns_query, etc.
  product: windows               # ou linux, aws, azure, etc.
  # service: security            # pour event_id spécifiques

detection:
  selection:
    # Champs de détection (AND implicite dans un même bloc)
    Image|endswith: '\powershell.exe'
    CommandLine|contains|all:
      - '-EncodedCommand'
      - '-NonInteractive'

  filter_legitimate:
    # Exclusions (NOT)
    ParentImage|startswith:
      - 'C:\Windows\System32\msiexec.exe'

  condition: selection and not filter_legitimate

fields:
  - Image
  - CommandLine
  - ParentImage
  - User

falsepositives:
  - Legitimate administrative scripts using encoded commands
  - Software deployment tools (SCCM, Intune)

level: high   # informational | low | medium | high | critical
tags:
  - attack.execution
  - attack.t1059.001
```

---

## Exemple 1 — PowerShell Encoded Command (T1059.001)

```yaml
title: PowerShell Encoded Command Execution
id: b9d9cc83-380b-4ba3-8d8f-60c0c9d2e8db
status: stable
description: >
  Détecte l'exécution de PowerShell avec un argument EncodedCommand,
  technique fréquente pour contourner la détection de scripts malveillants.
author: SOC Team
date: 2025/05/13
references:
  - https://attack.mitre.org/techniques/T1059/001/

logsource:
  category: process_creation
  product: windows

detection:
  selection_main:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - ' -EncodedCommand '
      - ' -enc '
      - ' -ec '
      - ' -EnC '

  filter_known_software:
    # Exclure les outils légitimes connus (ajuster selon environnement)
    ParentImage|endswith:
      - '\msiexec.exe'
      - '\ccmexec.exe'    # SCCM
    CommandLine|contains:
      - 'Microsoft.PowerShell.Commands.Internal'

  filter_admin_workstations:
    Computer|startswith:
      - 'ADMIN-'
      - 'JUMP-'
    User|startswith:
      - 'svc-deploy'
      - 'svc-ansible'

  condition: selection_main and not 1 of filter_*

fields:
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - User
  - Computer

falsepositives:
  - Software deployment agents (SCCM, Intune, Ansible)
  - Legitimate automation scripts from authorized admin hosts

level: high
tags:
  - attack.execution
  - attack.defense_evasion
  - attack.t1059.001
  - attack.t1027
```

---

## Exemple 2 — Mouvement latéral via PsExec (T1569.002)

```yaml
title: Lateral Movement via PsExec
id: 42e3c936-9c8d-4f8d-8b8d-5b8d5b8d5b8d
status: stable
description: >
  Détecte l'exécution de PsExec ou PsExec64, outil d'administration légitime
  fréquemment utilisé pour le mouvement latéral. Filtré pour exclure les usages
  autorisés depuis les jump servers.
author: SOC Team
date: 2025/05/13
references:
  - https://attack.mitre.org/techniques/T1569/002/
  - https://docs.microsoft.com/en-us/sysinternals/downloads/psexec

logsource:
  category: process_creation
  product: windows

detection:
  selection_image:
    Image|endswith:
      - '\psexec.exe'
      - '\psexec64.exe'
      - '\PsExec.exe'
      - '\PsExec64.exe'

  selection_service:
    # PsExec crée un service PSEXESVC
    Image|endswith: '\PSEXESVC.exe'

  filter_authorized_sources:
    Computer|startswith:
      - 'JUMP-'
      - 'BASTION-'
      - 'SCCM-'
    User|startswith:
      - 'svc-ops'
      - 'svc-deploy'

  filter_system:
    User: 'NT AUTHORITY\SYSTEM'
    ParentImage|endswith: '\services.exe'

  condition: (1 of selection_*) and not 1 of filter_*

fields:
  - Image
  - CommandLine
  - ParentImage
  - User
  - Computer
  - TargetObject

falsepositives:
  - Legitimate remote administration from authorized jump servers
  - IT operations using PsExec for maintenance

level: high
tags:
  - attack.lateral_movement
  - attack.execution
  - attack.t1569.002
  - attack.t1021.002
```

---

## Exemple 3 — Accès LSASS (T1003.001)

```yaml
title: LSASS Memory Access - Credential Dumping
id: f73d81e7-c53f-4573-9855-6d5bfe26a783
status: stable
description: >
  Détecte les accès à la mémoire du processus LSASS pour extraction de credentials.
  Couvre Mimikatz, procdump, Task Manager dump, et accès via OpenProcess/ReadProcessMemory.
author: SOC Team
date: 2025/05/13
references:
  - https://attack.mitre.org/techniques/T1003/001/

logsource:
  category: process_access
  product: windows

detection:
  selection_lsass_target:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'    # PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION
      - '0x1410'    # ReadProcessMemory
      - '0x1438'    # Mimikatz default
      - '0x143a'    # Mimikatz sekurlsa
      - '0x1f0fff'  # Full access
      - '0x1fffff'  # Full access variant

  filter_legitimate:
    SourceImage|startswith:
      - 'C:\Windows\System32\svchost.exe'
      - 'C:\Windows\System32\werfault.exe'
      - 'C:\Windows\System32\taskmgr.exe'
    GrantedAccess: '0x1000'  # Minimal access from Task Manager

  filter_edr:
    # Exclure les agents EDR (ajuster selon EDR déployé)
    SourceImage|contains:
      - 'CrowdStrike'
      - 'SentinelOne'
      - 'MDE'

  condition: selection_lsass_target and not 1 of filter_*

fields:
  - SourceImage
  - TargetImage
  - GrantedAccess
  - CallTrace

falsepositives:
  - Security tools and EDR agents
  - Crash dump utilities on critical failures

level: critical
tags:
  - attack.credential_access
  - attack.t1003.001
```

---

## Conversion Sigma — sigma-cli

```bash
# Installation
pip install sigma-cli
sigma plugin install splunk
sigma plugin install elasticsearch

# Conversion vers Splunk SPL
sigma convert -t splunk -p splunk_windows rule.yml

# Conversion vers Elastic ESQL
sigma convert -t elasticsearch -p ecs_windows rule.yml

# Conversion vers plusieurs formats en lot
for rule in rules/*.yml; do
  echo "=== Converting: $rule ==="
  sigma convert -t splunk -p splunk_windows "$rule" 2>/dev/null \
    >> /output/splunk_all_rules.conf
done

# Avec pipeline personnalisé
sigma convert \
  -t splunk \
  -p splunk_windows \
  -p my_custom_pipeline.yml \
  --output-format savedsearches \
  rules/lateral_movement/

# Conversion Elastic avec mapping ECS
sigma convert \
  -t elasticsearch \
  -p ecs_windows \
  -p ecs_zeek_beats \
  --output-format kibana_ndjson \
  rules/network/
```

---

## Processus — Detection Engineering

```
1. LOG SOURCE
   └─ Identifier les sources disponibles (Windows Event, Sysmon, EDR, Netflow)
   └─ Valider la présence des champs nécessaires (CommandLine, ParentImage...)

2. HYPOTHESIS
   └─ "Un attaquant qui fait X laissera y observable dans log z"
   └─ S'appuyer sur MITRE ATT&CK, threat intel, incident passés

3. RULE WRITING
   └─ Écrire en Sigma (format universel)
   └─ Couvrir les variantes connues (noms alternatifs, casing, paths)
   └─ Ajouter les filtres dès l'écriture

4. TEST — MALICIOUS
   └─ Atomic Red Team : https://github.com/redcanaryco/atomic-red-team
   └─ Simuler manuellement la technique
   └─ Valider que la règle se déclenche

5. TEST — BENIGN
   └─ Tester sur les logs des 30 derniers jours
   └─ Mesurer le taux de faux positifs
   └─ Affiner les filtres

6. TUNE
   └─ Ratio FP acceptable : < 5% pour high/critical
   └─ Ajouter les exclusions légitimes documentées

7. DEPLOY
   └─ Commit dans le dépôt Sigma (Git)
   └─ CI/CD : test automatique avant merge
   └─ Déploiement SIEM avec monitoring du volume d'alertes

8. MONITOR
   └─ Suivre le ratio VP/FP hebdomadaire
   └─ Réviser si > 20% FP ou 0 VP sur 30 jours
```

---

## Gaps de détection courants

| Gap | Cause | Solution |
|---|---|---|
| Pas de CommandLine dans Event 4688 | Audit non configuré | Activer `Include command line in process creation events` via GPO |
| Pas de ParentImage | Source Sysmon non déployé | Déployer Sysmon avec config SwiftOnSecurity ou Neo23x0 |
| Faux négatifs sur encodage PS | Règle trop stricte sur casing | Utiliser `|contains|all` avec `nocase` en Sigma |
| Pas de visibilité WMI | Audit WMI non activé | Event 4688 + Sysmon Event 19/20/21 |
| Logs réseau sans contenu | NetFlow seulement | Ajouter proxy logs, DNS logs, ou Zeek |
| EDR alert sans contexte SIEM | Silos de données | Forwarder EDR alerts vers SIEM |

---

## MITRE ATT&CK — Mapping dans Sigma

```yaml
# Référence des tags Sigma ↔ MITRE ATT&CK
tags:
  # Tactiques
  - attack.reconnaissance        # TA0043
  - attack.initial_access        # TA0001
  - attack.execution             # TA0002
  - attack.persistence           # TA0003
  - attack.privilege_escalation  # TA0004
  - attack.defense_evasion       # TA0005
  - attack.credential_access     # TA0006
  - attack.discovery             # TA0007
  - attack.lateral_movement      # TA0008
  - attack.collection            # TA0009
  - attack.command_and_control   # TA0011
  - attack.exfiltration          # TA0010
  - attack.impact                # TA0040

  # Techniques (exemples)
  - attack.t1059.001   # PowerShell
  - attack.t1059.003   # Windows Command Shell
  - attack.t1003.001   # LSASS Memory
  - attack.t1547.001   # Registry Run Keys
  - attack.t1053.005   # Scheduled Task
  - attack.t1078       # Valid Accounts
  - attack.t1110.003   # Password Spraying
```

---

## SigmaHQ — Ressources

```bash
# Cloner le dépôt officiel de règles Sigma
git clone https://github.com/SigmaHQ/sigma.git

# Structure du dépôt
# sigma/rules/
#   windows/     — règles Windows (process_creation, registry, etc.)
#   linux/       — règles Linux
#   cloud/       — AWS, Azure, GCP
#   network/     — Suricata, Zeek, firewall
#   web/         — Web server logs

# Chercher des règles par technique MITRE
grep -r "t1059.001" sigma/rules/ --include="*.yml" -l

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

# Pipeline de CI pour validation
sigma check --validation-config validation.yml rules/
```

<Tip>Tester les règles Sigma contre un jeu de logs bénins (30 jours de production) AVANT le déploiement en production — un taux de FP > 10% sur une règle "high" va rapidement saturer les analystes et conduire à l'alert fatigue. Utiliser Atomic Red Team pour valider la détection côté malveillant, et les logs de production pour calibrer les filtres.</Tip>