· Jonathan Izquierdo · Noticias seguridad  ·

65 min de lectura

Doxing al jefe de antiterrorismo: los datos salieron de filtraciones ajenas, no de la Policía

El INCIBE descartó una intrusión en sus sistemas y las primeras comprobaciones apuntaron a lo mismo en la Policía: los datos del máximo responsable antiterrorista se compusieron cruzando brechas anteriores de empresas y proveedores. Qué significa eso para cualquiera.

El INCIBE descartó una intrusión en sus sistemas y las primeras comprobaciones apuntaron a lo mismo en la Policía: los datos del máximo responsable antiterrorista se compusieron cruzando brechas anteriores de empresas y proveedores. Qué significa eso para cualquiera.

Calcula tu peritaje

Presupuesto orientativo en 2 minutos. Sin compromiso, datos confidenciales.

Calcular precio →

o consulta gratuita

Los datos del máximo responsable de antiterrorismo de España circularon por internet en febrero de 2026, y no salieron de los sistemas de la Policía. Un actor que firmaba como Police-ESP-Doxed publicó en foros de hacking el domicilio, el DNI, los teléfonos y las fechas de nacimiento del jefe de la Comisaría General de Información, junto con datos de una decena de directivos y antiguos cargos del INCIBE. El INCIBE descartó que sus propios sistemas hubieran sido vulnerados y explicó que este tipo de doxing suele componerse agregando filtraciones anteriores de servicios en los que la persona figura como cliente; en el caso policial, las primeras comprobaciones periodísticas apuntaban a lo mismo, aunque no se ha localizado una confirmación técnica primaria de la Policía sobre el origen exacto (EscudoDigital, 26 de febrero de 2026).

Que circulen el domicilio y el DNI del jefe de antiterrorismo es gravísimo. Pero conviene señalar de qué es síntoma, porque no lo es de una negligencia de la Policía: es de que el perfil completo de cualquier persona puede reconstruirse a partir de brechas ajenas que ni ella ni su empleador controlan. El propio INCIBE lo formuló mejor que ningún titular de aquellos días: «la aparición de datos de una persona vinculada a una entidad concreta no demuestra, por sí sola, que haya existido una brecha en los sistemas de esa entidad».

Esa distinción no es un matiz técnico, y es exactamente donde un perito aporta algo. Cambia quién responde, qué se investiga y qué se puede prevenir. Si hubiera habido intrusión, el foco sería el parcheado, la segmentación y la responsabilidad patrimonial del organismo. Como no la hubo, el foco es otro: la vida útil indefinida de los datos ya filtrados, y el hecho de que agregarlos no requiere vulnerar nada, no deja rastro en la víctima institucional y no se corrige actualizando servidores.

Corrección importante: no hubo intrusión en los sistemas de la Policía

Este artículo se escribió los primeros días, cuando la filtración se estaba leyendo como un ataque a la Policía Nacional. No lo fue. El INCIBE descartó que sus sistemas fueran vulnerados y las primeras comprobaciones periodísticas apuntaron a lo mismo en la Policía: los datos procedían de filtraciones anteriores de empresas y proveedores ajenos, cruzadas entre sí para componer perfiles de personas concretas (EscudoDigital, 26 de febrero de 2026). El INCIBE lo dijo con todas las letras: «la aparición de datos de una persona vinculada a una entidad concreta no demuestra, por sí sola, que haya existido una brecha».

El autor firmaba como Police-ESP-Doxed, y en junio de 2026 la Policía Nacional detuvo en la provincia de Granada a un menor como presunto responsable, por un delito de revelación de secretos (elhacker.net).

Por qué importa la distinción, y por qué el caso sigue siendo grave: no es lo mismo que alguien entre en los sistemas policiales que un doxing por agregación. Lo segundo no requiere vulnerar nada, no deja rastro en la víctima institucional y no se puede prevenir parcheando servidores. Es, en la práctica, más difícil de combatir. Lo que expone no es un fallo de la Policía: es que el perfil completo de cualquier persona puede reconstruirse a partir de brechas ajenas que nadie controla.

TL;DR - Resumen ejecutivo

En 60 segundos:

AspectoDato clave
Qué pasóPublicación (doxing) de datos de altos mandos y agentes, compuesta a partir de filtraciones previas de terceros, no de una intrusión en sistemas policiales
Afectado principalJefe de la Comisaría General de Información de la Policía Nacional
Otros afectadosUna decena de directivos y antiguos cargos del INCIBE
ContextoMisma semana que los incidentes de Moncloa, Fiscalía y Consejo de Seguridad Nacional, sin que se haya acreditado un vector común
Datos publicadosDomicilio, DNI, teléfonos, fechas de nacimiento, correos y contraseñas antiguas — de brechas de terceros, no de sistemas policiales
AutoríaActor identificado como Police-ESP-Doxed; en junio de 2026 la Policía detuvo en Granada a un menor por revelación de secretos
Riesgo críticoExposición personal de mandos identificados, no compromiso operativo de sistemas
Patrón sistémicoUn incidente más en una serie institucional (2024-2026); varios, este incluido, no fueron intrusiones sino difusión de datos compuestos con filtraciones de terceros
Marco legalRGPD y LOPDGDD (responsables privados), LO 7/2021 (datos policiales) y Código Penal art. 197 (autores)

Consulta pericial gratuita

Cuándo salió a la luz

El caso se hizo público a finales de febrero de 2026, cuando aparecieron en foros de hacking fichas con datos personales de mandos policiales y de directivos del INCIBE (The Objective; EscudoDigital). Coincidió en el tiempo con otros incidentes que la cobertura agrupó bajo la etiqueta de «semana negra».

No reproduzco aquí una cronología hora a hora. La secuencia exacta de comparecencias, reuniones y comunicados institucionales no puede reconstruirse con enlaces a fuentes primarias, y una tabla de horas sin respaldo documental daría una precisión que los hechos públicos no sostienen. Lo verificable es el marco: la publicación se produjo a finales de febrero y el desenlace conocido llegó en junio de 2026, con la detención de un presunto responsable (más abajo).

La respuesta institucional a aquella semana fue objeto de crítica pública, pero conviene una salvedad que cambia la lectura: medir a la Policía Nacional con la vara de los plazos de la NIS2 sería un error de categoría, porque esos plazos rigen la reacción a una intrusión en los propios sistemas y aquí no la hubo.

Qué datos fueron expuestos: análisis en profundidad

Aunque los detalles completos no se han hecho públicos por razones de seguridad nacional, las fuentes periodísticas y las muestras que han circulado en foros especializados permiten trazar un mapa bastante preciso de la tipología de datos expuestos. Como perito forense, analizo cada categoría no solo por lo que es, sino por lo que un adversario puede hacer con ella.

Datos personales de altos mandos

DatoRiesgo inmediatoEscenario de ataque
Nombre completo del jefe antiterroristaIdentificación por actores terroristasAtención selectiva, vigilancia física, amenazas a familia
Dirección de residenciaVulnerabilidad física directaAtención a domicilio, vigilancia de rutinas
Teléfono personalAcceso al dispositivo móvilSIM swapping, spyware tipo Pegasus, ingeniería social
Correo electrónicoPunto de entrada digitalSpear-phishing dirigido, credential stuffing en otros servicios

Lo que un ciudadano medio no entiende es que el nombre y el cargo del jefe de antiterrorismo de la Policía Nacional es información que hasta ahora solo conocian personas con acreditación de seguridad. Es información clasificada. No aparece en el BOE, no se pública en ningun directorio. Es información que se protege expresamente porque las personas que la ostentan son objetivos de primer orden para organizaciones terroristas.

Ahora esa información esta en internet. Y no va a desaparecer.

Lo que NO salió, y por qué importa decirlo

No aparecieron credenciales de acceso a sistemas policiales —ni de SIDENPOL, ADEXTTRA, SIRDEE, ATLAS o la VPN corporativa— ni, con ellas, ninguna cadena de ataque hacia esos sistemas. Los datos se compusieron cruzando filtraciones de operadoras, eléctricas y bancos donde estas personas figuraban como clientes, de modo que lo que apareció fueron datos personales de consumidor, no llaves de sistemas policiales.

La distinción es la tesis de este artículo y conviene sostenerla también aquí: un doxing por agregación no toca los sistemas de la organización. Lo que expone es el rastro que una persona ha ido dejando en decenas de servicios privados a lo largo de años — y eso es exactamente lo que lo hace difícil de prevenir, porque no depende de la seguridad del empleador.

El doxing por agregación y el compromiso de sistemas son fenómenos distintos y se defienden de forma distinta, y confundirlos tiene consecuencias prácticas: contra el primero no sirve parchear, segmentar ni rotar credenciales, porque el atacante nunca entró. Sirve reducir la superficie de datos personales que una persona deja en servicios de terceros — y eso ni lo controla la organización ni se arregla con presupuesto de seguridad.

La superficie de ataque de las fuerzas de seguridad modernas

Un aspecto que rara vez se discute públicamente es la enorme superficie de ataque que presentan las fuerzas de seguridad modernas. La digitalización de la actividad policial, acelerada desde 2020, ha multiplicado los puntos de entrada potenciales:

  • Acceso remoto: Miles de agentes acceden a sistemas policiales desde dispositivos móviles y portatiles fuera de comisaría
  • Integraciones europeas: Conexiones con SIS II (Sistema de Información Schengen), Europol SIENA, bases de datos de Interpol
  • Proveedores externos: Empresas privadas que desarrollan y mantienen software policial con acceso privilegiado
  • Comunicaciones cifradas: Sistemas como SIRDEE que requieren infraestructura de gestión de claves
  • Almacenamiento de evidencia digital: Repositorios con pruebas judiciales digitales de miles de investigaciones
  • Dispositivos IoT y cámaras: Sistemas de videovigilancia, lectores de matriculas y sensores conectados a la red

La superficie es enorme por definición: la Policía Nacional cuenta con decenas de miles de agentes que acceden a diario a múltiples sistemas desde dentro y fuera de comisaría, y cada credencial válida es una vía potencial de entrada. Proteger esa superficie con un sistema anti-APT desactualizado es como proteger una fortaleza con murallas de papel.

La descentralizacion agrava el problema. La Policía Nacional opera desde comisarias repartidas por toda España, cada una con su propia infraestructura de red local. La seguridad de toda la organización depende de que cada una de esas comisarias mantenga sus sistemas actualizados y correctamente configurados. En mi experiencia auditando redes distribuidas, la comisaría más remota y con menos recursos de TI es, invariablemente, el punto más vulnerable.

El papel crítico de los proveedores externos

Un aspecto que merece atención específica es el papel de los proveedores externos en la cadena de seguridad de la Policía Nacional. La Administración no desarrolla ni mantiene sus propios sistemas informáticos: contrata a empresas privadas para hacerlo. Estas empresas tienen acceso privilegiado a los sistemas más sensibles del Estado.

En la práctica, un ingeniero de una empresa contratista que mantiene el sistema de gestión de bases de datos de la Policía Nacional puede tener más acceso técnico a esos datos que el propio comisario jefe. Ese ingeniero pasa por un proceso de habilitación de seguridad, si, pero una vez dentro, sus credenciales son tan valiosas como las de cualquier agente. Y si esas credenciales se comprometiesen como parte de esta brecha, o como parte de un ataque a la cadena de suministro, las consecuencias serían idénticas.

He trabajado en casos donde el vector de entrada fue exactamente este: un empleado de un contratista cuyo portátil de trabajo fue comprometido porque lo usaba también para fines personales. Desde ese portátil, el atacante accedio a la VPN del cliente con las credenciales del contratista y desde ahi a los sistemas internos. La Policía Nacional tiene decenas de contratos activos con proveedores de tecnología. Cada uno de esos contratos es un potencial vector de entrada si no se gestiona con el nivel de seguridad adecuado.

Información operativa clasificada

Alcance de este apartado: las categorías que siguen describen por qué la identidad y el destino de un mando son datos sensibles y qué haría un adversario con ellos. No son lo que salió en esta publicación —que fue rastro personal de consumidor (domicilio, DNI, teléfonos, correos)—: los datos operativos clasificados viven en sistemas que no fueron vulnerados. Se mantienen aquí porque explican la gravedad del objetivo elegido, no un compromiso de sistemas.

CategoríaQue incluyeConsecuencia si se explota
Estructura organizativa internaOrganigrama completo de unidades, jerarquía de mandoUn adversario conoce exactamente como funciona el aparato de seguridad
Destinos y asignacionesQue agentes están en que unidades y localizacionesIdentificación de agentes encubiertos por descarte
Protocolos de actuaciónProcedimientos operativos estándarAnticipación de respuestas policiales por parte de criminales
Contactos de cooperación internacionalNombres y datos de enlaces con Europol, FBI, MI5Compromiso de relaciones de inteligencia bilaterales
Datos de formación especializadaCursos realizados por cada agente (explosivos, cibercrimen, antiterrorismo)Identificación de perfiles de alto valor por especialidad

En mi experiencia, la información de destinos y asignaciones es particularmente crítica. Un agente de la Policía Nacional destinado en la Comisaría General de Información cuya asignación llegue a hacerse pública queda automáticamente identificado como agente de inteligencia policial. Si ese agente estaba realizando trabajo encubierto en alguna red de radicalizacion, su vida puede estar en peligro real.

Pero hay un aspecto aun más insidioso que la exposición directa de datos: la capacidad de inferencia. Un analista de inteligencia enemigo con acceso a la filtración puede cruzar los datos de destinos, formación y contactos para reconstruir operaciones completas. No necesita que los datos digan explícitamente “el agente X esta infiltrado en la célula Y”. Le basta con saber que el agente X esta destinado en la Comisaría General de Información, que realizo un curso de “técnicas de infiltración en redes de radicalizacion” y que sus contactos de enlace incluyen a homologos del MI5 britanico y la DGSI francesa. Con esos tres datos, la inferencia es trivial.

Este tipo de análisis de inferencia se emplea también para detectar fugas de información corporativa: con acceso a datos de recursos humanos, formación y contactos se puede reconstruir buena parte de la estructura interna de una organización. Un servicio de inteligencia hostil con acceso a los datos de la Policía Nacional puede hacer exactamente lo mismo.

La valoración de estos datos en el mercado de inteligencia

Las cifras de dark web que circulan por registro y por credencial no tienen una fuente verificable que las sostenga, y mezclan precio de mercado con valor estratégico, que son cosas distintas. Lo cierto sin necesidad de cuantificarlo: los datos de un mando antiterrorista no valen lo que un par de credenciales de una plataforma de streaming. Su valor no está en un precio de reventa, sino en la ventaja que dan a quien quiera localizar o vigilar a esa persona. Y ahora están disponibles para quien quiera buscarlos.

Por qué importa la sensibilidad, no el volumen

La filtración de un nombre y un destino policial puede poner en riesgo la seguridad de un agente, y por eso la identidad de determinados cargos se protege de forma reforzada en los procedimientos judiciales. Lo que hace singular a este caso no es el volumen —seguramente menor que el de otras filtraciones— sino la sensibilidad extrema de la información expuesta: los datos de un mando antiterrorista valen, en términos de inteligencia, mucho más que millones de registros de ciudadanos ordinarios.

Análisis técnico del vector de ataque

Cómo se compuso la ficha, y por qué las hipótesis de intrusión no aplican aquí

Alcance de este apartado: lo que sigue analiza los otros incidentes de aquella semana —Moncloa, Fiscalía, Consejo de Seguridad Nacional—, donde sí se habló de compromiso de sistemas. No explica la publicación de datos del mando policial, que no requirió intrusión alguna. Se mantiene porque el estado de las defensas del Estado es un asunto de interés propio, pero no es la causa de este caso y conviene no leerlo como tal.

En el caso que abre este artículo el «cómo» es mucho menos sofisticado de lo que se supuso: seleccionar un nombre, rastrearlo en los repositorios de filtraciones antiguas —operadoras, eléctricas, banca, plataformas— y ensamblar las piezas hasta obtener una ficha. No hay vector de intrusión que buscar porque no hubo intrusión, y esa es precisamente la razón de que sea difícil de prevenir.

Sobre el sistema anti-APT del Estado (relativo a los otros incidentes de la semana)

Se publicó entonces que el sistema anti-APT (Advanced Persistent Threat) del Estado llevaba 100 días sin recibir actualizaciones por un fallo en el proceso de contratación pública. El dato procede de la cobertura periodística de aquellos días y no se ha contrastado con una fuente institucional; lo que sigue explica qué implicaría de ser exacto, no qué causó esta publicación de datos.

Un sistema anti-APT es el equivalente al sistema inmunologico de una red informática. Funciona mediante:

  • Análisis comportamental: Detecta patrones de actividad anómalos comparandolos con líneas base de comportamiento normal
  • Sandboxing: Ejecuta archivos sospechosos en entornos aislados para observar su comportamiento antes de permitir su entrada en la red
  • Feeds de inteligencia de amenazas: Recibe actualizaciones constantes sobre nuevas amenazas, indicadores de compromiso y firmas de malware
  • Correlación de eventos: Cruza datos de múltiples fuentes (logs, tráfico de red, endpoints) para identificar ataques complejos

Sin actualizaciones durante 100 días, un sistema anti-APT es como un medico que no ha leido una revista médica en tres meses: no conoce las enfermedades nuevas. En el mundo de la ciberseguridad, 100 días sin actualizaciones equivalen a cientos o miles de nuevas vulnerabilidades, nuevas variantes de malware y nuevas técnicas de ataque que el sistema simplemente no puede detectar.

He trabajado con sistemas anti-APT de los principales fabricantes (Palo Alto Cortex, CrowdStrike Falcon, SentinelOne) y todos ellos dependen de actualizaciones diarias, a veces horarias, de sus feeds de inteligencia. Un desfase de 24 horas ya es motivo de alerta en cualquier SOC serio; uno de 100 días deja el sistema ciego ante todo lo aparecido en ese intervalo. Es una deficiencia grave de gestión, y así conviene llamarla: «negligencia criminal» es una calificación jurídica que no corresponde hacer a un perito, y menos sobre hechos que no ha examinado.

Hipótesis 2: Compromiso de la cadena de suministro

La segunda hipótesis es que el atacante comprometiese a un proveedor tecnológico común a varias instituciones afectadas. Es un vector real —un compromiso de proveedor puede alcanzar a la vez a organizaciones con dependencias comunes—, pero no hay evidencia pública que lo vincule con este doxing, y las estadísticas de frecuencia de Mandiant sobre este vector (en torno al 17 % de las intrusiones investigadas) no son una probabilidad para este caso concreto.

El modelo de contratación pública español favorece involuntariamente este tipo de ataques. La Administración General del Estado tiende a adjudicar contratos de servicios tecnológicos a un número reducido de grandes integradores. Estos integradores tienen acceso privilegiado a los sistemas de múltiples ministerios y organismos. Comprometer a uno de ellos es comprometer a todos sus clientes simultáneamente.

Hipótesis 3: Spear-phishing dirigido (probabilidad media)

El spear-phishing contra personal de fuerzas de seguridad es una técnica documentada y habitual, y los dos datos que la sitúan vienen del mismo informe. En el ENISA Threat Landscape 2025, el phishing es el vector de intrusión dominante con cerca del 60 % de los casos observados —por delante de la explotación de vulnerabilidades (21,3 %) y de las botnets (9,9 %)—, y la administración pública es el sector más atacado de la Unión Europea, con el 38,2 % de los incidentes registrados, muy por encima del transporte (7,5 %) o las finanzas (4,5 %). Un agente con acceso privilegiado que haga clic en un enlace malicioso puede abrir la puerta a toda la red.

Hipótesis 4: Vulnerabilidad en acceso remoto (probabilidad media)

Desde la pandemia, miles de agentes acceden a sistemas policiales desde fuera de las comisarias. Las VPN y los sistemas de acceso remoto son puntos de entrada habituales en ataques contra infraestructura gubernamental. La vulnerabilidad en Ivanti Connect Secure que afecto a la Comisión Europea en 2025 es un ejemplo directo de este vector.

Hipótesis 5: Amenaza interna (probabilidad baja)

Aunque la escala y simultaneidad del ataque apuntan a un actor externo, no se puede descartar completamente un componente interno. Un insider descontento con acceso privilegiado podría haber facilitado el acceso inicial o proporcionado credenciales directamente.

Indicadores técnicos que señalan un ataque sofisticado

Aunque no tengo acceso a los indicadores de compromiso (IoCs) clasificados, varios elementos públicos permiten inferir que este no fue un ataque oportunista sino una operación planificada y ejecutada con recursos significativos:

Precisión en la selección de objetivos: la publicación no fue un volcado masivo e indiscriminado, sino fichas de personas concretas. Eso indica selección previa de los objetivos por su cargo —algo que se hace consultando fuentes abiertas— y no reconocimiento de una estructura interna: para cruzar filtraciones antiguas basta con saber a quién buscar.

Simultaneidad de los ataques: Comprometer cuatro instituciones del Estado en la misma ventana temporal requiere coordinacion operativa y capacidad para mantener múltiples líneas de ataque activas simultáneamente. Los grupos de cibercrimen común rara vez tienen esta capacidad. Los grupos APT estatales y los servicios de inteligencia hostiles, si.

Nadie lo detectó porque no había nada que detectar: que el caso se conociera por la publicación en foros y no por una alerta interna se leyó entonces como evasión sofisticada. La explicación es más simple y más incómoda: ningún sistema de la Policía registró nada porque la composición de la ficha ocurrió íntegramente fuera de su perímetro. Un DLP no puede alertar de datos que no salen de tu red.

Aprovechamiento de la ventana de vulnerabilidad: Si los atacantes cronometraron su operación para coincidir con el vacio de actualizaciones del sistema anti-APT, tenían conocimiento previo del estado de los contratos de mantenimiento. Esto podría indicar un insider que proporciono información, o una monitorización sofisticada de los portales de contratación pública.

Y aquí conviene detenerse. Los cuatro indicadores de arriba se leyeron en su día como la firma de un actor estatal. No lo eran: en junio de 2026 la Policía Nacional detuvo en la provincia de Granada a un menor como presunto responsable. La lección no es menor para cualquiera que analice un incidente en caliente: la sofisticación aparente de un resultado no acredita la sofisticación del autor. Componer una ficha cruzando filtraciones antiguas produce un resultado que parece inteligencia de Estado y no requiere más que paciencia y acceso a repositorios que están al alcance de cualquiera.

Comparación con brechas gubernamentales internacionales

BrechaPaísAñoVectorDatos expuestosTiempo de detección
OPM BreachEE.UU.2015Credenciales comprometidas de contratista21.5M empleados federales, huellas digitales, SF-8614 meses
BlueLeaksEE.UU.2020Vulnerabilidad web en proveedor Netsential269 GB, 200 departamentos policialesDesconocido (publicación directa)
Hack Estonian MFAEstonia2007DDoS masivo + exfiltraciónDatos diplomáticos y gubernamentalesDías
APT28 vs BundestagAlemania2015Spear-phishing16 GB datos parlamentariosSemanas
ANSSI breach intentoFrancia2021Centreon supply chain (Sandworm)Múltiples organismos, acceso prolongado3 años (!)
Policía NacionalEspaña2026Sin intrusión: agregación de filtraciones previas de tercerosDatos personales del jefe de la Comisaría General de InformaciónNo aplica

Lo que la tabla deja ver es que este caso no pertenece a la misma categoría que los demás: en todos los anteriores hubo intrusión, vector y tiempo de detección. Aquí no hay ninguna de las tres cosas, y sin embargo el dato expuesto —la identidad y el domicilio del jefe de antiterrorismo— es tan sensible como el de cualquiera de ellos. Esa es la lección incómoda: la gravedad del resultado no guarda relación con la sofisticación del medio.

El sistema anti-APT sin actualizar: qué implica y a qué incidentes se refiere

Qué hace un sistema anti-APT y por qué es crítico

Para que el lector no técnico entienda la gravedad de que el sistema anti-APT del Estado llevase 100 días sin actualizaciones, necesito explicar que hace exactamente este tipo de sistema.

Un sistema anti-APT es la defensa de última generación contra los ataques más sofisticados. Los antivirus tradicionales detectan malware conocido comparando archivos con una base de datos de firmas. Los sistemas anti-APT van mucho más alla:

  1. Análisis comportamental en tiempo real: Monitorizan cada proceso, cada conexión de red, cada operación de lectura/escritura en busca de patrones que indiquen un ataque, incluso si el malware es completamente nuevo y desconocido

  2. Sandboxing avanzado: Cada archivo que entra en la red (adjuntos de email, descargas web, transferencias USB) se ejecuta primero en un entorno virtual aislado donde se observa su comportamiento durante segundos o minutos antes de permitir su paso

  3. Feeds de inteligencia de amenazas (Threat Intelligence): Reciben actualizaciones constantes, a veces cada hora, con información sobre nuevos indicadores de compromiso (IoCs), direcciones IP maliciosas, dominios de comando y control, hashes de malware reciente

  4. Correlación SIEM integrada: Cruzan datos de miles de fuentes (firewalls, endpoints, servidores, aplicaciones) para detectar patrones de ataque que no serían visibles analizando cada fuente por separado

  5. Machine learning y detección de anomalias: Modelos que aprenden el comportamiento normal de la red y alertan cuando algo se desvie de ese patrón, incluso si no coincide con ningun ataque conocido

  6. Respuesta automatizada: Capacidad de aislar automáticamente equipos comprometidos, bloquear comunicaciones con servidores de comando y control y preservar evidencia forense

Por que 100 días sin actualizaciones es catastrofico

En ciberseguridad, el ciclo de vida de una amenaza se mide en horas, no en meses. Cada día se publican decenas de nuevas vulnerabilidades. Cada semana aparecen nuevas variantes de malware. Cada mes, nuevas técnicas de ataque.

En un intervalo así se acumula todo lo que el sistema deja de ver: miles de vulnerabilidades nuevas en las bases públicas —la NVD del NIST registra decenas al día—, numerosas campañas de los grupos más activos, familias de malware inéditas y una corriente continua de indicadores de compromiso que el sistema desactualizado ya no recibe. No pongo cifras exactas por hito porque serían proyecciones, no mediciones: lo relevante es el orden de magnitud, y es grande.

Sin esas actualizaciones, el sistema anti-APT del Estado era esencialmente ciego ante cualquier amenaza posterior a la fecha en que dejo de actualizarse. Un atacante que utilizase cualquier herramienta o técnica desarrollada en esos 100 días podría operar con total impunidad dentro de la red.

El problema de la contratación pública en ciberseguridad

Y aquí llegamos al fondo del asunto. El sistema anti-APT dejo de recibir actualizaciones no porque hubiese un fallo técnico, no porque el fabricante dejase de dar soporte, sino porque el contrato de mantenimiento expiro y el nuevo contrato no se adjudico a tiempo. Un problema burocratico. Un trámite administrativo.

En mi opinion profesional, alguien debería asumir responsabilidades políticas por esto. No es aceptable que la seguridad de las fuerzas de seguridad del Estado, que la seguridad del jefe de antiterrorismo de España, dependa de que un expediente de contratación se trámite a tiempo.

El problema es estructural. La Ley de Contratos del Sector Público (Ley 9/2017) establece plazos y procedimientos que, aplicados a la contratación de servicios de ciberseguridad críticos, generan ventanas de vulnerabilidad inaceptables:

  • Licitacion abierta: 35-45 días de plazo mínimo de presentación de ofertas
  • Evaluación y adjudicacion: 30-60 días habituales
  • Formalización del contrato: 10-15 días adicionales
  • Recursos: Si un licitador recurre, el proceso puede paralizarse meses

En total, el periodo entre la finalización de un contrato y la entrada en vigor del siguiente puede superar fácilmente los 6 meses. Seis meses sin actualizaciones de seguridad en un sistema que protege la infraestructura crítica del Estado.

La solución técnica existe y es sencilla: contratos marco con ejecución inmediata, cláusulas de prórroga automática hasta la adjudicacion del nuevo contrato, o incluso la internalizacion de capacidades críticas de ciberseguridad. Pero implementar estas soluciones requiere voluntad política, y hasta ahora esa voluntad no ha existido.

Vendor lock-in en la Administración

Otro aspecto que rara vez se discute es el vendor lock-in en los contratos de ciberseguridad del Estado. Cuando un único proveedor controla el sistema anti-APT de múltiples organismos, la dependencia es total. Si ese proveedor falla, no hay plan B. En mis auditorias para el sector privado, siempre recomiendo arquitecturas multi-vendor con redundancia. Es más caro, pero el coste de un fallo total como el que acabamos de presenciar es incalculablemente mayor.

Impacto en las operaciones de seguridad nacional

Riesgos para las operaciones antiterroristas

Lo que más me preocupa como profesional de la ciberseguridad es el efecto cascada sobre las operaciones antiterroristas en curso. España mantiene un nivel de alerta antiterrorista 4 (sobre 5) desde 2015, y la Policía Nacional gestiona decenas de operaciones simultáneas contra celulas yihadistas, lobos solitarios y organizaciones de extrema derecha.

La exposición de los datos del jefe de la unidad antiterrorista tiene consecuencias operativas inmediatas:

Compromiso de la cadena de mando: El jefe antiterrorista coordina todas las operaciones. Si un adversario conoce su identidad, sus datos de contacto y sus patrones de comunicación, puede monitorizar o incluso suplantar sus comunicaciones. He documentado ataques de suplantación de identidad en mis peritajes que comenzaron exactamente así: con datos personales filtrados que se usaron para construir un perfil de comunicación creíble.

Identificación de agentes encubiertos: Si la filtración incluye destinos y asignaciones de agentes, como sugieren las fuentes, un análisis cruzado permite identificar a agentes destinados en la Comisaría General de Información que esten realizando trabajo encubierto en redes de radicalizacion. Esto no solo pone en peligro al agente, sino que compromete la operación entera y puede alertar a los objetivos.

Desconfianza en los canales de comunicación: Si los sistemas de comunicación policial están comprometidos, los agentes no pueden confiar en que sus comunicaciones sean privadas. Esto genera una parálisis operativa que puede durar meses, hasta que se restablezca la confianza en la infraestructura.

Compromiso de la cooperación internacional: Los datos de contacto de los enlaces con Europol, FBI, MI5 y otros servicios de inteligencia aliados pueden haberse filtrado. Esto no solo afecta a España: afecta a la confianza de nuestros aliados en compartir inteligencia con nosotros. Y en el mundo de la inteligencia, la confianza es la moneda más valiosa.

Dónde se detiene el daño, y por qué eso importa

Un doxing por agregación tiene un techo, y conviene saber dónde está. Lo que se compone cruzando filtraciones de operadoras, bancos y comercios es el rastro que una persona ha dejado como consumidora: domicilio, documento de identidad, teléfonos, correos y contraseñas antiguas de servicios privados. Con eso se puede localizar a alguien, suplantarlo ante un servicio de atención al cliente o preparar un señuelo creíble. No se accede a ningún sistema de su organización, porque esos datos nunca estuvieron ahí.

Esa frontera es exactamente lo que separa este caso de una intrusión, y explica por qué las medidas que se reclamaron entonces —rotar credenciales, segmentar la red, auditar accesos— no habrían evitado nada: son respuestas a un problema distinto del que ocurrió.

Lo que sí queda expuesto, y no tiene arreglo técnico, es la seguridad personal de quien ocupa un cargo sensible. Un domicilio publicado no se revoca. Y esa exposición no depende de lo bien protegida que esté la red de su empleador, sino de decenas de contratos privados que esa persona firmó a lo largo de años y sobre cuya seguridad no tuvo ningún control. Es un problema real, más difícil de resolver que una intrusión, y es el que este caso deja sobre la mesa.

El patrón sistémico: no es un caso aislado

Tabla de brechas institucionales en España 2024-2026

Lo que convierte esta brecha en algo más que un incidente aislado es el patrón de ataques a instituciones del Estado español que se ha intensificado en los últimos dos años. He elaborado esta tabla para que quede constancia del problema sistémico que estamos enfrentando como país.

Alcance de esta tabla: de las entradas siguientes, la del Hospital Clínic está contrastada —el ataque de RansomHouse fue el 5 de marzo de 2023—; las demás recogen lo publicado en su momento y no he podido cotejar cada fecha e importe con una fuente institucional. Léanse como orden de magnitud del patrón, no como un registro cerrado. Y una precisión que evita confundir dos cosas: el episodio de 2026 que motiva este artículo no fue una intrusión en el INCIBE, según el propio organismo.

FechaInstituciónTipo de brechaDatos afectadosConsecuencia conocida
Mar 2024INCIBEIncidente reportado sobre sistemas internosDatos de incidentes reportados, contactos empresarialesInvestigación interna, comunicado público tardío
Jun 2024Ayuntamiento de Sevilla (LockBit)Ransomware1,5 TB (cifra reivindicada por LockBit): datos municipales, nóminas, datos de ciudadanos5M de euros en costes de recuperación, semanas sin servicios
Sep 2024Fiscalía de BarcelonaAcceso a expedientes digitalesExpedientes de investigaciones en cursoImpacto en procedimientos judiciales
Mar 2023Hospital Clínic de BarcelonaRansomware RansomHouse4,5 TB (cifra reivindicada por el grupo): datos de pacientes e investigaciones clínicasAplazamiento de 150 cirugías, datos publicados en la dark web
Ene 2025DGT (Dirección General de Tráfico)Filtración base de datos34 millones de registros de conductoresDatos vendidos en dark web por 2 BTC
Feb 2025Congreso de los DiputadosPhishing masivoCredenciales de diputados y asesoresAcceso a emails parlamentarios
Sep 2025Ministerio de CienciaIDOR (Insecure Direct Object Reference)Datos de proyectos de investigación y evaluadoresExposición de información sensible de I+D
Dic 2025Hacienda (AEAT)IDORDatos fiscales de contribuyentesAcceso a datos tributarios de terceros
Feb 2026Endesa (infraestructura crítica)Brecha de datosDatos de clientes y contrataciónMillones de registros comprometidos
Feb 2026Policía NacionalDoxing por agregación, sin brecha de sistemasDatos personales del jefe de la Comisaría General de InformaciónExposición personal del mando identificado
Feb 2026Presidencia del Gobierno (Moncloa)Doxing por agregación; no consta intrusiónDatos de contacto de altos cargosCrisis institucional. El hueco de soporte anti-APT es real y está documentado, pero no se ha acreditado que fuera la vía
Feb 2026Fiscalía General del EstadoDatos difundidos; origen no acreditadoInformación institucionalInvestigación en curso
Feb 2026Consejo de Seguridad NacionalDatos difundidos; origen no acreditadoDatos de contacto de miembrosInvestigación en curso

Trece incidentes en menos de dos años — y conviene no leerlos todos igual: cuatro de las trece filas no son brechas de sistemas, sino difusión de datos compuestos a partir de filtraciones anteriores. Confundir las dos cosas es lo que convierte un fallo de contratación en un ciberataque, y es exactamente el error que este artículo desmonta. Y estas son solo las que se han hecho públicas. En mi experiencia, por cada brecha que llega a los medios hay al menos dos o tres que se gestionan internamente sin comunicación pública.

Mirando esta tabla, el patrón es inconfundible. No estamos ante incidentes aislados. Estamos ante un fallo sistémico de la ciberseguridad institucional española. Es como si tuvieses un edificio con trece goteras en dos años: en algun momento dejas de arreglar goteras y aceptas que el problema es el tejado.

El coste acumulado no puede cifrarse con rigor

Sumar el coste de todos estos incidentes para presentar un total daría una precisión ficticia: los informes de IBM publican promedios de su muestra global, en dólares y por brecha, no un coste verificado por episodio español, y encadenar estimaciones fila por fila —cada una con su propio margen— no produce una cifra defendible. Que la factura acumulada de la ciberinseguridad institucional es alta es evidente; ponerle un número redondo sin un modelo reproducible detrás sería inventarlo. Para el orden de magnitud del coste medio de una brecha, la referencia es el informe de IBM, con sus cifras globales y su metodología.

Con una fracción de lo que cuesta remediar se podría prevenir: financiar una agencia con autoridad ejecutiva, desplegar MFA en la Administración y cerrar los vacíos contractuales. La prevención casi siempre sale más barata que la remediación.

La conexión con la brecha de Moncloa

Aquella semana se dio por hecha una conexión entre este caso y la brecha de Moncloa, pero no consta un vector común. Coinciden en la fecha y poco más: la publicación relativa al mando policial se atribuyó provisionalmente a la agregación de filtraciones de terceros, no a una intrusión. Que un análisis forense cruzado pudiera hallar más adelante un nexo es una hipótesis, no un hecho acreditado, y presentarla como certeza —«mismo vector», «evidencia abrumadora»— fue precisamente el error que este artículo corrige.

La transposición pendiente de NIS2

El plazo de transposición de la Directiva NIS2 (UE) 2022/2555 venció en octubre de 2024, y España seguía sin haberla incorporado: el 8 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE por no haber notificado la transposición completa (Comisión Europea). La Directiva establece obligaciones de ciberseguridad para numerosas entidades esenciales e importantes, incluidas administraciones públicas.

Como detallo en mi análisis de la NIS2 y sus implicaciones para España, la directiva exige gestión de riesgos con evaluaciones periódicas, notificación temprana de incidentes en 24 horas (y notificación completa en 72), medidas técnicas proporcionales al riesgo, continuidad de negocio y seguridad de la cadena de suministro.

Con un matiz que este caso obliga a subrayar: la propia Directiva excluye de su ámbito a las entidades públicas que actúan en seguridad nacional, seguridad pública y garantía del cumplimiento de la ley (art. 2.7, texto en español). Por eso NIS2 no puede presentarse como el régimen directamente aplicable a la actividad policial analizada aquí, ni su retraso como la causa de este doxing —que, además, no fue una intrusión en sistemas del Estado—. El retraso en la transposición es un problema real de gobernanza; no es la explicación de este caso.

Reclamación por responsabilidad patrimonial: a quién y en qué plazo

La responsabilidad patrimonial de la Administración exige un funcionamiento —normal o anormal— del servicio público al que imputar el daño, y que el perjuicio sea efectivo, evaluable e individualizado (art. 32 de la Ley 40/2015). En este caso los datos no salieron de un sistema policial, de modo que la vía de reclamación apuntaría, en su caso, frente a las empresas cuyas brechas anteriores alimentaron el perfil, no frente al Ministerio del Interior.

El plazo para reclamar por responsabilidad patrimonial es de un año desde que se tuvo conocimiento del hecho (art. 67.1 de la Ley 39/2015). Conviene no esperar a una notificación formal del alcance de la exposición, que puede tardar meses: se inicia la reclamación con la información disponible y se completa con el informe pericial individualizado.

Qué normas están en juego (y contra quién)

Conviene no presentar un cuadro de «obligaciones incumplidas» por la Administración, porque eso presupone una intrusión en sistemas del Estado que no consta. El marco aplicable depende de quién sufrió realmente la brecha y de la finalidad del tratamiento:

  • Si los datos procedían de empresas privadas (operadoras, bancos, comercios), las obligaciones de protección y notificación recaían sobre cada uno de esos responsables privados, bajo el RGPD y la LOPDGDD, no sobre Interior.
  • Los tratamientos policiales con fines de prevención e investigación penal no se rigen por el RGPD general, sino por la LO 7/2021; y para la Administración General del Estado la AEPD resuelve con apercibimiento (art. 77 LOPDGDD), no con las multas del régimen empresarial. Publicar los topes de 10 o 20 M€ como «consecuencia» para la Policía sería incorrecto.
  • La responsabilidad de los autores de la agregación y difusión se tipifica en los arts. 197.1, 197.2 y 197.3 del Código Penal —el tipo por el que se practicó la detención—, como se detalla más abajo.

Sobre las responsabilidades políticas

El hueco de soporte del sistema anti-APT que se destapó aquella semana es un fallo de gestión real y merece depuración de responsabilidades en el plano político y administrativo. Pero atribuir negligencia concreta a un órgano o a una persona exige un expediente y una pericial que aquí no existen, y hacerlo sobre hechos no examinados es, además de temerario, ajeno a lo que un perito puede sostener. Este apartado se limita, por eso, al marco: qué normas rigen y a quién, sin señalar culpables por estos hechos.

La dimensión penal: delitos que podrían haberse cometido

Más allá de la responsabilidad administrativa, se planteó también una eventual dimensión penal —la de los atacantes y la de una hipotética negligencia interna—. Conviene tratarlas por separado, porque solo la primera tiene aquí un hecho al que agarrarse.

Delitos atribuibles a los atacantes:

DelitoArtículo del Código PenalPenaAplicabilidad a lo que ocurrió
Descubrimiento y revelación de secretosArt. 197.1 y 197.21 a 4 años de prisiónEs el tipo por el que se practicó la detención. El 197.2 alcanza a quien se apodera o utiliza datos personales registrados en ficheros, que es exactamente lo que hace la agregación de filtraciones ajenas
Difusión a terceros de los datos obtenidosArt. 197.3mitad superior de la pena anteriorPublicar el resultado en foros es la conducta agravada, y es el núcleo del doxing
Acceso ilícito a sistemas informáticosArt. 197 bis.16 meses a 2 años de prisiónNo aplica aquí. El tipo exige acceder al sistema «vulnerando las medidas de seguridad establecidas para impedirlo», y no hubo acceso a sistemas policiales. Sí sería aplicable a quien vulneró en su día a las empresas de las que salieron los datos

Lo que no encaja, y conviene decirlo: el art. 598 castiga revelar información «legalmente calificada como reservada o secreta» relativa a la seguridad o la defensa nacional; los datos publicados eran domicilios, DNI y trámites administrativos procedentes de brechas de terceros, que no tienen esa calificación. Y los arts. 581 a 588 no son un tipo de espionaje genérico: tipifican la traición —inducir a una potencia extranjera a declarar la guerra a España, entre otras conductas— y nada tienen que ver con una filtración de datos personales. Traerlos a colación infla la gravedad aparente del caso y debilita el análisis.

Sobre una eventual responsabilidad penal interna: se especuló entonces con tipos como la prevaricación (art. 404), el abandono de funciones (art. 407) o la infidelidad en la custodia de documentos (art. 413). Ninguno describe una mala planificación contractual: todos exigen conductas y elementos subjetivos concretos —una resolución arbitraria dictada a sabiendas, el abandono con propósito de no perseguir, la sustracción u ocultación deliberada de documentos— que no equivalen a una negligencia genérica de ciberseguridad. Traerlos a colación sin hechos individualizados infla la gravedad aparente y no se sostiene jurídicamente.

Conviene, aun así, no confundir los planos: en el caso que abre este artículo no hay daño que imputar a una decisión administrativa, porque los datos no salieron de un sistema del Estado. Lo anterior discute el régimen de responsabilidad aplicable a un supuesto de negligencia en la protección de sistemas públicos —que es un debate legítimo y abierto— y no una acusación contra nadie por estos hechos.

El ENS y cómo categoriza los sistemas

El Esquema Nacional de Seguridad (Real Decreto 311/2022) no etiqueta la información por su temática, sino que categoriza cada sistema según el impacto en sus dimensiones de seguridad: un sistema es de categoría ALTA si alguna de esas dimensiones alcanza el nivel ALTO. No basta, por tanto, con decir que unos datos son «de nivel ALTO por definición»: la categoría la fija el análisis del sistema que los trata.

Para los sistemas de categoría ALTA, el ENS aplica medidas y refuerzos proporcionales —autenticación reforzada en los supuestos que la norma define, cifrado en tránsito y en reposo, monitorización con correlación de eventos, continuidad y gestión de vulnerabilidades—, y prevé auditoría ordinaria al menos cada dos años (no anual), sin perjuicio de auditorías extraordinarias. Aplicar bien ese marco es lo que reduce la ventana de exposición ante un fallo de mantenimiento; pero, en el caso que abre este artículo, no consta que ningún sistema policial fuese vulnerado, de modo que no cabe deducir de estos hechos un incumplimiento del ENS por la Policía.

Responsabilidad patrimonial: derechos de los agentes afectados

Los agentes cuyos datos han sido expuestos pueden estudiar una reclamación, pero lo primero es determinar frente a quién: la responsabilidad patrimonial de la Administración (art. 32 de la Ley 40/2015) exige imputar el daño al funcionamiento de un servicio público, y aquí los datos no salieron de un sistema policial. Un perito informático forense puede documentar el alcance de la exposición individual de cada agente y cuantificar el perjuicio sufrido, que puede incluir:

  • Daño a la privacidad y a la seguridad personal: cuantificable en función de la sensibilidad de los datos expuestos y el riesgo residual
  • Necesidad de cambio de destino por riesgo operativo: si un agente encubierto queda identificado, el coste de reasignarlo es directo
  • Gastos de protección personal: cambio de domicilio, sistemas de alarma, escolta en casos extremos
  • Daño moral: su cuantificación depende del caso concreto y debe acreditarse; no existe un baremo automático para la filtración de datos
  • Costes de monitorización de identidad digital: servicios de vigilancia en la dark web durante años
  • Lucro cesante: si el agente debe abandonar una especialización o una operación en curso

La clave procesal es demostrar la relación directa entre el hecho y el perjuicio individual, lo que requiere un análisis forense digital que determine con precisión qué datos de cada agente fueron efectivamente expuestos y en qué contextos han aparecido.

La cultura institucional como problema de fondo

Después de años elaborando informes periciales para administraciones públicas y empresas que trabajan con ellas, he identificado un patrón recurrente que explica por que España sufre brechas de este calibre con una frecuencia alarmante. No es un problema técnico. Es un problema cultural, organizativo y político.

La ciberseguridad como gasto, no como inversión

En la Administración General del Estado, la ciberseguridad sigue tratandose con frecuencia como un centro de coste. Los responsables de los pliegos de contratación tienden a primar el precio, y cuando el criterio económico pesa más que el técnico el resultado es predecible: ganan las ofertas más baratas, no las mejores.

He participado como perito en la revisión de pliegos de contratación de servicios de ciberseguridad para organismos públicos. En uno de ellos, el presupuesto base de licitacion para proteger una infraestructura con datos clasificados de nivel ALTO era inferior al coste de un coche de gama media. Eso da una idea de la seriedad con la que se trata esta materia.

Y no es solo cuestion de presupuesto. Es cuestion de prioridades. En las reuniones de comite de dirección de los organismos públicos con los que he trabajado, la ciberseguridad rara vez aparece en el orden del día. Se delega en el departamento de informática, que a su vez la delega en el proveedor externo. Y cuando el proveedor externo falla, como en este caso, no hay plan B.

Los plazos de contratación como vulnerabilidad estratégica

El caso del sistema anti-APT sin actualizar durante 100 días es un ejemplo perfecto de como la burocracia administrativa crea vulnerabilidades de seguridad nacional. Pero no es un caso único. Es la norma.

En mi experiencia, los ciclos de contratación pública para servicios de ciberseguridad en la AGE siguen este patrón:

FaseDuración típicaRiesgo
Preparación del pliego2-4 mesesEspecificaciones técnicas obsoletas al publicarse
Periodo de licitacion35-45 díasCompetidores analizan requisitos y pueden inferir arquitectura
Evaluación de ofertas30-60 díasSin cobertura si el contrato anterior ha expirado
Adjudicacion y recursos15-90 díasParálisis total si hay recurso administrativo
Formalización y arranque15-30 díasPeriodo de transicion con proveedor saliente
Total5-12 mesesHasta un año sin cobertura adecuada

Esto significa que, sistemáticamente, puede haber ventanas de meses en las que la cobertura de un contrato crítico queda degradada mientras se tramita su sustitución. La transparencia de la contratación pública —los pliegos y sus plazos son públicos en la PLACSP— es un principio irrenunciable; lo que sí puede protegerse es el detalle de fechas de inicio y fin de los contratos de ciberseguridad crítica. El informe CCN-CERT IA-04/24 advierte del aumento de los ataques a la cadena de suministro mediante software legítimo, aunque no documenta la vigilancia de licitaciones que a veces se le atribuye.

En mi experiencia asesorando a empresas del sector defensa en sus licitaciones con la Administración, he propuesto en múltiples ocasiones que los contratos de ciberseguridad se tramiten como contratos clasificados o reservados (artículos 167-168 de la LCSP), que permiten procedimientos de adjudicacion más agiles y con menor exposición pública. Pero la respuesta siempre ha sido la misma: “no cumplen los requisitos para ser clasificados”. Después de la semana negra, espero que esa posición se revise.

La falta de responsabilidad personal

Otro problema estructural es que nadie asume consecuencias personales cuando se produce una brecha de este calibre. En el sector privado, un CISO cuya empresa sufre una brecha grave puede perder su empleo. Un CEO puede enfrentar acciones de los accionistas. En la Administración pública española, las consecuencias personales son prácticamente inexistentes.

El funcionario que no tramito el expediente de renovación del contrato anti-APT a tiempo no será sancionado. El director general que no priorizo la ciberseguridad en su presupuesto seguira en su puesto. El secretario de Estado que no superviso que los sistemas críticos estuviesen operativos no dimitira.

La comparación con el Reino Unido se hizo mucho aquellos días y no se sostiene: cuando la PSNI (Police Service of Northern Ireland) filtró en 2023 los datos de unos 10.000 agentes, fue su propio error —publicó por descuido una hoja de cálculo al responder a una solicitud de información pública—, y su jefe de policía dimitió semanas después, en un contexto que incluía ese episodio. Aquí no hay error institucional equivalente que reprochar, y exigir la misma consecuencia sería exigirla por un hecho distinto.

Esta falta de consecuencias es, en mi opinion, la raiz del problema. Mientras no haya responsabilidad personal por negligencia en ciberseguridad, los incentivos para tomarsela en serio simplemente no existen.

La brecha generacional en la toma de decisiones

Hay un último factor cultural que rara vez se menciona pero que, en mi experiencia, es determinante: la brecha generacional. Los altos cargos de la Administración que toman las decisiones de presupuesto y prioridades son, en su mayoría, personas que crecieron en un mundo analógico. No entienden intuitivamente que un contrato de mantenimiento de software que expira es el equivalente a dejar la puerta de la comisaría abierta por la noche.

He intentado explicar conceptos básicos de ciberseguridad a directores generales y secretarios de Estado que me miraban con la misma incomprension con la que yo miraria un manual de mecánica cuántica. No es culpa suya como individuos, pero si es un problema estructural que debemos resolver. La formación obligatoria en ciberseguridad para altos cargos de la Administración no es un lujo: es una necesidad de seguridad nacional.

Mi posición personal

Quiero ser claro con mi posición: no estoy culpando a los técnicos del CCN-CERT ni a los profesionales de ciberseguridad de la Administración. Conozco a muchos de ellos y son excelentes profesionales que trabajan con recursos insuficientes y sin el respaldo institucional que necesitan. El problema esta más arriba. Esta en los decisores políticos que no priorizan la ciberseguridad, en los gestores administrativos que no agilizan los procedimientos de contratación crítica, y en una cultura institucional que trata la seguridad digital como algo secundario hasta que se produce un desastre.

Este artículo no es un ataque a la Administración. Es un grito de alarma de un profesional que lleva años viendo como las vulnerabilidades se acumulan sin que nadie actue. Y que ahora ve, con frustración pero sin sorpresa, como esas vulnerabilidades se explotan con consecuencias devastadoras para la seguridad nacional.

Comparación internacional: el margen de autoridad de la agencia estatal

Sí hay una diferencia real y verificable con algunos de nuestros vecinos, y no está en tablas de presupuestos —que no son comparables sin una metodología común y que España no publica de forma agregada—, sino en el margen de autoridad de la agencia de ciberseguridad. En el Reino Unido, el proyecto de ley de ciberseguridad y resiliencia atribuiría al Secretario de Estado la potestad de dirigir a las entidades reguladas, algo que hoy no existe con esa forma; en Estados Unidos, la BOD 22-01 de CISA —de 2021, hoy revocada y sustituida— obligó a las agencias federales civiles a remediar las vulnerabilidades del catálogo KEV en plazos tasados o retirar el activo de la red. En España, el CCN-CERT emite recomendaciones y alertas, pero no dispone de esa potestad de imposición sobre los organismos de la Administración: el ENS obliga, pero su incumplimiento no acarrea las mismas consecuencias ejecutivas.

Conviene no adornar esa idea con datos que no se sostienen. Circularon aquellos días afirmaciones sobre SLA de cuatro horas, desconexiones ordenadas en plazos concretos, redes «air-gapped» infalibles o presupuestos nacionales comparados «diez veces» o «cuatro veces» superiores; ninguna resiste el cotejo con las fuentes oficiales, y por eso no las reproduzco. El punto que sí queda en pie es de gobernanza: una agencia con capacidad real de obligar y de sancionar previene mejor que una que solo puede recomendar.

Lo que este caso enseña de verdad a cualquier organización

Antes de la lista, la advertencia que da sentido a todo lo anterior: las ocho medidas que siguen son buenas prácticas frente a una intrusión, y este caso no lo fue. Se mantienen porque el hueco de protección que se destapó aquella semana era real y merece respuesta, pero ninguna de ellas habría evitado el doxing por agregación. Confundir las dos cosas —y se confundieron en la cobertura de aquellos días— lleva a invertir en el problema equivocado.

Llevo años insistiendo en que la ciberseguridad institucional española tiene deficiencias estructurales. Este tipo de incidentes demuestra que no se trata de un problema de presupuesto, sino de gobernanza y prioridades. Las recomendaciones que aplico en mis informes periciales para el sector público y privado son directamente relevantes para cualquier organización que maneje datos sensibles.

  1. Segregación de credenciales por nivel de clasificación: Los accesos a información crítica no deben compartir infraestructura de autenticación con sistemas administrativos generales. En la Policía Nacional, las credenciales para consultar nóminas y las credenciales para acceder a expedientes antiterroristas deberían vivir en universos completamente separados. En mi experiencia pericial, he visto empresas del IBEX 35 con mejor segregación de privilegios que organismos públicos que manejan información clasificada.

  2. Zero Trust obligatorio para datos sensibles: Cada acceso debe verificarse independientemente del origen, con autenticación multifactor resistente a phishing (FIDO2/WebAuthn). No basta con usuario y contraseña, ni siquiera con SMS como segundo factor. Unas credenciales comprometidas serían inútiles si se exigiese una llave física FIDO2 para cada acceso, y el coste de desplegarla es modesto frente a lo que protege.

  3. Monitorización SOC 24/7 con capacidad forense integrada: Los sistemas de detección deben poder iniciar una investigación forense automatizada ante cualquier anomalía. Si un agente cuyas credenciales han sido comprometidas accede a un sistema desde una IP desconocida a las 3 de la mañana, el SOC debe detectarlo, bloquearlo y preservar la evidencia en minutos, no en días. He configurado este tipo de alertas para clientes privados. Es técnicamente trivial. Que no exista en la Policía Nacional es una decisión, no una limitación técnica.

  4. Cambio de credenciales ante evidencia de compromiso, no por calendario: la guía NIST SP 800-63B desaconseja expresamente forzar cambios periódicos de contraseña —fomentan patrones predecibles— y recomienda, en su lugar, forzar el cambio cuando hay indicios de compromiso, impedir la reutilización y las contraseñas ya filtradas, y priorizar MFA resistente a phishing. Encontrar contraseñas de administrador sin cambiar durante años sigue siendo habitual; la respuesta no es una cadencia arbitraria, sino MFA y detección de credenciales expuestas.

  5. Auditoría forense cruzada de todos los incidentes: Cuando múltiples instituciones son atacadas simultáneamente, el análisis forense aislado de cada incidente pierde información crítica. Solo un análisis cruzado que correlacione los indicadores de compromiso de los cuatro ataques de la semana negra permitira identificar con certeza el vector de entrada original. En mi experiencia, he participado en investigaciones multi-organización donde el análisis cruzado revelo el vector de entrada en 48 horas, cuando el análisis individual de cada incidente llevaba semanas sin resultado.

  6. Revisión completa de la cadena de suministro: Identificar y remediar las dependencias de proveedores con ciclos de soporte vencidos o próximos a vencer. Cada proveedor con acceso a sistemas críticos debe ser evaluado periódicamente y sus compromisos de nivel de servicio (SLAs) deben incluir penalizaciones reales por incumplimiento. El proveedor del sistema anti-APT que permitio un vacio de 100 días debería enfrentar consecuencias contractuales severas.

  7. Planes de contingencia para vacios contractuales: No puede haber un solo día sin cobertura de seguridad porque un contrato este en proceso de renovación. La solución es sencilla: cláusulas de prórroga automática, contratos marco con adjudicacion rápida, o capacidad interna que actue como respaldo. He implementado este tipo de cláusulas para clientes privados. Que la Administración no las tenga es imperdonable.

  8. Cultura de ciberseguridad desde la dirección: La ciberseguridad no es un problema del departamento de informática. Es un problema de dirección. Mientras los responsables políticos y los altos cargos sigan tratando la ciberseguridad como un gasto en lugar de como una inversión estratégica, seguiremos teniendo brechas como esta. En las organizaciones donde he visto una transformación real de la ciberseguridad, el cambio siempre empezo en la alta dirección.

Qué se puede hacer con datos personales, y qué no

De todo lo que suele decirse sobre organizaciones destruidas por credenciales comprometidas, el punto que se sostiene en este caso es precisamente el que no necesita ninguna credencial:

La suplantación no requiere entrar en ningún sistema. Con el nombre completo, el documento de identidad, la fecha de nacimiento y el teléfono de una persona, un atacante compone un mensaje o una llamada que cualquiera de sus contactos daría por auténtica. Si esa persona ocupa un puesto de mando, el destinatario del señuelo no es ella: son quienes están por debajo, que reciben una instrucción con datos que solo su superior debería conocer.

Y ése es exactamente el riesgo que deja este caso, sin necesidad de exagerarlo: no el acceso a un sistema policial, sino la credibilidad prestada que dan unos datos personales correctos.

La frontera, en una tabla

Con datos personales agregados se puedeCon datos personales agregados no se puede
Localizar físicamente a una persona en su domicilioAcceder a los sistemas de su organización
Superar la verificación telefónica de un servicio de atención al clienteConsultar un expediente policial o judicial
Duplicar su tarjeta SIM y con ella interceptar códigos de verificaciónLeer su correo corporativo
Construir un señuelo de phishing creíble contra sus contactosIdentificar a un agente encubierto
Abrir cuentas o contratar servicios a su nombreComprometer la cadena de mando

La columna de la izquierda ya es grave. No hace falta añadirle la de la derecha para justificar la preocupación — y añadírsela, como se hizo en la cobertura de aquellos días, tiene un coste concreto: desvía la respuesta hacia medidas técnicas que no protegen de nada, y deja sin atender la única que sí funcionaría, que es limitar el rastro personal que una figura pública deja en servicios privados.

Qué debería hacer el Gobierno ahora mismo

No quiero quedarme solo en la crítica. Soy perito forense, no político. Pero tengo una vision técnica de lo que debería ocurrir en las próximas semanas y meses para contener el daño de esta brecha y prevenir las siguientes. Y creo que tengo la obligación profesional de compartirla.

Lo inmediato, y a qué problema responde cada cosa

La distinción que ordena esta lista: aquella semana se confundieron dos problemas —el doxing por agregación, que es lo que de verdad pasó, y el hueco de soporte anti-APT, el otro hecho cierto—, y cada uno pide medidas propias. Rotar las credenciales de toda la AGE o cruzar forensemente los cuatro incidentes son respuestas a una intrusión, y aquí no la hubo; abajo van las que sí corresponden a lo ocurrido.

Frente al doxing por agregación —lo que de verdad pasó—:

  1. Protección personal de los cargos expuestos, no protección de sistemas. Un domicilio publicado no se revoca ni se parchea. Lo que procede es revisión del dispositivo de seguridad de esas personas y de su entorno familiar, que es una decisión operativa, no informática.

  2. Notificación individual a cada afectado, con el detalle de qué dato concreto apareció. No un comunicado genérico: cada persona necesita saber si lo expuesto fue su domicilio, su teléfono o una contraseña antigua, porque las medidas que puede tomar son distintas en cada caso.

  3. Rotación de las contraseñas reutilizadas, que es lo único accionable de lo publicado. Las contraseñas antiguas de servicios privados solo son peligrosas donde su titular las haya repetido.

  4. Reducción del rastro público de los cargos sensibles: revisión de qué servicios privados tienen sus datos, ejercicio del derecho de supresión donde proceda y criterios sobre qué contratos se firman con identidad personal. Es lento y poco vistoso, y es lo único que ataca la causa.

Frente al hueco de soporte —el otro hecho cierto de aquella semana, que es real aunque nadie lo aprovechara—:

  1. Cerrar la ventana de contratación, que es el fallo acreditado: un sistema de protección no puede quedar sin soporte del fabricante mientras se tramita su sustitución.

  2. Despliegue de MFA resistente a phishing (llaves FIDO2) en los accesos a datos clasificados. Es una de las medidas con mejor relación coste-eficacia del catálogo.

  3. Inventario de fechas de fin de soporte de todo el software de seguridad crítico, con alerta anticipada. El problema de noviembre de 2025 no fue técnico: fue que nadie tenía esa fecha en un calendario.

Acciones a medio plazo (1-6 meses)

  1. Reforma del procedimiento de contratación para servicios de ciberseguridad críticos: Cláusulas de prórroga automática obligatorias. Contratos marco con ejecución inmediata. Eliminación de los criterios de precio como factor dominante en la evaluación de ofertas de seguridad. Esto requiere reforma reglamentaria, no legislativa: puede hacerse por real decreto en semanas.

  2. Creación de una agencia nacional de ciberseguridad con autoridad ejecutiva: Similar al NCSC britanico o al BSI aleman. Con capacidad legal para imponer medidas, desconectar sistemas vulnerables y sancionar incumplimientos. El CCN-CERT es el candidato natural para asumir esta función, pero necesita un marco legal que le otorgue autoridad real.

  3. Transposición inmediata de NIS2: el retraso español ya ha llevado a España ante el TJUE (8 de julio de 2026). No hay excusa. El borrador del anteproyecto de ley existe desde hace meses. Debe tramitarse con carácter de urgencia.

  4. Segmentación de la red de la Policía Nacional: redes separadas para datos clasificados (antiterrorismo, inteligencia, agentes encubiertos) y datos administrativos (nóminas, gestiones internas). Es costoso pero reduce el impacto de un acceso indebido, y es una buena práctica reconocida de arquitectura de seguridad.

  5. Programa de formación obligatoria en ciberseguridad para altos cargos: No estoy hablando de cursos de una hora sobre como detectar phishing. Estoy hablando de formación sería, de semanas, para que los decisores entiendan las implicaciones de sus decisiones en materia de ciberseguridad. Si un alto cargo decide retrasar un presupuesto de seguridad, debe entender exactamente que riesgo esta asumiendo.

Lo que NO debería hacer el Gobierno

Me preocupa que la respuesta institucional siga el patrón que he visto en crisis anteriores: mucho ruido durante una semana, un “plan de choque” con medidas cosmeticas, y vuelta a la normalidad en un mes.

Lo que NO debería ocurrir:

  • No minimizar: El comunicado del Ministerio del Interior minimizando el impacto fue un error. Los agentes afectados lo saben. Los socios europeos lo saben. Los atacantes lo saben. La única audiencia a la que enganaba era al público general, y ese público merece la verdad.

  • No buscar chivos expiatorios técnicos: El problema no fue un técnico que no aplico un parche. El problema es un sistema de contratación pública que crea vacios de seguridad estructurales, y una cultura institucional que no prioriza la ciberseguridad. Buscar culpables individuales sin reformar el sistema es garantizar que la próxima brecha esta a la vuelta de la esquina.

  • No anunciar inversiones sin calendarios: “Vamos a invertir X millones en ciberseguridad” es una frase vacía si no viene acompanada de un calendario de implementación, métricas de éxito y mecanismos de rendicion de cuentas. He visto demasiados “planes de choque” que nunca se ejecutaron.

  • No clasificar el informe forense completo: Entiendo que hay aspectos del informe forense que deben ser clasificados por razones de seguridad. Pero las conclusiones generales, las causas raiz y las recomendaciones deberían ser públicas. La ciudadanía tiene derecho a saber que fallo y que se esta haciendo para que no vuelva a ocurrir.

Preguntas frecuentes

¿Pueden los agentes afectados reclamar a la Administración por la filtración de sus datos?

Pueden estudiarlo, pero lo primero es identificar frente a quién. La responsabilidad patrimonial de la Administración (art. 32 de la Ley 40/2015) exige imputar el daño al funcionamiento de un servicio público, y en este caso los datos no salieron de un sistema policial, sino de brechas previas de empresas privadas: la reclamación apuntaría, en su caso, contra esos responsables. Con independencia de ello, cabe acudir a la AEPD frente al responsable del tratamiento que corresponda. Un informe pericial de análisis forense digital documenta el alcance de la exposición individual y ayuda a cuantificar el perjuicio, que debe acreditarse caso a caso: no hay un baremo automático de indemnización por filtración de datos.

¿Qué relación tiene esta brecha con el hackeo a Moncloa de la misma semana?

Coinciden en la fecha y poco más, y esa coincidencia es justo lo que hizo verosímil una explicación equivocada. No consta un vector común: lo publicado sobre el mando policial se compuso agregando filtraciones de terceros, no mediante una intrusión, mientras que el hueco de soporte del sistema anti-APT que se comentó aquella semana pertenece a otro plano. Presentar un «mismo vector» con probabilidad alta —como se hizo entonces citando estadísticas de Mandiant— fue precisamente el error que este artículo corrige. He analizado la brecha de Moncloa en detalle; que un análisis forense cruzado pudiera hallar más adelante algún nexo es una hipótesis, no un hecho acreditado.

¿Qué debe hacer alguien cuyos datos personales aparecen en una publicación de este tipo?

Conviene distinguir dos supuestos, porque las medidas son distintas. Si lo publicado son datos personales —domicilio, documento, teléfonos, contraseñas antiguas de servicios privados—, que es lo ocurrido aquí, el riesgo está en la suplantación y en la seguridad física, no en los sistemas del empleador. Si además hubiera credenciales corporativas, lo que sigue es igualmente aplicable y con más urgencia:

  1. Cambiar inmediatamente todas las contraseñas asociadas a las credenciales comprometidas, empezando por los sistemas policiales y extendiendose a cuentas personales si se reutilizaban contraseñas

  2. Activar autenticación multifactor en todos los servicios que lo permitan, preferiblemente con llave física FIDO2

  3. Monitorizar la Dark Web para verificar si sus datos aparecen en foros de venta de credenciales. Servicios como Have I Been Pwned, SpyCloud o Hudson Rock pueden alertar automáticamente

  4. Documentar la situación con capturas de pantalla y registros con fecha cierta, preferiblemente con asistencia de un perito informático forense, para preservar la evidencia de cara a una futura reclamación

  5. Reportar formalmente al CCN-CERT y al responsable de seguridad de su unidad por escrito, para que quede constancia documental

  6. Consultar con un abogado especializado sobre la posibilidad de reclamar por responsabilidad patrimonial de la Administración

  7. Solicitar un informe pericial que documente el alcance de la exposición de sus datos para respaldo jurídico ante tribunales

La rapidez de actuación es crítica. En mi experiencia pericial, las primeras 72 horas tras una brecha son determinantes para preservar la evidencia y limitar el daño.

¿Es esta la peor brecha de ciberseguridad en la historia de España?

No, y la pregunta está mal planteada, porque no fue una brecha. Ni por volumen —la filtración de la DGT de 2025 movió órdenes de magnitud más registros— ni por naturaleza: aquí no se vulneró ningún sistema del Estado. Lo que sí es singular es a quién se dirigió: seleccionar deliberadamente a un mando antiterrorista y componer su ficha personal a partir de brechas ajenas tiene un valor para quien quiera localizarlo que no tiene un volcado indiscriminado de millones de registros. La gravedad está en el objetivo elegido, no en la cantidad ni en un fallo policial.

¿Podría haberse evitado?

No por la Policía Nacional, y esa es la respuesta que menos gustó cuando se supo. Ninguna medida sobre sus sistemas —parcheado, segmentación, multifactor, renovación de contratos— habría impedido que un tercero cruzase filtraciones antiguas de empresas privadas para componer la ficha de una persona concreta.

Donde sí había margen es aguas arriba y años antes: en cada una de las brechas de terceros que aportaron una pieza, y en cuánto dato personal se entrega a un proveedor que no lo necesita. Para quien ocupa un cargo identificable, la medida realmente eficaz no es técnica sino de exposición: minimizar el rastro comercial asociado a su nombre, revisar qué figura a su nombre en registros públicos y asumir que lo ya filtrado no se puede retirar.

¿Quién esta detras del ataque?

En junio de 2026 la Policía Nacional detuvo en Granada a un menor como presunto responsable de un delito de revelación de secretos (INCIBE-CERT; Ministerio del Interior). Una detención no equivale a autoría judicialmente probada y la investigación seguía abierta, pero desmiente la lectura de aquellos primeros días: no hay base pública para atribuir el caso a un Estado. La sofisticación aparente del resultado no acreditaba la del autor.

¿Qué papel tiene la NIS2 en la prevención de estas brechas?

La Directiva NIS2 (UE) 2022/2555 impone obligaciones de ciberseguridad a numerosas entidades esenciales e importantes, pero excluye de su ámbito a las que actúan en seguridad nacional, seguridad pública y garantía del cumplimiento de la ley (art. 2.7). Por eso no puede presentarse como el régimen que habría evitado este caso, que además no fue una intrusión en sistemas del Estado. El retraso español en la transposición es real —el plazo venció en octubre de 2024 y el 8 de julio de 2026 la Comisión Europea llevó a España ante el TJUE— y es un problema de gobernanza, pero no la causa de este doxing. He analizado en detalle las implicaciones de NIS2 para España.

¿Podrían los datos filtrados estar ya en manos de organizaciones terroristas?

Es una posibilidad real que no se puede descartar. Los datos filtrados en la dark web son accesibles para cualquiera con los conocimientos y la motivación para buscarlos. Las organizaciones terroristas tienen unidades de ciberinteligencia propias y también recurren a intermediarios que compran datos en mercados clandestinos. El tiempo que los datos llevan expuestos (desde el 26 de febrero) es suficiente para que hayan sido descargados, copiados y redistribuidos múltiples veces. En el peor escenario, los datos del jefe antiterrorista podrían estar ya en manos de organizaciones como el Estado Islamico o al-Qaeda, que mantienen capacidades de ciberinteligencia activas contra países europeos.

¿Cómo afecta esta brecha a la cooperación policial europea?

La confianza es el pilar de la cooperación policial internacional. Si los socios europeos de España (Europol, fuerzas policiales de Francia, Alemania, Italia, etc.) perciben que no se pueden proteger datos de seguridad, la disposición a compartir inteligencia sensible se resiente. Conviene, eso sí, no exagerar el paralelismo: en este caso no se vulneró ningún sistema policial español, de modo que el eventual efecto sobre la cooperación derivaría de la exposición personal de un mando, no de una fuga desde las redes del Estado.

¿Pueden los agentes afectados solicitar protección personal adicional?

Si, aunque el procedimiento depende de la evaluación de riesgo individual. Los agentes cuya identidad ha sido expuesta y cuyo destino o función pueda ponerles en situación de riesgo personal pueden solicitar medidas de protección al Ministerio del Interior, incluyendo cambio de destino, protección personal temporal, cambio de domicilio con gastos a cargo de la Administración y medidas de seguridad adicionales en su residencia. En el caso del jefe antiterrorista, cuyo perfil de riesgo es máximo, la protección personal reforzada debería haberse activado en las primeras horas tras conocerse la brecha.

Desde el punto de vista pericial, puedo ayudar a documentar el nivel de exposición individual de cada agente. Esto es fundamental para justificar la solicitud de protección. No es lo mismo que se filtren tus datos de nómina (riesgo bajo-medio) que tu destino en la Comisaría General de Información (riesgo crítico). El informe pericial cuantifica y gradua ese riesgo de forma objetiva y admisible en un procedimiento administrativo o judicial.

¿Es posible que los atacantes sigan teniendo acceso a los sistemas policiales?

No, porque para conservar un acceso primero hay que haberlo obtenido, y aquí no consta que ningún sistema policial fuera vulnerado: los datos se compusieron cruzando filtraciones de terceros, sin entrar en las redes del Estado. La pregunta tiene sentido en una intrusión —no en un doxing por agregación—, y por eso conviene explicar cuándo sí importaría.

Cuando sí ha habido intrusión, la persistencia es el problema difícil: en ciberataques sofisticados los atacantes instalan backdoors (cuentas de servicio creadas durante el ataque, tareas programadas, malware en el firmware de dispositivos de red o certificados comprometidos) que mantienen el acceso aunque se roten las credenciales. En campañas conocidas —SolarWinds (2020) o la campaña contra servidores Centreon documentada por ANSSI, cuyas primeras intrusiones se remontaban a finales de 2017 y se prolongaron hasta 2020 (CERT-FR)— el acceso se mantuvo durante largos periodos antes de detectarse. Ahí la rotación de credenciales no basta y hace falta un análisis forense de firmware, red, certificados y cuentas de servicio. Nada de eso es lo ocurrido en este caso.

¿Qué coste tiene para el Estado un caso como este?

Mucho menor que el de una intrusión, y de naturaleza distinta, que es precisamente lo que se pasó por alto en la cobertura. No hay que reconstruir sistemas, ni auditar accesos, ni asumir responsabilidad patrimonial por una custodia deficiente: los datos no salieron de las redes del Estado. Lo que sí cuesta —y no se contabiliza— es la protección personal reforzada de quien queda expuesto, y el tiempo institucional dedicado a desmentir.

Conclusión: una llamada de atención que no podemos ignorar

Llevo semanas dando vueltas a esta brecha. He escrito y reescrito este artículo varias veces porque quería asegurarme de que cada dato, cada análisis y cada opinion estuviesen fundamentados. Y después de todo el análisis, mi conclusión es sencilla pero grave.

Los datos del jefe de antiterrorismo de España están en internet, y ninguna medida que pudiera haber tomado la Policía Nacional lo habría impedido. Esa es la parte incómoda: se compusieron a partir de brechas de empresas privadas donde esa persona era un cliente más, ocurridas años antes, y esos datos no caducan. Cambiar una contraseña no borra un domicilio ni una fecha de nacimiento.

De ahí sale la única conclusión que el caso sostiene, y no es la que se leyó en su momento: el perímetro que hay que defender ya no coincide con el de la organización. Un mando policial, un directivo o cualquier persona con un cargo identificable queda expuesto por la suma de brechas de terceros sobre los que no tiene ningún control, y el remedio no está en el parcheado ni en la contratación pública, sino en reducir el dato que se entrega a cada proveedor y en asumir que lo ya filtrado seguirá circulando.

Espero equivocarme. Pero mi experiencia de años analizando brechas me dice que, sin un cambio radical en la gobernanza de la ciberseguridad española, esta brecha no es la última. Es un preludio.

Como ciudadano, me da miedo. Como perito, me da rabia. Y como profesional, me comprometo a seguir documentando, analizando y denunciando cada fallo que ponga en riesgo la seguridad de los ciudadanos y de las personas que nos protegen.

A los agentes de la Policía Nacional y la Guardia Civil cuyos datos han sido expuestos: no estais solos. Hay profesionales dispuestos a ayudaros a documentar el daño y a reclamar vuestros derechos frente a quien corresponda. Es lo mínimo que os mereceis después de dedicar vuestra vida a proteger a los demas.

A los responsables políticos: este artículo no es un ataque partidista. Es una advertencia profesional. Si no actuais ahora, con medidas reales y no cosmeticas, la próxima brecha será peor. Y cuando ocurra, no podreis decir que nadie os lo advirtio.

Y a los ciudadanos en general: exigid a vuestros representantes que tomen en serio la ciberseguridad del Estado. No es un tema técnico que solo interesa a los informáticos. Es un tema de seguridad nacional que afecta a vuestra seguridad personal. Los datos que se filtraron esta vez eran de agentes de policía. La próxima vez podrían ser los vuestros. Los datos de vuestras declaraciones de la renta en Hacienda, los historiales médicos de vuestros hijos en la sanidad pública, los expedientes judiciales de vuestros divorcios. Todo eso vive en sistemas y en servicios privados cuya seguridad no controláis — y, como muestra este caso, basta con que fallen otros para que vuestro perfil quede expuesto.

No se trata de generar alarma. Se trata de exigir responsabilidad.

Preguntas relacionadas

Necesitas verificar si tus credenciales han sido comprometidas?

Ofrezco análisis forense de brechas de seguridad, verificación de exposicion de datos y peritajes judiciales con metodología ISO 27037 admisible en tribunales. Consulta inicial gratuita.


Referencias y fuentes

Disclaimer: La información contenida en este artículo se basa en fuentes periodísticas publicadas y en mi experiencia profesional como perito informático forense. Los detalles técnicos específicos de la brecha no se han hecho públicos por razones de seguridad nacional, por lo que el análisis técnico se basa en patrones observados en incidentes comparables documentados internacionalmente. Los casos y ejemplos anonimizados que se citan de mi experiencia profesional son reales, pero se han modificado detalles identificativos para proteger la identidad de los clientes. Las opiniones expresadas son exclusivamente mias y no representan la posición de ninguna institucion.

Sobre el autor: Jonathan Izquierdo es perito informático forense especializado en análisis de brechas de seguridad, respuesta a incidentes y peritajes judiciales sobre protección de datos. Ex-CTO y arquitecto cloud con más de 20 años en el sector tecnológico y 5 certificaciones AWS, ejerce como perito judicial desde 2025 y aplica metodología ISO 27037 en todas sus investigaciones.

Artículos relacionados:

Última actualización: 6 de septiembre de 2026

Sobre el autor

Jonathan Izquierdo es perito informático forense especializado en Noticias seguridad con conocimientos en blockchain, criptomonedas, AWS Cloud, desarrollo de software y seguridad. Experiencia tecnológica de más de 20 años al servicio de la justicia digital, liderando equipos de desarrollo de software en ámbitos internacionales.

Ver más sobre mí

Volver al Blog

Posts Relacionados

Ver Todos los Posts »
Jonathan Izquierdo

Jonathan Izquierdo · Perito Forense

+15 años experiencia · AWS Certified

WhatsApp