Pas de 0-day, pas de malware d'État : juste des mots de passe volés et des portes laissées ouvertes. Et c'est justement pour ça qu'il faut le lire.
L'ANSSI a publié le 23 septembre son rapport d'incident sur la compromission de la DGFIP. 20 pages, version publique caviardée, classée TLP:CLEAR.
Je l'ai lu en entier.
Et avant d'aller plus loin, une précision : je ne suis pas là pour jeter la pierre.
Mon blog s'est fait toucher par une 0-day. Pourtant je fais de la tech depuis 20 ans, et je pensais avoir verrouillé ce qu'il fallait. Donc je sais que ça peut arriver à tout le monde.
Mais il faut bien retenir une chose.
Une 0-day, par définition, vous ne pouvez pas l'anticiper. Ce qui s'est passé à la DGFIP, si. Et c'est l'ANSSI elle-même qui l'écrit : la compromission n'est pas la conséquence d'une attaque sophistiquée.
Le but de cet article, c'est de comprendre comment ça s'est passé, et surtout ce qu'il faut surveiller pour que ça ne vous arrive pas.
Que s'est-il passé ?
Le 12 août à 13h50, un acteur nommé Zerobytes revendique sur un forum le vol de données de la plateforme impots.gouv.fr.
Le lendemain, il publie le détail. Selon le rapport, près de 353 000 particuliers et 252 000 professionnels sont concernés, via E-Contact, l'outil de messagerie entre la DGFIP et les usagers.
(Petite note : l'annexe du même rapport cite la revendication de l'attaquant à 678 437 enregistrements. L'écart n'est pas expliqué. Je suppose que c'est la différence entre ce qui est revendiqué et ce qui est confirmé.)
Le même jour, deuxième revendication : les données cadastrales. L'attaquant parle de 2 millions de Français (noms, dates de naissance, parcelles, biens détenus).
Le plus inquiétant n'est pas le volume.
C'est le calendrier. L'exfiltration principale a eu lieu le 24 juin. Personne ne l'a vue. La DGFIP l'a apprise sept semaines plus tard, par la revendication de l'attaquant.
Comment l'attaquant est-il entré ?
La chaîne est d'une simplicité déconcertante :
- Des agents utilisent des appareils personnels (ou des machines d'organismes tiers) pour accéder à des outils pro.
- Ces machines sont probablement infectées par des infostealers, qui aspirent les identifiants enregistrés.
- Les identifiants sont revendus. Plusieurs dizaines de comptes y passent, sur trois mois.
- Deux portails, PIGP et ADER, n'ont pas d'authentification multifacteur. Un login et un mot de passe suffisent.
- L'attaquant se connecte au PIGP depuis internet, puis rebondit sur ADER via le RIE (le réseau interministériel de l'État), auquel il a accès grâce à la compromission préalable du ministère de l'Éducation nationale.
- Une fois dans E-Contact, il développe un scraper et aspire les fiches, page par page.
Aucune tentative de brute force. Aucun credential stuffing. L'attaquant avait les bons mots de passe.
Pour la partie cadastrale, même logique. Le poste d'un géomètre-expert, dans un cabinet privé, est compromis. Le portail APEX qui lui donne accès au cadastre a bien un second facteur... un OTP envoyé par email.
Et si l'infostealer a votre session de messagerie, il a aussi votre OTP.
Le moment où tout aurait pu s'arrêter
C'est la séquence qui m'a le plus marqué :
- 23 juin, 20h50 : le compte utilisé par l'attaquant déclenche une alerte automatique. Un ticket est créé au SOC.
- 24 juin, 04h26 : l'exfiltration automatisée démarre.
- 24 juin, 10h40 : le SOC traite le ticket et réinitialise le mot de passe du compte.
- 25 juin, 02h31 : l'exfiltration se termine.
Vous avez bien lu. Le mot de passe est changé en pleine exfiltration, et l'exfiltration continue pendant encore 16 heures.
Parce que réinitialiser un mot de passe ne coupe pas les sessions déjà ouvertes. Et parce que l'alerte portait sur le PIGP, alors que l'attaquant travaillait sur ADER, qui n'était pas supervisé.
La vérité c'est que je connais des tas d'applis en production qui ont exactement ce défaut. Peut-être la vôtre.
Mais les signaux étaient là
Le rapport liste tout ce qui aurait pu lever une alerte :
- 11 Go échangés entre le 22 et le 25 juin, puis 3 Go en juillet, sans alerte.
- Aucun rate limiting : un scraper qui enchaîne des milliers de requêtes passe crème.
- Des connexions nocturnes.
- Des IP localisées en Inde, des IP de VPN, des IP déjà catégorisées comme malveillantes.
- Les mêmes IP réutilisées sur plusieurs comptes connus comme compromis.
- Un compte non privilégié qui peut consulter un volume massif de fiches.
Pris un par un, chaque signal génère du faux positif. Le rapport le reconnaît. Mais corrélés, ils racontent une histoire très claire.
Et côté coordination, ça coince aussi :
- Le 9 juin, l'Éducation nationale partage 17 marqueurs de compromission à tous les ministères. Une des IP de l'attaquant est dedans. Elle sera utilisée contre la DGFIP les 22 et 23 juin.
- Le 15 juin, un partenaire signale deux comptes compromis à l'ANSSI. La DGFIP ne répond pas, l'ANSSI ne relance pas.
- Un compte identifié comme compromis le 3 juin est réinitialisé le 12 juin. 9 jours.
Je ne tape pas sur les équipes. Quand on gère des dizaines de comptes compromis en flux continu, sur un SI de cette taille, on court après le problème. Le rapport le dit d'ailleurs : l'analyse systématique de chaque compte compromis est trop chronophage pour être exhaustive.
C'est justement pour ça qu'il faut automatiser tout ce qui peut l'être.
Donc, quoi surveiller chez vous ?
Voici la checklist que j'ai tirée du rapport. Elle vaut pour une administration, mais aussi pour votre SaaS, votre back-office ou votre CMS.
L'identité
- MFA sur tout ce qui touche à de la donnée sensible. Pas seulement sur l'admin.
- Un second facteur indépendant du premier : app TOTP, clé physique, passkey. Pas un OTP par email si la boîte mail tombe avec le même mot de passe.
- Pas d'accès pro depuis des machines perso non administrées. Si vous ne pouvez pas l'interdire, compensez (MFA fort, droits restreints, sessions courtes).
- Une veille sur les fuites d'identifiants. Mais ne comptez pas uniquement dessus : elle ne sera jamais exhaustive, ni instantanée.
Les sessions
- Un reset de mot de passe doit révoquer toutes les sessions actives, sur toutes les applis. Sans exception.
- En cas de compromission répétée d'un même compte, cherchez la cause racine (la machine est probablement toujours infectée).
Concrètement, si vos sessions sont en Redis, ça tient en quelques lignes :
// À appeler à chaque reset de mot de passe
async function revokeAllSessions(redis, userId) {
const sessions = await redis.sMembers(`user:${userId}:sessions`)
if (sessions.length) {
await redis.del(sessions.map((id) => `sess:${id}`))
}
await redis.del(`user:${userId}:sessions`)
}
Ça suppose d'indexer les sessions par utilisateur à la connexion. Si vous ne le faites pas aujourd'hui, c'est le premier chantier.
L'applicatif
- Rate limiting par utilisateur, pas seulement par IP.
- Quotas métier : nombre de fiches consultées par jour, volume téléchargé par session. Un humain ne lit pas 10 000 fiches dans la nuit.
- Moindre privilège : chaque compte ne voit que ce dont il a besoin.
- Filtrage GeoIP et réputation IP. Si vous ne pouvez pas bloquer, au minimum, alertez.
La supervision
- Toutes les applis dans les logs centralisés. Une appli non supervisée, c'est un angle mort que l'attaquant trouvera avant vous.
- De la corrélation, pas des alertes isolées : heure de connexion + IP douteuse + volume anormal = alerte haute.
- Une alerte doit déclencher une analyse de toute l'activité du compte depuis la date supposée de compromission, pas seulement un reset.
- Envisagez le blocage automatique d'un compte sur comportement suspect. Mieux vaut un faux positif qui râle qu'un vrai positif qui exfiltre.
Les tiers et le réseau
- Un partenaire connecté à votre SI fait partie de votre surface d'attaque. Le géomètre-expert en est la preuve.
- Les applis internes ne doivent pas être accessibles depuis internet, sauf via VPN.
- Cartographiez les flux légitimes. Sans ça, impossible de bloquer quoi que ce soit proprement.
- Quand on vous partage des marqueurs de compromission, traitez-les vite. Un IOC qui dort une semaine ne sert plus à grand-chose.
Ce que je retiens
La DGFIP a coupé définitivement l'accès à ADER pour ses agents, et fermé le PIGP aux comptes agents. Ça a un coût opérationnel réel, et le rapport ne le cache pas.
Mais le plus intéressant, c'est la liste des remédiations. Rien de révolutionnaire : MFA, pas d'appareils perso, quotas, supervision, révocation des sessions.
Des basiques.
Et c'est ça, la vraie leçon. On fantasme souvent sur les attaques sophistiquées, les 0-day, les APT. Moi le premier, parce que je m'en suis pris une.
Mais la majorité des fuites ne passent pas par là. Elles passent par un mot de passe volé sur un PC perso et une appli qui ne se demande jamais pourquoi quelqu'un aspire 11 Go à 4h du matin.
Alors posez-vous la question : si demain un de vos comptes utilisateurs est volé, combien de temps avant que vous le voyiez ?
Et surtout, qui le verra en premier : vous, ou l'attaquant sur un forum ?
