Groupes APT : de la fiche MITRE ATT&CK à des priorités de détection

APT28, Midnight Blizzard, Volt Typhoon, Scattered Spider : les noms de groupes d’attaquants font les gros titres, mais que faire de ces fiches quand on défend un système d’information ? Nous avons analysé les 176 groupes de la base MITRE ATT&CK Enterprise pour répondre à une question pratique : quelles techniques détecter en premier, et comment passer d’un nom de groupe à une règle de détection.

Un « groupe », c’est quoi exactement ?

Dans ATT&CK, un groupe est un ensemble d’activités que la communauté suit sous un nom commun : mêmes outils, mêmes infrastructures, mêmes habitudes. Ce n’est pas forcément une organisation précise. L’ANSSI parle d’ailleurs de mode opératoire d’attaque plutôt que de groupe, précisément pour ne pas confondre une signature technique observée et une équipe humaine.

Trois conséquences pratiques :

  • Un même acteur a plusieurs noms. Chaque éditeur nomme ce qu’il observe. APT29 est aussi Cozy Bear, NOBELIUM, Midnight Blizzard, Dark Halo ou IRON RITUAL selon la source ; Lazarus Group est aussi Diamond Sleet, ZINC ou HIDDEN COBRA. Depuis 2023, Microsoft nomme les acteurs d’après la météo : Blizzard pour la Russie, Typhoon pour la Chine, Sandstorm pour l’Iran, Sleet pour la Corée du Nord, Tempest pour les groupes financiers ;
  • Les correspondances sont approximatives. Deux éditeurs peuvent regrouper différemment les mêmes intrusions : « X = Y » veut souvent dire « X recoupe largement Y » ;
  • L’attribution est un autre métier. Relier un mode opératoire à un État relève d’une décision politique fondée sur du renseignement, pas d’une signature. Côté défense, on n’a presque jamais besoin de savoir qui ; on a besoin de savoir comment.

Ce que 176 groupes ont en commun

Nous avons extrait du bundle STIX officiel d’ATT&CK Enterprise (données de septembre 2026) toutes les techniques documentées pour chaque groupe, puis compté combien de groupes utilisent chacune. 172 groupes sur 176 ont au moins une technique documentée.

Graphique : les 15 techniques les plus partagées, de T1105 (88 groupes) à T1070.004 (47 groupes)
Nombre de groupes chez qui chaque technique est documentée dans ATT&CK Enterprise.

Plusieurs enseignements ressortent :

  • L’exécution passe par les interpréteurs du système. Au niveau technique parent, « Command and Scripting Interpreter » (T1059) est documentée chez 124 groupes, dont PowerShell chez 85 et l’invite de commandes chez 73. Journaliser PowerShell (Script Block Logging) et les lignes de commande est le meilleur rapport effort/couverture qui existe ;
  • L’entrée reste humaine. Exécution par l’utilisateur (T1204, 99 groupes) et hameçonnage (T1566, 98 groupes) : un fichier ou un lien piégé reste le point de départ le plus documenté ;
  • Les attaquants se déguisent. Imitation de noms ou chemins légitimes (T1036.005, 63 groupes), offuscation (T1027, 93 groupes au niveau parent) : chercher « svchost.exe » hors de System32 reste une détection rentable ;
  • La persistance est banale. Clés Run (57 groupes) et tâches planifiées (54 groupes) : des mécanismes simples, visibles, et donc détectables si l’on regarde ;
  • Les comptes valides (T1078, 66 groupes au niveau parent) rappellent qu’une partie des intrusions ne déclenche aucune alerte « malware ».

Les outils, eux aussi, sont partagés

OutilGroupesNature
Mimikatz51extraction d’identifiants (LSASS, Kerberos)
PsExec38exécution à distance (Sysinternals, légitime)
Net33commande Windows native (découverte, comptes)
Cobalt Strike30cadriciel d’intrusion commercial, très piraté
Impacket18bibliothèque Python pour SMB, WMI, Kerberos
AdFind12requêtes LDAP sur Active Directory
Rclone9synchronisation cloud, utilisée pour l’exfiltration

La moitié de ces outils sont des logiciels légitimes ou des commandes natives. C’est la logique du « living off the land » : bloquer l’outil est souvent impossible, il faut détecter l’usage anormal (PsExec lancé depuis un poste utilisateur, Rclone vers un stockage cloud inconnu, AdFind exécuté par un compte non administrateur).

Un biais à garder en tête : ces chiffres mesurent ce qui a été publié, pas ce qui se passe réellement. Les groupes les plus étudiés, les environnements Windows et les techniques faciles à observer sont surreprésentés. C’est une carte de ce que la communauté a vu, pas un sondage des attaques.

Quatre profils, quatre leçons de détection

APT28 : le cas français

Le CERT-FR a publié le 29 avril 2025 un rapport sur le ciblage d’entités françaises par le mode opératoire APT28, observé entre 2021 et 2024 par l’ANSSI et ses partenaires. En 2024, les victimes françaises relevaient des secteurs gouvernemental, diplomatique et de la recherche. Le même jour, la France a publiquement attribué ce mode opératoire au renseignement militaire russe. Le rapport détaille plusieurs chaînes d’infection et fournit des indicateurs : c’est la source à privilégier pour un défenseur en France.

APT29 / Midnight Blizzard : l’identité avant tout

En janvier 2024, Microsoft a révélé qu’APT29 avait obtenu l’accès à des boîtes mail de dirigeants par une attaque par pulvérisation de mots de passe sur un ancien compte de test sans MFA, puis via une application OAuth disposant de droits élevés. Aucun malware sophistiqué : un compte oublié et une application trop privilégiée. Leçon : inventorier les comptes de test et les applications OAuth, et alerter sur les pulvérisations de mots de passe (nombreux échecs sur de nombreux comptes depuis une même source).

Volt Typhoon : rien à détecter… sauf le comportement

L’avis AA24-038A (CISA et partenaires, février 2024) décrit un acteur qui se pré-positionne dans des infrastructures critiques en n’utilisant presque que des outils natifs : wmic, ntdsutil pour copier la base Active Directory, netsh pour des redirections de ports, et des routeurs domestiques compromis comme relais. Aucune signature de malware ne l’arrête ; seules des lignes de base comportementales le peuvent (qui exécute ntdsutil ? pourquoi ce serveur ouvre-t-il un proxy de ports ?).

Scattered Spider : le centre d’assistance comme porte d’entrée

L’avis AA23-320A (novembre 2023, mis à jour en 2025) décrit des attaquants qui appellent le centre d’assistance en se faisant passer pour un salarié, obtiennent une réinitialisation du MFA, puis installent des outils de prise en main à distance légitimes. Leçon : la procédure de réinitialisation du MFA est un contrôle de sécurité, et l’installation d’un outil de télémaintenance non approuvé doit déclencher une alerte.

Méthode : de la fiche de groupe à la règle de détection

  1. Choisir les groupes pertinents. Pas les 176 : ceux qui visent votre secteur et votre région, d’après les rapports du CERT-FR, de votre CERT sectoriel et les descriptions ATT&CK. Cinq à dix groupes suffisent ;
  2. Superposer leurs techniques. Une technique partagée par plusieurs de ces groupes (et par beaucoup de groupes en général) passe en tête de liste ;
  3. Confronter à votre couverture. Pour chaque technique prioritaire : avez-vous la télémétrie (journaux, EDR) ? une règle ? une règle testée ? L’écart entre les trois est votre feuille de route ;
  4. Écrire et tester. Une règle par comportement, testée par une simulation (Atomic Red Team, Caldera) avant d’être déclarée opérationnelle ;
  5. Recommencer à chaque nouveau rapport. Les groupes changent d’outils plus vite que de comportements : les techniques évoluent lentement, les indicateurs très vite.

Construire le calque Navigator

L’outil ATT&CK Navigator affiche la matrice avec un score par technique. Ce script Python (bibliothèque standard uniquement) produit un calque « nombre de groupes par technique » à partir du bundle STIX officiel, à charger dans Navigator via Open Existing Layer :

#!/usr/bin/env python3
# Télécharger d'abord : https://raw.githubusercontent.com/mitre/cti/master/enterprise-attack/enterprise-attack.json
import json, collections

bundle = json.load(open("enterprise-attack.json"))
objs = {o["id"]: o for o in bundle["objects"]}
actif = lambda o: not o.get("revoked") and not o.get("x_mitre_deprecated")
ext_id = lambda o: next(r["external_id"] for r in o["external_references"] if r.get("source_name") == "mitre-attack")

paires = set()
for r in bundle["objects"]:
    if r["type"] == "relationship" and r["relationship_type"] == "uses" and actif(r):
        src, dst = objs.get(r["source_ref"]), objs.get(r["target_ref"])
        if src and dst and src["type"] == "intrusion-set" and dst["type"] == "attack-pattern" and actif(src) and actif(dst):
            paires.add((src["id"], ext_id(dst)))

score = collections.Counter(tid for _, tid in paires)
layer = {
    "name": "Techniques partagées par les groupes",
    "domain": "enterprise-attack",
    "versions": {"layer": "4.5"},
    "techniques": [{"techniqueID": t, "score": n} for t, n in score.items()],
    "gradient": {"colors": ["#ffffff", "#ff6666"], "minValue": 0, "maxValue": max(score.values())},
}
json.dump(layer, open("calque-groupes.json", "w"), indent=1)
print(score.most_common(10))

Pour restreindre à vos groupes prioritaires, filtrer src["name"] sur une liste de noms. Le projet Top ATT&CK Techniques du Center for Threat-Informed Defense propose une approche plus fine, qui pondère aussi la facilité de détection et l’impact.

Une règle Sigma pour la persistance par tâche planifiée

Sigma est un format de règles indépendant du SIEM, convertible vers Splunk, Elastic, Sentinel ou Wazuh. Exemple ciblant T1053.005 (54 groupes) : une tâche créée en ligne de commande qui exécute un programme situé dans un répertoire inscriptible par l’utilisateur.

title: Tâche planifiée créée vers un répertoire inscriptible par l'utilisateur
id: 5b0f5d2e-7c1a-4c3e-9f7e-2a6d8b1c4e90
status: experimental
description: Création d'une tâche planifiée par schtasks.exe pointant vers AppData, Temp, Public ou ProgramData.
references:
  - https://attack.mitre.org/techniques/T1053/005/
tags:
  - attack.persistence
  - attack.t1053.005
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: 'schtasks.exe'
    CommandLine|contains: '/create'
  chemin_suspect:
    CommandLine|contains:
      - 'AppData'
      - 'Temp'
      - 'UsersPublic'
      - 'ProgramData'
  condition: selection and chemin_suspect
falsepositives:
  - Installateurs et agents de mise à jour légitimes (à exclure après observation)
level: medium

Le dépôt SigmaHQ contient plusieurs milliers de règles déjà classées par technique ATT&CK : avant d’écrire, chercher le tag de la technique (attack.t1053.005) dans le dépôt. Et pour que ces règles aient quelque chose à lire, il faut la télémétrie : événement 4688 avec ligne de commande, ou Sysmon (événement 1).

Les pièges à éviter

  • Collectionner les indicateurs (adresses IP, empreintes) d’un groupe : ils expirent en jours. Les techniques et comportements durent des années ;
  • Viser 100 % de la matrice : c’est impossible et inutile. Une couverture solide des vingt techniques les plus partagées vaut mieux qu’une couverture théorique de deux cents ;
  • Confondre « technique couverte » et « attaque détectée » : une technique recouvre de nombreuses procédures. Une règle sur schtasks.exe ne voit pas une tâche créée via l’API COM ou PowerShell (Register-ScheduledTask) : d’où l’intérêt de l’événement 4698, qui journalise la tâche elle-même ;
  • Faire de l’attribution à partir d’une technique : 85 groupes utilisent PowerShell. Voir PowerShell ne dit rien de l’auteur.

En résumé

Les fiches de groupes APT sont surtout utiles quand on les agrège. Individuellement, elles racontent une histoire ; ensemble, elles montrent que la majorité des intrusions documentées reposent sur une poignée de techniques banales : interpréteurs de commandes, fichiers piégés, outils légitimes détournés, persistance par clés Run ou tâches planifiées, comptes valides. Bien journaliser et bien détecter ces quelques comportements couvre une large part des groupes connus, quel que soit leur nom du jour.

Transparence : cet article a été rédigé avec l’aide d’un assistant Claude. Les statistiques proviennent de notre propre extraction du bundle ATT&CK Enterprise (licence CC-BY 4.0, MITRE), réalisée en septembre 2026 ; elles évolueront avec les versions d’ATT&CK. La règle Sigma est un exemple à tester avant tout déploiement.

Sources