The DGFiP Breach: An Attack No Antivirus Could Ever Flag

DGFiP: an intrusion with no malware involved

In mid August 2026, the French Directorate General of Public Finances confirmed illegitimate access to its information system. Two separate intrusions were publicly claimed. The first involved 678,438 rows of tax data, roughly 285,570 of which relate to professionals and companies.

The detail that should hold a detection team's attention is not the volume. It is the method.

What is known about the tradecraft

According to elements confirmed by the administration and reported by the specialised press, initial access relied on the theft of credentials belonging to two entirely legitimate accounts: one belonging to a tax administration officer, the other to an authorised third party with access to the system. From those accounts, the attacker reached the internal VPN, then a search tool used to query tax databases on individuals and businesses.

The extracted data covers taxpayer identity, family quotient, reference tax income and withholding rate. The administration states that no user account password was compromised.

A second intrusion, claimed in late July against a cadastral data server, reportedly covers 252,149 rows corresponding to more than two million property owners. The multi factor authentication bypass claimed by the attacker has not been confirmed by an independent source, and the attacker's estimate of a twenty million person exposure remains exactly that, an attacker's claim.

Why no protection tool could see anything

Walk the chain step by step, from the point of view of a security agent installed on the endpoint or the server.

A valid account authenticates: normal. A VPN session opens with correct credentials: normal. An internal business application is launched: normal. Queries run inside that application, which exists precisely for that purpose: normal.

At no point is a suspicious binary written to disk. At no point is a vulnerability exploited. At no point does a known signature appear. Antivirus, EDR and file reputation engines have structurally nothing to report, not through misconfiguration, but because no malicious artefact exists to detect.

This is the classic blind spot of valid credential abuse, and it is now among the most common vectors observed in real intrusions.

Low and slow, or the art of staying under the threshold

The most instructive element of the case is timing. The attacker deliberately avoided bulk queries, the kind that trigger volume alerts, and moved slowly enough to stay under detection thresholds. Several weeks passed between the first intrusion in late June and the public claim in mid August.

That approach carries a simple message for detection teams: a fixed threshold is public information to anyone patient enough to measure it. A patient attacker calibrates throughput below the limit, and a rule that fires at one thousand queries per hour will never see nine hundred queries per hour sustained for three weeks.

The answer is not to lower the threshold, which would drown the SOC in false positives. It is to compare each account against its own habit rather than against an absolute value shared by everyone.

What behavioural detection could have caught

None of the following requires an exotic product. All of it rests on logs most organisations already collect, provided someone writes the rule that interrogates them.

An account departing from its own baseline. An officer who normally consults a few dozen records a day and suddenly consults several hundred, even spread out, departs from their own history. The signal is not absolute volume, it is relative deviation.

A third party operating outside its scope. External accounts almost always have a narrow, predictable purpose. A query touching entities outside that scope is a strong anomaly, and these accounts are rarely monitored with the same care as internal ones.

VPN authentication from a new origin. New country, new network operator, new declared operating system: each in isolation produces noise, but their combination on a privileged account is actionable.

A first time access to a sensitive application. The simple fact that an account opens a mass consultation tool for the first time is information in itself, and it is straightforward to express.

Activity outside usual hours. A three in the morning lookup on an account that has never worked at night is worth more than any volume threshold.

The ATT&CK techniques involved

The chain maps directly onto MITRE ATT&CK, which makes coverage verifiable against your own estate.

• T1078, Valid Accounts: initial access and persistence both rely on legitimate accounts.
• T1133, External Remote Services: the internal VPN as the way in.
• T1213, Data from Information Repositories: extraction from a business consultation tool.

A useful exercise is to take those three identifiers and check, in your own SIEM, which rules actually fire. The answer is often shorter than expected.

What this changes for a detection team

The natural reflex after an incident like this is to look for one more tool. The DGFiP case suggests the opposite: the required telemetry already existed, authentication, VPN and application logs were all being produced. What was missing was the detection content capable of turning those logs into an alert.

That is a difference in kind. A tool is deployed once. Detection content is maintained, tested and updated at the pace of observed tradecraft, and that is where most of the gap lies between an intrusion caught in three days and one caught in six weeks.

Our Sigma rules covering valid account abuse, remote access and extraction from internal applications are executed against the real engine before release, mapped to ATT&CK, and shipped pre converted for Splunk, Microsoft Sentinel, Elastic, IBM QRadar, CrowdStrike Falcon LogScale and Panther. No conversion step is required on your side.

To learn more, see our Sigma rules feed.