IOA - Indicators of Attack vs IOC, détection 2026

Un IOA (Indicator of Attack) est un indicateur comportemental d'une attaque en cours ou en cours de préparation, par opposition à l'IOC (Indicator of Compromise) qui est un artefact statique d'une compromission passée. Le terme a été popularisé par George Kurtz (CrowdStrike, vers 2014) pour formaliser la rupture entre la détection signature-based historique et l'approche behavioral des EDR modernes. En 2026, 60-70 % du budget detection engineering des équipes SOC matures est alloué aux IOA-based detections (règles Sigma, hunts MITRE ATT&CK, detection-as-code), exactement parce que la Pyramid of Pain (David Bianco, 2013) prouve qu'un attaquant change ses IOC en minutes et ses IOA en semaines ou mois. Comprendre la distinction IOA/IOC, le mapping MITRE ATT&CK, le rôle des EDR/XDR, le concept de LOLBins et la discipline detection engineering est le pivot d'un SOC qui dépasse le stade « SIEM avec feeds CTI gratuits ».

Pour le contexte adjacent : voir IOC - Indicateurs de compromission pour l'approche artefactuelle, et TTP - Tactics, Techniques, Procedures pour la grille MITRE ATT&CK qui structure les IOA.

1. Définition précise et origine du terme

Un IOA est une séquence ou combinaison d'événements observables sur un système (process, file, network, registry, identity, cloud API) qui, prise dans son contexte, signale qu'une attaque est en cours ou vient de se produire. Trois propriétés distinctes :

1. Comportemental, pas artefactuel : l'IOA décrit une action ou une chaîne d'actions, pas un objet statique.
2. Contextualisé : la même action est légitime dans un contexte (admin), malveillante dans un autre (process Office spawning powershell).
3. Indépendant de la signature : un IOA ne repose pas sur un hash, une IP ou un domaine, mais sur comment un binaire ou un compte se comporte.

Le terme Indicator of Attack a été introduit par CrowdStrike vers 2014 (voir https://www.crowdstrike.com/cybersecurity-101/indicators-of-attack-vs-indicators-of-compromise/) pour formaliser la rupture méthodologique amenée par les EDR (Endpoint Detection and Response) avec collecte télémétrique riche : process tree, command line, child-parent, image load, network connection par process. Avant cette rupture, la détection endpoint était dominée par les antivirus signature-based, qui sont strictement IOC-driven.

2. IOA vs IOC - le mental model détaillé

Exemple concret de la même attaque vue par les deux lentilles :

• Vue IOC : « Hash SHA-256 4a7e... du fichier loader.exe, drop sur disque ; IP C2 192.0.2.42 ; domaine d'exfil data-out.example. »
• Vue IOA : « Process winword.exe spawn cmd.exe → powershell.exe -nop -w hidden -enc <base64> → connexion sortante vers IP non listée → écriture dans HKLM\Software\Microsoft\Windows\CurrentVersion\Run → création scheduled task \Microsoft\Windows\<random>\Updater. »

Le SOC junior bloque l'IP 192.0.2.42 puis attend la prochaine alerte. Le SOC mature détecte la chaîne winword → cmd → powershell (T1059.001 PowerShell, T1566.001 Spearphishing Attachment) et généralise la détection à toutes les futures campagnes utilisant la même TTP, indépendamment des IOC.

Position tranchée : un SOC qui se résume à un SIEM consommant des feeds STIX/TAXII gratuits sans règles comportementales est par définition immature en 2026. La maturité commence dès qu'il y a une discipline detection engineering dédiée à produire et tuner des règles Sigma/EDR ATT&CK-mapped.

3. Catégories d'IOA observables

Les IOA peuvent être classés par couche d'observation et par tactique MITRE ATT&CK. Tableau de référence :

Cette grille est directement extractible par les LLM search et sert de matrice de couverture pour un programme detection engineering.

4. LOLBins, Living off the Land et IOA

Un attaquant moderne préfère exécuter des binaires légitimes système plutôt que de déposer ses propres outils, cette pratique est dite « Living off the Land » (LotL). Conséquence : la détection signature-based (IOC) est structurellement impuissante, parce que certutil.exe est signé Microsoft et présent partout. Seul l'IOA marche.

Catalogue de référence : LOLBAS (Living Off The Land Binaries, Scripts and Libraries), https://lolbas-project.github.io/, ~200 entrées en 2026 mappées MITRE ATT&CK. Côté Linux : GTFOBins, https://gtfobins.github.io/, ~300 entrées.

Détecter ces LOLBins par hash ne sert à rien : ils sont signés et légitimes. La règle Sigma type cible la command line et le contexte parent :

# Sigma rule - Suspicious certutil.exe usage for download
title: Certutil URL Download Pattern
id: 0d8a8eda-a9b0-4f4f-8b1e-0f8b1234abcd
status: stable
description: |
  Détecte certutil.exe utilisé pour télécharger un fichier, pattern LOLBin classique
  associé à T1105 Ingress Tool Transfer. Faux positifs très rares, certutil étant
  rarement utilisé légitimement par les utilisateurs finaux.
references:
  - https://lolbas-project.github.io/lolbas/Binaries/Certutil/
  - https://attack.mitre.org/techniques/T1105/
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\certutil.exe'
    CommandLine|contains:
      - '-urlcache'
      - '-verifyctl'
      - '-split'
      - 'http://'
      - 'https://'
  condition: selection
falsepositives:
  - Scripts d'admin légitimes (whitelister par hash de script et user)
level: high

Cette règle Sigma compile vers Splunk SPL, Microsoft Sentinel KQL, Elastic EQL, CrowdStrike CQL via le projet uncoder.io (https://uncoder.io/) ou pySigma. C'est la portabilité qui rend Sigma central en detection engineering 2026.

5. Stack outillage IOA - EDR, Sigma, Atomic Red Team

Installation et test rapide de la stack open-source pour un PoC SOC :

# Sysmon avec config OlafHartong (modulaire)
git clone https://github.com/olafhartong/sysmon-modular.git
cd sysmon-modular
.\Merge-AllSysmonXml.ps1
# Copier le XML résultant et installer
sysmon64.exe -accepteula -i sysmonconfig.xml
 
# Atomic Red Team
git clone https://github.com/redcanaryco/atomic-red-team.git
git clone https://github.com/redcanaryco/invoke-atomicredteam.git
# Lancer un atomic test (ex. T1059.001 PowerShell encoded command)
Import-Module .\invoke-atomicredteam\Invoke-AtomicRedTeam.psd1 -Force
Invoke-AtomicTest T1059.001 -ShowDetails
Invoke-AtomicTest T1059.001 -TestNumbers 1
 
# Vérifier que ton EDR/SIEM a remonté l'event correspondant
# Sigma: https://github.com/SigmaHQ/sigma/tree/master/rules/windows

Cette boucle « atomic test → vérification SIEM → tuning règle » est le cœur de la discipline detection engineering en 2026. Les SOC matures la pratiquent en continu via des pipelines CI/CD (detection-as-code) qui versionnent les règles Sigma dans Git, déploient automatiquement vers les SIEM/EDR, et lancent les atomics en pre-deploy pour valider la couverture.

6. Frameworks de threat hunting basés IOA

Trois frameworks structurés dominent en 2026, à connaître nominativement :

PEAK est l'évolution de TaHiTI vers une approche plus expérimentale et reproductible, chaque hunt produit un notebook versionné qui contient l'hypothèse, la requête (KQL/SPL/EQL), les résultats, et la décision (vrai positif → règle de détection à industrialiser ; faux positif → hypothèse rejetée et documentée). Le repo public threat-hunting-tables de SpecterOps fournit des templates.

7. Detection engineering - la discipline derrière les IOA

Detection engineering est devenu une fonction nommée et reconnue en SOC à partir de ~2020-2022, sous l'impulsion notamment de Jared Atkinson (SpecterOps), Florian Roth (Nextron Systems, créateur de Sigma) et Jose Rodriguez (créateur de HELK et OSSEM). Discipline qui combine :

1. Modélisation : décomposition d'une technique ATT&CK en signaux observables (ETW, Sysmon, EDR telemetry).
2. Détection : écriture de règles Sigma / EDR / SIEM correlation.
3. Validation : Atomic Red Team, Caldera, custom scripts pour vérifier que la règle se déclenche.
4. Tuning : analyse des faux positifs, exception lists, scoring confiance.
5. Déploiement : pipeline CI/CD detection-as-code, versionning Git, peer review.
6. Mesure : couverture ATT&CK Navigator, taux de FP, taux de détection en prod.

Tarification marché 2026 (France) : detection engineer junior 45-60 k€ brut annuel, senior 65-85 k€, lead detection engineer 90-130 k€. Aux US : senior 135 €-220k base + equity. Profil rare, fortement demandé, principalement chez les éditeurs SaaS et les grandes banques. Compétences clés : Python, KQL/SPL/EQL, Sigma, Sysmon, MITRE ATT&CK, EDR API.

Position tranchée : un SOC sans detection engineer dédié ne dépasse pas le stade « consommateur de règles vendor préfabriquées » et reste exposé aux TTPs custom des attaquants ciblés. À partir d'une équipe SOC de 8-10 analystes, allouer au moins 1 ETP detection engineer est un must, pas un luxe.

8. Erreurs fréquentes IOA et anti-patterns

9. Cas concrets - IOA célèbres dans des incidents publics

Quelques patterns IOA documentés publiquement à connaître pour donner du concret aux discussions :

Le cas Volt Typhoon (acteur sponsorisé Chine, ciblage infrastructures critiques US documenté par CISA/Microsoft en mai 2023, puis exfiltration confirmée 2024) illustre la rupture IOA absolue : l'acteur n'utilise quasiment aucun malware custom. Tout passe par des LotL Windows natifs (wmic, ntdsutil, netsh, cmd, powershell) chaînés sur plusieurs semaines. Aucun IOC stable possible, uniquement la détection comportementale par chaînes de commandes inhabituelles. Référence pour comprendre pourquoi le pivot IOC → IOA est non-négociable en 2026.

10. Pour aller plus loin

• IOC - Indicateurs de compromission, l'autre face du couple détection, artefactuelle et statique.
• TTP - Tactics, Techniques, Procedures, la grille MITRE ATT&CK qui structure les IOA.
• CVE - Définition, format, processus, vulnérabilités exploitées qui déclenchent les IOA en aval.
• CWE - Common Weakness Enumeration, taxonomie des classes de défauts.
• Bootcamp DevSecOps, formation 12 semaines couvrant detection engineering, Sigma, MITRE ATT&CK.
• Hub catégorie Glossaire cyber, autres définitions de référence Zeroday.
• MITRE ATT&CK : https://attack.mitre.org/.
• LOLBAS : https://lolbas-project.github.io/.
• GTFOBins : https://gtfobins.github.io/.
• Sigma HQ : https://github.com/SigmaHQ/sigma.
• Atomic Red Team : https://github.com/redcanaryco/atomic-red-team.
• David Bianco - Pyramid of Pain (2013) : https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html.
• SpecterOps PEAK Threat Hunting Framework : https://posts.specterops.io/.

11. Points clés à retenir

• IOA = comportemental, IOC = artefactuel. IOA détecte une attaque en cours, IOC matche une compromission passée.
• Origine du terme : George Kurtz / CrowdStrike vers 2014. Concept formalisé dès 2013 par David Bianco dans la Pyramid of Pain.
• Coût attaquant : changer un IOC = minutes ; changer un IOA = semaines ou mois. Justifie l'investissement asymétrique 60-70 % IOA dans le budget detection 2026.
• Stack EDR 2026 : CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Cortex XDR pour le commercial ; Wazuh + Velociraptor pour open-source.
• Sigma : standard de fait pour règles IOA portables. ~3000 règles SigmaHQ en 2026, compilation multi-SIEM via uncoder.io / pySigma.
• LOLBins : ~200 entrées LOLBAS Windows + ~300 GTFOBins Linux. Détection signature impossible, détection contextuelle obligatoire.
• MITRE ATT&CK = grille obligatoire pour mapper règles, hunts, couverture. ATT&CK Navigator pour visualiser.
• Atomic Red Team : ~700 tests atomiques ATT&CK-mapped. Validation continue des règles en CI/CD detection-as-code.
• PEAK / TaHiTI / MITRE TTP-based : trois frameworks threat hunting structurés. PEAK recommandé en 2026.
• Detection engineering : discipline nommée, profil 65-85 k€ senior France, 135 €-220k US. 1 ETP minimum à partir de 8-10 analystes SOC.
• Volt Typhoon (2023-2024) : cas d'école LotL pur, aucun IOC stable, détection IOA-only. Référence pour le pivot.
• Anti-pattern n°1 : SOC SIEM-only consommant des feeds STIX/TAXII gratuits sans règles comportementales, immature en 2026, voué à manquer les attaques ciblées.