DGFiP : l'attaque qui ne déclenche aucune alerte antivirus

DGFiP : une intrusion sans logiciel malveillant

La Direction générale des finances publiques a confirmé mi-août 2026 des accès illégitimes à son système d'information. Deux intrusions distinctes ont été revendiquées publiquement, la première portant sur 678 438 lignes de données fiscales, dont environ 285 570 concernant des professionnels et des entreprises.

Le détail qui doit retenir l'attention des équipes de détection n'est pas le volume. C'est la méthode.

Ce que l'on sait du mode opératoire

Selon les éléments confirmés par l'administration et relayés par la presse spécialisée, l'accès initial repose sur l'usurpation des identifiants de deux comptes parfaitement légitimes : celui d'un agent de la DGFiP, et celui d'un tiers habilité disposant d'un accès au système. Depuis ces comptes, l'attaquant a obtenu un accès au VPN interne, puis à un outil de recherche permettant d'interroger les bases fiscales sur des particuliers et des professionnels.

Les données extraites portent sur l'identité des contribuables, le quotient familial, le revenu fiscal de référence et le taux de prélèvement à la source. L'administration précise qu'aucun mot de passe de compte usager n'a été compromis.

Une seconde intrusion, revendiquée fin juillet sur un serveur de données cadastrales, porterait sur 252 149 lignes correspondant à plus de deux millions de propriétaires. Le contournement d'authentification multifacteur revendiqué par l'attaquant n'a pas été confirmé par une source indépendante, et son estimation d'un potentiel de vingt millions de personnes reste une affirmation d'attaquant.

Pourquoi aucun outil de protection ne pouvait voir quoi que ce soit

Reprenons la chaîne, étape par étape, du point de vue d'un agent de sécurité installé sur le poste ou le serveur.

Un compte valide s'authentifie : comportement normal. Une connexion VPN s'établit avec des identifiants corrects : comportement normal. Une application métier interne est ouverte : comportement normal. Des requêtes sont exécutées dans cette application, qui est faite pour cela : comportement normal.

À aucun moment un binaire suspect n'est écrit sur disque. À aucun moment une vulnérabilité n'est exploitée. À aucun moment une signature connue n'apparaît. Un antivirus, un EDR ou un moteur de réputation de fichiers n'ont structurellement rien à signaler, non par défaut de configuration, mais parce qu'il n'existe aucun artefact malveillant à détecter.

C'est le point aveugle classique de l'abus d'identifiants valides, et c'est aujourd'hui l'un des vecteurs les plus répandus dans les intrusions constatées.

Le low and slow, ou l'art de rester sous le seuil

L'élément le plus instructif du dossier est la temporalité. L'attaquant a délibérément évité les requêtes massives, celles qui déclenchent une alerte de volumétrie, pour progresser lentement et rester sous les seuils de détection. Entre la première intrusion fin juin et la revendication publique à la mi-août, plusieurs semaines se sont écoulées.

Cette approche dit une chose simple aux équipes de détection : un seuil fixe est une information publique pour qui prend le temps de le mesurer. Un attaquant patient calibre son débit sous la limite, et une règle qui déclenche à mille requêtes par heure ne verra jamais neuf cents requêtes par heure répétées pendant trois semaines.

La parade n'est pas de baisser le seuil, ce qui noierait le SOC sous les faux positifs. Elle consiste à comparer chaque compte à sa propre habitude plutôt qu'à une valeur absolue partagée par tous.

Ce qu'une détection comportementale aurait pu voir

Aucune de ces observations ne nécessite un produit exotique. Toutes reposent sur des journaux que la plupart des organisations collectent déjà, à condition d'écrire la règle qui les interroge.

Un compte qui sort de sa propre ligne de base. Un agent qui consulte habituellement quelques dizaines de dossiers par jour et qui en consulte plusieurs centaines, même étalés, s'écarte de son propre historique. Le signal n'est pas le volume absolu, c'est l'écart relatif.

Un tiers habilité qui sort de son périmètre. Les comptes externes ont presque toujours un usage étroit et prévisible. Une interrogation portant sur des entités hors de ce périmètre est une anomalie forte, et ces comptes sont rarement surveillés avec la même attention que les comptes internes.

Une authentification VPN depuis une origine nouvelle. Nouveau pays, nouvel opérateur, nouveau système d'exploitation déclaré : chacun pris isolément produit du bruit, mais leur conjonction sur un compte à privilèges est un signal exploitable.

Un premier accès à une application sensible. Le fait qu'un compte ouvre pour la première fois un outil de consultation de masse est en soi une information, et elle est simple à matérialiser.

Une activité hors des plages habituelles. Une consultation à trois heures du matin sur un compte qui n'a jamais travaillé de nuit vaut mieux qu'un seuil de volumétrie.

Les techniques ATT&CK concernées

La chaîne se lit directement dans le référentiel MITRE ATT&CK, ce qui permet de vérifier la couverture de son propre parc.

• T1078, Valid Accounts : l'accès initial et le maintien reposent sur des comptes légitimes.
• T1133, External Remote Services : le VPN interne comme point de passage.
• T1213, Data from Information Repositories : l'extraction depuis un outil métier de consultation.

Un exercice utile consiste à prendre ces trois identifiants et à vérifier, dans son propre SIEM, quelles règles se déclenchent réellement. La réponse est souvent plus courte qu'attendu.

Ce que cela change pour une équipe de détection

Le réflexe naturel après un incident de cette nature est de chercher un outil supplémentaire. Le dossier DGFiP suggère l'inverse : la télémétrie nécessaire existait, les journaux d'authentification, de VPN et d'application étaient produits. Ce qui manquait, c'était le contenu de détection capable de transformer ces journaux en alerte.

C'est une différence de nature. Un outil se déploie une fois. Le contenu de détection se maintient, se teste et se met à jour au rythme des techniques observées, et c'est là que se joue l'essentiel de l'écart entre une intrusion vue en trois jours et une intrusion vue en six semaines.

Nos règles Sigma couvrant l'abus de comptes valides, les accès distants et l'extraction depuis des applications internes sont exécutées contre le moteur réel avant publication, mappées ATT&CK, et livrées pré-converties pour Splunk, Microsoft Sentinel, Elastic, IBM QRadar, CrowdStrike Falcon LogScale et Panther. Aucune étape de conversion n'est requise de votre côté.

Pour en savoir plus, consultez notre flux de règles Sigma.