IOA : définition, taxonomie MITRE et règles Sigma 2026

Comparaison concrète sur le même incident :
 
  Scénario : ransomware déployé via phishing avec macro Word
 
  IOC associés (ce qui reste) :
    Hash MD5 du dropper malveillant
    Domaine C2 utilisé pour déposer le payload
    IP du serveur de chiffrement
    Extension de fichier ajoutée aux fichiers chiffrés
    Note de rançon avec adresse Bitcoin
 
  IOA associés (ce qui s'est passé) :
    winword.exe spawn cmd.exe (anormal)
    cmd.exe spawn powershell.exe avec -EncodedCommand
    powershell.exe download via Invoke-WebRequest sur IP non whitelistée
    Création d'une tâche planifiée pour persistance
    Énumération massive de fichiers via icacls
    Chiffrement haut volume avec extension uniforme

Pyramid of Pain (du plus facile au plus dur à changer) :
 
  Hash values            : trivial (recompile)
  IP addresses           : easy (rotation VPS)
  Domain names           : simple (DGA)
  Network/Host artifacts : annoying
  Tools                  : challenging
  TTPs (=IOA)            : tough ← détection IOA force changement
                                    de modus operandi attaquant

IOA 1 - Document Office spawn shell
  Pattern : winword.exe / excel.exe / outlook.exe spawn
            cmd.exe / powershell.exe / wscript.exe / mshta.exe
  MITRE : T1566.001 Spearphishing Attachment
 
IOA 2 - Téléchargement par binaire Living-off-the-Land
  Pattern : certutil.exe / bitsadmin.exe / curl.exe avec URL externe
  MITRE : T1105 Ingress Tool Transfer

IOA 3 - PowerShell obfusqué
  Pattern : powershell.exe -EncodedCommand <base64>
            ou -e <base64>
            ou Invoke-Expression sur string
  MITRE : T1059.001 PowerShell
 
IOA 4 - WMI execution distant
  Pattern : wmic.exe /node: process call create
  MITRE : T1047 Windows Management Instrumentation

IOA 5 - Tâche planifiée suspecte
  Pattern : schtasks.exe /create avec nom aléatoire
            ou pointant vers binaire dans %TEMP% ou %APPDATA%
  MITRE : T1053.005 Scheduled Task
 
IOA 6 - Service Windows nommé aléatoirement
  Pattern : sc.exe create avec nom incohérent ou service auto-start
  MITRE : T1543.003 Windows Service
 
IOA 7 - Registre Run/RunOnce modifié
  Pattern : modification de HKCU\Software\Microsoft\Windows\
            CurrentVersion\Run par process non-installer
  MITRE : T1547.001 Registry Run Keys

IOA 8 - Token impersonation
  Pattern : process accède à token d'un autre process privilégié
  MITRE : T1134 Access Token Manipulation
 
IOA 9 - UAC bypass via fodhelper / computerdefaults
  Pattern : fodhelper.exe / computerdefaults.exe avec hijack registry
  MITRE : T1548.002 Bypass User Account Control

IOA 10 - LSASS dump
  Pattern : process non-Microsoft accède LSASS avec PROCESS_VM_READ
            ou ouverture de lsass.exe par procdump.exe / mimikatz
  MITRE : T1003.001 LSASS Memory
 
IOA 11 - Kerberoasting
  Pattern : compte utilisateur demande TGS pour comptes SPN
            avec encryption type 0x17 (RC4-HMAC) en volume anormal
  MITRE : T1558.003 Kerberoasting
 
IOA 12 - DCSync
  Pattern : compte non-DC demande DRSReplicationGetChanges via RPC
  MITRE : T1003.006 DCSync

IOA 13 - PsExec / SMB lateral movement
  Pattern : création service distant via SMB depuis non-admin host
            ou installation PSEXESVC.exe
  MITRE : T1021.002 SMB/Windows Admin Shares
 
IOA 14 - WinRM remoting suspect
  Pattern : wsmprovhost.exe spawning cmd / powershell
            depuis source non-management
  MITRE : T1021.006 Windows Remote Management

IOA 15 - Beaconing C2
  Pattern : connexions sortantes régulières vers même destination
            avec jitter, port atypique, durée courte
  MITRE : T1071 Application Layer Protocol
 
IOA 16 - DNS tunneling
  Pattern : volume anormal de DNS queries longues
            avec entropie élevée vers domaine récemment créé
  MITRE : T1071.004 DNS

Étape 1 - Identifier la technique MITRE ATT&CK ciblée
  Choisir une technique précise (ex. T1003.001 LSASS Memory)
  Lire la fiche MITRE complète :
    Procedures examples (groupes APT, malware)
    Detection (sources de données suggérées)
    Mitigations
  Étudier 3-5 implémentations différentes (variations attaquants)
 
Étape 2 - Documenter les comportements observables
  Quelles sources de données capturent l'événement ?
    Sysmon EID 10 (ProcessAccess) pour LSASS
    Windows Security 4688 (process creation)
    EDR telemetry (CrowdStrike, Defender, SentinelOne)
  Quels champs sont caractéristiques ?
  Quels patterns distinguent malicieux de légitime ?
 
Étape 3 - Écrire la règle en Sigma (format portable)
  Hub central : SigmaHQ/sigma sur GitHub (3000+ règles)
  Format YAML standardisé
  Conversion automatique vers SIEM cible via pysigma
 
Étape 4 - Tester et déployer
  Lab : GOAD, DetectionLab, Atomic Red Team
  Mode audit 7-14 jours pour mesurer faux positifs
  Tuning des conditions
  Déploiement en mode alerting puis blocking si EDR

title: LSASS Memory Access by Suspicious Process
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects access to LSASS memory by non-Microsoft signed processes,
             a common pattern for credential dumping with Mimikatz, ProcDump,
             or custom tools.
references:
  - https://attack.mitre.org/techniques/T1003/001/
  - https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
author: SecurityTeam
date: 2026-04-15
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1410'    # PROCESS_VM_READ + PROCESS_QUERY_INFORMATION
      - '0x1010'
      - '0x1438'
      - '0x143a'
      - '0x1418'
  filter_legitimate:
    SourceImage|contains:
      - '\System32\svchost.exe'
      - '\System32\wbem\WmiPrvSE.exe'
      - '\System32\taskhostw.exe'
  filter_signed_microsoft:
    SourceImage|startswith:
      - 'C:\Program Files\Windows Defender\'
      - 'C:\Program Files\Microsoft\'
  condition: selection and not (filter_legitimate or filter_signed_microsoft)
falsepositives:
  - Antivirus or EDR products legitimately accessing LSASS
  - Microsoft signed troubleshooting tools
level: high
tags:
  - attack.credential_access
  - attack.t1003.001

# Installer pysigma
pip install pysigma pysigma-backend-splunk pysigma-backend-elasticsearch \
            pysigma-backend-microsoft365defender
 
# Convertir vers Splunk SPL
sigma convert -t splunk lsass-access.yml
 
# Output Splunk :
# index=windows EventCode=10 (TargetImage="*\\lsass.exe")
#   GrantedAccess IN ("0x1410","0x1010","0x1438","0x143a","0x1418")
#   NOT (SourceImage="*\\System32\\svchost.exe" OR
#        SourceImage="*\\System32\\wbem\\WmiPrvSE.exe" OR
#        SourceImage="*\\System32\\taskhostw.exe")
#   NOT (SourceImage="C:\\Program Files\\Windows Defender\\*" OR
#        SourceImage="C:\\Program Files\\Microsoft\\*")
 
# Convertir vers Microsoft Defender 365 KQL
sigma convert -t microsoft365defender lsass-access.yml
 
# Convertir vers Elastic EQL
sigma convert -t lucene lsass-access.yml

# Detect PowerShell launched from Office
title: PowerShell Launched From Office Application
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  condition: selection
level: high
tags: [attack.execution, attack.t1059.001]
 
---
# Detect Kerberoasting
title: Suspicious Kerberos TGS Requests with RC4
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
    TicketOptions: '0x40810000'
  filter_machine:
    TargetUserName|endswith: '$'
  timeframe: 5m
  condition: selection and not filter_machine | count(TargetUserName) by ServiceName > 5
level: high
tags: [attack.credential_access, attack.t1558.003]
 
---
# Detect lateral movement WMI
title: Remote WMI Process Creation
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: '\wmiprvse.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  condition: selection
level: medium
tags: [attack.lateral_movement, attack.t1047]

Architecture CrowdStrike Falcon IOA :
 
  Niveau 1 - Sensor endpoint
    Capture 1000+ types d'événements (process, file, registry,
    network, memory, kernel)
    Streaming continu vers cloud Falcon
 
  Niveau 2 - Event Stream Processing (cloud)
    Corrélation temporelle d'événements
    Application de centaines d'IOA pré-définies
    Latence < 5 secondes typique
 
  Niveau 3 - AI-powered IOAs (depuis 2023)
    Modèles ML entraînés sur télémétrie globale CrowdStrike
    Détection de patterns inédits sans règle explicite
    Découverte de techniques d'attaque émergentes
 
  Niveau 4 - Threat hunting (Falcon Overwatch)
    Équipe humaine 24/7
    Hunting basé sur hypothèses
    Création de nouvelles IOA à partir d'observations

Capabilities Defender for Endpoint :
 
  Behavioral analysis
    Basé sur télémétrie ETW (Event Tracing for Windows)
    1000+ behaviors pré-configurés
    Mapping MITRE ATT&CK natif
 
  Microsoft Threat Intelligence
    Cloud-based, mise à jour continue
    Insight sur 84 trillion signaux quotidiens
 
  Attack disruption (auto-response)
    Capacité depuis 2023 à isoler asset, désactiver compte
    automatiquement sur certains scenarios (ransomware notamment)
 
  Custom detection rules
    Format KQL (Kusto Query Language)
    Conversion depuis Sigma possible

Approche unique SentinelOne :
 
  Storyline
    Reconstruction automatique de chaîne d'attaque
    Tous les événements liés à un incident sont automatiquement
    consolidés en une visualisation narrative
    Capacité de rollback automatique
 
  Static AI
    ML pré-exécution analyse fichiers avant lancement
    Bloque malware connu et inconnu
 
  Behavioral AI
    Détection comportementale temps réel
    Patterns IOA appliqués sur télémétrie
 
  Active EDR
    Investigation et réponse depuis console
    Hunting via PowerQuery

Falco (CNCF, OSS) :
 
  Capture syscalls via eBPF
  Règles déclaratives en YAML
  Détection runtime container et host
  Adapté Kubernetes natif
 
Exemples règles Falco :
  Container running unexpected process
  Write to root filesystem in container
  Outbound connection to unexpected destination
  Privilege escalation via setuid binary

1. IOA classique (règles déterministes)
 
  Mécanisme : if-then-else strict sur événements
  Exemple : if process X then alert
  Force : précis, faible bruit, explicable
  Faiblesse : limite aux patterns connus
 
2. Heuristique (règles probabilistes)
 
  Mécanisme : score basé sur multiples indicateurs faibles
  Exemple : binaire non signé (+3) + connexion réseau (+2)
            + write registry (+2) = score 7/10 → alert si > 6
  Force : couverture plus large
  Faiblesse : plus de faux positifs
 
3. ML Detection (modèles entraînés)
 
  Mécanisme : ML supervised ou unsupervised sur télémétrie
  Exemple : autoencoder détecte déviation comportementale utilisateur
  Force : détecte l'inconnu (zero-day, technique nouvelle)
  Faiblesse : explicabilité limitée, exige beaucoup de données,
              risque biais

Pipeline détection EDR 2026 :
 
  Événement endpoint
       ↓
  Filtrage initial (whitelist process légitimes)
       ↓
  Application règles IOA déterministes
       ↓ (si match)
  Scoring heuristique sur contexte
       ↓
  Évaluation ML model (anomaly detection)
       ↓
  Threat intelligence enrichment
       ↓
  Alert ranking (high/medium/low)
       ↓
  Action automatique ou escalade humaine

Métriques à suivre par règle IOA :
 
  True Positive (TP) : alerte = vrai incident
  False Positive (FP) : alerte = comportement légitime
  True Negative (TN) : pas d'alerte = pas d'incident (rarement mesurable)
  False Negative (FN) : pas d'alerte = vrai incident (mesurable post-incident)
 
Ratios cibles :
  Précision = TP / (TP + FP) > 70 % pour règle production
  Rappel = TP / (TP + FN) > 80 % pour règle critique
  F1 score équilibrant les deux

1. Whitelisting contextuel
   Identifier processus légitimes spécifiques à l'organisation
   Ex : EDR de votre antivirus accède à LSASS = normal
   Ex : Outil de monitoring utilise WMI = normal
   À documenter et maintenir
 
2. Threshold dynamique
   Baseline de comportement utilisateur/asset
   Alerter sur déviation, pas valeur absolue
   Ex : utilisateur typiquement 5 logon/jour, déclencher si > 20
 
3. Multi-stage rules
   Combiner plusieurs signaux faibles plutôt qu'un seul fort
   Ex : process anormal + connexion réseau + persistence = alerte
   Plus discriminant qu'un seul signal
 
4. Corrélation temporelle
   Pattern observé dans une fenêtre courte plus suspect
   Ex : 5 échecs Kerberos en 1 minute > 5 échecs en 8 heures
 
5. Enrichissement contexte business
   Asset criticality (DC > workstation user)
   User role (admin > standard user)
   Tag d'environnement (prod > dev)
   Score d'alerte modulé par contexte
 
6. ML supervised pour ranking
   Modèle entraîné sur historique tickets SOC
   Prédit probabilité TP vs FP pour chaque alerte
   Optimise charge analyste Tier 1

Hebdomadaire :
  Revue 20-30 alertes les plus fréquentes
  Identification des FP récurrents
  Ajustement règles concernées
 
Mensuel :
  Suppression des règles avec ratio FP > 30 %
  Création nouvelles règles sur trends récents
  Audit couverture MITRE ATT&CK
 
Trimestriel :
  Purple team exercise sur 10-20 techniques
  Mesure couverture vs gap
  Roadmap d'amélioration

Phase 1 - Red team simulation
  Choix de 5-10 techniques MITRE ATT&CK à tester
  Outils :
    Atomic Red Team (Red Canary, scripts par technique)
    MITRE Caldera (orchestration agentic)
    Manuel avec Impacket, Mimikatz, etc.
  Exécution dans environnement de test ou prod limité
 
Phase 2 - Blue team observation
  Vérification des télémétries collectées
  Quelles règles IOA ont déclenché ?
  Quel temps de détection (MTTD) ?
  Quelles règles auraient dû déclencher mais n'ont pas ?
 
Phase 3 - Gap analysis et développement
  Pour chaque technique non détectée :
    Analyser les événements observables
    Écrire règle Sigma dédiée
    Tester en lab
    Déployer en mode audit puis alert
 
Phase 4 - Mesure de couverture
  Re-exécution des techniques
  Vérification que toutes déclenchent
  Mise à jour matrice MITRE ATT&CK couverture
  Documentation pour direction et conformité

Atomic Red Team (Red Canary, OSS)
  Scripts shell/PowerShell par technique MITRE
  Plus de 1000 atomic tests
  Reproductibles facilement
 
MITRE Caldera (OSS)
  Orchestration multi-agents
  Adversary emulation campaigns
  Gestion de scénarios complexes
 
VECTR (SecurityRiskAdvisors, OSS)
  Tracking des exercises purple team
  Métriques de couverture dans le temps
  Reporting au management
 
DeTT&CT (OSS)
  Mapping de couverture MITRE ATT&CK
  Visualisation gaps de détection
  Intégration Sigma rules
 
Pyramid of Pain assessment :
  Évaluer où vos détections opèrent
  Plus haut = mieux (vers TTPs)

Couverture MITRE ATT&CK :
  % des techniques détectées dans les 14 tactiques
  Cible mature 2026 : 60-80 % couverture techniques publiques
 
Mean Time to Detect (MTTD) :
  Temps entre exécution attaque et alerte
  Cible : < 5 minutes pour techniques courantes
 
True Positive Rate :
  Détections valides / total alertes
  Cible : > 70 %
 
Détections par tactique :
  Distribution équilibrée souhaitée
  Identifier les blind spots (souvent Persistence, Defense Evasion)

Scénario : SOC Tier 1+2 monté en 2026, EDR CrowdStrike Falcon,
            SIEM Splunk, équipe de 5 analystes
 
Mois 1 - Bootstrap
  Activer toutes les IOA OOTB CrowdStrike (out of the box)
  Importer SigmaHQ rules pertinentes (300+ règles initial)
  Mode alerting passif, observation
  Identifier top 20 alertes les plus bruyantes
 
Mois 2-3 - Tuning baseline
  Whitelisting des process légitimes organisation
  Suppression des règles avec FP > 50 %
  Création tags business sur assets critiques
  Premier exercice purple team (5 techniques)
 
Mois 4-6 - Custom IOA
  Développement de 10-20 règles custom basées sur :
    Stack technologique spécifique
    Threat intel sectorielle (ex : finance = APT38)
    Lessons learned d'incidents internes ou pairs
 
Mois 7-12 - Maturité
  Couverture MITRE ATT&CK > 50 %
  MTTD < 10 min sur techniques courantes
  Cycle purple team trimestriel
  Reporting régulier au RSSI / management
  Automation via SOAR pour réponses standard

Apport ML dans IOA :
 
  Détection de patterns inédits sans règle explicite
  Adaptation dynamique aux nouvelles techniques
  Réduction des faux positifs via ranking
  Génération d'IOA candidates par observation
 
Limites :
  Dépendance à la qualité du training data
  Difficulté d'explicabilité (alertes opaques)
  Risque de drift dans le temps
  Adversarial examples possibles

IOA cloud-native typiques 2026 :
 
  Container :
    Process anormal lancé dans container
    Write to read-only filesystem
    Privilege escalation via setuid
    Connexion sortante non whitelistée
    Exec into running container par non-admin
 
  Kubernetes :
    Pod créé avec privilèges hostNetwork
    ServiceAccount token utilisé hors namespace
    NetworkPolicy bypass tentatif
    RBAC escalation via verbs imprudents
 
  Serverless / FaaS :
    Lambda function avec IAM excessivement large
    Invocation depuis source inhabituelle
    Cold start anormal de fréquence
 
Outils 2026 :
  Sysdig Falco (eBPF runtime security)
  Aqua Tracee
  Tetragon (Cilium)
  Wiz Runtime

IOA spécifiques LLM 2026 :
 
  Prompt injection patterns dans inputs
  Volume anormal de requêtes par user (extraction tentative)
  Outputs contenant patterns secrets / API keys
  Tool calling vers endpoints non whitelistés
  Encoding tricks (base64, leetspeak, low-resource lang)
  Context contamination via RAG poisoning
 
Voir [qu'est-ce que la sécurité des LLM](/ressources/llm-security/securite-llm-definition).

1. Déployer des centaines d'IOA sans tuning
   → SOC noyé sous les alertes, fatigue, miss vrais incidents
   → Mieux : 50 règles bien tunées que 500 bruyantes
 
2. Ignorer la couverture MITRE ATT&CK
   → Concentration sur Initial Access seulement
   → Blind spots sur Persistence, Defense Evasion, Lateral Movement
   → Cartographier régulièrement (DeTT&CT)
 
3. Ne pas tester ses propres règles
   → Règles écrites pour le théorique, jamais validées
   → Atomic Red Team obligatoire en CI/CD SOC
 
4. Manquer de contexte business
   → Toutes les alertes traitées avec même priorité
   → Asset criticality + user risk score essentiels
 
5. Pas de cycle purple team régulier
   → Détections obsolètes face aux techniques 2026
   → Trimestriel minimum
 
6. Ne pas partager avec la communauté
   → Réinventer constamment
   → SigmaHQ, MITRE ATT&CK Workbench permettent de partager
 
7. Alertes sans action
   → Règles écrites mais pas de playbook associé
   → SOAR + runbooks documentés requis