Novembre 2026 · formation-cybersecurite

La DGFiP a appris sa fuite par son attaquant. Les signaux dormaient depuis 7 semaines

Le 12 août 2026 à 13 h 50, un attaquant publie sur un forum qu'il détient les données de la plateforme impots.gouv.fr. L'Agence nationale de la sécurité des systèmes d'information (ANSSI) prévient la Direction générale des Finances publiques (DGFiP) le même jour, à 16 h 32. Les données étaient sorties 7 semaines plus tôt. Ni la DGFiP ni l'ANSSI ne l'avaient vu. Le rapport d'incident, publié le 29 septembre 2026, ne raconte pas l'exploit d'un attaquant exceptionnel. Il raconte 2 mois pendant lesquels les signaux sont arrivés un par un, et où personne ne les a rapprochés.

Le fait

L'extraction, c'est-à-dire la copie des données vers un serveur extérieur, a duré du 24 juin 2026 à 4 h 26 au 25 juin 2026 à 2 h 31. Elle a porté sur E-Contact, la messagerie qui sert aux échanges entre les usagers et la DGFiP. Une seconde vague a suivi entre le 21 et le 23 juillet 2026, sur la même application. Le 13 août 2026, l'attaquant a revendiqué un autre vol, celui du cadastre, le registre public des propriétés. Ces données ont été copiées entre le 27 juillet et le 8 août 2026, par un autre chemin.

Pour le premier vol, la revendication du 13 août 2026 parle de près de 353 000 particuliers et 252 000 professionnels. Pour le cadastre, le point de situation du CERT-FR, le centre gouvernemental de veille et de réponse aux attaques informatiques, retient environ 434 000 propriétaires.

Le rapport est clair sur la manière dont l'attaque a réussi. Elle n'a rien de sophistiqué. Elle exploite 3 faiblesses. La première concerne les identifiants. Des agents ont utilisé les leurs sur des ordinateurs que la DGFiP n'administrait pas. Et 2 portails ne demandaient pas de second facteur en plus du mot de passe. La deuxième concerne le réseau : des applications sensibles étaient joignables depuis le réseau interministériel de l'État sans séparation entre les réseaux. La troisième concerne la détection : personne ne surveillait l'un des portails utilisés, et aucun outil ne rapprochait les signaux suspects.

Le décor, avant la chronologie

3 choses doivent être connues avant de lire les dates.

Le réseau interministériel de l'État (RIE) relie les ministères entre eux. Une intrusion chez l'un donne donc un point d'appui pour atteindre les autres sans passer par internet. C'est pour cette raison que le ministère de l'Éducation nationale apparaît dans cette affaire.

La DGFiP a 3 portails, et chacun est surveillé séparément. Le PIGP, pour portail internet de la gestion publique, est ouvert sur internet et sert notamment aux agents et aux comptables des collectivités. ADER donne accès à certaines applications de la DGFiP, uniquement depuis le RIE. APEX est réservé aux partenaires extérieurs, notaires et géomètres-experts. L'attaque s'est jouée dans l'écart entre ces 3 surveillances.

La DGFiP paie aussi un prestataire qui surveille les plateformes où se revendent des identifiants volés. Quand un compte de la DGFiP y apparaît, le centre opérationnel de sécurité change le mot de passe, vérifie ce qui s'est passé sur ce compte et prévient l'agent. Tout cela fonctionne, et le rapport le reconnaît. Il ajoute qu'il traite un compte à la fois, et que cela ne suffit pas.

La chronologie, signal par signal

• Du 2 au 8 mai 2026, un compte se connecte depuis 3 lieux différents, dont des adresses situées en Inde et classées comme malveillantes. Personne ne relève. Le 7 mai 2026, le mot de passe de ce compte est changé, mais pour une autre raison, dans le cadre d'un autre dossier suivi par la DGFiP.
• Du 13 au 17 mai 2026, 3 autres comptes sont volés. À partir du 22 mai 2026, l'attaquant s'en sert sur le PIGP depuis des adresses malveillantes. Ces connexions sont enregistrées dans les journaux et ne déclenchent aucune alerte. Les 24 et 25 mai 2026, plusieurs comptes différents se connectent depuis une même adresse IP, c'est-à-dire depuis un même point sur internet. C'est le signe d'une campagne, pas d'un utilisateur distrait. Le mot de passe du compte signalé par le prestataire change le 25 mai 2026. Les connexions suspectes du groupe continuent jusqu'au 3 juin 2026. Le dernier des 3 comptes ne voit son mot de passe changé que le 12 juin 2026, soit 9 jours après son identification.
• Le 7 juin 2026, une alerte est enfin levée, et elle est traitée le jour même. Des recherches inhabituelles dans une messagerie déclenchent l'alerte. Le mot de passe du compte est changé dans la journée. Mais ce compte venait de passer du PIGP à ADER, depuis le RIE. Personne ne le voit, parce que personne ne surveille ADER. La réponse était la bonne, mais elle ne portait que sur un seul portail.
• Le 9 juin 2026, le ministère de l'Éducation nationale entre dans l'histoire. Il est lui-même victime d'une intrusion, et ses systèmes sont raccordés au RIE. Il prévient les équipes de réponse aux incidents de tous les ministères. Il leur transmet 17 marqueurs techniques et leur demande de surveiller les connexions qui viennent de ses adresses. L'une de ces adresses servira 13 jours plus tard à atteindre la DGFiP. L'information a circulé. Personne ne s'en est servi.
• Le 15 juin 2026, un partenaire signale à l'ANSSI 2 comptes de la DGFiP compromis. Le rapport note que la DGFiP ne répond pas, et que l'Agence ne la relance pas. Ces 2 comptes avaient déjà été remis en état les 2 et 9 juin 2026. Personne ne se demande pourquoi un partenaire extérieur les signale encore.
• Du 21 au 23 juin 2026, l'attaquant prépare son extraction. Il se connecte avec un nouveau compte, explore l'application, télécharge une documentation technique, fait une capture d'écran de E-Contact et met au point un outil qui aspire les fiches une par une. Le 23 juin 2026 à 20 h 50, ses recherches déclenchent une alerte, et un ticket est ouvert au centre opérationnel de sécurité.
• Le 24 juin 2026, l'extraction a lieu pendant qu'on traite l'alerte. Elle démarre à 4 h 26 et se poursuit toute la matinée. À 10 h 40, le ticket de la veille est traité et le mot de passe du compte est changé. L'extraction continue. Le rapport précise qu'un changement de mot de passe n'interrompt ni la session ni l'extraction en cours. Elle ne s'arrête qu'à 2 h 31, le 25 juin 2026. Entre le 22 et le 25 juin 2026, 11 Go (gigaoctets) ont circulé sans déclencher la moindre alerte.
• Le 29 juin 2026, un partenaire signale à l'ANSSI le compte qui a servi à l'extraction. La DGFiP répond que le fait est connu et que le compte a été remis en état. Ses propres analyses ne l'avaient pas identifié. Un partenaire extérieur lui apprenait donc que ce compte était compromis, alors qu'elle croyait l'avoir réglé.
• Les 6 et 7 juillet 2026, la même scène se répète. Une alerte est levée sur un compte déjà remis en état le 7 juin 2026. Elle est traitée le lendemain, par un nouveau changement de mot de passe. Rien d'autre ne se passe pendant 2 semaines.
• Du 21 au 24 juillet 2026, l'attaquant reprend 3 Go de données. Il travaille toujours sur E-Contact, avec un autre compte. Les recherches suspectes sont détectées le 23 juillet 2026. Cette fois, le traitement du 24 juillet 2026 ne se limite pas au compte : il bloque aussi l'adresse IP utilisée. C'est la première mesure qui touche autre chose que le compte lui-même.
• Du 6 au 11 août 2026, l'ANSSI trouve la trace en remontant ses propres relevés. Elle identifie 2 adresses IP malveillantes qui visaient des portails de la DGFiP, et prévient la DGFiP le 6 août 2026. La DGFiP répond le 11 août 2026 qu'elle a trouvé des connexions suspectes, changé 5 mots de passe et bloqué les 2 adresses.
• Le 12 août 2026 à 13 h 50, c'est l'attaquant qui annonce la nouvelle. L'ANSSI prévient la DGFiP à 16 h 32. Aucune des 2 extractions n'avait été détectée, ni par la DGFiP, ni par l'ANSSI.
• Le 13 août 2026, le cadastre révèle un second chemin. Un géomètre-expert d'un cabinet privé a vu son ordinateur compromis. Le code de double authentification arrivait par courriel sur ce même ordinateur, et l'attaquant l'a lu. Les données ont été copiées du 27 juillet au 8 août 2026.

Ce que cette liste montre

Reprenez les dates dans l'ordre. Des adresses malveillantes sont repérées dès mai 2026 et ne déclenchent rien. Un compte est remis en état, et les connexions du groupe continuent 3 semaines. Un attaquant change de portail, et personne ne le voit. Un autre ministère transmet 17 marqueurs, et personne ne les applique. 2 partenaires signalent des comptes, et personne ne répond. 4 alertes sont levées et traitées. L'extraction du 24 juin continue pendant l'une d'elles. 11 Go puis 3 Go circulent, et rien ne s'allume.

Aucun de ces signaux n'a manqué. Ce qui a manqué, c'est quelqu'un dont le travail était de les rapprocher. Le rapport le dit noir sur blanc : aucun mécanisme ne reliait les signaux suspects entre eux, alors que plusieurs d'entre eux, pris ensemble, auraient suffi à lever une alerte. Il ajoute que chaque signal, pris seul, produit trop de fausses alertes pour être exploitable. Les outils existaient donc, et chacun produisait sa part d'information. Le problème n'était pas l'outil. Il était dans l'organisation.

Le 24 juin 2026 mérite qu'on s'y arrête. Changer un mot de passe ferme l'accès avec ce mot de passe. Cela ne ferme pas la session déjà ouverte, et cela ne change rien à ce qui se passe sur un autre portail. Le ticket a donc été traité, l'alerte a été refermée, et l'extraction a continué 16 heures. La personne qui a traité le ticket a fait ce qu'on lui demandait. Ce qu'on lui demandait ne réglait pas le problème.

Il reste le cadastre. Un code de double authentification envoyé par courriel sur un ordinateur déjà infecté ne protège rien, puisque l'attaquant lit le code en même temps que le reste. Le rapport le dit, et il recommande un jeton physique ou une application installée sur un autre appareil. Cette remarque vise l'État. Elle vaut aussi pour toutes les entreprises qui ont activé la double authentification pour cocher une case.

En cybersécurité, la technique est souvent le sujet le moins pertinent

Le rapport vient de l'agence nationale, et sa conclusion surprend.

Les 3 faiblesses qu'il décrit se corrigent par des mesures techniques. Interdire les ordinateurs personnels. Ajouter un second facteur partout. Séparer les réseaux. Surveiller tous les portails. Limiter le volume de données qu'une requête peut rapporter. Ce sont des chantiers, ils coûtent cher, ils prennent des mois, et ils sont indispensables. Aucun dirigeant sérieux ne peut les ignorer.

Mais regardez ce qui a réellement décidé de l'ampleur de cette fuite. L'attaquant ne casse aucun chiffrement. Il ne découvre aucune faille inconnue. Il ne contourne aucun pare-feu par une prouesse. Il se sert de mots de passe volés sur des ordinateurs personnels, et il avance parce que chaque alerte a été traitée séparément. Ce n'est donc pas l'habileté de l'attaquant qui a rendu cette fuite possible. C'est la défaillance de la victime.

Les outils ont produit tous les signaux. Ce qui a manqué n'était pas un outil. C'était une personne chargée de rapprocher ces signaux, et quelqu'un qui décide d'élargir la vérification quand un signal ne rentre pas dans la case prévue. Le rapport l'écrit lui-même : ces corrections ne pourront aboutir sans l'appui de toute la chaîne métier et de la hiérarchie. Autrement dit, sans des gens qui arbitrent.

C'est pour cette raison que je travaille sur ce que les équipes font d'une mauvaise nouvelle, et pas sur l'outil qui va la produire. Une équipe qui alerte et une direction qui ne change rien obtiennent le même résultat qu'une équipe qui ne voit rien.

Ce que ça change dans une PME

Le même enchaînement existe dans une entreprise de 40 personnes, en plus petit. Il y est plus dangereux, parce que personne n'a pour rôle de surveiller ce qui se passe entre les outils.

Regardez sur quels appareils vos identifiants servent. Un identifiant professionnel utilisé sur un ordinateur familial est un identifiant que quelqu'un d'autre peut déjà avoir. Le rapport demande d'interdire cet usage, pas de le déconseiller. Concrètement, faites la liste des comptes qui ouvrent la production ou les données clients, et vérifiez sur quel appareil ils se connectent vraiment.

Vérifiez où arrive votre second facteur. S'il arrive sur l'ordinateur qui porte déjà le mot de passe, il ne protège de rien, comme l'a montré le cas du géomètre-expert.

Sachez si vos sessions se ferment. Changer un mot de passe sans fermer les sessions ouvertes donne l'impression d'avoir coupé l'accès. C'est exactement ce qui s'est passé le 24 juin 2026, et l'extraction a continué 16 heures.

Désignez la personne qui décide d'élargir. La question n'est pas de savoir qui traite l'alerte, mais qui décide d'élargir la vérification quand l'alerte ne couvre pas tout. Tant que ce rôle n'est pas attribué, chaque alerte est traitée pour elle-même, et l'extraction continue pendant qu'on referme le ticket.

Le rapport ne dit à aucun moment que les agents de la DGFiP ont mal travaillé. Il décrit des services qui ont répondu à ce qu'ils voyaient, avec les outils qu'ils avaient, sur le périmètre dont ils étaient responsables. C'est pour cette raison que le cas se transpose. Si une organisation ne voit pas une attaque, ce n'est pas parce que ses agents sont mauvais. C'est parce que personne n'a pour mission de relier ce que chacun voit.

1. ANSSI, Rapport d'incident, septembre 2026, n° 3033/ANSSI/SDO/NP, 23 septembre 2026, publié le 29 septembre 2026. https://cyber.gouv.fr/documents/821/20260923_NP_TLPCLEAR_ANSSI_Rapport_incident_DGFIP.pdf
2. ANSSI, L'ANSSI publie le rapport d'incident sur les cyberattaques ayant touché la DGFiP, 29 septembre 2026. https://cyber.gouv.fr/actualites/lanssi-publie-le-rapport-dincident-sur-les-cyberattaques-ayant-touche-la-dgfip/
3. CERT-FR, Point de situation de l'opération REACTIV, septembre 2026, CERTFR-2026-CTI-006. https://www.cert.cyber.gouv.fr/uploads/CERTFR-2026-CTI-006.pdf