Cambiar la contraseña no cierra la sesión: el robo de datos de la DGFiP según el informe de la ANSSI

El 24 de junio de 2026, a las 10:40, el centro de operaciones de seguridad (SOC) de la Dirección General de Finanzas Públicas francesa (DGFiP) restableció la contraseña de una cuenta de empleado desde la que la víspera se habían hecho búsquedas anómalas. La exfiltración de datos de contribuyentes con esa misma cuenta siguió hasta las 02:31 del día 25, casi dieciséis horas después.

El episodio figura en el informe de incidente de la ANSSI, un documento de veinte páginas fechado el 23 de septiembre que la agencia francesa de ciberseguridad publicó el día 29. El texto reconstruye la intrusión con horas, volúmenes de datos y decisiones del equipo de respuesta. Muestra, con fechas, que restablecer una contraseña no cierra por sí solo las sesiones que están abiertas.

Salvo que se indique otra cosa, los detalles proceden del informe y de la nota oficial de la agencia. Parte de la versión pública está enmascarada, y para lo que no figura en ella citamos el medio o el comunicado que lo recoge.

¿Por qué restablecer la contraseña no cerró la sesión del atacante?

El restablecimiento del 24 de junio de 2026 respondía a una alerta del portal PIGP y no alcanzó la sesión que el atacante tenía abierta en otro portal, ADER. La exfiltración siguió por eso hasta las 02:31 del día 25, según el informe de la ANSSI. El documento no explica el mecanismo técnico. Constata que el restablecimiento no interrumpió la sesión ni la exfiltración en curso.

La secuencia de esas horas es esta. El 23 de junio a las 20:50, unas búsquedas extrañas en PIGP abrieron de forma automática una incidencia en el SOC de la DGFiP. El 24 a las 04:26, la misma cuenta empezó a extraer datos de E-Contact a través de ADER, en una sesión de varias horas. El SOC tramitó la incidencia a las 10:40 y restableció la contraseña, cuando la extracción llevaba más de seis horas en marcha. Ese mismo día, el proveedor de vigilancia de credenciales de la DGFiP había marcado la cuenta como comprometida.

En julio se repitió el patrón. El 22 hubo dos nuevas sesiones de exfiltración, el SOC detectó búsquedas sospechosas el 23 y la cuenta implicada se restableció el 24. El informe recoge además el caso de una cuenta restablecida el 7 de junio que el atacante volvió a usar el 6 y el 7 de julio.

El 6 de agosto, la ANSSI comunicó a la DGFiP dos direcciones IP sospechosas tras una búsqueda retrospectiva en sus sondas. El 12 llegó la reivindicación pública. El 13 de agosto la DGFiP desactivó el acceso a ADER para las cuentas de sus agentes, el 14 bloqueó el portal APEX y el 18 cortó el acceso a PIGP para esas mismas cuentas.

¿Qué datos se robaron en el ciberataque a la DGFiP?

El ciberataque a la DGFiP, ocurrido entre mayo y agosto de 2026, afectó a cerca de 353.000 particulares y 252.000 profesionales, según el informe de la ANSSI. Sus datos estaban en E-Contact, la aplicación de mensajería con la que la administración tributaria se comunica con los contribuyentes. A eso se suman los datos catastrales obtenidos por una segunda vía.

El actor que el informe llama Zerobytes reivindicó el 12 de agosto, en un foro, 678.437 registros, y el 13 anunció el robo de datos catastrales. El comunicado del Ministerio de Economía del 14 de agosto habló de un total de 678.000 particulares y profesionales. El informe, posterior, da las cifras más bajas.

En volumen, el informe mide 11 GB de datos intercambiados entre el 22 y el 25 de junio y otros 3 GB entre el 21 y el 23 de julio. La versión pública no desglosa los tipos de dato. Según The Hacker News, los registros incluían identificador fiscal, datos de contacto, situación familiar, renta de referencia y tipo de retención.

¿Cómo entró el atacante en los portales de la DGFiP?

El atacante entró con credenciales válidas de empleados y de un profesional externo en tres portales, PIGP, ADER y APEX. Dos de ellos no pedían autenticación multifactor a las cuentas de los agentes, según el informe de la ANSSI.

Contraseñas robadas en equipos que la DGFiP no gestionaba

En tres meses, el atacante obtuvo credenciales de varias decenas de agentes de la DGFiP. El informe no identificó ningún ataque de fuerza bruta ni de relleno de credenciales (credential stuffing), de modo que las contraseñas ya estaban robadas, probablemente por programas de robo de información (infostealers) instalados en ordenadores personales y en equipos de terceros.

Dos portales convertían esas credenciales comprometidas en acceso. PIGP, un portal de gestión pública que el personal de la DGFiP usaba también para el correo web y los servicios de recursos humanos, era accesible desde internet. ADER daba acceso a las aplicaciones internas a través de la RIE, la red interministerial del Estado francés. A las cuentas de los agentes, ambos les pedían solo usuario y contraseña, sin autenticación multifactor.

Para llegar a ADER había que estar dentro de la red interministerial. El informe indica que el atacante lo consiguió a través de infraestructura comprometida del Ministerio de Educación, conectada a esa misma red. La agencia lo atribuye a que había aplicaciones sensibles accesibles desde la RIE sin compartimentación, lo que permitió el movimiento lateral desde sistemas ajenos.

¿Por qué falló el código enviado por correo en APEX?

El código de un solo uso que APEX enviaba por correo no detuvo al atacante porque, según el informe, el probable compromiso del ordenador del titular de la cuenta permitió saltárselo. APEX es el portal que usan notarios y topógrafos para consultar el catastro, y entre el 27 de julio y el 8 de agosto alguien entró en él con la cuenta de un topógrafo de un despacho privado.

Las recomendaciones del informe añaden que un código por correo no es una elección razonable cuando un único par de usuario y contraseña abre también el buzón.

¿Por qué ni el SOC ni la ANSSI detectaron la exfiltración?

Ni los sistemas de la DGFiP ni los de la ANSSI detectaron las dos oleadas de exfiltración de datos, según la nota de la agencia del 29 de septiembre de 2026. El informe lo explica por la falta de supervisión de ADER, la ausencia de correlación entre señales y los límites de la supervisión de red de la agencia.

El SOC de la DGFiP supervisaba PIGP y no ADER, el portal por el que salieron los datos de E-Contact. El 7 de junio y el 24 de junio, el tratamiento de una alerta de PIGP pasó por alto el salto del atacante de un portal al otro.

Las señales existían y no se correlacionaron. El informe cita conexiones de madrugada, salidas por servicios de VPN, direcciones situadas en la India, direcciones IP catalogadas como maliciosas y el volumen de datos intercambiado. Añade que el número de peticiones por usuario no se medía. Según la agencia, cada parámetro por separado genera demasiados falsos positivos, pero la correlación de varios habría podido levantar alertas.

Hubo también avisos previos. El 9 de junio, el centro de seguridad del Ministerio de Educación comunicó a los demás ministerios un incidente en sus sistemas y compartió 17 indicadores. Adjuntó la lista de direcciones IP de su ministerio y pidió vigilar las conexiones que llegaran desde ellas por la RIE. Una de las direcciones que el atacante usó para llegar a ADER figuraba en esa lista.

La ANSSI reconoce sus límites. El informe indica que la agencia no dispone de supervisión a nivel de aplicación en estos sistemas y que su supervisión de red no pudo ver a un atacante que usaba cuentas legítimas. Admite además que el volumen acumulado de peticiones debería haber disparado alertas.

La vigilancia de credenciales filtradas tampoco compensó esas carencias. El informe señala que ese servicio no puede cubrir todos los mercados de reventa, que una cuenta comprometida nunca fue notificada y que otra, notificada el 3 de junio, tuvo su último cambio de contraseña nueve días después. Advierte también de que restablecer la contraseña solo es eficaz si se limpia el equipo infectado.

¿Fue sofisticado el ciberataque a la DGFiP?

La intrusión en la DGFiP no es consecuencia de un ataque sofisticado, según el informe de la ANSSI fechado el 23 de septiembre de 2026. La agencia la atribuye a debilidades en la gestión de identidades, la arquitectura y la detección. El 14 de agosto, dos días después de la primera reivindicación, el Ministerio de Economía había atribuido la falta de detección a «la sofisticación del ataque».

El director de la ANSSI, Vincent Strubel, describió la operación, según Alliancy, como poco avanzada en lo técnico y particularmente persistente. Portales antiguos que solo piden contraseña, redes compartidas entre organismos sin compartimentar y aplicaciones de gestión sin conexión al SOC son frecuentes fuera de la administración francesa, en organizaciones con décadas de sistemas acumulados.

¿Qué medidas correctivas pide la ANSSI?

Las medidas que pide el informe de la ANSSI se reparten en tres bloques: acceso a las aplicaciones de gestión, protección frente al robo de credenciales y proceso de restablecimiento. Están redactadas como exigencias, sin fechas de cumplimiento. Agrupadas por tema, son estas:

• El uso de equipos personales para acceder a recursos profesionales debe prohibirse, y los equipos gestionados deben contar con actualizaciones mensuales, EDR y VPN permanente.
• La autenticación debe exigir un segundo factor resistente al robo del primero, con llave física o aplicación en un dispositivo separado.
• El restablecimiento de una contraseña debe ir acompañado de la revocación de las sesiones activas en todas las aplicaciones y portales accesibles, y de un análisis de la actividad de la cuenta desde la fecha supuesta de compromiso.
• Las aplicaciones de gestión deben integrarse en el SIEM, con límites de consulta y con bloqueo o alerta por geolocalización y reputación de la dirección IP.
• Cada empleado debe acceder solo a la información que su función requiere, según el principio de mínimo privilegio.
• Las aplicaciones internas deben ser accesibles solo desde puestos gestionados, los colaboradores externos deben entrar por VPN y el tráfico entre ministerios debe filtrarse con más rigor.

¿Cómo comprobar si tu organización tiene las mismas carencias?

Las carencias que describe el informe de la ANSSI se pueden comprobar en otra organización con cinco pruebas: sesiones tras un restablecimiento, cobertura del SOC, alertas por volumen, equipos de acceso y alcance de terceros.

¿Cambiar la contraseña cierra las sesiones abiertas?

Depende de cada aplicación, y en muchas la sesión abierta sigue activa hasta que caduca o se revoca de forma expresa. La prueba requiere una cuenta de ensayo y un cronómetro. Abre sesión en cada aplicación crítica, restablece la contraseña desde el directorio y mide cuánto tiempo sigue respondiendo cada sesión.

En Entra ID, por ejemplo, restablecer la contraseña y revocar de forma expresa no tienen el mismo alcance. Según la documentación de Microsoft, el restablecimiento revoca los tokens de actualización obtenidos con la contraseña y puede dejar activas sesiones establecidas sin ella, mientras que Revoke-MgUserSignInSession invalida todos los tokens de actualización del usuario y las cookies de sesión del navegador. Un token de acceso ya emitido sigue siendo válido hasta que caduca, una hora por defecto, salvo que el cliente y el servicio admitan evaluación continua de acceso.

Una aplicación que emite su token de sesión lo mantiene hasta que ella misma lo revoca. En portales antiguos, cerrar la sesión suele exigir invalidarla en el servidor de aplicaciones. Tu procedimiento de respuesta debe decir quién lo hace y en qué orden.

¿Envían registros al SOC todas las aplicaciones con datos personales?

Las aplicaciones que no figuran entre las fuentes del SIEM quedan fuera de la detección, como ocurrió con ADER en la DGFiP. Cruza el inventario de aplicaciones que tratan datos personales o financieros con la lista de fuentes que recibe el SIEM, y pon responsable y fecha a cada ausencia. La guía sobre qué registros enviar a un SIEM y cuáles no sirve para ordenar esa lista por valor de detección. Un SOC gestionado o interno solo responde de las aplicaciones que le envían eventos.

¿Salta alguna alerta por volumen de consultas?

En la DGFiP no saltó. Según el informe de la ANSSI, los 11 GB intercambiados entre el 22 y el 25 de junio de 2026 no generaron alerta y el número de peticiones por usuario no se medía. El documento recuerda que para esto se usan mecanismos de limitación de peticiones. Un umbral de consultas por usuario y hora es un primer paso, y el análisis de comportamiento (UEBA) lo afina. Los registros señuelo lo complementan, porque una ficha falsa que ningún empleado tiene motivo para abrir avisa en la primera consulta, igual que los honeytokens y cuentas señuelo en el directorio.

¿Desde qué equipos entra tu personal?

El origen más probable de las credenciales, según el informe, son equipos personales y de terceros. Si tu política de uso de equipos personales (BYOD) permite acceder a aplicaciones internas desde máquinas sin gestionar, el segundo factor pasa a ser la principal barrera entre un infostealer y tus datos. El análisis de ClickFix y ACR Stealer muestra cómo operan los infostealers. La vigilancia de credenciales filtradas solo sirve si cada aviso tiene un plazo de respuesta y si esa respuesta incluye limpiar el equipo donde se capturó la contraseña.

¿Hasta dónde llega un tercero conectado a tu red?

El atacante llegó a las aplicaciones tributarias desde otro ministerio y desde el despacho de un profesional externo. En España, la Red SARA cumple una función parecida a la RIE al interconectar administraciones, y en el sector privado ocurre lo mismo con las redes compartidas con filiales o proveedores. Comprueba qué puede ver un equipo ajeno una vez conectado. La guía de segmentación de la red interna recorre ese análisis, y el control de esos accesos forma parte de la gestión del riesgo de terceros.

¿Qué exigen NIS2 y el ENS sobre autenticación y registro de actividad?

El artículo 21.2.j de la Directiva NIS2 incluye entre las medidas de gestión de riesgos el uso de autenticación multifactor o continua «cuando proceda». El Esquema Nacional de Seguridad dedica medidas específicas al mecanismo de autenticación de los usuarios de la organización (op.acc.6) y de los externos (op.acc.5), y al registro de la actividad (op.exp.8).

El caso francés documenta portales sin segundo factor y un portal sin supervisión. NIS2 sitúa esas decisiones bajo la responsabilidad de la dirección.

¿Quién está detrás del ataque y qué deja sin responder el informe?

El informe de la ANSSI llama Zerobytes al actor que reivindicó el robo y no atribuye el ataque a nadie. La vía judicial avanzó aparte. Según Next, un joven de 18 años fue detenido el 18 de agosto, investigado formalmente el 20 y enviado a prisión provisional. Un segundo sospechoso, menor de edad, fue detenido el 26 de agosto y puesto en libertad.

El informe deja varios puntos abiertos. Los nombres de las cuentas están anonimizados y la lista de cuentas comprometidas no se publica. Los permisos de los usuarios en las aplicaciones no se estudiaron y quedan para una auditoría posterior. Sobre los otros organismos del Estado conectados a la RIE, el texto solo indica que se hallaron numerosos rastros de intentos de movimiento lateral.

Restablecer una contraseña suele ser el primer paso de un plan de respuesta a incidentes. En la DGFiP, la sesión abierta en ADER siguió activa casi dieciséis horas después del restablecimiento, con la exfiltración en curso. La primera comprobación de la lista anterior mide ese mismo intervalo en las aplicaciones de cada organización.

Fuentes y atribución: este análisis se apoya en el informe de incidente y la nota oficial de la ANSSI, en el comunicado del Ministerio de Economía francés del 14 de agosto y en la cobertura de The Hacker News, Alliancy y Next. Recoge la información disponible a 6 de octubre de 2026. Parte del informe público está enmascarada. El incidente se debió al abuso de accesos legítimos y a carencias de configuración y supervisión, y ninguna mención implica un fallo de seguridad en los productos o servicios citados. A las personas detenidas les ampara la presunción de inocencia.

Aviso técnico: el comportamiento de las sesiones tras un restablecimiento depende de cada aplicación, de su versión y de su configuración. Las comprobaciones descritas deben hacerse con cuentas de ensayo y en ventanas acordadas, y todo cambio en la revocación de sesiones o en los límites de consulta debe validarse antes en un entorno de pruebas.