DGFiP : pourquoi changer le mot de passe ne suffit pas toujours à arrêter une attaque

Le 29 septembre 2026, l’ANSSI a rendu public son rapport d’incident sur les cyberattaques ayant touché la Direction générale des Finances publiques pendant l’été.1

Le document est intéressant moins par la sophistication technique de l’attaque que par la combinaison de faiblesses qu’il met en évidence. L’ANSSI les regroupe autour de trois domaines : identité, architecture et détection.

Cette lecture apporte une leçon utile bien au-delà de la DGFiP : lorsqu’un attaquant utilise des identifiants valides et des chemins d’accès autorisés, chaque composant peut considérer localement l’activité comme légitime alors que la chaîne complète est anormale.

Un identifiant valide ne signifie pas un utilisateur légitime

Le communiqué initial du ministère indiquait déjà que les accès illégitimes reposaient sur l’usurpation d’identifiants d’un agent de la DGFiP et d’un tiers habilité.3

Le rapport d’incident va plus loin en décrivant un volume important de couples identifiant-mot de passe à la disposition de l’attaquant.1

Pour un système d’authentification, la difficulté est fondamentale : un mot de passe correct ne permet pas, à lui seul, de distinguer son propriétaire d’un attaquant qui l’a récupéré.

La question opérationnelle n’est donc plus seulement :

« ce compte est-il autorisé ? »

mais :

« cette utilisation du compte est-elle cohérente avec son contexte habituel ? »

Localisation, horaire, terminal, adresse IP, fréquence des connexions et volumes consultés deviennent alors des éléments de sécurité à part entière.

Compte, mot de passe et session sont trois objets différents

Lors d’une compromission, le premier réflexe est souvent de réinitialiser le mot de passe ou de désactiver le compte.

C’est indispensable, mais l’architecture moderne comporte d’autres objets de confiance : sessions actives, cookies, jetons d’accès, fédérations d’identité, rôles temporaires ou connexions déjà établies.

Une représentation utile distingue donc :

identité → authentification → session → portail → application → données

Couper un élément de cette chaîne ne garantit pas automatiquement que tous les éléments situés en aval cessent de fonctionner.

Le bon exercice de réponse à incident consiste à demander, pour chaque mécanisme : qui l’émet ? combien de temps reste-t-il valide ? comment est-il révoqué ? quelles applications lui font confiance ?

L’architecture transforme un compte compromis en chemin d’attaque

Un identifiant volé n’a de valeur que s’il permet d’atteindre quelque chose.

C’est ici que la deuxième faiblesse décrite par l’ANSSI devient essentielle : l’architecture.

Le rapport relève des accès possibles à des infrastructures sensibles depuis des réseaux ou portails qui ont servi de point d’entrée ou de rebond.1

Une analyse limitée au compte répond à :

« qui s’est connecté ? »

Une analyse architecturale doit aussi répondre à :

« que pouvait atteindre cette identité une fois connectée ? »

La représentation pertinente devient alors un graphe :

compte → portail → réseau → application → jeu de données

auquel on ajoute les contrôles :

MFA → filtrage → cloisonnement → autorisation → journalisation

C’est le chemin complet qui détermine l’impact potentiel.

Le troisième angle mort : voir chaque événement sans voir l’histoire

Le rapport de l’ANSSI insiste également sur la détection.

Des signaux existaient, mais les capacités de supervision ne couvraient pas nécessairement tous les composants utiles à la reconstruction de l’activité.1

C’est un problème fréquent : une organisation peut disposer de nombreux journaux sans disposer d’une chronologie exploitable de bout en bout.

Un portail enregistre une connexion.

Une application enregistre des consultations.

Un équipement réseau observe des flux.

Un SIEM reçoit une partie de ces événements.

Pris séparément, chacun peut sembler acceptable.

Corrélés, ils peuvent raconter une histoire très différente.

La question à poser au SOC devient donc :

« pouvons-nous suivre une même identité du point d’entrée jusqu’à la donnée consultée ? »

La cartographie utile pendant un incident n’est pas un dessin statique

Pour répondre rapidement, il faut pouvoir relier au minimum cinq familles d’objets :

Identités : comptes, groupes, rôles, tiers habilités.

Points d’accès : VPN, portails, bastions, fédérations.

Composants : applications, serveurs, API, réseaux.

Données : jeux de données et fonctions métier accessibles.

Télémétrie : journaux disponibles, sondes, SIEM et propriétaires de ces traces.

Une cartographie qui représente uniquement les serveurs ne répond pas à l’incident.

Une cartographie qui représente uniquement les identités non plus.

Il faut relier qui peut entrer, par où, vers quoi, avec quelle autorisation et avec quelle capacité de détection.

Cas pratique : un compte compromis

Prenons un scénario fictif inspiré uniquement des catégories de faiblesse décrites par l’ANSSI, sans prétendre reproduire l’architecture réelle de la DGFiP.

Un attaquant récupère les identifiants d’un utilisateur habilité.

Il se connecte à un portail exposé.

Le portail lui donne accès à une application métier.

L’application autorise la consultation d’un jeu de données important.

Le chemin est :

identifiants → portail → session → application → données

Ajoutons la supervision :

portail → journal A

application → journal B

réseau → sonde C

journaux A + B + C → SIEM

Trois questions deviennent immédiatement testables.

Premièrement : la révocation du compte invalide-t-elle toutes les sessions existantes ?

Deuxièmement : le portail permet-il d’atteindre plus d’applications que nécessaire ?

Troisièmement : les journaux permettent-ils de corréler connexion, navigation et extraction ?

Ce sont trois questions différentes, correspondant précisément aux dimensions identité, architecture et détection.

Tester la réponse avant l’incident

Le rapport DGFiP fournit une bonne base pour un exercice simple.

Choisissez un compte disposant d’un accès sensible et simulez sa compromission.

Test 1 — Identité : pouvez-vous désactiver le compte et invalider rapidement toutes ses sessions et autorisations dérivées ?

Test 2 — Architecture : pouvez-vous lister en quelques minutes toutes les applications et données accessibles depuis son point d’entrée ?

Test 3 — Détection : pouvez-vous reconstruire sa chronologie sur plusieurs composants sans demander manuellement des journaux à cinq équipes différentes ?

Test 4 — Responsabilité : savez-vous qui doit agir sur chacun des composants du chemin ?

Si l’une de ces réponses demande plusieurs heures d’investigation, l’organisation possède peut-être les informations, mais pas encore la visibilité opérationnelle nécessaire.

L’enseignement dépasse la DGFiP

Après les violations de données touchant les services de l’État, l’ANSSI a renforcé en septembre son dispositif REACTIV, centré notamment sur les compromissions de comptes utilisateurs et les exfiltrations.4

Le point important pour les autres organisations n’est pas de transposer mécaniquement l’incident DGFiP.

C’est d’en retenir une méthode.

Une compromission d’identité devient dangereuse lorsqu’elle rencontre une architecture qui lui offre un chemin, puis une supervision qui ne relie pas suffisamment les événements.

Autrement dit :

identité compromise + chemin accessible + visibilité incomplète = risque d’exfiltration difficile à détecter.

La défense doit donc être pensée avec le même niveau de continuité que l’attaque.

Le compte n’est que le début du chemin.