MITRE ATT&CK Framework, The Practical Way to Use it in 2026 Security Engineering (Le cadre ATT&CK de MITRE, la façon pratique de l'utiliser en 2026)

Ce qu'est MITRE ATT&CK et ce qu'il n'est pas

ATT&CK est un modèle comportemental, pas une base de données de vulnérabilités.

• ATT&CK réponses : Comment les adversaires se comportent-ils lorsqu'ils tentent d'atteindre leurs objectifs ?
• CVE réponses : Quelle est la faiblesse spécifique d'un produit ou d'une version ?

ATT&CK inclut des techniques qui ressemblent à de l'"exploitation", mais l'unité de valeur n'est pas "un bogue". Il s'agit de la chaîne de comportements répétables : accès initial, exécution, accès aux informations d'identification, découverte, mouvement latéral, collecte, exfiltration, impact.

L'ATT&CK ne remplace pas les cadres de travail tels que Kill Chain.

La chaîne de la mort cybernétique est un cadrage du cycle de vie. L'ATT&CK est un catalogue de comportement avec des identifiants, des relations et une structure matricielle vivante. Dans la pratique, les équipes utilisent souvent Kill Chain (ou un outil similaire) comme narratif et ATT&CK comme index d'ingénierie.

Le vocabulaire de base à maîtriser

Le document "Design and Philosophy" de MITRE explique sans détour pourquoi cela est important : les équipes confondent les termes, les correspondances deviennent des déchets et les mesures deviennent du théâtre. Les distinctions ci-dessous sont celles qui permettent au cadre d'être utilisable à grande échelle.

Tactique = le "pourquoi"

Les tactiques représentent l'objectif tactique d'un adversaire, c'est-à-dire la raison d'être d'une action. La page de MITRE sur les tactiques d'entreprise définit les tactiques exactement de cette manière. (MITRE ATT&CK)

Dans l'entreprise ATT&CK, les tactiques sont les colonnes de la matrice - elles couvrent le cycle de vie de l'intrusion, de la reconnaissance à l'impact. (CrowdStrike)

Techniques et sous-techniques = le "comment".

Les techniques sont la façon dont les adversaires réalisent une tactique. Le catalogue de techniques de MITRE décrit les techniques comme le "comment" des objectifs tactiques. (MITRE ATT&CK)

Les sous-techniques rendent le "comment" plus précis (par exemple, le "Phishing" se divise en variantes spécifiques). La raison pratique de s'en préoccuper : une meilleure spécificité produit de meilleures détections et moins de fausses mesures.

Procédures = "ce qui s'est exactement passé dans la nature".

MITRE insiste sur le fait que les procédures sont les mises en œuvre spécifiques et observées que les adversaires ont utilisées, couvrant souvent plusieurs techniques dans une intrusion réelle. (MITRE ATT&CK)

C'est pourquoi l'ATT&CK reste utile même lorsque les outils changent : les procédures évoluent, mais de nombreuses techniques restent stables.

Ce qu'il y a dans l'ATT&CK en 2026, les pièces que les ingénieurs utilisent réellement

Les matrices

MITRE tient à jour des matrices pour plusieurs domaines (entreprise, mobile, ICS). Le domaine de l'entreprise est celui par lequel la plupart des défenseurs commencent. (MITRE ATT&CK)

Les pages techniques

Une page technique n'est pas qu'une simple étiquette. Pour les défenseurs, les champs les plus importants sont les suivants :

• ID de la technique (référence stable pour la cartographie et les mesures)
• Description (ce qu'il faut détecter)
• Exemples de procédures (à quoi ressemblent les véritables intrusions)
• Atténuations (ce qui réduit la probabilité ou l'impact)
• Détections l'orientation (ce que la télémétrie tend à aider)

L'index des techniques d'entreprise de MITRE montre que le champ d'application est vaste et évolutif (plus de 200 techniques), d'où la nécessité d'établir des priorités et des mesures, et non pas de "tout cartographier une fois et de l'oublier". (MITRE ATT&CK)

Les termes à forte intention de clics autour de "mitre attack framework" - et ce qu'ils indiquent

Les résultats de recherche et le comportement des "gens qui demandent aussi" tendent à se regrouper autour d'une poignée de phrases. Vous pouvez les considérer comme une liste de choses à faire :

1. "Matrice ATT&CK de MITRE" Les gens veulent une vue d'ensemble : où vivent les attaques et comment s'alignent leurs contrôles.
2. "tactiques et techniques Les gens veulent du vocabulaire pour que SOC, IR, threat intel, et red team cessent de se parler l'un l'autre.
3. "Cartographie ATT&CK" Les gens veulent relier les détections, les journaux, les alertes, les incidents et les résultats à des identifiants techniques afin que la couverture devienne mesurable.
4. "La chasse aux menaces avec ATT&CK Les gens veulent un moyen reproductible de générer des hypothèses et de chasser les comportements - pas des CIO.
5. "Navigateur ATT&CK Les gens veulent un artefact visuel qu'ils peuvent partager avec leurs dirigeants et leurs pairs, sans aplanir les nuances. Le Navigator de MITRE est conçu exactement pour cela : annoter et explorer les matrices, visualiser la couverture, planifier le travail rouge/bleu. (mitre-attack.github.io)

Cinq flux de travail où l'ATT&CK devient une véritable ingénierie

1 Ingénierie de détection, transformer les règles en couverture

L'objectif n'est pas de parvenir à 3 000 détections. L'objectif est couverture comportementale contre les techniques qui comptent pour votre environnement.

Une boucle d'ingénierie minimale viable se présente comme suit :

1. Inventorier les sources de télémétrie (EDR, journaux Windows, authentification, DNS, proxy, journaux d'audit SaaS, plan de contrôle en nuage).
2. Associer les détections existantes aux identifiants des techniques de l'ATT&CK.
3. Identifier les lacunes techniques à haut risque (sur la base de votre modèle de menace et de vos surfaces exposées).
4. Élaborer des détections et des plans d'action pour combler ces lacunes.
5. Valider en permanence à l'aide de l'émulation ou d'essais contrôlés.

CrowdStrike explique qu'il s'agit de cartographier les alertes/analyses pour mettre en évidence les lacunes dans lesquelles les attaquants peuvent opérer sans déclencher les contrôles existants. (CrowdStrike)

Un format de cartographie qui évolue

Utilisez un objet structuré simple. YAML est courant car il se prête bien à la révision par Git.

detection_id : DET-AD-0012
name : Suspicious Kerberos Ticket Requests, potential credential dumping follow-up
attaque :
  - technique : T1558
    sous-technique : T1558.003
    tactique : Accès aux données d'identification
télémétrie :
  - windows_security_eventlog
  - contrôleur_de_domaine
query_refs :
  - splunk_spl : "index=wineventlog EventCode=4769 ..."
  - kql : "SecurityEvent | where EventID == 4769 ..."
response :
  owner : identity_ir
  playbook : PB-IDENT-004
confidence :
  test_coverage : partial
  known_false_positives : ["comptes de service de sauvegarde"]

Vous remarquerez que cette structure sépare la cartographie du langage de requête. C'est délibéré : les requêtes changent ; les identifiants techniques sont votre index stable.

2 La chasse aux menaces, l'élaboration d'hypothèses à partir des comportements

L'ATT&CK brille lorsque l'on cesse de se demander "Avons-nous ce COI ?" et que l'on commence à se poser des questions :

• Si un adversaire se trouve dans notre environnement, quelle technique utilisera-t-il ensuite ?
• À quoi cela ressemble-t-il dans notre télémétrie ?
• Qu'est-ce qui serait "normal" ou "anormal" pour notre organisation ?

Une approche pratique de la chasse :

• Choisissez une tactique (l'accès aux données d'identification est un choix courant de grande valeur).
• Choisissez de 1 à 3 techniques qui correspondent à la réalité de votre environnement (Windows, Cloud, etc.).
• Définir ce qu'est une "bonne télémétrie".
• Chassez avec des hypothèses testables et limitées dans le temps.
• Convertir les résultats en détections, en listes d'autorisation ou en améliorations de l'exploitation forestière.

3 Réponse aux incidents, transformer les délais en améliorations durables

Après un incident, ATT&CK vous permet de produire un "artefact d'apprentissage" qui n'est pas lié à une famille de logiciels malveillants.

Au lieu d'écrire "Ils ont utilisé l'outil X", vous produisez :

• La chaîne des techniques, avec l'horodatage et les preuves.
• Les lacunes de détection qui ont permis chaque étape.
• Les mesures d'atténuation ou d'abattage qui auraient permis de réduire le temps de séjour.

C'est ainsi que l'on cesse de répéter le même type d'incident tous les trimestres.

4 L'équipe violette et l'émulation, la validation des affirmations de votre matrice

L'ATT&CK est facile à "peindre en vert" sur une diapositive. Il est plus difficile de le prouver.

Une approche adaptée à l'équipe violette :

• Sélectionnez une chaîne de techniques réaliste (5 à 10 étapes).
• Emuler avec des outils sûrs (ou des scripts contrôlés) qui exercent la même télémétrie.
• Valider les détections et le temps de réponse.
• Mettre à jour la couche des navigateurs en se fondant sur des données probantes et non sur l'optimisme.

Le navigateur existe pour rendre ce flux de travail partageable et reproductible. (mitre-attack.github.io)

5 Métriques, prioriser le travail sans se mentir à soi-même

Si vous ne retenez qu'une chose de cet article, retenez ceci :

Les indicateurs ATT&CK n'ont de sens que s'ils sont liés à des preuves.

Une bonne mesure de la couverture n'est pas "nous avons cartographié 70% de techniques".

Une mesure utile est la suivante :

• Pour les 20 techniques les plus utilisées, quelles sont les % détectées par télémétrie de haute fidélité ?
• Combien sont validés par émulation au moins une fois par trimestre ?
• Combien de temps s'écoule-t-il entre l'exécution de la technique, l'alerte et l'endiguement ?

Voici un modèle de tableau que les équipes utilisent réellement.

Couche	Ce que vous mesurez	Artéfact de preuve	Anti-modèle à éviter
Couverture	% de techniques prioritaires avec logique de détection	ID de règles + mappings dans Git	"Cartographié" sans preuve de télémétrie
Qualité	Proxy de précision/rappel	Taux de PF, retour d'information des analystes	Compter les alertes comme des succès
Vitesse	MTTD/MTTR par tactique	Horodatage des incidents	Calcul de la moyenne pour éliminer les valeurs aberrantes
La résilience	Répétabilité en cas de changement	L'émulation fonctionne	Victoires ponctuelles sur table
Risque	Priorité à l'exposition	Inventaire des actifs + surface d'attaque	"Techniques de pointe au niveau mondial" uniquement

Le pont CVE-to-ATT&CK, comment arrêter de traiter les vulnérabilités et les détections comme des mondes séparés

CVE vous indique la porte ; ATT&CK vous indique le chemin

Lorsqu'une vulnérabilité à fort impact apparaît, les équipes font souvent deux choses :

1. Patch (ou mitigation).
2. Ajouter des signatures WAF ou des blocs IOC.

Mais les véritables intrusions ne se font pas en une seule étape. Les attaquants exploitent la porte, puis se comportent.

Le pont le plus simple est le suivant :

• Exploitation de la carte à Accès initial techniques, en particulier T1190 Exploitation d'une application publique. MITRE définit explicitement T1190 comme l'exploitation d'une faiblesse dans un hôte/système orienté vers l'internet pour accéder initialement à un réseau. (MITRE ATT&CK)
• Il convient ensuite d'établir les chaînes de comportement suivantes : exécution, persistance, accès aux informations d'identification, découverte, mouvement latéral, exfiltration, impact.

C'est ainsi que l'on transforme la "panique CVE" en un plan de détection durable.

Trois études de cas CVE, mises en correspondance avec des chaînes de comportement ATT&CK réalistes

Étude de cas 1 Log4Shell CVE-2021-44228, l'histoire canonique "vulnérabilité → intrusion complète".

Pourquoi cela compte encore en 2026 : il s'agit du modèle mental le plus clair sur la rapidité avec laquelle l'exploitation de la vulnérabilité se transforme en un comportement à l'échelle de l'environnement.

Chaîne typique (de haut niveau, non spécifique à un outil) :

• Accès initial : exploitation d'une application destinée au public (T1190)
• Exécution : exécution de la commande par le biais de l'exécution de l'application (correspond souvent à des familles d'exécution de scripts ou d'interprètes en fonction de la plate-forme).
• Persistance : shells web, tâches programmées, installations de services (variable)
• Accès aux données d'identification : déversement de crédits, vol de jetons
• Découverte + Mouvement latéral
• Collecte + Exfiltration
• Impact (parfois ransomware)

Même si vous avez appliqué des correctifs il y a plusieurs années, cette chaîne est le modèle que vous devez réutiliser pour le prochain RCE majeur.

Etude de cas 2 OpenSSH regreSSHion CVE-2024-6387, pourquoi les bogues de "configuration par défaut" sont des cauchemars opérationnels

CVE-2024-6387 ("regreSSHion") est largement documenté comme un problème de race condition dans le serveur d'OpenSSH (sshd), impliquant des appels de fonction non sûrs dans un gestionnaire de signal dans des conditions LoginGraceTime. (Sécurité Palo Alto Networks)

Pourquoi les défenseurs doivent se préoccuper d'autre chose que des correctifs :

• SSH est souvent utilisé pour l'accès à l'administration.
• Les tentatives d'exploitation peuvent ressembler à une tempête d'échecs de l'activité d'authentification et de poignée de main et à un comportement de synchronisation.
• Dès qu'un point d'ancrage existe, les techniques suivantes deviennent prévisibles : accès aux informations d'identification, utilisation de services à distance, mouvements latéraux.

Si votre environnement dispose d'une interface SSH orientée vers l'internet (ou de chemins SSH gérés par le fournisseur), vous ne voulez pas seulement une liste de contrôle des correctifs. Vous voulez :

• Détection du comportement anormal du démon SSH et des rafales
• Durcissement pour réduire la surface d'exposition
• Surveillance post-compromission alignée sur la chaîne technique

Étude de cas 3 Vulnérabilités de réseau et de plate-forme activement exploitées, pourquoi ATT&CK vous donne la structure de triage la plus rapide

En février 2026, de nombreux médias ont attiré l'attention sur un problème critique concernant un contrôleur SD-WAN Cisco Catalyst (CVE-2026-20127), en faisant état d'un historique d'exploitation et d'une gravité élevée, soulignant le risque lorsque les interfaces de gestion sont exposées à l'internet. (TechRadar)

Indépendamment, le catalogue américain CISA KEV est conçu pour répertorier les vulnérabilités présentant des preuves d'exploitation active, et il est continuellement mis à jour. (CISA)

Même si vous ne mémorisez pas chaque nouveau CVE, l'approche ATT&CK reste stable :

• S'il s'agit d'un plan de gestion exposé à l'internet, modélisez-le comme suit Accès initial via l'exploitation
• Prévoir les comportements de suivi
• Utiliser une couche de couverture pour s'assurer que les détections ne sont pas inventées pendant l'incident.

ATT&CK Navigator, transformer votre programme en quelque chose de visible

ATT&CK Navigator de MITRE est un outil en ligne permettant d'annoter et d'explorer les matrices, utilisées pour visualiser la couverture défensive et planifier le travail rouge/bleu. (mitre-attack.github.io)

Une façon pratique de l'utiliser :

• Couche 1 : "Couverture télémétrique" (où se trouvent les journaux)
• Couche 2 : "Couverture de détection" (où vous disposez d'une logique de détection fiable)
• Couche 3 : "Couverture validée" (lorsque vous disposez de preuves d'émulation au cours des 90 derniers jours)

C'est ainsi que l'on évite le mode d'échec le plus courant : une cartographie techniquement correcte mais qui n'a pas de sens sur le plan opérationnel.

Extraction des données ATT&CK via TAXII, un code réel que vous pouvez exécuter

MITRE fournit un point d'accès officiel à l'API ATT&CK TAXII 2.1 (attack-taxii.mitre.org), documenté dans les pages de MITRE sur les ressources et la documentation. (GitHub)

Vous trouverez ci-dessous un exemple en Python qui démontre le flux de travail : se connecter à la racine de l'API TAXII, énumérer les collections, et extraire les objets ATT&CK (vous pouvez l'adapter à vos pipelines internes).

"""
Exemple : Extraire les données STIX d'ATT&CK du serveur TAXII 2.1 de MITRE.
Docs :  (racine de l'API /api/v21/)
"""
from taxii2client.v21 import Server

API_ROOT = ""

server = Server(API_ROOT)
api_roots = server.api_roots
print(f "Racines de l'API : {len(racines_api)}")

root = api_roots[0]
collections = root.collections
print("Collections :")
for c in collections :
  print("-", c.title, c.id)

# Choisissez une collection (vous devrez peut-être choisir Enterprise ATT&CK collection by title)
enterprise = next(c for c in collections if "Enterprise" in (c.title or ""))
col = root.collection(enterprise.id)

# Extraire une petite page d'objets (paginer pour obtenir l'ensemble des données)
bundle = col.get_objects(limit=200)
objets = bundle.get("objets", [])
techniques = [o for o in objects if o.get("type") == "attack-pattern"]
print(f "Objets récupérés={len(objets)} techniques={len(techniques)}")

# Impression de quelques noms de techniques + identifiants externes
pour t dans techniques[:10] :
  ext_refs = t.get("external_references", [])
  tid = next((r.get("external_id") for r in ext_refs if r.get("source_name") == "mitre-attack"), None)
  print(tid, "-", t.get("name"))

Si vous ne souhaitez pas créer votre propre analyseur, l'écosystème de MITRE comprend également des outils et des modèles de données destinés à travailler avec les ensembles de données ATT&CK de manière programmatique. (npm)

Les bribes de détection, des exemples modestes mais réalistes

Exemple de Sigma, modèle suspect de berceau de téléchargement PowerShell

Il ne s'agit pas de "magie ATT&CK". C'est simplement la façon dont les ingénieurs relient les détections aux identifications de techniques et font en sorte qu'elles puissent être examinées.

titre : Berceau de téléchargement PowerShell suspect
id : 2e0a2a4f-xxxx-xxxx-xxxxxxxxxxxx
statut : expérimental
description : Détecte PowerShell invoquant des modèles de berceau de téléchargement communs.
références :
  - 
tags :
  - attack.execution
  - attaque.t1059.001
logsource :
  produit : windows
  catégorie : process_creation
détection :
  sélection :
    Image|endswith : '\\Npowershell.exe'
    CommandLine|contains :
      - 'IEX'
      - DownloadString' (Chaîne de téléchargement)
      - 'Invoke-WebRequest'
      - FromBase64String
  condition : sélection
faux positifs :
  - Scripts d'administration
niveau : moyen

Exemple KQL Microsoft Defender, chaîne d'exécution parent-enfant peu commune

DeviceProcessEvents
| où FileName =~ "powershell.exe"
| where InitiatingProcessFileName in~ ("w3wp.exe", "java.exe", "tomcat*.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

L'important n'est pas de connaître la requête exacte. Il s'agit de maintenir la correspondance stable et vérifiable.

Pour l'ancrage des techniques, il convient de se référer aux définitions des techniques de MITRE lors du choix des identifiants. (MITRE ATT&CK)

ATT&CK est le langage des défenseurs en matière de comportement et de couverture. Mais dans le monde réel, les équipes ont également besoin preuveL'exposition peut-elle être exploitée dans notre environnement, et à quoi ressemble la chaîne de comportement qui en résulte ?

C'est là qu'un flux de travail automatisé et basé sur des preuves est utile. Penligent se présente comme une plateforme de test de pénétration alimentée par l'IA qui automatise la reconnaissance, la validation CVE, l'exploitation, l'escalade des privilèges et le mouvement latéral pour simuler des chaînes d'attaque réalistes. (Penligent)

Une façon pratique de la relier à l'ATT&CK, sans la forcer :

• Utilisez ATT&CK pour définir le chaîne de comportement qui vous tient à cœur (ce qui devrait être détecté).
• Utiliser la validation contrôlée (en laboratoire ou sur des cibles autorisées) pour générer artefacts de preuveLes données de l'enquête sont les suivantes : journaux, traces, délais, et confirmation de l'exploitabilité.
• Alimentez ces artefacts en ingénierie de détection et en manuels d'intervention en cas d'incident.

Penligent a également publié des documents visant à faire le lien entre les "résultats" et les "preuves", notamment des études de cas centrées sur CVE qui illustrent l'importance de la vérification. (Penligent)

Les erreurs courantes qui font échouer les programmes d'ATT&CK

1. Traiter la cartographie comme un projet ponctuel sur tableur S'il ne fait pas l'objet d'un contrôle de version avec ses propriétaires, il meurt.
2. Compter la "couverture" sans la qualité de la télémétrie Si vous ne pouvez pas observer le comportement de manière fiable, vous ne le "couvrez" pas.
3. Cartographie au mauvais niveau de spécificité Des correspondances techniques trop larges cachent des lacunes ; des correspondances trop spécifiques créent une fausse précision. Utilisez des sous-techniques lorsque votre télémétrie le permet.
4. Ignorer les procédures et le contexte La même technique peut sembler bénigne ou malveillante selon le contexte. Ce n'est pas pour rien que MITRE met l'accent sur les procédures. (MITRE ATT&CK)

Références

• MITRE ATT&CK Enterprise Matrix (MITRE ATT&CK)
• MITRE ATT&CK Tactics overview (MITRE ATT&CK)
• MITRE ATT&CK Enterprise Techniques index (MITRE ATT&CK)
• Technique T1190 Exploitation d'une application publique (MITRE ATT&CK)
• MITRE ATT&CK Navigator (mitre-attack.github.io)
• Données et outils MITRE ATT&CK, y compris TAXII (MITRE ATT&CK)
• MITRE ATT&CK Design and Philosophy PDF (MITRE ATT&CK)
• Présentation par CrowdStrike de MITRE ATT&CK et des cas d'utilisation opérationnelle courants (CrowdStrike)
• Définition et champ d'application de Palo Alto Networks Cyberpedia (Palo Alto Networks)
• Microsoft Security "What is MITRE ATT&CK" overview (Microsoft)
• Splunk "MITRE ATT&CK : The Complete Guide" (encadrement orienté praticien) (Splunk)
• Claude Code Security and Penligent, From White-Box Findings to Black-Box Proof (Penligent)
• Vue d'ensemble Penligent.aiL'outil de test de pénétration automatisé (Penligent)
• Exploit DB en 2026, CVE case-study roundup (Penligent)
• The 2026 Ultimate Guide to AI Penetration Testing, agentic red teaming workflows (Penligent)