MITRE ATT&CK Exfiltration (TA0010) : le guide pour les défenseurs

Une idée reçue revient souvent en comité : si la matrice MITRE ATT&CK est verte sur la tactique Exfiltration (TA0010), les fuites seraient couvertes. En pratique, les choses sont différentes. Une case verte dit qu’une règle existe quelque part. Elle ne dit pas si cette règle bloque le fichier qui part ce mardi, depuis tel poste, par tel canal.

Dans MITRE ATT&CK, la tactique Exfiltration (identifiant TA0010) regroupe les techniques qu’un attaquant emploie pour sortir des données de votre réseau. MITRE la résume sobrement : l’adversaire cherche à voler des données.

Pas de recette d’attaque ici. Nous prenons TA0010 comme une grille, pour voir où vos contrôles ont des trous et quoi tester en premier. Pour la méthode générale, voyez notre page sur le test d’exfiltration de données.

Ce que contient TA0010

À la date de rédaction, en octobre 2026, la page officielle de la tactique sur attack.mitre.org liste neuf techniques, dont plusieurs ont des sous-techniques. Le référentiel change à chaque version, en général deux fois par an : vérifiez la liste avant de figer une matrice de couverture. Voici la version actuelle, lue côté défense.

Faites défiler le tableau →

Lire TA0010 en familles plutôt qu’en lignes

1. Les canaux réseau

T1041 et T1048 relèvent du filtrage sortant, du proxy et de la supervision réseau. Ce qui nous intéresse, c’est ce que le pare-feu laisse sortir ; sa configuration, vous la connaissez déjà. D’ailleurs, deux angles morts reviennent souvent, le DNS et le trafic chiffré. Chacun a son article : exfiltration via DNS et limites de l’inspection TLS.

2. Les services cloud et SaaS

T1567 et T1537 sont les plus difficiles à traiter, parce que les destinations sont légitimes. Bloquer le stockage grand public ? Franchement difficile quand le même éditeur, Microsoft ou Google par exemple, héberge à la fois vos outils internes et les comptes personnels de vos salariés. Ici, le nom de domaine ne vous aide pas. La DLP doit regarder ce qui part, et vers quel compte.

3. Le poste de travail et le physique

T1052 et T1011 concernent le poste. Ce sont souvent les premières règles déployées, et les moins retestées. Votre politique USB a trois ans ? A-t-elle survécu aux mises à jour de l’agent et aux exceptions accordées depuis ? Le plus simple reste quand même de brancher une clé sur un poste de chaque profil.

4. Les modificateurs de comportement

T1020, T1030 et T1029 décrivent des manières d’utiliser un canal : automatiser, fractionner, planifier. Concrètement, si une règle arrête un gros fichier mais laisse passer le même fichier découpé en petits morceaux, un attaquant patient la contourne sans effort. Beaucoup de faux négatifs silencieux viennent de là.

De la matrice aux contrôles : une méthode en cinq étapes

1. Inventorier vos contrôles de sortie. DLP endpoint, DLP réseau, proxy, CASB, DLP de messagerie, règles cloud natives. Pour chacun, notez ce qu’il couvre chez vous : postes, flux inspectés.
2. Associer chaque contrôle aux identifiants TA0010. Chez vous, une même technique peut être couverte par deux contrôles, ou par aucun. Les cases vides deviennent votre première liste de travail.
3. Séparer « couvert sur le papier » et « couvert prouvé ». Une case cochée parce qu’une règle existe reste une hypothèse tant qu’aucun scénario n’a été rejoué contre elle.
4. Rejouer les scénarios avec des données synthétiques. Nos campagnes enchaînent découverte, collecte, préparation, automatisation et exfiltration, comme un opérateur réel, mais avec des leurres : faux numéros, faux documents marqués. Les premières étapes relèvent des tactiques Discovery (TA0007) et Collection (TA0009). Voir l’article sur les données synthétiques en production.
5. Mesurer dans le temps. Une couverture constatée en janvier peut tomber en mars après une migration ou une mise à jour d’agent. Avec Enforcis, chaque campagne produit un résultat daté. Les prochaines versions permettront de programmer des rejeux périodiques ou déclenchés par un changement, selon la criticité du périmètre et la fraîcheur attendue de la preuve.

Un scénario concret, vu du défenseur

Exemple : une fintech a déployé une DLP endpoint et un proxy filtrant. Sa matrice affiche T1052, T1048 et T1567 comme couverts. Le RSSI demande quand même un test.

Résultat plausible : le blocage USB fonctionne sur les postes Windows gérés, mais pas sur ceux d’une filiale restés sur un autre profil d’agent. Le proxy bloque les gros envois vers le stockage grand public, sauf qu’un fichier synthétique fractionné passe (T1567 combiné à T1030). Côté SOC, l’alerte arrive pour un cas sur trois, sans escalade.

Aucune de ces failles n’apparaissait dans la console : c’est là tout le piège. La correction est souvent simple : harmoniser un profil, abaisser un seuil cumulé, ajouter une règle de corrélation. Encore faut-il savoir par où commencer. Les résultats Enforcis se lisent aujourd’hui en 3 états (Bloqué, Détecté sans blocage, Non détecté), scénario par scénario. Les prochaines versions apporteront un reporting à plusieurs niveaux (direction, RSSI, opérations), avec des correspondances MITRE ATT&CK et, lorsque la correspondance est établie, MITRE D3FEND, ainsi que des intégrations SIEM.

Checklist rapide pour votre matrice TA0010

• Chaque technique de la liste officielle à jour a au moins un de vos contrôles en face.
• Chaque association a été testée par rejeu, avec sa date de dernier test.
• Les sous-techniques sont traitées séparément quand le contrôle diffère : T1567.002 (stockage cloud) et T1567.001 (dépôt de code) ne se filtrent pas pareil.
• Les modificateurs (T1020, T1030, T1029) sont testés en combinaison avec un canal.
• Vous vérifiez la détection en plus du blocage : alerte générée, reçue, traitée.
• Les résultats débouchent sur une liste d’actions classées, en plus du score de couverture.

Les limites d’ATT&CK pour la prévention des fuites

FAQ