Hackeo a Moncloa: filtran datos de Pedro Sanchez, ministros y altos cargos de seguridad nacional

100 días sin protección anti-APT. Ese es el tiempo que la Presidencia del Gobierno de España estuvo expuesta a ciberataques avanzados entre noviembre de 2025 y febrero de 2026, según ha revelado El Español. Durante ese periodo, hackers lograron filtrar datos sensibles del presidente Pedro Sanchez, ministros, el Jefe del Estado Mayor de la Defensa (JEMAD), el fiscal general del Estado, miembros del Consejo de Seguridad Nacional y credenciales de cientos de agentes de la Policia Nacional y la Guardía Civil.

El resultado: Moncloa ha invertido más de 2 millones de euros en refuerzo de ciberseguridad, la UE investiga a España por no transponer la Directiva NIS2 y el panorama de ciberseguridad institucional español queda en entredicho ante la comunidad internacional.

Como perito informático forense que ha analizado brechas en organizaciones públicas y privadas, este incidente confirma un patrón que llevo documentando en mis informes periciales desde hace años: las organizaciones más sensibles a menudo descubren sus brechas cuando ya es demasiado tarde, especialmente cuando la cadena de suministro tecnologica falla en el momento crítico. Lo que paso en Moncloa no es un caso aislado. Es la consecuencia previsible de un modelo de gestión de la ciberseguridad que prioriza los contratos sobre la continuidad operativa.

Voy a ser directo en este artículo porque la situación lo merece: lo que ocurrio en Moncloa es un fallo de negligencia, no un fallo de sofisticacion del atacante. Ningun atacante necesita ser sofisticado cuando la puerta esta abierta. Y 100 días sin actualizaciones de seguridad en la Presidencia del Gobierno es una puerta abierta con un cartel de bienvenida.

En este análisis detallo la cronologia completa del incidente día a dia, la técnica probable del ataque con reconstruccion del ciclo APT, las implicaciones para la seguridad nacional española (incluyendo riesgos de segundo y tercer orden que aun no se han materializado), el contexto europeo y el procedimiento de infracción de la UE contra España, la comparación con los modelos de ciberseguridad gubernamental de Francia, Alemania, Reino Unido y Estonia, la fragmentacion de la gobernanza de ciberseguridad en España, el coste real de la brecha frente al coste de la prevención, y las lecciones concretas que toda organización puede extraer de este caso.

Todo ello desde mi perspectiva profesional como perito forense que ha investigado decenas de brechas similares en el sector privado, con opiniones críticas fundamentadas en mi experiencia directa.

Este es, probablemente, el análisis más detallado publicado hasta la fecha sobre el hackeo a Moncloa desde una perspectiva forense independiente.

Que ocurrio: cronologia completa del hackeo a Moncloa

Entre el 26 de febrero y el 4 de marzo de 2026, varios actores maliciosos publicaron datos sensibles de altos cargos del Estado español. La filtracion no fue un evento aislado sino una secuencia de exposiciones escalonadas que afectaron a distintos niveles del aparato gubernamental, cada día más profundas y más daninas.

He reconstruido la cronologia completa a partir de las publicaciones de El Español, The Objective, Voz Populi y Esdiario, cruzando fechas con los timestamps de los dumps publicados en foros de la dark web. Como perito forense, es importante entender que este tipo de filtraciones escalonadas no son aleatorias: los atacantes publican datos de forma progresiva para maximizar el impacto mediatico y presionar a la víctima.

Cronologia extendida día a dia

En mi opinion profesional, lo más grave de esta cronologia no es la filtracion en si, sino los 100 días de silencio previos. He visto este mismo patrón en decenas de peritajes: el atacante esta dentro de la red durante semanas o meses, exfiltrando datos sin que nadie lo detecte, porque el sistema de detección esta degradado o directamente inoperante. Cuando la filtracion se hace pública, el daño ya esta hecho y la ventana para una respuesta eficaz se ha cerrado.

Hay un detalle de la cronologia que merece atencion especial: la formalizacion del contrato de sustitucion se produjo a mediados de febrero, pero la primera filtracion pública fue el 26 de febrero. Esto sugiere dos posibilidades igualmente preocupantes. La primera: los atacantes ya tenian los datos desde antes de que se activara el nuevo sistema, y la publicacion fue deliberadamente posterior para maximizar el daño. La segunda: el nuevo sistema detecto la brecha y los atacantes, al saber que habian sido descubiertos, decidieron publicar los datos antes de perder el acceso. En ambos escenarios, la conclusión es la misma: los 100 días sin protección fueron suficientes para que los atacantes completaran su objetivo.

El patrón de filtracion escalonada

Un aspecto que no se ha analizado suficientemente en la cobertura mediatica es la estrategia de publicacion escalonada que siguieron los atacantes. Esto no es aleatorio. En mi experiencia como perito forense, las filtraciones escalonadas cumplen multiples propositos:

1. Presion creciente: Cada nueva oleada de datos aumenta la presion sobre la víctima para negociar, pagar o ceder ante las demandas del atacante
2. Demostracion de capacidad: Publicar datos de cargos cada vez más sensibles (primero ministros, luego JEMAD, luego Consejo de Seguridad Nacional) demuestra que el atacante tiene acceso profundo y amplio
3. Manipulación mediatica: Cada oleada genera un nuevo ciclo de noticias, manteniendo el incidente en primera plana durante días en lugar de horas
4. Desgaste institucional: La gestión continua de la crisis durante una semana completa consume recursos, atencion y credibilidad de forma acumulativa
5. Ocultacion del alcance real: Mientras los medios y la opinion pública se centran en los datos publicados, el atacante puede estar vendiendo o explotando datos adicionales que no ha hecho públicos

He visto este mismo patrón en ataques de ransomware contra empresas españolas: el atacante pública primero una muestra pequeña de datos, espera la reacción, y si la víctima no paga, pública progresivamente más información sensible. La diferencia es que en el caso de Moncloa, los datos tienen implicaciones de seguridad nacional que multiplican el impacto de cada oleada.

Cargos afectados

La filtracion comprometio datos de los niveles más altos del Estado:

• Presidente del Gobierno: Pedro Sanchez
• Varios ministros del Consejo de Ministros
• JEMAD: Jefe del Estado Mayor de la Defensa
• Fiscal General del Estado
• Miembros del Consejo de Seguridad Nacional
• Cientos de agentes de la Policia Nacional y la Guardía Civil
• Personal de la Fiscalia General del Estado
• Secretarios de Estado y altos cargos de diversos ministerios
• Personal de apoyo y administrativo cuyas credenciales proporcionan acceso a sistemás internos

La gravedad no reside solo en la cantidad de datos expuestos, sino en la naturaleza de los afectados: se trata de las personas que gestionan la seguridad nacional del pais. Un atacante con acceso a los datos personales del JEMAD, los miembros del Consejo de Seguridad Nacional y cientos de agentes de las fuerzas de seguridad tiene en sus maños un mapa completo de la estructura de defensa española.

Para dimensionar la magnitud, es útil comparar con otras filtraciones gubernamentales recientes en Europa. El hackeo al Bundestag aleman en 2015 (atribuido al grupo APT28/Fancy Bear) comprometio 16 GB de datos de parlamentarios, pero no incluia credenciales de las fuerzas de seguridad ni datos de cargos de defensa. El ataque al sistema informático del Parlamento noruego en 2020 afecto a cuentas de email de parlamentarios pero no alcanzo a cargos ejecutivos. En comparación, la brecha de Moncloa afecta al nivel ejecutivo más alto del Estado (presidente y ministros), al mando militar (JEMAD), al poder judicial (fiscal general) y a las fuerzas de seguridad del Estado (cientos de agentes). Es, en terminos de alcance jerarquico, una de las filtraciones gubernamentales más graves de la historia reciente de Europa.

Desglose detallado de los datos expuestos y sus riesgos

En mis peritajes siempre insisto en que no todos los datos tienen el mismo valor para un atacante. Un nombre y un DNI no es lo mismo que unas credenciales de acceso a un sistema policial. Para entender la verdadera magnitud de esta brecha, hay que analizar cada tipo de dato y lo que un adversario sofisticado puede hacer con el.

Datos personales identificativos

Como perito que ha documentado casos de SIM swapping en España, puedo afirmar que con el nombre completo, DNI, fecha de nacimiento y número de teléfono de una persona, un atacante competente puede clonar su linea telefónica en menos de 24 horas. El proceso es sencillo: el atacante llama a la operadora de telefonía suplantando la identidad de la víctima (con los datos filtrados puede superar cualquier verificación de identidad telefónica), solicita un duplicado de SIM alegando pérdida o robo, y en cuanto la nueva SIM se activa, recibe todos los SMS y llamadas de la víctima, incluyendo los códigos de verificación de doble factor.

Si ese dato pertenece a un ministro o al JEMAD, las consecuencias van desde el acceso a comunicaciones privadas hasta la interceptacion de códigos de autenticación de sistemás gubernamentales. Y este es solo uno de los muchos vectores de ataque que los datos filtrados de Moncloa habilitan.

Credenciales de acceso

Este es, en mi opinion profesional, el dato más crítico de toda la filtracion.

He visto este mismo escenario en empresas que he peritado: las credenciales filtradas de un empleado dan acceso a un sistema, desde ese sistema se extraen credenciales de otro con más privilegios, y en pocas horas el atacante tiene acceso de administrador a toda la red. En el caso de Moncloa, con cientos de credenciales de agentes de las fuerzas de seguridad comprometidas, la superficie de ataque en cadena es enorme.

Información clasificada y de seguridad nacional

En mi experiencia como perito, cuando una organización me contrata para analizar una brecha, lo primero que evaluo es la “cadena de explotacion”: que puede hacer un atacante combinando los distintos tipos de datos filtrados. En el caso de Moncloa, la combinacion de datos personales, credenciales y datos de seguridad nacional crea una cadena de explotacion de una gravedad sin precedentes en la historia reciente de España.

Un escenario realista de explotacion combinada

Para que se entienda la gravedad real, voy a describir un escenario de explotacion completamente realista basado en los tipos de datos filtrados. No es especulacion: es exactamente lo que un actor estatal hostil con estos datos podría ejecutar.

Paso 1 - Reconocimiento: Con los datos personales del JEMAD (nombre, DNI, dirección, teléfono), el atacante elabora un perfil completo: rutinas, contactos frecuentes, viajes, reuniones programadas.

Paso 2 - Preparación del ataque: Usando las credenciales de un agente de la Guardía Civil filtradas en la brecha, el atacante accede a un sistema policial para obtener información adicional sobre el entorno del JEMAD: escolta, vehiculo oficial, protocolo de seguridad habitual.

Paso 3 - Spear phishing personalizado: Con toda esa información, el atacante envia un email al JEMAD desde una cuenta que simula ser la de un ministro (cuyo email institucional también fue filtrado), adjuntando un documento que aparenta ser un informe del Consejo de Seguridad Nacional. El documento contiene un exploit que instala un implante en el dispositivo del JEMAD.

Paso 4 - Acceso persistente: El implante da acceso a las comunicaciones del JEMAD: emails, mensajes, documentos clasificados, calendarios, contactos. El atacante ahora tiene visibilidad directa sobre la toma de decisiones de seguridad nacional de España.

Paso 5 - Exfiltración estrategica: Durante semanas, el atacante extrae documentos sobre posiciones diplomaticas, planes militares, evaluaciones de amenazas y comunicaciones con aliados de la OTAN. La información se envia a un servidor C2 en un pais sin acuerdo de extradicion con España.

Este escenario no requiere tecnología avanzada. Solo requiere los datos que ya se han filtrado y la capacidad operativa de un servicio de inteligencia de tamaño medio. Y lo más preocupante: puede que ya se haya ejecutado durante los 100 días de exposicion sin que nadie lo haya detectado.

Análisis técnico profundo: como fallo la protección de Moncloa

Que es un sistema anti-APT y por que es crítico

Un sistema anti-APT (Advanced Persistent Threat) es la linea de defensa más sofisticada contra ciberataques dirigidos por actores estatales o grupos de cibercrimen avanzado. No es un antivirus. No es un firewall. Es un ecosistema completo de detección que combina multiples tecnologías para identificar amenazas que ninguna herramienta individual detectaria.

Para entender por que 100 días sin actualizaciones es catastrofico, primero hay que entender como funciona un sistema anti-APT:

La diferencia crítica: detección por firmás vs detección por comportamiento

Esta distincion es fundamental para entender la gravedad de lo que paso en Moncloa. En mi trabajo como perito forense, cuando analizo una brecha, lo primero que verifico es que capas de detección estaban activas y cuales estaban degradadas.

Detección basada en firmas: funciona como una lista negra. Si el malware coincide con una firma conocida, se bloquea. Es rápida, eficiente y tiene muy pocos falsos positivos. Pero es completamente ciega ante malware nuevo. Si la última firma se actualizo en noviembre de 2025, cualquier malware creado desde diciembre es invisible para el sistema.

Detección por comportamiento: funciona observando que hacen los procesos, no como se llaman. Un proceso que cifra archivos masivamente es sospechoso independientemente de su firma. Esta capa es más resiliente a la falta de actualizaciones, pero también se degrada: los atacantes sofisticados saben como hacer que su malware se comporte de forma “normal” durante las primeras horas, realizando acciones daninas de forma gradual para no disparar alertas conductuales.

La combinacion de ambas es lo que hace eficaz a un sistema anti-APT. Sin actualizaciones, la detección por firmás muere inmediatamente. La detección por comportamiento sobrevive parcialmente pero se degrada en semanas. Despues de 100 días, la capacidad de detección del sistema esta, en terminos prácticos, muerta.

En mi opinion profesional, esto no debería haber ocurrido porque cualquier responsable de ciberseguridad con experiencia sabe que un sistema de detección sin actualizaciones durante más de 30 días es un punto ciego crítico. Mantenerlo operativo durante 100 días da una falsa sensacion de seguridad que es peor que no tener ningun sistema: al menos si no tienes sistema sabes que no estas protegido.

Por que 100 días sin actualizaciones es catastrofico

Para ponerlo en perspectiva con datos concretos:

100 días son suficientes para que un atacante sofisticado complete todo el ciclo de un APT: reconocimiento, acceso inicial, establecimiento de persistencia, movimiento lateral, descubrimiento de datos, exfiltración y borrado de huellas. Con un sistema de detección actualizado, al menos una de estas fases debería haber disparado una alerta. Sin actualizaciones, el atacante opera con total impunidad.

Reconstruccion del posible ciclo de ataque

Basandome en mi experiencia peritando brechas en organizaciones de tamaño comparable y en los patrones documentados por Mandiant, MITRE ATT&CK y el CCN-CERT, puedo reconstruir un ciclo de ataque plausible para el caso Moncloa:

Fase 1 - Reconocimiento (noviembre 2025): Los atacantes detectan que el sistema anti-APT de Moncloa ha dejado de actualizarse. Esto puede hacerse de multiples formas: escaneo de red que identifica versiones de software, análisis de los headers de las comunicaciones salientes del sistema, o simplemente información privilegiada de alguien con acceso a la cadena de suministro del fabricante. En mi experiencia, los grupos APT monitorizan activamente las cadenas de suministro de los fabricantes de seguridad y estan atentos a cambios en las politicas de soporte.

Fase 2 - Acceso inicial (noviembre-diciembre 2025): Con el conocimiento de que el sistema anti-APT esta desactualizado, los atacantes preparan un payload que sería detectado por las firmás de noviembre 2025 pero no por las anteriores. Envian un email de spear-phishing a un funcionario de Moncloa con un adjunto que contiene un exploit para una vulnerabilidad publicada después de la última actualizacion del sistema. El anti-APT no lo detecta porque no tiene la firma correspondiente. El exploit se ejecuta y establece una conexión de comando y control (C2) con un servidor externo.

Fase 3 - Establecimiento de persistencia (diciembre 2025): Una vez dentro, el atacante instala mecanismos de persistencia: tareas programadas, servicios de Windows, claves de registro, o incluso implantes en el firmware si tiene acceso físico indirecto. La persistencia garantiza que el atacante pueda volver a entrar incluso si se reinician los sistemás o se detecta y elimina el acceso inicial.

Fase 4 - Movimiento lateral (diciembre 2025 - enero 2026): Desde el primer equipo comprometido, el atacante se mueve a otros sistemás de la red interna de Moncloa. Utiliza técnicas living-off-the-land (PowerShell, WMI, PsExec) que no generan alertas porque son herramientas legitimás del sistema. Cada nuevo sistema comprometido amplía el acceso y revela nuevas credenciales, documentos y datos.

Fase 5 - Descubrimiento y exfiltración (enero - febrero 2026): Con acceso amplio a la red, el atacante mapea los datos disponibles e identifica los más valiosos: datos personales de altos cargos, credenciales de agentes, documentos del Consejo de Seguridad Nacional. La exfiltración se realiza de forma gradual, en paquetes pequeños, para no disparar alertas volumetricas (que probablemente tampoco estaban operativas).

Fase 6 - Publicacion (26 febrero - 4 marzo 2026): Los atacantes deciden publicar los datos, bien porque han obtenido todo lo que buscaban, porque han sido detectados por el nuevo sistema anti-APT que se despliega a mediados de febrero, o porque la publicacion es en si misma parte de su objetivo (desestabilizacion, presion politica, demostración de capacidad).

Este ciclo es coherente con la cronologia conocida y con los patrones documentados de APTs que atacan gobiernos europeos. No puedo afirmar que sea exactamente lo que ocurrio, pero como perito forense que ha analizado decenas de brechas, puedo decir que es la hipotesis más probable basandome en la información disponible.

Las técnicas de evasion que el sistema obsoleto no podía detectar

Para entender la inutilidad práctica de un sistema anti-APT sin actualizaciones durante 100 días, hay que considerar las técnicas específicas que los atacantes pudieron usar sabiendo que el sistema estaba desactualizado:

Living-off-the-land binaries (LOLBins): Herramientas legitimás del sistema operativo (PowerShell, certutil, bitsadmin, mshta) utilizadas para ejecutar código malicioso. Estas técnicas se actualizan constantemente en el framework MITRE ATT&CK y los sistemás anti-APT necesitan reglas nuevas para detectar usos anómalos de estas herramientas. Sin actualizaciones, usos sospechosos de LOLBins pasan completamente desapercibidos.

Fileless malware: Malware que no escribe archivos en disco sino que se ejecuta completamente en memoria. Los sistemás anti-APT detectan fileless malware mediante análisis de comportamiento de procesos en memoria, pero las técnicas de evasion evolucionan rápidamente. Un sistema con firmás de noviembre 2025 no reconoceria las variantes de fileless malware publicadas en diciembre, enero o febrero.

DLL sideloading y DLL hijacking: Técnicas que explotan el orden de carga de librerias dinamicas de Windows para ejecutar código malicioso en el contexto de un proceso legítimo. Los fabricantes de anti-APT anadon continuamente nuevas detecciones para variantes de estas técnicas. Sin esas detecciones, el atacante puede ejecutar su payload como si fuera parte de un proceso confiable.

Abuso de servicios cloud: Uso de servicios cloud legítimos (OneDrive, Google Drive, Azure Blob Storage, AWS S3) como infraestructura de comando y control. El trafico parece normal porque se dirige a dominios de Microsoft, Google o Amazon. Los sistemás anti-APT actualizados tienen reglas para identificar patrones sospechosos en el uso de estos servicios. Sin actualizaciones, este trafico C2 se mezcla con el trafico legítimo y pasa desapercibido.

Tunneling DNS: Exfiltración de datos codificando la información en consultas DNS. Es una técnica antigua pero que sigue siendo efectiva porque muchas organizaciones no monitorizan el trafico DNS de forma adecuada. Los sistemás anti-APT actualizados tienen modelos de detección de anomalias DNS que identifican patrones de tunneling. Sin actualizaciones, esos modelos no incorporan las últimás técnicas de ofuscacion de tunneling DNS.

Cualquiera de estas técnicas, y probablemente varias combinadas, habría permitido a los atacantes operar dentro de la red de Moncloa durante los 100 días de exposicion sin ser detectados. El sistema anti-APT estaba fisicamente presente, pero funcionalmente ciego.

En una analogia que suelo usar con mis clientes para explicar la gravedad de la situación: imagina que tienes un sistema de alarma en tu casa, pero las camaras graban en blanco y negro, los sensores de movimiento solo detectan objetos de más de 100 kilos, y la central de alarmás no recibe la senal desde hace tres meses. La alarma “funciona” tecnicamente: enciende una luz cuando la activas, suena cuando pulsas el boton de panico. Pero no detecta nada real. Eso es exactamente lo que le paso al sistema anti-APT de Moncloa: seguia ejecutandose, generaba dashboards, mostraba graficas. Pero su capacidad real de detección se habia degradado hasta la irrelevancia.

Implicaciones para la seguridad nacional de España

Los riesgos de segundo y tercer orden que nadie esta discutiendo

La cobertura mediatica se ha centrado en el hecho de la filtracion y en la identidad de los afectados. Pero como perito forense, lo que más me preocupa son los riesgos de segundo y tercer orden que aun no se han materializado pero que son practicamente inevitables.

Riesgo 1: Compromisos en cadena no detectados. Las credenciales filtradas de cientos de agentes de Policia Nacional y Guardía Civil no solo dan acceso a los sistemás de Moncloa. Si esos agentes usan las mismás credenciales (o variantes predecibles) en otros sistemás gubernamentales, cada credencial filtrada es una puerta a bases de datos policiales, sistemás judiciales, plataformás de cooperacion internacional y registros de ciudadaños. El riesgo de un compromiso en cadena es real y probablemente ya se esta materializando.

Riesgo 2: Operaciones de inteligencia comprometidas. Los datos del JEMAD y los miembros del Consejo de Seguridad Nacional no son datos personales ordinarios. Son datos que un servicio de inteligencia hostil puede usar para reconstruir la estructura de decisión de la seguridad nacional española: quien habla con quien, que temás se tratan, que prioridades se establecen, que posiciones se defienden ante la OTAN y la UE. Esta información tiene un valor estrategico que va mucho más alla del daño personal a los individuos afectados.

Riesgo 3: Identificación de agentes encubiertos. Entre los cientos de agentes cuyas credenciales se filtraron, es posible que haya miembros de unidades de infiltracion, investigación encubierta o antiterrorismo. Si un grupo criminal o terrorista cruza los datos filtrados con otras fuentes de información disponibles en la dark web, podría identificar a agentes actualmente infiltrados en organizaciones criminales. Las consecuencias para su seguridad personal son evidentes y graves.

Riesgo 4: Manipulación de procesos judiciales. Los datos de la Fiscalia General del Estado que se filtraron podrían incluir información sobre investigaciones en curso y estrategias procesales. Un imputado que accediera a esta información podría usarla para obstruir la justicia, destruir pruebas o intimidar testigos. Esto no es especulativo: he peritado casos donde la filtracion de información procesal tuvo exactamente este efecto.

Riesgo 5: Perdida de confianza de aliados. España comparte información de inteligencia con otros paises de la OTAN y de la UE a traves de canales seguros. Si los aliados perciben que la ciberseguridad española esta comprometida, pueden reducir el nivel de información que comparten con España. Esto debilitaria la capacidad de inteligencia española de forma duradera, mucho más alla del impacto inmediato de la brecha.

Riesgo 6: Efecto demostración para otros atacantes. La publicacion exitosa de datos de la máxima institucion del Estado español envia un mensaje a otros grupos de ciberataque: España es un objetivo accesible. Si Moncloa fue comprometida, los ministerios con menos recursos son objetivos aun más atractivos. En ciberseguridad, los exitos visibles de los atacantes generan un efecto de atraccion que multiplica los intentos de ataque contra la misma víctima y contra organizaciones similares.

La respuesta inmediata: 2 millones de euros en refuerzo

Tras la brecha, Moncloa ha invertido más de 2 millones de euros en refuerzo de ciberseguridad. Aunque el detalle de las medidas no se ha hecho público, una respuesta típica a un incidente de esta magnitud incluye:

Como analizo más adelante en la seccion de respuesta a incidentes, estas medidas son necesarias pero insuficientes si no van acompanadas de cambios estructurales en la gobernanza.

Hay un aspecto económico que merece mencion: 2 millones de euros suena a mucho dinero, pero en el contexto de la ciberseguridad gubernamental de un pais del G20, es una cantidad modesta. Francia invierte más de 100 millones de euros anuales en la ANSSI. Alemania invierte más de 200 millones en el BSI. Incluso Estonia, con una poblacion de 1,3 millones de personas, invierte más de 10 millones anuales en ciberseguridad gubernamental. Los 2 millones de euros de Moncloa son un parche de emergencia, no una solución estructural. Si esta inversion no se acompana de un incremento sostenido del presupuesto de ciberseguridad gubernamental, estaremos ante la misma situación en dos o tres años.

El problema de la cadena de suministro: dependencia crítica de un único proveedor

Vendor lock-in en ciberseguridad gubernamental

Lo que ocurrio en Moncloa no es solo un fallo técnico. Es un fallo estructural del modelo de gestión de la ciberseguridad gubernamental española. He visto este mismo patrón en empresas que perito: el proveedor deja de dar soporte y nadie se entera hasta que es demasiado tarde. En el caso de Moncloa, la dependencia de un único fabricante de sistemás anti-APT creo un punto único de fallo que comprometio toda la postura de seguridad de la Presidencia del Gobierno.

El vendor lock-in en ciberseguridad gubernamental funciona así:

1. Contratacion inicial: Un organismo público lícita un contrato de ciberseguridad. El fabricante ganador despliega su solución propietaria, con sus propios formatos de logs, sus propias reglas de detección, su propia consola de gestión
2. Dependencia progresiva: Con el tiempo, toda la operativa de seguridad se construye alrededor del sistema del fabricante. Los analistas aprenden su interfaz, las alertas se integran en el SIEM, los procedimientos de respuesta a incidentes se basan en las capacidades del sistema
3. Coste de sustitucion creciente: Cambiar de fabricante implica reentrenar al personal, rehacer las integraciones, reescribir los procedimientos y asumir un periodo de transicion con cobertura reducida
4. Asimetria de poder: El fabricante sabe que sustituirlo es costoso y complejo. Esto le da capacidad de negociación sobre precios, condiciones de soporte y plazos

En el caso de Moncloa, cuando el fabricante dejo de proporcionar actualizaciones en noviembre de 2025, el Gobierno se encontro con que no tenia alternativa inmediata. El proceso de contratación pública para sustituir el sistema tardo meses. Mientras tanto, la Presidencia del Gobierno estuvo sin protección avanzada contra amenazas.

Lo que exige NIS2 sobre cadena de suministro

La Directiva NIS2, en su artículo 21.2.d, establece de forma explicita la obligación de gestionar los riesgos de la cadena de suministro. Es uno de los requisitos más detallados de toda la directiva, precisamente porque la UE reconoce que la dependencia de proveedores tecnologicos es un riesgo crítico para las entidades esenciales.

NIS2 Art. 21.2.d exige que las entidades esenciales (y Moncloa, como administración pública central, lo sería) implementen:

• Evaluación de riesgos de proveedores: Analizar la postura de seguridad de cada proveedor crítico, incluyendo su capacidad para mantener la continuidad del servicio
• Clausulas contractuales de seguridad: Los contratos con proveedores deben incluir requisitos de ciberseguridad, obligaciones de notificación de incidentes y garantías de continuidad de servicio
• Monitorizacion continua de proveedores: No basta con evaluar al proveedor al inicio del contrato. Hay que monitorizar su estado de seguridad durante toda la relación contractual
• Planes de contingencia: Procedimientos documentados para actuar cuando un proveedor falla, incluyendo alternativas precontratadas o medidas compensatorias temporales
• Diversificacion de proveedores críticos: Evitar puntos únicos de fallo. Si un proveedor falla, debe existir una alternativa que pueda activarse en un plazo razonable
• Clausulas de salida y portabilidad: Los contratos deben garantizar que al finalizar la relación, los datos, logs y configuraciones pueden migrarse a la nueva solución sin pérdida de información ni de continuidad operativa

En mi experiencia pericial, el incumplimiento del artículo 21.2.d de NIS2 es el que más directamente explica lo ocurrido en Moncloa. No se trata de un requisito abstracto o burocratico: es una obligación operativa concreta que, de haberse cumplido, habría impedido que la Presidencia del Gobierno pasara 100 días sin protección anti-APT.

Si España hubiera transpuesto NIS2 a tiempo (antes de octubre de 2024), Moncloa habría estado obligada legalmente a tener un plan de contingencia para exactamente este escenario. El hecho de que no lo tuviera demuestra que la no transposición de NIS2 no es solo un problema jurídico: tiene consecuencias operativas reales y medibles.

Puntos únicos de fallo en la ciberseguridad española

El caso Moncloa no es un incidente aislado. Es sintomatico de un problema más amplio en la gestión de la ciberseguridad gubernamental española: la concentracion de capacidades críticas en un número reducido de proveedores.

En mis peritajes para empresas del sector público, he identificado repetidamente este patrón:

• Un único fabricante de anti-APT protege multiples ministerios y organismos
• Un único integrador de seguridad gestiona los SOC de varias administraciones públicas
• Un único proveedor de cloud aloja los sistemás críticos de varias entidades
• Escasez de personal especializado que dificulta la diversificacion y la supervision independiente

Cuando cualquiera de estos puntos falla, el impacto se multiplica. Y como he visto en mis investigaciones, los atacantes lo saben: identifican al proveedor común y dirigen sus ataques a ese punto de concentracion para comprometer multiples objetivos con un solo ataque.

He peritado un caso que ilustra perfectamente este riesgo. Una empresa de servicios gestionados de ciberseguridad (MSSP) que proporcionaba SOC a 23 PYMEs fue comprometida a traves de una vulnerabilidad en su plataforma de gestión remota. El atacante no tuvo que hackear 23 empresas: hackeo una y obtuvo acceso a las 23. En 48 horas, desplegó ransomware en los sistemás de 17 de los 23 clientes, porque las credenciales de administración remota del MSSP daban acceso directo a todos ellos.

El paralelo con Moncloa es evidente: si un único fabricante protege la Presidencia del Gobierno y otros ministerios, y ese fabricante falla o deja de dar soporte, todos los organismos protegidos por ese fabricante quedan simultaneamente expuestos. La diversificacion no es un lujo: es una necesidad operativa.

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

Hay un aspecto del vendor lock-in gubernamental que es específico del sector público y que rara vez se discute: la Ley de Contratos del Sector Público (Ley 9/2017) impone procedimientos de contratación que, aunque necesarios para la transparencia y la competencia, pueden ser incompatibles con la velocidad que requiere la ciberseguridad.

Un procedimiento abierto de contratación pública tarda entre 3 y 6 meses desde la publicacion del pliego hasta la adjudicacion del contrato. Si le sumamos el periodo de preparación del pliego (1-2 meses), las posibles impugnaciones (2-3 meses adicionales) y el despliegue de la nueva solución (1-2 meses), el tiempo total puede superar los 12 meses.

Esto significa que si una organización pública necesita sustituir un sistema de ciberseguridad crítico, necesita empezar el proceso al menos 12 meses antes de que el sistema actual deje de recibir soporte. Si el fabricante anuncia el fin de soporte con 6 meses de antelacion (que ya es poco habitual), la organización pública no tiene tiempo suficiente para completar el proceso de contratación antes de quedarse sin protección.

Existen mecanismos de contratación de emergencia (artículo 120 de la Ley 9/2017) que permiten acelerar el proceso cuando hay una situación de urgencia “no imputable al orgaño de contratación”. Pero usar este mecanismo para sustituir un sistema anti-APT cuyo fin de soporte era conocido con antelacion es juridicamente cuestionable: la urgencia si era imputable al orgaño de contratación, que debería haber anticipado la necesidad de sustitucion.

Este dilema no tiene solución fácil, pero si tiene una solución práctica: anticipacion. Las cláusulas contractuales de todos los sistemás de seguridad críticos deberían incluir:

• Obligación del fabricante de comunicar cualquier cambio en la politica de soporte con un mínimo de 18 meses de antelacion
• Clausulas de continuidad que obliguen al fabricante a mantener actualizaciones durante el periodo de transicion
• Contratos marco preaprobados con fabricantes alternativos que puedan activarse de forma rápida en caso de necesidad
• Evaluación anual del ciclo de vida de todos los productos críticos con alerta automática a 18, 12 y 6 meses del fin de soporte

Comparacion internacional: como protegen otros paises europeos a sus gobiernos

Para entender la magnitud del fallo de Moncloa, es útil comparar como gestionan otros paises europeos la ciberseguridad de sus gobiernos. España no esta sola en enfrentar amenazas, pero si esta significativamente por detras de sus pares en capacidad de respuesta y gobernanza.

Modelos de referencia en Europa

Francia - ANSSI (Agence Nationale de la Securite des Systemes d’Information)

La ANSSI francesa es, en mi opinion profesional, el modelo de referencia en Europa para la ciberseguridad gubernamental. Depende directamente del Primer Ministro a traves de la Secretaria General de Defensa y Seguridad Nacional. Cuenta con más de 600 empleados especializados y un presupuesto anual de más de 100 millones de euros. La ANSSI tiene autoridad para imponer requisitos de seguridad a todos los ministerios y puede intervenir directamente en la respuesta a incidentes. Su modelo de “calificacion” de productos de seguridad obliga a los organismos públicos a usar solo soluciónes certificadas, lo que reduce el riesgo de vendor lock-in al existir multiples productos calificados.

Alemania - BSI (Bundesamt fur Sicherheit in der Informationstechnik)

El BSI aleman tiene un enfoque más técnico y normativo. Con más de 1.500 empleados, el BSI pública estandares de seguridad (IT-Grundschutz) que son obligatorios para toda la administración federal. El BSI opera un CERT gubernamental dedicado con capacidad de respuesta 24/7 y mantiene un catálogo de productos de seguridad aprobados con multiples proveedores por categoría. Alemania fue uno de los primeros paises en transponer NIS2, con la ley NIS2UmsuCG aprobada en 2024.

Reino Unido - NCSC (National Cyber Security Centre)

El NCSC britanico, parte del GCHQ, combina inteligencia de senales con capacidad operativa de ciberseguridad. El programa Active Cyber Defence protege automáticamente millones de conexiones gubernamentales. El NCSC pública guías prácticas (como el Cyber Essentials) y opera un servicio de alerta temprana que notifica a las organizaciones cuando detecta amenazas dirigidas contra ellas. Su modelo de “seguridad por defecto” significa que los ministerios reciben protección base sin necesidad de contratarla individualmente.

Estonia - RIA (Riigi Infosusteem Amet)

Incluyo a Estonia porque, a pesar de ser un pais pequeño, es el referente europeo en ciberseguridad gubernamental desde que sufrio los ciberataques masivos de 2007 atribuidos a Rusia. Tras esos ataques, Estonia creo un ecosistema de ciberseguridad que incluye: una infraestructura digital distribuida (X-Road) disenada para ser resiliente a ataques, un sistema de respaldo completo de datos gubernamentales en una “embajada de datos” en Luxemburgo, ejercicios anuales de ciberdefensa a gran escala (Locked Shields, organizados por el NATO CCDCOE con sede en Tallin), y una obligación legal de que todos los sistemás gubernamentales cumplan con el estandar ISKE (equivalente estonio del ENS pero con auditorias de cumplimiento más rigurosas y frecuentes).

Lo que Estonia demostro es que el tamaño del pais no determina la calidad de su ciberseguridad. Lo que determina es la voluntad politica y la priorizacion de recursos. Estonia invierte el 0.5% de su PIB en ciberseguridad gubernamental, un porcentaje significativamente mayor que el de España. Y lo más relevante: Estonia sufrio un ciberataque catastrofico en 2007 y lo uso como catalizador para transformar completamente su postura de ciberseguridad. La pregunta es si España hará lo mismo con el hackeo a Moncloa, o si este incidente se olvidara en semanas y nada cambiara estructuralmente.

Paises Bajos - NCSC-NL

Otro modelo relevante es el de los Paises Bajos. Su NCSC-NL tiene una particularidad interesante: pública informes detallados de incidentes de ciberseguridad en organismos gubernamentales, incluyendo las causas raiz y las medidas adoptadas. Esta transparencia no debilita la seguridad: la refuerza, porque permite que otros organismos aprendan de los errores ajenos. Si España adoptara un modelo similar de transparencia, el hackeo a Moncloa podría servir para mejorar la ciberseguridad de toda la administración pública. Sin transparencia, cada organismo esta condenado a cometer los mismos errores.

Tabla comparativa: España vs pares europeos

La diferencia es notable. Mientras Francia, Alemania y el Reino Unido tienen agencias autonomás con autoridad directa sobre la seguridad de sus gobiernos, presupuestos dedicados y capacidad operativa propia, España depende de un modelo fragmentado donde el CCN-CERT opera bajo el paraguas del CNI con recursos limitados y sin autoridad para imponer estandares a otros ministerios.

Lo que España podría aprender de cada modelo

De Francia: La autoridad de imposicion. Cuando la ANSSI detecta una vulnerabilidad crítica en un sistema de un ministerio, puede ordenar su remediacion inmediata. No necesita pedir permiso ni coordinar con nadie. Si la ANSSI hubiera tenido jurisdicción sobre Moncloa, habría obligado a sustituir el sistema anti-APT el mismo día que el fabricante dejo de actualizarlo, o habría impuesto medidas compensatorias inmediatas. En España, el CCN-CERT puede recomendar pero no puede obligar. Y las recomendaciones, como hemos visto, no siempre se siguen.

De Alemania: El marco normativo obligatorio. El IT-Grundschutz del BSI no es una guía de buenas prácticas: es un estandar obligatorio para toda la administración federal. Cada organismo debe certificar su cumplimiento periódicamente. Si Moncloa estuviera sujeta a un estandar equivalente, la obsolescencia del sistema anti-APT habría sido detectada en la auditoria de cumplimiento trimestral. En España, el Esquema Nacional de Seguridad (ENS) existe pero su cumplimiento y auditoria son desiguales entre organismos.

Del Reino Unido: La protección automática y centralizada. El programa Active Cyber Defence del NCSC protege automáticamente a todos los dominios gubernamentales (.gov.uk) contra amenazas comunes: phishing, malware, DNS malicioso. Los ministerios reciben esta protección sin necesidad de contratarla ni gestionarla individualmente. Si España tuviera un programa equivalente, habría proporcionado una capa base de protección durante los 100 días sin anti-APT, reduciendo significativamente la superficie de ataque.

En mi opinion profesional, España necesita una agencia de ciberseguridad gubernamental con tres caracteristicas que hoy no tiene: autonomia organizativa (no depender del CNI), autoridad de imposicion (poder obligar a los organismos a cumplir estandares de seguridad) y presupuesto dedicado y suficiente (no sujeto a las restricciones presupuestarias de otros organismos). Sin estas tres condiciones, seguiremos viendo incidentes como el de Moncloa.

Análisis politico e institucional: quien es responsable

La fragmentacion de la ciberseguridad española

Uno de los problemás estructurales que este incidente pone de manifiesto es la fragmentacion de competencias en materia de ciberseguridad en España. No existe un único organismo con autoridad clara y recursos suficientes para proteger toda la administración pública.

CCN-CERT (Centro Criptologico Nacional): Depende del CNI y es el CERT de referencia para las administraciones públicas. Pero su capacidad operativa esta limitada por el hecho de que depende del Centro Nacional de Inteligencia, cuya prioridad es la inteligencia, no la ciberseguridad operativa de los ministerios. El CCN-CERT emite guías y alertas, pero no tiene autoridad para imponer medidas a Moncloa o a cualquier otro ministerio.

DTIC (Departamento de Tecnologias de la Información y las Comunicaciones): Dependiente de Presidencia del Gobierno, es el organismo que gestiona la infraestructura tecnologica de Moncloa. Es, presumiblemente, quien contrato el sistema anti-APT que dejo de funcionar y quien debería haber detectado la caducidad del soporte. La pregunta obvia es: sabia DTIC que el sistema llevaba 100 días sin actualizaciones y, si lo sabia, por que no activo un plan de contingencia?

DSN (Departamento de Seguridad Nacional): Asesora al Presidente del Gobierno en materia de seguridad nacional. Deberia haber sido alertado de que un sistema crítico de ciberseguridad de Moncloa estaba degradado. Si no fue informado, hay un fallo de comunicación interna grave. Si fue informado y no actuo, hay un fallo de gobernanza aun más grave.

INCIBE: Dependiente del Ministerio de Transformacion Digital, es el CERT de referencia para ciudadaños y empresas, no para la administración pública. No tiene competencia directa sobre la ciberseguridad de Moncloa.

Mando Conjunto del Ciberespacio (MCCE): Dependiente del Ministerio de Defensa, es responsable de la ciberdefensa militar. Su competencia se limita al ámbito de las Fuerzas Armadas, aunque la filtracion de datos del JEMAD debería haberlo involucrado.

Esta fragmentacion es, en mi opinion profesional, la raiz del problema. No existe un único responsable con autoridad, presupuesto y capacidad operativa para garantizar la ciberseguridad de toda la administración pública española. Cada organismo depende de un ministerio diferente, con prioridades diferentes y sin obligación de coordinarse de forma efectiva.

La brecha entre la retorica y la realidad

España ha publicado dos Estrategias Nacionales de Ciberseguridad (2013 y 2019) y ha participado activamente en foros europeos de ciberseguridad. Pero la brecha entre la retorica institucional y la realidad operativa es enorme. Un gobierno que no es capaz de mantener actualizado su propio sistema anti-APT durante 100 días no esta en posición de liderar la ciberseguridad europea ni de exigir a las empresas privadas que cumplan con estandares que el mismo incumple.

Este no es un problema nuevo. En los últimos 18 meses hemos visto una serie de incidentes que demuestran un patrón sistemático de debilidad en la ciberseguridad institucional española:

• La brecha de datos de la Policia Nacional que expuso información de unidades antiterroristas
• La multa de 10 millones de euros de la AEPD a AENA por el uso de reconocimiento facial en aeropuertos sin base legal
• El ciberataque a la bolsa de vivienda de Barcelona que expuso 6.800 datos personales
• El hackeo al sistema de la Comision Nacional del Mercado de Valores que obligo a suspender operaciones durante horas

Cada uno de estos incidentes se presento como un caso aislado. Pero cuando los analizas en conjunto, como hago en mis informes periciales, el patrón es claro: falta de inversion, fragmentacion de competencias, ausencia de un marco legal actualizado y una cultura institucional que trata la ciberseguridad como un gasto y no como una inversion.

La responsabilidad politica

Una pregunta que nadie ha planteado publicamente pero que como perito considero fundamental: quien tomo la decisión de no activar un plan de contingencia cuando el sistema anti-APT dejo de recibir actualizaciones en noviembre de 2025? Alguien en la cadena de mando tuvo que saber que el sistema estaba degradado. O peor: nadie lo supo, lo que significaria que no habia ningun mecanismo de supervision operativa sobre los sistemás de seguridad de la Presidencia del Gobierno.

En cualquiera de los dos escenarios, hay una responsabilidad politica que no se puede eludir. Si alguien sabia y no actuo, hay negligencia. Si nadie sabia, hay incompetencia organizativa. Y en ambos casos, los ciudadaños españoles cuya seguridad nacional depende de estos sistemás merecen una explicación pública y un plan concreto para que no vuelva a ocurrir.

La necesidad de un CISO nacional

Una de las conclusiones más claras de este incidente es que España necesita un responsable nacional de ciberseguridad con autoridad ejecutiva real. Actualmente, las competencias de ciberseguridad estan repartidas entre el CCN-CERT (CNI), el INCIBE (Ministerio de Transformacion Digital), el MCCE (Ministerio de Defensa) y el DSN (Presidencia del Gobierno). Ninguno tiene autoridad sobre los otros. Ninguno tiene un presupuesto dedicado suficiente. Y como demuestra el caso Moncloa, ninguno fue capaz de prevenir una brecha en la máxima institucion del Estado.

Lo que España necesita es una figura equivalente al National Cyber Director de Estados Unidos o al directeur general de la ANSSI francesa: un responsable único con autoridad sobre la ciberseguridad de toda la administración pública, con acceso directo al Presidente del Gobierno y con un presupuesto dedicado que no dependa de las prioridades presupuestarias de otros ministerios.

Esta figura debería tener la capacidad de:

• Imponer estandares mínimos de seguridad a todos los organismos públicos
• Auditar el cumplimiento de esos estandares de forma periodica e independiente
• Activar protocolos de emergencia cuando detecte situaciones de riesgo como la que precedio a la brecha de Moncloa
• Coordinar la respuesta a incidentes de seguridad nacional a traves de todos los organismos afectados
• Representar a España en foros internacionales de ciberseguridad con autoridad y credibilidad

Sin esta figura, seguiremos dependiendo de un modelo de coordinacion voluntaria donde cada organismo gestiona su ciberseguridad de forma independiente y donde nadie tiene la autoridad para imponer medidas cuando un sistema crítico esta en riesgo. El resultado de ese modelo es exactamente lo que hemos visto en Moncloa: 100 días sin protección y una brecha de datos de seguridad nacional.

La investigación de la UE: procedimiento de infracción por NIS2

Que significa la investigación de la UE

Este incidente no ocurre en el vacio. La UE ya estaba investigando a España por no transponer la Directiva NIS2, la normativa europea de ciberseguridad que debería haberse incorporado al ordenamiento jurídico español antes de octubre de 2024. España acumula más de 16 meses de retraso en una de las directivas más críticas para la seguridad digital del continente.

El procedimiento de infracción paso a paso

La Comision Europea ha abierto un procedimiento de infracción contra España (y contra otros 22 Estados miembros) por no transponer NIS2 en plazo. Este es el proceso y lo que puede pasar:

Precedentes de sanciones por no transposición

La UE ya ha sancionado a Estados miembros por no transponer directivas de ciberseguridad y protección de datos. Algunos precedentes relevantes:

• Portugal - Directiva NIS1 (2018): Fue uno de los últimos paises en transponer la primera directiva NIS. Recibio un dictamen motivado pero evito el TJUE al transponer in extremis
• Grecia - RGPD implementation (2019): Sanciones por deficiencias en la implementacion de la autoridad de protección de datos, con requerimiento de correccion en 6 meses
• Alemania - Directiva de datos abiertos (2021): Multa de 1.6 millones de euros por retraso en la transposición, más una multa coercitiva diaria de 47.000 EUR que se aplico durante varios meses
• España - Directiva antiblanqueo (2020): España fue sancionada con dictamen motivado por retraso en la transposición de la Quinta Directiva Antiblanqueo, lo que forzó una tramitación urgente en las Cortes

Lo relevante de estos precedentes es que la Comision Europea ya no es tolerante con los retrasos en la transposición. Con 101 directivas pendientes, España es uno de los peores cumplidores de la UE. La combinacion del retraso en NIS2 con el hackeo a Moncloa refuerza la posición de la Comision y hace más probable que el procedimiento avance hasta el TJUE.

Calculo estimado de las sanciones para España

El calculo de las sanciones del TJUE por no transposición sigue una formula establecida que tiene en cuenta tres factores: la gravedad de la infracción, su duracion y la capacidad de pago del Estado miembro (medida por su PIB).

Para España, con un PIB de aproximadamente 1,46 billones de euros (2025), los parametros serían:

Estas cifras son estimaciones basadas en precedentes del TJUE, pero dan una idea de la magnitud de las sanciones potenciales. Y lo más importante: la multa coercitiva diaria se acumula hasta que España complete la transposición. Cada día de retraso adicional suma más de 100.000 euros al total.

El estado del anteproyecto español

España esta trabajando en la Ley de Coordinacion y Gobernanza de la Ciberseguridad, que transpondria NIS2 al ordenamiento jurídico español. El anteproyecto fue aprobado por el Consejo de Ministros pero sigue pendiente de tramitación parlamentaria. Dadas las dinamicas politicas actuales, con un gobierno en minoria, no hay garantía de que la ley se apruebe en los próximos meses.

La ironia es que esta ley habría obligado a Moncloa a implementar exactamente las medidas que habrían prevenido esta brecha: gestión de riesgos en la cadena de suministro, continuidad de los sistemás de detección, planes de contingencia para proveedores críticos y notificación temprana de incidentes.

El efecto del hackeo a Moncloa en el procedimiento de infracción

En mi opinion profesional, el hackeo a Moncloa ha cambiado la dinamica del procedimiento de infracción de la UE contra España. Antes del incidente, España era uno más de los 23 Estados miembros que no habian transpuesto NIS2 a tiempo. Ahora, España es el Estado miembro que no transpuso NIS2 y cuya propia Presidencia del Gobierno sufrio un ciberataque directamente relacionado con las carencias que NIS2 pretende cubrir.

La Comision Europea no ha mencionado publicamente el hackeo en relación con el procedimiento de infracción, pero sería ingenuo pensar que no afecta a la evaluación. Los servicios jurídicos de la Comision seguramente han tomado nota de que las consecuencias de la no transposición de NIS2 ya no son teoricas: se han materializado en la forma de una brecha de seguridad nacional en el pais que no cumplio con la directiva.

Esto refuerza tres argumentos que la Comision puede usar ante el TJUE:

1. Urgencia de la transposición: La brecha demuestra que la falta de un marco legal actualizado tiene consecuencias reales e inmediatas
2. Necesidad de sanciones disuasorias: Una multa significativa es necesaria para que España (y otros Estados miembros rezagados) prioricen la transposición
3. Daño concreto cuantificable: La brecha proporciona evidencia tangible del perjuicio causado por la no transposición, algo que normalmente es difícil de demostrar en procedimientos de infracción

5 lecciones detalladas para organizaciones, desde la experiencia pericial

Llevo años elaborando informes periciales para empresas que han sufrido brechas similares. El caso Moncloa ofrece lecciones directamente aplicables a cualquier organización que dependa de sistemás de ciberseguridad gestionados por terceros. Lo que le ha pasado al Gobierno de España le puede pasar a cualquier PYME que deje caducar su antivirus.

Leccion 1: La cadena de suministro tecnologica es un vector crítico

Si el fabricante de tu solución de seguridad deja de dar soporte, tu organización queda expuesta. He peritado el caso de una empresa de logistica en Andalucia que sufrio un ransomware tres semanas después de que su proveedor de EDR fuera adquirido por otra empresa y cesara temporalmente las actualizaciones. Nadie en la empresa sabia que el sistema estaba degradado. El ransomware cifro todos los servidores de producción y la empresa perdio dos semanas de facturacion.

Lo que las empresas deben hacer:

• Monitorizar el ciclo de vida de todos los productos de seguridad desplegados. Configurar alertas para 12 meses, 6 meses y 3 meses antes del fin de soporte anunciado
• Planificar la sustitucion con al menos 6 meses de antelacion al fin de soporte. No esperar a que el fabricante deje de actualizar para empezar a buscar alternativas
• Diversificar proveedores para evitar puntos únicos de fallo. Si tu anti-APT es de un fabricante, tu EDR debería ser de otro. Si ambos son del mismo, un único fallo compromete ambas capas
• Incluir cláusulas de transicion en los contratos: el fabricante debe mantener actualizaciones hasta que el sustituto este completamente operativo
• Mantener un registro centralizado de todos los productos de seguridad con sus fechas de fin de soporte, responsable asignado y plan de sustitucion documentado

He elaborado un modelo de hoja de seguimiento que recomiendo a todos mis clientes de peritaje preventivo:

Si Moncloa hubiera tenido esta tabla actualizada, el “0 meses restantes” del anti-APT habría disparado una alarma inmediata. El hecho de que no la tuvieran (o de que la tuvieran y la ignoraran) es en si mismo un indicador de la falta de madurez en la gestión de ciberseguridad.

Leccion 2: La continuidad contractual no es negociable

El gap entre el fin de soporte del fabricante y la formalizacion del nuevo contrato fue la causa directa de la exposicion en Moncloa. He visto este patrón en al menos cinco peritajes en los últimos dos años: el contrato de seguridad caduca, el departamento de compras tarda semanas o meses en formalizar la renovacion o la sustitucion, y durante ese periodo la empresa esta desprotegida.

En un caso que perite para un despacho de abogados de Madrid, el contrato de su firewall de nueva generacion caduco en agosto. El proveedor dejo de actualizar las firmas. El departamento de IT no se dio cuenta hasta octubre, cuando un phishing sofisticado comprometio las credenciales de dos socios. El atacante accedio a expedientes de clientes durante tres semanas antes de que se detectara la intrusion. El despacho se enfrento a reclamaciones de sus clientes por violación de la confidencialidad abogado-cliente, una reclamación ante la AEPD y un daño reputacional que le costo varios clientes importantes.

En otro caso, una empresa del sector energetico en Andalucia tenia un contrato de mantenimiento de su SIEM con una empresa de servicios gestionados. El contrato vencio en diciembre y la renovacion se retraso por una disputa sobre el precio. La empresa de servicios gestionados dejo de monitorizar las alertas el 1 de enero. Durante los 45 días que tardo en resolverse la disputa, un atacante comprometio la red OT (Operational Technology) de la empresa, que controla infraestructura crítica. El incidente pudo haber tenido consecuencias físicas además de digitales. Cuando me contrataron para el peritaje, determine que el atacante habia entrado el 8 de enero, solo una semana después de que cesara la monitorizacion. La evidencia sugeria que el atacante habia estado esperando exactamente ese momento.

La leccion para las empresas es clara: si un despacho de abogados de Madrid y una empresa del sector energetico de Andalucia pueden sufrir brechas por gaps contractuales, cualquier organización puede. Y el patrón es siempre el mismo: el contrato vence, hay un periodo sin cobertura, y el atacante lo aprovecha. La solución no es tecnologica: es contractual y organizativa.

Los contratos de ciberseguridad deben incluir:

• Clausulas de continuidad de servicio hasta la transicion efectiva a la nueva solución, con SLA mínimo de respuesta ante amenazas críticas durante la transicion
• Penalizaciones económicas por interrupcion unilateral del soporte sin preaviso suficiente (mínimo 12 meses de preaviso para contratos anuales, 18 meses para contratos plurianuales)
• Planes de contingencia documentados y probados al menos una vez al año, que incluyan escenarios de pérdida total de soporte del proveedor
• Derecho de auditoria sobre el estado de las actualizaciones del proveedor, ejercitable sin previo aviso al menos una vez por trimestre
• Cláusula de notificación inmediata si el proveedor sufre un incidente de seguridad que pueda afectar a la protección del cliente

Leccion 3: La detección debe ser continua, sin excepciones

Un sistema anti-APT sin actualizaciones es como no tener sistema. Peor aun: es como tener un sistema que te da una falsa sensacion de seguridad. La falsa sensacion de seguridad es, en mi experiencia profesional, más peligrosa que la ausencia total de protección, porque lleva a comportamientos de riesgo que no se adoptarian si se supiera que no hay protección.

He peritado un caso donde una empresa de comercio electrónico tenia un SIEM que llevaba meses sin recibir logs de uno de sus servidores críticos porque la integracion se rompio tras una actualizacion del sistema operativo. Nadie verifico que los logs seguian llegando. Cuando un atacante comprometio ese servidor, no hubo ninguna alerta porque el SIEM simplemente no lo estaba monitorizando. El atacante estuvo dentro 4 meses, exfiltro datos de 23.000 clientes incluyendo tarjetas de credito, y la empresa se entero cuando Visa les contacto por un patrón de fraude anormalmente alto en tarjetas de sus clientes.

En otro caso, una clinica dental en Valencia tenia un antivirus que habia dejado de actualizarse porque la tarjeta de credito asociada al pago anual habia caducado. El proveedor envio tres avisos por email, pero iban al buzón de la persona que habia configurado la cuenta y que ya no trabajaba en la clinica. El antivirus mostro un aviso en pantalla durante dos semanas, pero el personal lo ignoro pensando que era publicidad. Un ransomware cifro todos los historiales clinicos de 8.000 pacientes. La clinica pago un rescate de 12.000 euros y aun así perdio los datos de los últimos 3 meses porque los backups también estaban en la misma red y fueron cifrados.

Las organizaciones deben verificar de forma continua:

• Que las actualizaciones de firmás e IoC se aplican diariamente. Configurar alertas si las actualizaciones no se reciben en 24 horas
• Que los feeds de inteligencia de amenazas estan activos y proporcionando datos actualizados
• Que el personal de seguridad recibe alertas operativas del sistema. Si las alertas dejan de llegar, no significa que no haya amenazas: puede significar que el sistema ha dejado de funcionar
• Que los dashboards de monitorizacion se revisan diariamente. Un dashboard vacio no es un dashboard sano: puede ser un dashboard desconectado
• Que existe un mecanismo de “dead man’s switch”: si el sistema de seguridad no reporta actividad durante más de 24 horas, se genera automáticamente una alerta de nivel crítico

El concepto de “dead man’s switch” es algo que recomiendo a todos mis clientes. La idea es simple: si tu sistema de seguridad esta funcionando correctamente, debería estar generando alertas, logs y reportes de forma continua. Si deja de hacerlo, no significa que no haya amenazas: significa que algo esta mal con el sistema. Configurar una alerta que se dispare cuando el sistema deja de reportar es una medida simple que habría detectado la obsolescencia del sistema anti-APT de Moncloa en las primeras 24 horas, no 100 días después.

Leccion 4: El presupuesto de ciberseguridad no puede ser reactivo

Moncloa invirtio más de 2 millones de euros después del incidente. El coste de haber mantenido la continuidad del sistema anti-APT habría sido una fraccion de esa cifra.

En mi experiencia como perito, las empresas que invierten reactivamente siempre pagan mas. He visto a empresas gastar 10 veces más en la respuesta a un incidente de lo que habría costado prevenirlo. Y no me refiero solo al coste técnico: el coste reputacional, el coste legal, las horas de trabajo pérdidas, la interrupcion del negocio y el daño a la confianza de los clientes multiplican el impacto económico por un factor de 3 a 5 veces sobre el coste técnico directo.

Según datos de IBM Cost of a Data Breach Report 2025, el coste medio de una brecha de datos en el sector público es de 2,6 millones de euros. Pero el coste de mantener un sistema de detección actualizado rara vez supera los 200.000-300.000 euros anuales para una organización del tamaño de Moncloa. La matematica es clara: invertir en prevención es siempre más económico que gestionar las consecuencias.

Un ejemplo concreto de mi práctica profesional: una empresa industrial de Jaen me contrato para peritar un incidente de ransomware. El atacante habia entrado por una vulnerabilidad conocida en un servidor VPN que llevaba 8 meses sin parchear. El parche estaba disponible desde el día siguiente a la publicacion de la vulnerabilidad. Aplicarlo habría costado 2 horas de trabajo de un técnico. En cambio, la empresa gasto más de 180.000 euros en respuesta al incidente, perdio 12 días de producción y sufrio un daño reputacional que le costo dos contratos con clientes importantes. Dos horas de trabajo preventivo habrían evitado 180.000 euros de daño. Ese es el ratio real de la prevención.

Leccion 5: La respuesta a incidentes debe estar preparada antes del incidente

El análisis forense digital posterior a un ataque solo puede recuperar evidencia que se haya preservado. Sin sistemás de detección activos durante 100 días, la cantidad de evidencia forense disponible se reduce drasticamente.

He peritado casos donde la empresa afectada no tenia logs de red de los 90 días previos al incidente porque su sistema de retención de logs estaba configurado con un periodo de 30 días. Cuando el atacante fue detectado tras 4 meses de permanencia, solo teniamos visibilidad del último mes. Los 3 meses anteriores eran un agujero negro forense. No pudimos determinar por donde entro el atacante, que datos exfiltro durante los primeros meses, ni cuantos sistemás comprometio antes de ser detectado.

He peritado un caso donde una empresa de servicios financieros sufrio una brecha y me llamo 72 horas después del incidente. Para entonces, el equipo interno de IT ya habia reinstalado los servidores comprometidos “para volver a la normalidad lo antes posible”. Al reinstalar, destruyeron la evidencia forense: imagenes de disco, memoria RAM, artefactos del atacante, logs locales. Mi capacidad para determinar el vector de entrada, el alcance real del compromiso y los datos exfiltrados quedo severamente limitada. El informe pericial que pude emitir fue mucho menos concluyente de lo que habría sido si me hubieran llamado antes de tocar los sistemas. La empresa termino pagando la multa máxima de la AEPD porque no pudo demostrar que habia tomado medidas adecuadas para proteger los datos.

Las organizaciones necesitan:

• Un plan de respuesta a incidentes documentado y ensayado al menos dos veces al año, que incluya explicitamente la instrucción de NO reinstalar ni modificar los sistemás comprometidos hasta que un forense los haya analizado
• Retenciones de logs configuradas a un mínimo de 12 meses. Para datos críticos, 24 meses. Almacenados en un sistema independiente que el atacante no pueda alcanzar
• Contacto previo con un perito informático forense para activar en caso de incidente. Buscar un perito después de sufrir la brecha implica perder horas críticas en las que la evidencia se degrada
• Backups inmutables verificados periódicamente. Los atacantes sofisticados buscan y destruyen los backups antes de activar el ransomware. Los backups deben estar en un sistema desconectado o inmutable (write-once, read-many)
• Segmentacion de red que limite el movimiento lateral del atacante. Si cada departamento esta en su propia VLAN con controles de acceso entre ellas, comprometer un segmento no da acceso automático a todos los demas

Que debería hacer Moncloa ahora: respuesta a incidentes basada en ISO 27035 y NIST CSF

Basandome en mi experiencia pericial y en los marcos de referencia ISO 27035 (gestión de incidentes de seguridad de la información) y NIST Cybersecurity Framework, estas son las 8 acciones que Moncloa debería ejecutar de forma inmediata. Algunas es probable que ya esten en marcha, pero como perito, considero crítico que se completen todas:

Mi valoración personal de la respuesta de Moncloa

Siendo directo: la inversion de 2 millones de euros en refuerzo de ciberseguridad es necesaria pero insuficiente si no va acompanada de un cambio estructural en la gobernanza de la ciberseguridad gubernamental. He visto a empresas gastar cantidades similares tras un incidente para comprar tecnología nueva, sin cambiar los procesos ni las personas que permitieron que el incidente ocurriera. Seis meses después, sufren otra brecha porque la tecnología nueva se gestiona con los mismos procesos defectuosos.

Lo que necesita Moncloa no es solo un nuevo sistema anti-APT. Necesita:

• Un responsable de ciberseguridad (CISO) con autoridad real y acceso directo al Presidente, no enterrado bajo tres niveles de burocracia en el DTIC
• Auditorias de seguridad trimestrales independientes, no realizadas por el mismo equipo que gestiona los sistemas
• Simulacros de incidentes (tabletop exercises) al menos dos veces al año, con participación de los altos cargos afectados
• Un protocolo de escalado automático cuando un sistema crítico de seguridad pierde actualizaciones durante más de 7 días
• Clausulas contractuales con todos los proveedores de seguridad que incluyan obligaciones de continuidad y penalizaciones por interrupcion

Sin estos cambios estructurales, la inversion de 2 millones de euros solo compra tiempo hasta el próximo incidente.

Que deben aprender las empresas: checklist de gestión de proveedores de seguridad

El caso Moncloa tiene implicaciones directas para cualquier empresa que dependa de proveedores de ciberseguridad. Esta checklist resume las acciones concretas que toda organización debería implementar:

Gestión del ciclo de vida de productos de seguridad

En mi práctica profesional, he desarrollado un sistema de gestión del ciclo de vida de productos de seguridad que recomiendo a todas las organizaciones que me consultan. No es complicado, pero requiere disciplina y un responsable claramente asignado:

• Mantener un inventario actualizado de todos los productos de seguridad desplegados, con su versión, fecha de instalación y fecha de fin de soporte. Este inventario debe revisarse al menos trimestralmente
• Configurar alertas automáticas para 18, 12, 6 y 3 meses antes del fin de soporte de cada producto. La alerta de 18 meses es crítica para administraciones públicas que necesitan tiempo para completar procesos de contratación
• Asignar un responsable para cada producto crítico que verifique mensualmente que las actualizaciones se estan aplicando. Este responsable debe firmar un check mensual que queda documentado
• Documentar un procedimiento de sustitucion para cada producto, con alternativas preaprobadas y tiempos estimados de transicion. El procedimiento debe incluir medidas compensatorias para el periodo de transicion
• Realizar un test de funcionamiento trimestral: ejecutar una muestra de malware conocido en un entorno controlado para verificar que el sistema lo detecta. Si no lo detecta, investigar inmediatamente

Clausulas contractuales obligatorias

• Obligación del proveedor de notificar con 12 meses de antelacion cualquier cambio en el ciclo de soporte del producto
• Cláusula de continuidad: el proveedor debe mantener actualizaciones hasta que la transicion al sustituto este completamente operativa
• Derecho de auditoria: la empresa debe poder verificar en cualquier momento que el proveedor esta cumpliendo con sus obligaciones de actualizacion
• Penalizaciones económicas por interrupcion unilateral del soporte sin preaviso suficiente
• Cláusula de acceso a datos: en caso de terminacion del contrato, el proveedor debe facilitar la exportacion de logs, configuraciones y datos en formato estandar

Redundancia en sistemás de seguridad

• Nunca depender de un único fabricante para la detección de amenazas. Si el anti-APT es del fabricante A, el EDR debe ser del fabricante B
• Mantener un SIEM independiente que agregue logs de todas las fuentes, de modo que si un sistema falla, los logs siguen estando disponibles
• Implementar al menos dos capas de detección independientes para cada vector de ataque crítico (email, endpoint, red, identidad)
• Probar periódicamente que cada capa funciona de forma independiente, simulando el fallo de las otras capas

Monitorizacion proactiva del estado de los sistemás de seguridad

He visto demasiadas empresas que asumen que sus sistemás de seguridad funcionan correctamente porque “no reciben alertas”. La ausencia de alertas no significa ausencia de amenazas. Puede significar que el sistema ha dejado de funcionar.

Cada organización debería implementar lo que yo llamo “verificación de pulso” de sus sistemás de seguridad:

Si Moncloa hubiera tenido esta tabla implementada y verificada, la caducidad del sistema anti-APT se habría detectado en la verificación diaria de actualizaciones. No 100 días después, cuando los datos ya estaban en la dark web.

Protocolo de actuación cuando un sistema de seguridad falla

Basandome en mi experiencia como perito y en las mejores prácticas del NIST Cybersecurity Framework, he desarrollado un protocolo de actuación inmediata que toda organización debería tener preparado para cuando un sistema de seguridad crítico falle o deje de recibir soporte:

Primeras 24 horas:

• Evaluar el impacto: que sistemás y datos quedan sin protección
• Notificar al responsable de seguridad y a la dirección
• Activar medidas compensatorias inmediatas: restricción de accesos remotos, monitorizacion manual reforzada, aumento de la frecuencia de backups
• Contactar al proveedor para negociar un periodo de transicion con soporte mínimo
• Documentar la situación y las medidas adoptadas

Primera semana:

• Desplegar herramientas de seguridad alternativas temporales (open source o versiones de evaluación de otros fabricantes)
• Intensificar la monitorizacion de logs: revisar manualmente los eventos de seguridad que el sistema obsoleto podría no estar detectando
• Realizar un escaneo de vulnerabilidades para identificar posibles compromisos ocurridos desde que el sistema dejo de actualizarse
• Iniciar el proceso de contratación urgente del sistema sustituto

Primer mes:

• Ejecutar un threat hunting básico: buscar indicadores de compromiso conocidos en los sistemás protegidos por el sistema obsoleto
• Considerar la contratación temporal de un servicio de monitorizacion externo (SOC as a Service) para cubrir el gap
• Verificar que todos los usuarios con acceso a los sistemás afectados tienen autenticación multifactor activa
• Preparar un informe de riesgos para la dirección que cuantifique el impacto potencial de una brecha durante el periodo de exposicion

Si Moncloa hubiera seguido este protocolo desde noviembre de 2025, los 100 días de exposicion se habrían reducido a semanas, y las medidas compensatorias habrían limitado significativamente la superficie de ataque disponible para los atacantes.

El coste de la inaccion: prevención vs respuesta

Una de las preguntas que más me hacen como perito es: “cuanto cuesta realmente protegerse, y merece la pena la inversion?”. La respuesta es siempre la misma: la prevención cuesta una fraccion de lo que cuesta la respuesta a un incidente. El caso Moncloa lo demuestra con números:

Fuentes: IBM Cost of a Data Breach Report 2025, ENISA NIS Investments Report 2025, Accenture State of Cybersecurity Resilience 2025.

Lo que estos números no capturan es el coste intangible: la pérdida de confianza de los ciudadaños en la capacidad del Gobierno para proteger sus datos, el daño a la posición de España en foros internacionales de ciberseguridad, y el efecto desmotivador sobre los cientos de agentes cuyas credenciales han sido comprometidas.

En mi experiencia como perito, el ratio real de coste prevención vs coste brecha suele ser aun mayor que 1:10, porque las empresas tienden a subestimar los costes indirectos de una brecha: horas de trabajo desviadas de tareas productivas, oportunidades de negocio pérdidas mientras se gestiona la crisis, y el incremento permanente de las primás de ciberseguro tras un incidente.

Desglose del coste real de la brecha de Moncloa

Para dimensionar correctamente el impacto económico del hackeo a Moncloa, hay que ir mucho más alla de los 2 millones de euros anunciados como inversion en refuerzo de ciberseguridad. Ese es solo el coste directo más visible. El coste real incluye:

Compara esos 3-5 millones de euros con el coste de haber mantenido la continuidad del sistema anti-APT: entre 200.000 y 400.000 euros anuales. La matematica es aplastante e irrefutable. Como perito, este es el argumento que presento ante los consejos de administración de mis clientes: no invertir en prevención no ahorra dinero, simplemente retrasa y multiplica el gasto.

Hay un factor adicional que rara vez se cuantifica: el coste de oportunidad. Los 2 millones de euros que Moncloa ha invertido en refuerzo de emergencia podrían haberse destinado a mejorar proactivamente la ciberseguridad: desplegar capacidades de threat hunting, contratar personal especializado, implementar un programa de concienciacion para los empleados, o financiar auditorias de seguridad periodicas. En cambio, se han gastado en apagar un fuego que no debería haberse producido. El dinero se ha gastado, pero la postura de seguridad no ha mejorado respecto a donde debería haber estado: simplemente se ha restaurado a un nivel que ya debería existir.

Ademas, los costes de la brecha no se detienen con la inversion inicial. Durante los próximos 12-24 meses, Moncloa tendrá que destinar recursos adicionales a: monitorizacion reforzada para verificar que el atacante ha sido completamente expulsado, gestión de reclamaciones de los afectados, respuesta a las investigaciones regulatorias (AEPD, UE), defensa ante posibles procedimientos judiciales, y refuerzo continuo de sistemás que fueron comprometidos. El coste total final probablemente superara los 5 millones de euros cuando se contabilice todo.

Que puede hacer un perito informático forense en estos casos

En incidentes de esta magnitud, el perito informático forense cumple funciones críticas tanto para la organización afectada como para los individuos cuyos datos han sido expuestos. He participado en la investigación de brechas que, salvando las distancias, comparten caracteristicas con el caso Moncloa: datos sensibles expuestos, sistemás de protección degradados y periodos prolongados de exposicion sin detección.

Para organizaciones afectadas

• Análisis forense de la brecha: Determinar el vector de entrada, el alcance del compromiso y los datos efectivamente exfiltrados. En un caso típico de brecha como la de Moncloa, esto implica analizar imagenes forenses de los sistemás comprometidos con herramientas como Volatility (memoria RAM), Wireshark (trafico de red), y Autopsy o EnCase (discos). El análisis debe reconstruir la timeline completa del atacante: por donde entro, que hizo, cuanto tiempo estuvo, que datos accedio y como los exfiltro
• Preservación de evidencia: Asegurar la cadena de custodía digital conforme a ISO 27037 para que las pruebas sean admisibles en procedimientos judiciales. Cada imagen forense se documenta con hashes SHA-256, actas de intervención con fecha y hora, y un registro completo de quien ha accedido a la evidencia en cada momento. Sin una cadena de custodía rigurosa, la evidencia pierde valor probatorio ante un juez
• Informe pericial judicial: Documentar tecnicamente el incidente para procedimientos regulatorios (AEPD) o judiciales. El informe no es un documento técnico generico: es un documento pericial que debe cumplir con los requisitos del artículo 478 de la LECrim para ser admisible como prueba. Debe detallar la metodología utilizada, los hallazgos técnicos, la cronologia del ataque, los datos comprometidos y las conclusiones profesionales del perito
• Evaluación de daños y cuantificacion del impacto: Cuantificar el impacto real de la brecha en terminos de datos comprometidos, sistemás afectados, riesgo residual y coste económico. Esta evaluación es fundamental para las reclamaciones de responsabilidad patrimonial y para las negociaciones con aseguradoras
• Asesoria durante la respuesta al incidente: Orientar al equipo de IT durante la contencion y remediacion para que no destruyan evidencia forense en el proceso de “volver a la normalidad”. En mi experiencia, las primeras horas tras la detección son críticas: las decisiones que se toman en ese periodo determinan cuanta evidencia se preserva y cuanta se pierde irremediablemente

Para individuos afectados

En el caso de Moncloa, los cientos de agentes cuyas credenciales fueron filtradas son víctimás directas con derecho a reclamación. Un perito informático forense puede ayudarles de las siguientes formas:

• Verificación de exposicion: Determinar si tus credenciales o datos aparecen en las filtraciones publicadas en la dark web. Esto incluye la busqueda en bases de datos de brechas conocidas, foros de la dark web y mercados de credenciales robadas. El resultado se documenta en un informe pericial que puede usarse como prueba en una reclamación
• Peritaje de daños: Documentar el perjuicio sufrido para reclamaciones por responsabilidad patrimonial de la administración. El informe pericial debe cuantificar el daño: datos personales expuestos, riesgo de suplantacion de identidad, coste de las medidas de protección que el afectado ha tenido que adoptar (cambio de cerraduras si la dirección fue expuesta, monitorizacion de credito, etc.)
• Monitorizacion forense de dispositivos: Analizar si tus dispositivos personales han sido comprometidos como consecuencia de la filtracion. Si un atacante tiene tus credenciales, puede haber intentado acceder a tus cuentas personales, y si tuvo exito, puede haber instalado malware en tus dispositivos
• Asesoramiento técnico personalizado: Recomendar medidas de protección personal inmediatas y a largo plazo. Cada caso es diferente: un ministro necesita medidas de protección distintas a las de un agente de la Guardía Civil, y ambos necesitan medidas distintas a las de un funcionario administrativo

Preguntas frecuentes

Pueden los ciudadaños reclamar por la filtracion de datos de cargos públicos?

Si la brecha afecto también a datos de ciudadaños (por ejemplo, credenciales de agentes que interactuan con bases de datos de la poblacion), los afectados podrían presentar una reclamación ante la AEPD al amparo del RGPD y solicitar una indemnizacion por daños y perjuicios. En cualquier caso, la responsabilidad patrimonial de la Administración Pública (artículo 32 de la Ley 40/2015) permite reclamaciones cuando un funcionamiento anormal del servicio público causa un daño efectivo. Un perito informático puede documentar el daño sufrido y emitir un informe pericial que sustente la reclamación.

Que diferencia hay entre un sistema anti-APT y un antivirus convencional?

Un antivirus convencional detecta malware conocido mediante firmás estaticas. Un sistema anti-APT combina análisis de comportamiento, sandboxing, inteligencia de amenazas en tiempo real y correlación de eventos para detectar ataques dirigidos y sofisticados (como los de actores estatales) que un antivirus no identificaria. Cuando un sistema anti-APT deja de recibir actualizaciones, pierde progresivamente su ventaja sobre un antivirus básico. Despues de 30 días sin actualizaciones, la detección basada en firmás esta completamente obsoleta. Despues de 60 días, incluso la detección comportamental se degrada significativamente. Despues de 100 días, el sistema es, en terminos prácticos, inutil frente a amenazas actuales.

Que debe hacer una empresa si su proveedor de ciberseguridad deja de dar soporte?

Lo prioritario es activar el plan de contingencia:

Un perito informático forense puede verificar que no se hayan producido intrusiones durante la ventana sin cobertura y emitir un informe pericial que acredite el estado de seguridad de los sistemas.

Que es el dwell time y por que importa en este caso?

El dwell time es el tiempo que un atacante permanece dentro de una red comprometida antes de ser detectado. Según el informe M-Trends 2025 de Mandiant, el dwell time medio global es de 10 días cuando la organización tiene sistemás de detección activos. Sin sistemás de detección funcionales, como fue el caso de Moncloa durante 100 días, el dwell time puede extenderse a meses. Esto significa que los atacantes podrían haber estado dentro de los sistemás de Moncloa durante semanas o meses, exfiltrando datos de forma progresiva sin ser detectados. Cuanto mayor es el dwell time, mayor es el daño potencial y menor es la cantidad de evidencia forense disponible para la investigación posterior.

Puede un atacante usar las credenciales filtradas para acceder a otros sistemás gubernamentales?

Si, y este es uno de los riesgos más graves de la brecha. Las credenciales de cientos de agentes de Policia Nacional y Guardía Civil podrían dar acceso a sistemás interconectados: bases de datos policiales (BDSN, ARGOS, SIDENPOL), plataformás de cooperacion europea (SIS II, Europol), sistemás de gestión de investigaciones en curso y registros de ciudadaños. Si los agentes reutilizaron sus contraseñas (algo que ocurre en el 65% de los casos según Verizon DBIR 2025), cada credencial filtrada es una puerta potencial a multiples sistemas. La rotacion inmediata de todas las credenciales es crítica, pero no garantiza que el atacante no haya dejado backdoors o cuentas alternativas durante los 100 días de exposicion.

Que sanciones podría enfrentar España por no transponer NIS2?

El procedimiento de infracción de la UE puede resultar en una sentencia del Tribunal de Justicia de la Union Europea (TJUE) con sanciones económicas. La multa mínima para España sería de aproximadamente 1,4 millones de euros como suma a tanto alzado, más una multa coercitiva diaria que puede superar los 100.000 euros por día hasta que se complete la transposición. Ademas, NIS2 establece sanciones propias para las entidades que no cumplan: hasta 10 millones de euros o el 2% de la facturacion global anual, lo que sea mayor. Si España hubiera transpuesto NIS2 y Moncloa hubiera sido evaluada como entidad esencial, la brecha podría haber generado una sanción directa a la administración responsable.

Que papel juega el CCN-CERT en la protección de Moncloa?

El CCN-CERT (Centro Criptologico Nacional - Computer Emergency Response Team) es el CERT de referencia para las administraciones públicas españolas. Depende del Centro Nacional de Inteligencia (CNI) y proporciona guías de seguridad, alertas de amenazas y apoyo en la respuesta a incidentes. Sin embargo, el CCN-CERT tiene un rol de coordinacion y asesoramiento, no de imposicion. No puede obligar a Moncloa a sustituir un sistema anti-APT obsoleto ni tiene autoridad para auditar directamente los contratos de seguridad de la Presidencia del Gobierno. Esta limitación de autoridad es uno de los factores estructurales que contribuyeron a la brecha.

Se puede saber si los atacantes siguen dentro de los sistemás de Moncloa?

Es la pregunta más crítica y la más difícil de responder. Un análisis forense completo puede identificar indicadores de persistencia: backdoors, cuentas de usuario no autorizadas, tareas programadas sospechosas, certificados digitales comprometidos, modificaciones en las politicas de grupo. Pero los atacantes sofisticados (APTs) utilizan técnicas de persistencia avanzadas que son extremadamente dificiles de detectar: rootkits de firmware, implantes en el BIOS/UEFI, modificaciones del MBR, o persistencia a nivel de hypervisor. La única forma de tener una seguridad razonable de que el atacante ha sido expulsado es realizar un barrido completo de todos los sistemas, incluyendo firmware y hardware, y monitorizar intensivamente durante al menos 90 días después de la remediacion.

Que debería hacer un agente de Policia o Guardía Civil cuyas credenciales han sido filtradas?

Lo inmediato: cambiar la contraseña en todos los servicios donde se haya utilizado la misma o una similar. Activar autenticación multifactor en todos los servicios que lo permitan. Contactar con el departamento de seguridad de su unidad para verificar si su cuenta ha sido utilizada de forma no autorizada. Monitorizar sus cuentas bancarias y solicitar alertas de credito para detectar posibles intentos de suplantacion de identidad. Documentar cualquier actividad sospechosa (emails extraños, llamadas inusuales, intentos de phishing) y reportarla tanto a sus superiores como al CCN-CERT. Un perito informático forense puede analizar sus dispositivos personales para verificar que no han sido comprometidos como consecuencia de la filtracion.

Pueden los medios de comunicación publicar los datos filtrados?

Es una cuestion jurídica compleja. El derecho a la información (artículo 20 de la Constitución) protege la publicacion de información de interes público, y un hackeo a la Presidencia del Gobierno indiscutiblemente lo es. Sin embargo, la publicacion de datos personales concretos (DNI, direcciones, credenciales) de las personas afectadas podría vulnerar su derecho a la protección de datos (RGPD) y, en el caso de agentes de seguridad, poner en riesgo su integridad física. Los medios que han informado sobre la brecha han optado, correctamente, por revelar la existencia y magnitud de la filtracion sin publicar los datos concretos de las personas afectadas. Publicar las credenciales de agentes de las fuerzas de seguridad sería, además de ilegal, potencialmente peligroso.

Este incidente podría haberse evitado con un antivirus normal?

No. Un antivirus convencional no habría evitado esta brecha. Los atacantes que tienen como objetivo la Presidencia del Gobierno de un pais de la OTAN no utilizan malware que un antivirus básico detectaria. Utilizan herramientas personalizadas, técnicas living-off-the-land que emplean herramientas legitimás del sistema operativo, y malware sin archivos (fileless) que se ejecuta solo en memoria. Para detectar estas amenazas se necesita exactamente lo que Moncloa tenia y dejo de funcionar: un sistema anti-APT con análisis de comportamiento, sandboxing e inteligencia de amenazas actualizada. La pregunta no es si un antivirus habría bastado (no habría bastado), sino por que se permitio que el sistema correcto dejara de funcionar durante 100 días.

Que pasa con los datos una vez publicados en la dark web?

Una vez que los datos se publican en la dark web, es practicamente imposible eliminarlos. Los datos se replican, se descargan, se venden, se comparten y se incorporan a bases de datos de inteligencia de amenazas. Los datos personales de los altos cargos de Moncloa estarán circulando en la dark web indefinidamente. Esto significa que el riesgo de explotacion no se limita al periodo inmediato posterior a la filtracion: puede materializarse meses o años después, cuando un atacante diferente encuentre los datos y los utilice para un proposito distinto. He peritado un caso donde los datos de una brecha de 2022 se utilizaron para un ataque de spear phishing en 2025. Los datos no caducan en la dark web.

Podria haber un actor estatal detras de este ataque?

Es una posibilidad que no se puede descartar. Los datos filtrados (altos cargos del Gobierno, JEMAD, Consejo de Seguridad Nacional, agentes de las fuerzas de seguridad) son exactamente el tipo de información que un servicio de inteligencia extranjero buscaria. Los actores estatales tienen la motivación, la capacidad técnica y la paciencia para explotar una ventana de 100 días sin detección. Según ENISA, las campanas APT contra gobiernos europeos aumentaron un 38% en 2025, con actores asociados a Rusia, China y Corea del Norte como principales amenazas. Sin embargo, la atribucion de ciberataques a actores estatales es extremadamente difícil y requiere un análisis forense completo de las herramientas, técnicas y procedimientos utilizados, que solo las agencias de inteligencia con acceso a los sistemás comprometidos pueden realizar.

Lo que este incidente significa para el ciudadaño medio

Una pregunta que me hacen a menudo cuando comento incidentes de ciberseguridad gubernamental es: “esto me afecta a mi?”. La respuesta es si, y de formás que quizas no son evidentes.

Tus datos en maños del Estado también estan en riesgo

Si los sistemás de la Presidencia del Gobierno no estuvieron adecuadamente protegidos durante 100 días, es legítimo preguntarse que nivel de protección tienen tus datos en otras administraciones públicas: tu historial medico en el sistema de salud, tus datos fiscales en la AEAT, tus antecedentes en los sistemás policiales, tu información catastral, tus expedientes educativos.

No estoy diciendo que todos estos sistemás esten comprometidos. Pero si que el caso Moncloa demuestra que las administraciones públicas españolas no son inmunes a brechas de seguridad, y que la ausencia de un marco legal actualizado (NIS2 sin transponer) significa que no hay mecanismos de supervision efectivos para garantizar que tus datos estan protegidos adecuadamente.

Como puedes protegerte

Aunque no puedes controlar la seguridad de los sistemás gubernamentales, si puedes tomar medidas para reducir tu exposicion:

• Minimiza los datos que proporcionas: No des más información de la estrictamente necesaria en formularios gubernamentales. Si un campo es opcional, dejalo vacio
• Activa la autenticación reforzada: Utiliza Cl@ve PIN o Cl@ve Permanente con verificación en dos pasos para tus trámites con la administración. Si tus credenciales se filtran, el segundo factor bloquea el acceso
• Monitoriza tu identidad digital: Configura alertas de Google para tu nombre completo y DNI. Si aparecen en una filtracion, lo sabras rápidamente. Servicios como haveibeenpwned.com te avisan si tu email aparece en brechas conocidas
• Ejerce tus derechos: El RGPD te da derecho a saber que datos tiene cada administración sobre ti (derecho de acceso, artículo 15), a solicitar su correccion (artículo 16) y a reclamar ante la AEPD si consideras que no se estan protegiendo adecuadamente (artículo 77)

Tu derecho a una administración segura

Como ciudadaño, tienes derecho a que la administración pública gestione tus datos con las medidas de seguridad adecuadas. El ENS (Esquema Nacional de Seguridad) lo exige. El RGPD lo exige. La futura transposición de NIS2 lo exigira de forma aun más estricta. Cuando una administración falla en esta obligación y tus datos se ven comprometidos, tienes derecho a reclamar una indemnizacion por responsabilidad patrimonial (artículo 32 de la Ley 40/2015).

Un perito informático forense puede ayudarte a documentar el daño sufrido y a elaborar el informe técnico necesario para sustentar la reclamación. No es un proceso sencillo, pero es un derecho que cada vez más ciudadaños estan ejerciendo.

La brecha de confianza digital

Mas alla de los riesgos técnicos y legales, el hackeo a Moncloa tiene un impacto en la confianza de los ciudadaños en la administración digital. España ha apostado fuertemente por la digitalizacion de los servicios públicos: la Cl@ve digital, la Sede Electrónica, el certificado digital, la carpeta ciudadana. Todos estos servicios dependen de que los ciudadaños confien en que sus datos estan seguros en maños de la administración.

Cuando el propio Gobierno demuestra que no es capaz de proteger los datos de su presidente, sus ministros y sus agentes de seguridad, la pregunta inevitable es: “si no pueden proteger los datos del presidente, como van a proteger los mios?”. Esta pregunta no tiene una respuesta fácil, y el daño a la confianza digital puede ser duradero.

En mis peritajes para empresas, he observado que las brechas de datos tienen un impacto en la adopcion de servicios digitales que va más alla de la organización afectada. Cuando una empresa sufre una brecha conocida, sus competidores también ven una caida temporal en la adopcion de sus servicios digitales, porque los usuarios generalizan la desconfianza al sector completo. Lo mismo puede ocurrir con la administración pública: una brecha en Moncloa puede reducir la adopcion de servicios públicos digitales en general, revirtiendo años de esfuerzo en digitalizacion.

La única forma de mitigar este daño es la transparencia: explicar que paso, por que paso, que se ha hecho para que no vuelva a ocurrir y que medidas de protección adicionales se han implementado. El silencio institucional no protege la confianza: la destruye.

Conclusión: un incidente que no debería haber ocurrido

Despues de analizar en profundidad todos los aspectos de este incidente, mi conclusión como perito informático forense es clara: el hackeo a Moncloa era evitable. No estamos ante un ataque de una sofisticacion extraordinaria que supero defensas razonables. Estamos ante el resultado directo de un fallo en la gestión de la cadena de suministro tecnologica que dejo la Presidencia del Gobierno sin protección avanzada durante 100 días.

Los hechos son inequivocos:

1. El fabricante del sistema anti-APT dejo de actualizar en noviembre de 2025
2. Nadie activo un plan de contingencia durante 100 días
3. El contrato de sustitucion no se formalizo hasta mediados de febrero de 2026
4. Durante ese periodo, los atacantes accedieron a los datos más sensibles del Estado español
5. La filtracion afecto al presidente, ministros, el JEMAD, el fiscal general y cientos de agentes de las fuerzas de seguridad

Cada uno de estos puntos es un fallo individual. Juntos, representan un fracaso sistemico de la gobernanza de la ciberseguridad en la máxima institucion del Estado español. Y lo que es peor: este fracaso ocurre en el mismo periodo en el que España debería estar transponiendo la Directiva NIS2, disenada precisamente para prevenir este tipo de incidentes.

La pregunta que debemos hacernos no es solo “como paso esto”, sino “cuantas instituciones más estan en la misma situación ahora mismo”. Porque si la Presidencia del Gobierno, con sus recursos y su perfil de amenaza, no fue capaz de mantener su sistema de seguridad actualizado, es razonable suponer que ministerios, comunidades autonomás y ayuntamientos con menos recursos estan en una situación igual o peor.

Como perito, mi recomendación final es la misma que doy a todas las organizaciones que me consultan tras un incidente: no esperes a que te pase a ti. Revisa tus sistemás de seguridad hoy, verifica que estan actualizados, confirma que tus contratos de soporte estan vigentes y asegurate de que tienes un plan B para cuando un proveedor falle. Porque los proveedores fallan. Siempre.

Si al leer este artículo te has dado cuenta de que tu organización tiene un sistema de seguridad sin actualizaciones, un contrato de soporte a punto de vencer o un plan de contingencia que nunca se ha probado, actua hoy. No manana. No la próxima semana. Hoy. El caso Moncloa demuestra que 100 días es más que suficiente para que un atacante convierta una brecha de seguridad en una crisis nacional. Y tu organización no tiene los recursos de la Presidencia del Gobierno para invertir 2 millones de euros en recuperarse después del desastre.

Si necesitas ayuda para evaluar el estado de seguridad de tu organización, para verificar que tus sistemás de protección estan correctamente configurados y actualizados, o para preparar un plan de respuesta a incidentes que puedas activar cuando lo necesites, estoy disponible para una consulta inicial gratuita. Mejor prevenir que peritar.

El hackeo a Moncloa pasara a la historia de la ciberseguridad española como un punto de inflexion. La pregunta es si será el punto de inflexion que provoco un cambio real en la gobernanza de la ciberseguridad del Estado, o el punto de inflexion que demostro que ni siquiera una brecha de seguridad nacional es suficiente para cambiar las cosas en España. Como profesional de la ciberseguridad, espero sinceramente que sea lo primero. Como observador realista de la politica española, me temo que pueda ser lo segundo.

Preguntas relacionadas

Si te interesa este tema, estos artículos de nuestro blog profundizan en aspectos directamente relacionados:

• Ley de Ciberseguridad NIS2 en España 2026: obligaciones para empresas y administraciones - Todo lo que NIS2 exige y que Moncloa no cumplio
• Brecha de datos en la Policia Nacional: información antiterrorista expuesta - Otro incidente grave en instituciones españolas en 2026
• Que hace un perito informático forense: servicios de análisis forense digital - Como un perito puede ayudarte tras una brecha de seguridad
• Balance de ciberseguridad INCIBE 2025: 122.223 incidentes en España - El contexto general de la ciberseguridad en España
• Ransomware en PYMEs: el 57% que paga recupera sus datos - Cuando la falta de prevención lleva al peor escenario
• Fraude BEC contra PYMEs: la Guardía Civil alerta del aumento de estafas por email - Otro ejemplo de como las credenciales filtradas se explotan

Fuentes consultadas:

• El Español - Hackers exponen datos de Pedro Sanchez, ministros y altos cargos de seguridad nacional (11 marzo 2026)
• The Objective - Brecha de ciberseguridad en Moncloa: filtracion de datos de altos cargos (26 febrero 2026)
• Voz Populi - Ciberataque a la Presidencia del Gobierno: credenciales de agentes comprometidas (27 febrero 2026)
• Público - Datos de altos cargos del Gobierno expuestos por hackers: JEMAD y Consejo de Seguridad Nacional (28 febrero 2026)
• Esdiario - Filtracion de credenciales de agentes de seguridad del Estado (febrero 2026)
• Directiva NIS2 (UE) 2022/2555 - Texto completo EUR-Lex
• Esquema Nacional de Seguridad - Real Decreto 311/2022 (BOE)
• RGPD - Reglamento (UE) 2016/679
• CCN-CERT - Centro Criptologico Nacional: guías y alertas
• Mandiant M-Trends 2025 - Dwell time, metricas de detección y tendencias APT
• IBM Cost of a Data Breach Report 2025 - Coste medio de brechas por sector
• INCIBE - Balance de ciberseguridad 2025: 122.223 incidentes gestionados
• Ley 40/2015 de Régimen Jurídico del Sector Público (BOE)
• ENISA Threat Landscape 2025 - Campanas APT contra gobiernos europeos
• Verizon Data Breach Investigations Report (DBIR) 2025 - Reutilizacion de credenciales
• CrowdStrike Global Threat Report 2025 - Malware nuevo no catalogado
• AV-TEST Institute - Estadisticas de nuevas muestras de malware diarias
• ANSSI (Francia) - Modelo de ciberseguridad gubernamental
• BSI (Alemania) - IT-Grundschutz y certificación de productos
• NCSC (Reino Unido) - Active Cyber Defence y lecciones aprendidas

Nota del autor: Este artículo representa mi análisis profesional independiente del incidente de Moncloa, basado en la información publicada por fuentes periodisticas y en mi experiencia como perito informático forense. No he tenido acceso a los sistemás comprometidos ni a información clasificada. Las hipotesis técnicas que presento estan basadas en los patrones documentados de ataques similares y en mi experiencia peritando brechas de seguridad en organizaciones públicas y privadas. Las opiniones expresadas son estrictamente profesionales y no tienen motivación politica.

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 con 5 certificaciones AWS, aplica metodología ISO 27037 en todas sus investigaciones. Si tu organización ha sufrido o sospecha una brecha de seguridad, puedes solicitar una consulta inicial gratuita.

Última actualizacion: 16 Marzo 2026