A password reset does not end open sessions: what ANSSI's report on the DGFiP cyberattack shows

At 10:40 on 24 June 2026, the security operations centre (SOC) of France's public finances directorate, the DGFiP, reset the password of a staff account that had run anomalous searches the evening before. The exfiltration of taxpayer data through that same account carried on until 02:31 on 25 June, almost sixteen hours later.

The episode appears in ANSSI's incident report, a twenty-page document dated 23 September that the French cybersecurity agency published on the 29th. It reconstructs the intrusion with times, data volumes and the decisions taken by the response team. It shows, with dates, that resetting a password does not by itself close sessions that are already open.

Unless stated otherwise, the details below come from the report and the agency's official note. Part of the public version is redacted, and for anything it does not contain we cite the outlet or press release that reports it.

Why did resetting the password not end the attacker's session?

The reset of 24 June 2026 was a response to an alert from the PIGP portal and did not reach the session the attacker held on a second portal, ADER. The exfiltration therefore went on until 02:31 on the 25th, according to ANSSI's report. The document does not explain the technical mechanism. It records that the reset interrupted neither the session nor the exfiltration under way.

The sequence over those hours was as follows. At 20:50 on 23 June, unusual searches on PIGP automatically opened a ticket at the DGFiP's SOC. At 04:26 on the 24th, the same account began extracting data from E-Contact through ADER, in a session lasting several hours. The SOC handled the ticket at 10:40 and reset the password, by which time the extraction had been running for more than six hours. That same day, the DGFiP's credential-monitoring provider had flagged the account as compromised.

The pattern repeated in July. Two new exfiltration sessions took place on the 22nd, the SOC detected suspicious searches on the 23rd and the account involved was reset on the 24th. The report also describes an account reset on 7 June that the attacker used again on 6 and 7 July.

On 6 August, ANSSI passed the DGFiP two suspicious IP addresses after a retrospective search of its sensors. The public claim came on the 12th. On 13 August the DGFiP disabled ADER access for its agents' accounts, on the 14th it locked the APEX portal and on the 18th it cut PIGP access for those same accounts.

What data was stolen in the DGFiP cyberattack?

The DGFiP cyberattack, which ran from May to August 2026, affected about 353,000 individuals and 252,000 professional users, according to ANSSI's report. Their data was held in E-Contact, the messaging application the tax administration uses to communicate with taxpayers. Land registry data obtained by a second route comes on top of that.

The actor the report calls Zerobytes claimed 678,437 records on a forum on 12 August, and on the 13th announced the theft of land registry data. The Economy Ministry's press release of 14 August spoke of 678,000 individuals and professionals in total. The report, which came later, gives the lower figures.

By volume, the report measures 11 GB of data exchanged between 22 and 25 June and a further 3 GB between 21 and 23 July. The public version does not break down the types of data. According to The Hacker News, the records included tax identifier, contact details, family situation, reference income and withholding rate.

How did the attacker get into the DGFiP portals?

The attacker logged in with valid credentials belonging to staff and to one outside professional on three portals, PIGP, ADER and APEX, two of which did not ask agents' accounts for multi-factor authentication, according to ANSSI's report.

Passwords stolen on machines the DGFiP did not manage

Over three months, the attacker obtained the credentials of several dozen DGFiP agents. The report found no brute-force attack and no credential stuffing, so the passwords had already been stolen, probably by infostealers installed on personal computers and third-party machines.

Two portals turned those compromised credentials into access. PIGP, a public management portal that DGFiP staff also used for webmail and HR services, was reachable from the internet. ADER gave access to internal applications over the RIE, the French state's interministerial network. Both asked agents' accounts for a username and password only, with no multi-factor authentication.

Reaching ADER meant being inside the interministerial network. The report says the attacker got there through compromised infrastructure at the Education Ministry, which is connected to the same network. The agency puts this down to sensitive applications being reachable from the RIE without compartmentalisation, which allowed lateral movement from other bodies' systems.

Why did the emailed code fail on APEX?

The one-time code APEX sent by email did not stop the attacker because, according to the report, the probable compromise of the account holder's computer made it possible to get round it. APEX is the portal notaries and surveyors use to consult the land registry, and between 27 July and 8 August someone logged in to it with the account of a surveyor at a private firm.

The report's recommendations add that a code sent by email is not a reasonable choice when a single username and password also opens the mailbox.

Why did neither the SOC nor ANSSI detect the exfiltration?

Neither wave of data exfiltration was detected by the DGFiP's systems or by ANSSI's, according to the note the agency published on 29 September 2026. The report explains this by the lack of monitoring on ADER, the absence of correlation between signals and the limits of the agency's network monitoring.

The DGFiP's SOC monitored PIGP and not ADER, the portal through which the E-Contact data left. On 7 June and again on 24 June, the handling of a PIGP alert missed the attacker's move from one portal to the other.

The signals existed and were not correlated. The report lists night-time connections, traffic leaving through VPN services, addresses located in India, IP addresses catalogued as malicious and the volume of data exchanged. It adds that the number of requests per user was not measured. According to the agency, each parameter taken alone produces too many false positives, but correlating several could have raised alerts.

There were earlier warnings too. On 9 June, the Education Ministry's security centre told the other ministries about an incident on its systems and shared 17 indicators. It attached the list of its ministry's IP addresses and asked them to watch connections arriving from those addresses over the RIE. One of the addresses the attacker used to reach ADER was on that list.

ANSSI acknowledges its limits. The report says the agency has no application-level monitoring on these systems and that its network monitoring could not see an attacker using legitimate accounts. It also admits that the cumulative volume of requests should have triggered alerts.

Monitoring for leaked credentials did not make up for those gaps. The report notes that such a service cannot cover every resale market, that one compromised account was never flagged and that another, flagged on 3 June, had its last password change nine days later. It also warns that resetting a password is only effective if the infected machine is cleaned.

Was the DGFiP cyberattack sophisticated?

ANSSI's report, dated 23 September 2026, states that the intrusion at the DGFiP is not the result of a sophisticated attack and attributes it to weaknesses in identity management, architecture and detection. On 14 August, two days after the first claim, the Economy Ministry had put the lack of detection down to "the sophistication of the attack".

ANSSI's director, Vincent Strubel, described the operation, according to Alliancy, as technically not very advanced and particularly persistent. Old portals that ask only for a password, networks shared between bodies without compartmentalisation and business applications with no feed to the SOC are common outside the French administration, in organisations with decades of accumulated systems.

What corrective measures does ANSSI call for?

ANSSI's report calls for measures in three blocks: access to business applications, protection against credential theft and the reset process. They are worded as requirements, with no compliance dates. Grouped by subject, they are these:

• Personal devices must not be used to reach professional resources, and managed devices must have monthly updates, EDR and an always-on VPN.
• Authentication must require a second factor that withstands theft of the first, using a hardware key or an app on a separate device.
• A password reset must come with revocation of active sessions on every accessible application and portal, and with a review of the account's activity since the presumed date of compromise.
• Business applications must be integrated into the SIEM, with query limits and with blocking or alerting based on geolocation and IP reputation.
• Each employee must have access only to the information their role requires, following the principle of least privilege.
• Internal applications must be reachable only from managed workstations, outside collaborators must come in over a VPN and traffic between ministries must be filtered more strictly.

How can you check whether your organisation has the same gaps?

The gaps ANSSI's report describes can be checked in another organisation with five tests: sessions after a reset, SOC coverage, volume alerts, access devices and third-party reach.

Does changing a password close open sessions?

It depends on each application, and in many of them the open session stays active until it expires or is explicitly revoked. The test needs a test account and a stopwatch. Open a session in each critical application, reset the password from the directory and measure how long each session keeps responding.

In Entra ID, for example, resetting the password and revoking explicitly do not have the same reach. According to Microsoft's documentation, the reset revokes the refresh tokens obtained with the password and can leave sessions established without it active, whereas Revoke-MgUserSignInSession invalidates all of the user's refresh tokens and the browser session cookies. An access token already issued stays valid until it expires, one hour by default, unless both client and service support continuous access evaluation.

An application that issues its own session token keeps it until the application itself revokes it. On older portals, ending the session usually means invalidating it on the application server. Your response procedure should say who does that and in what order.

Do all applications holding personal data send logs to the SOC?

Applications that are not among the SIEM's sources sit outside detection, as ADER did at the DGFiP. Cross-check the inventory of applications that process personal or financial data against the list of sources the SIEM receives, and give each absence an owner and a date. The guide on which logs to send to a SIEM helps to order that list by detection value. A managed SOC or an in-house one answers only for the applications that send it events.

Is there any alert on query volume?

At the DGFiP there was none. According to ANSSI's report, the 11 GB exchanged between 22 and 25 June 2026 generated no alert and the number of requests per user was not measured. The document points out that rate-limiting mechanisms are used for this. A threshold of queries per user per hour is a first step, and behavioural analytics (UEBA) refines it. Decoy records complement both, because a fake file that no employee has reason to open raises the alarm on the first query, as honeytokens and decoy accounts do in the directory.

Which devices do your staff log in from?

The report places the most likely origin of the credentials on personal and third-party machines. If your bring-your-own-device policy (BYOD) allows access to internal applications from unmanaged machines, the second factor becomes the main barrier between an infostealer and your data. Our analysis of ClickFix and ACR Stealer shows how infostealers operate. Leaked-credential monitoring only helps if each notification has a response deadline and if that response includes cleaning the machine where the password was captured.

How far can a third party connected to your network reach?

The attacker reached the tax applications from another ministry and from the office of an outside professional. In Spain, Red SARA plays a similar part to the RIE by interconnecting public bodies, and in the private sector the same applies to networks shared with subsidiaries or suppliers. Check what an outside machine can see once it is connected. The guide to internal network segmentation walks through that analysis, and controlling those connections is part of third-party risk management.

What do NIS2 and Spain's ENS require on authentication and activity logging?

Article 21(2)(j) of the NIS2 Directive lists the use of multi-factor or continuous authentication "where appropriate" among its risk-management measures. Spain's National Security Framework (ENS) has specific measures for the authentication mechanism of the organisation's users (op.acc.6) and of external users (op.acc.5), and for activity logging (op.exp.8).

The French case documents portals with no second factor and one portal with no monitoring. NIS2 places those decisions under management's responsibility.

Who is behind the attack and what does the report leave unanswered?

ANSSI's report calls the actor who claimed the theft Zerobytes and attributes the attack to no one. The judicial side moved separately. According to Next, an 18-year-old was arrested on 18 August, placed under formal investigation on the 20th and remanded in custody. A second suspect, a minor, was arrested on 26 August and released.

The report leaves several points open. Account names are anonymised and the list of compromised accounts is not published. Users' permissions inside the applications were not examined and are left for a later audit. On the other state bodies connected to the RIE, the text says only that numerous traces of attempted lateral movement were found.

Resetting a password is usually the first step in an incident response plan. At the DGFiP, the session open on ADER stayed active for almost sixteen hours after the reset, with the exfiltration under way. The first check in the list above measures that same interval in each organisation's applications.

Sources and attribution: this analysis draws on ANSSI's incident report and official note, the French Economy Ministry's press release of 14 August and coverage by The Hacker News, Alliancy and Next. It reflects the information available on 6 October 2026. Part of the public report is redacted. The incident stemmed from the abuse of legitimate access and from gaps in configuration and monitoring, and no mention implies a security flaw in the products or services cited. The people arrested are presumed innocent.

Technical notice: how sessions behave after a reset depends on each application, its version and its configuration. The checks described should be run with test accounts and in agreed windows, and every change to session revocation or query limits should first be validated in a test environment.