Hackeo Ministerio Ciencia 2026: análisis IDOR gobierno España

122.223 incidentes de ciberseguridad gestionó INCIBE en 2025, un 26% más que el año anterior. Y febrero de 2026 ya está dejando claro que la tendencia no frena: un hacker conocido como “GordonFreeman” forzó al Ministerio de Ciencia, Innovación y Universidades a cerrar su sede electrónica tras afirmar que había exfiltrado DNIs, pasaportes, IBANs y expedientes académicos de miles de estudiantes e investigadores mediante una vulnerabilidad IDOR.

Lo más alarmante no es el ataque en sí. Es que reproduce exactamente el mismo vector que el ciberataque a Hacienda denunciado días antes: Insecure Direct Object Reference con enumeración secuencial de identificadores. Dos ministerios, misma vulnerabilidad, misma semana. Como perito informático forense, este patrón revela un problema sistémico que va mucho más allá de un incidente aislado.

Resumen ejecutivo

Qué: Hacker “GordonFreeman” afirma acceso completo a bases de datos del Ministerio de Ciencia mediante IDOR
Datos expuestos: DNI, pasaportes escaneados, títulos universitarios, IBANs, expedientes académicos
Respuesta oficial: Cierre parcial sede electrónica el 3 de febrero; investigación CCN-CERT en curso
Patrón: Segundo caso IDOR en administración pública española en la misma semana (tras Hacienda)
Marco legal: Posible incumplimiento ENS (RD 311/2022) y RGPD Art. 32

Consulta gratuita ciberseguridad sector público

El hackeo al Ministerio de Ciencia: los hechos

Cronología del incidente

El 2 de febrero de 2026, el actor de amenazas “GordonFreeman” publicó en foros clandestinos un anuncio afirmando haber comprometido los sistemas del Ministerio de Ciencia, Innovación y Universidades. Según reportaron ADSLZone, The Objective y Escudo Digital, el atacante publicó capturas de pantalla con datos personales y financieros de estudiantes como muestra.

Resumen del incidente

Aspecto	Detalle
Fecha alerta	2 de febrero 2026
Actor	”GordonFreeman” (identidad desconocida)
Vector de ataque	IDOR + credenciales filtradas
Datos comprometidos	DNI/NIE, pasaportes escaneados, IBANs, títulos, expedientes académicos
Afectados potenciales	Estudiantes becarios, investigadores, solicitantes ayudas I+D+i
Respuesta oficial	Cierre parcial sede electrónica + investigación CCN-CERT
Coordinación	CCN-CERT + AEAD + INCIBE

A diferencia de Hacienda, que emitió un desmentido rápido, el Ministerio de Ciencia no ha negado categóricamente la brecha. El cierre de la sede electrónica sugiere que la amenaza fue tomada en serio desde el primer momento.

Patrón IDOR en gobierno español: ¿por qué se repite?

Segundo caso en una semana

Este incidente no es un caso aislado. Se produce en la misma semana que el presunto ciberataque a Hacienda, también mediante IDOR. Según Infobae, el actor “HaciendaSec” afirmó haber accedido a datos de 47,3 millones de contribuyentes con la misma técnica.

Incidente	Fecha	Vector	Datos	Estado
Hacienda (AEAT)	2 Feb 2026	IDOR + credenciales	47,3M contribuyentes	Desmentido oficial, investigación en curso
Ministerio Ciencia	2-3 Feb 2026	IDOR + credenciales	Estudiantes, investigadores, proyectos I+D	Sede cerrada, investigación CCN-CERT

Analicé el caso de Hacienda en detalle en mi artículo sobre el ciberataque IDOR a la AEAT. Las similitudes son demasiado evidentes para ser coincidencia.

Cuatro causas sistémicas

Como perito que ha auditado sistemas de administraciones públicas, identifico cuatro factores que explican por qué IDOR se repite una y otra vez en el sector público español:

1. Sistemas legacy de 10-15 años sin revisión de seguridad

Muchos portales de gestión de becas, ayudas y tramitación electrónica fueron desarrollados antes de la entrada en vigor del RGPD (2018) y del ENS actualizado (RD 311/2022). Tecnologías obsoletas (PHP 5.x, Java 6-7), frameworks sin soporte y arquitecturas monolíticas sin separación de capas son la norma, no la excepción.

2. Presupuesto IT insuficiente para ciberseguridad

Mientras que el sector privado tecnológico destina entre un 5-8% de su presupuesto IT a seguridad, las administraciones públicas españolas se mueven en el rango del 1-3%*. La inversión se prioriza en funcionalidades visibles (tramitación electrónica, portales ciudadanos) sobre controles de acceso y auditorías de seguridad.

Nota sobre datos presupuestarios

*Las cifras de inversión en ciberseguridad del sector público provienen de estimaciones sectoriales y auditorías publicadas por CCN-CERT. Los porcentajes exactos varían significativamente entre administraciones estatales, autonómicas y locales.

3. Desarrollo externalizado sin cláusulas de auditoría

Un porcentaje elevado del desarrollo de software público se externaliza a empresas integradoras cuyos contratos no incluyen cláusulas de auditoría de seguridad obligatoria ni testing OWASP. El resultado: sistemas funcionalmente completos pero inseguros desde su concepción.

4. Cultura “funcionalidad primero, seguridad después”

La presión por lanzar portales antes de plazos políticos y convocatorias anuales relega las auditorías de seguridad a un papel secundario. La mentalidad “si funciona, no lo toques” perpetúa vulnerabilidades IDOR triviales que existen durante años sin ser detectadas.

Broken Access Control: la vulnerabilidad número 1 en el mundo

IDOR no es una vulnerabilidad oscura. Forma parte de la categoría A01:2021 - Broken Access Control del OWASP Top 10, la clasificación de referencia mundial de vulnerabilidades web. Según OWASP, el 94% de las aplicaciones testadas presentan alguna forma de control de acceso deficiente, con más de 318.000 incidencias mapeadas en 34 CWEs distintos. Es la categoría con mayor número de ocurrencias de todo el ranking.

Que administraciones públicas con datos de millones de ciudadanos sean vulnerables a la amenaza número 1 del ranking OWASP no es solo un fallo técnico: es una negligencia estructural.

Datos expuestos: impacto en estudiantes y solicitantes

Qué datos estaban en juego

Según la información publicada por TechNadu, Escudo Digital y las capturas mostradas por el atacante, los datos presuntamente exfiltrados incluyen:

Tipo de dato	Ejemplos	Nivel de riesgo
Documentos de identidad	DNI/NIE escaneados, pasaportes	CRITICO
Datos bancarios	IBAN, recibos de pago de becas	CRITICO
Datos académicos	Títulos, certificados, justificantes matrícula, planes de estudio	ALTO
Datos personales	Emails, direcciones, teléfonos	ALTO
Datos de investigación	Proyectos I+D, memorias técnicas, CVs académicos	MEDIO-ALTO

Riesgos derivados para las víctimas

La combinación de DNI escaneado + IBAN + datos personales completos es una de las más peligrosas que existen en el ámbito del fraude digital:

Suplantación de identidad: Solicitar créditos, contratos de telefonía o cuentas bancarias con documentación real de la víctima
Domiciliaciones fraudulentas: Con un IBAN real, un atacante puede generar adeudos directos SEPA
Phishing ultra dirigido: Emails personalizados con datos reales del becario (nombre, beca concedida, universidad, director de tesis) pidiendo “actualizar datos bancarios”
Robo de propiedad intelectual: Proyectos de investigación innovadores copiados o comercializados antes de su publicación
Espionaje científico: Competidores internacionales o actores estatales accediendo a líneas de investigación estratégicas (defensa, biomedicina, energía)

Si eres estudiante o investigador afectado

Si solicitaste becas, ayudas I+D o participaste en convocatorias del Ministerio de Ciencia entre 2020-2026, asume riesgo potencial de exposición:

Cambia contraseñas de portales del Ministerio y universidades vinculadas
Activa MFA en todos los servicios académicos
Monitoriza tu IBAN semanalmente si lo facilitaste en solicitudes de beca
Desconfía de cualquier email pidiendo datos bancarios, aunque parezca legítimo
Solicita información al Ministerio ejerciendo tu derecho de acceso (Art. 15 RGPD)

Análisis técnico: cómo funciona IDOR con enumeración DNI

El mecanismo del ataque

Una vulnerabilidad IDOR ocurre cuando una aplicación web expone referencias directas a objetos internos (registros de base de datos, archivos, IDs) sin validar que el usuario autenticado tiene permiso para acceder a ese recurso concreto. En el contexto de administraciones españolas, el DNI es el identificador natural:

# Petición legítima (el becario accede a SU expediente)
GET /api/expediente?dni=12345678A   → Datos del becario autenticado ✅

# Petición IDOR (el becario accede a OTRO expediente)
GET /api/expediente?dni=12345679B   → Datos de otro becario ❌ (debería bloquearse)
GET /api/expediente?dni=12345680C   → Enumeración automatizada ❌
GET /api/expediente?dni=12345681D   → Extracción masiva ❌

Por qué el DNI facilita la enumeración

El DNI español tiene un formato predecible: 8 dígitos + 1 letra de control calculable. Esto significa que un atacante no necesita conocer DNIs reales: puede generar todos los DNIs válidos posibles (00000001A a 99999999Z) y filtrar los que devuelven datos. Con un script automatizado y sin rate limiting, se pueden probar miles de combinaciones por minuto.

Código vulnerable vs. código seguro

// ❌ VULNERABLE a IDOR - Sin validación de autorización
app.get('/api/expediente', isAuthenticated, (req, res) => {
  const dni = req.query.dni;
  const data = database.getExpediente(dni);
  res.json(data); // No valida si el usuario puede ver este DNI
});

// ✅ SEGURO - Con validación de autorización
app.get('/api/expediente', isAuthenticated, (req, res) => {
  const dni = req.query.dni;
  const userDNI = req.session.userDNI;

  if (dni !== userDNI && !req.session.isAdmin) {
    auditLog.warn(`IDOR attempt: ${userDNI} tried to access ${dni}`);
    return res.status(403).json({ error: 'Acceso no autorizado' });
  }

  const data = database.getExpediente(dni);
  res.json(data);
});

Medidas de prevención según OWASP

La OWASP Cheat Sheet sobre IDOR recomienda:

Validación de autorización en cada request: Verificar que el usuario autenticado tiene permiso para el recurso específico
Referencias indirectas: Usar UUIDs aleatorios en lugar de identificadores predecibles (DNI)
Control de acceso por sesión: Mapear objetos accesibles en la sesión del usuario
Rate limiting: Limitar peticiones por IP/sesión para dificultar enumeración automatizada
Auditoría de accesos: Registrar y alertar sobre patrones de acceso anómalos

Respuesta gubernamental: ¿qué debe hacer el Ministerio ahora?

Lo que ha hecho bien

El cierre preventivo de la sede electrónica fue una decisión acertada. Contrasta con la respuesta inicial de Hacienda, que se limitó a desmentir el ataque. Cerrar el sistema potencialmente comprometido es la primera medida del protocolo de respuesta a incidentes.

Lo que falta por hacer

Obligaciones legales inmediatas:

Obligación	Norma	Plazo	Estado (9 Feb)
Notificación brecha a AEPD	RGPD Art. 33	72 horas desde detección	Sin información pública
Notificación a interesados	RGPD Art. 34	”Sin dilación indebida”	No realizada
Comunicación al CCN-CERT	ENS Art. 36 (RD 311/2022)	Inmediata	En curso
Informe de impacto	ENS Anexo III	30 días	Pendiente

Acciones técnicas prioritarias:

Análisis forense completo: Determinar alcance real de la exfiltración (qué datos, cuántos registros, qué periodo)
Preservación de evidencia: Copia forense de logs, bases de datos y configuraciones antes de cualquier remediación
Parcheo de la vulnerabilidad IDOR: Implementar validación de autorización en todos los endpoints afectados
Rotación de credenciales: Si se usaron credenciales filtradas, resetear todas las credenciales de acceso administrativo
Notificación a afectados: Comunicar a estudiantes e investigadores qué datos pueden haber sido expuestos

Esquema Nacional de Seguridad (RD 311/2022)

El ENS actualizado en 2022 es de obligado cumplimiento para todas las administraciones públicas españolas. Portales con datos personales (DNI, IBAN, expedientes académicos) requieren como mínimo nivel MEDIO, lo que implica 114 controles de seguridad y auditorías externas cada 2 años. Los controles op.acc.5 (autenticación) y op.acc.6 (autorización) están diseñados específicamente para prevenir vulnerabilidades tipo IDOR.

Lecciones para sector público: hoja de ruta ciberseguridad

Lo que revela el patrón Hacienda + Ministerio Ciencia

Cuando la misma vulnerabilidad se explota con éxito en dos ministerios distintos en la misma semana, el diagnóstico es claro: no es un problema de un sistema, es un problema de todo el ecosistema. Las administraciones públicas españolas necesitan una transformación estructural en ciberseguridad.

Hoja de ruta en 5 fases

Fase 1 - Inventario urgente (semanas 1-2):

Catalogar todos los sistemas con datos personales en cada administración (estatal, autonómica, local)
Identificar endpoints API que aceptan identificadores de usuario como parámetro
Priorizar por volumen de datos y sensibilidad

Fase 2 - Pentesting IDOR focalizado (semanas 3-6):

Auditoría express de control de acceso en sistemas prioritarios
Testing de enumeración secuencial en todos los endpoints que usen DNI/NIE como parámetro
Verificación de rate limiting y detección de anomalías

Fase 3 - Remediación (semanas 7-10):

Implementar validación de autorización en cada endpoint identificado
Sustituir identificadores predecibles (DNI) por UUIDs en APIs
Configurar WAF con reglas anti-enumeración

Fase 4 - Monitorización continua (semanas 11-12):

Desplegar SIEM con alertas 24/7 (no solo horario laboral)
Configurar detección de patrones de enumeración secuencial
Establecer guardia técnica rotativa

Fase 5 - Cultura y formación (continua):

Formación obligatoria OWASP Top 10 para todos los desarrolladores (internos y externos)
Cláusulas de auditoría de seguridad en contratos de desarrollo externalizado
Programa de revelación responsable de vulnerabilidades (bug bounty público)

Coste de actuar vs. coste de no actuar

Concepto	Inversión preventiva	Coste post-brecha
Auditoría ENS completa	15.000 - 50.000 EUR	N/A
Pentesting IDOR focalizado	5.000 - 15.000 EUR	N/A
Sanción AEPD por brecha	N/A	100.000 - 10.000.000 EUR
Responsabilidad civil	N/A	Ilimitada
Daño reputacional	N/A	Incalculable

La ecuación es clara: invertir 20.000-65.000 EUR en prevención frente a arriesgar millones en sanciones, indemnizaciones y pérdida de confianza ciudadana. Detallo las opciones de precios de peritaje y auditoría en mi página de servicios.

Análisis forense especializado en sector público

Particularidades del forense en administraciones públicas

Cuando realizo análisis forense digital post-brecha en administraciones públicas, hay particularidades que lo diferencian del sector privado:

Cadena de custodia reforzada:

Documentación exhaustiva de cada acceso a evidencia digital con registros firmados
Mínimo dos funcionarios presentes durante la adquisición forense
Precintado físico de equipos con firma de la Secretaría General (no solo del perito)
El informe pericial puede derivar en responsabilidad penal de funcionarios (Art. 197.2 CP), no solo civil

Coordinación multi-agencia:

CCN-CERT como coordinador técnico en brechas de administraciones
INCIBE para asistencia técnica y recursos forenses especializados
Policía Nacional (UIT) si se investiga penalmente al atacante
AEPD para el cumplimiento normativo RGPD

Qué busco en un análisis forense post-IDOR:

# Indicador forense clave: patrón de enumeración
[2026-02-01 23:15:42] GET /api/expediente?dni=12345678A - User: atacante - IP: 203.0.113.45
[2026-02-01 23:15:43] GET /api/expediente?dni=12345679B - User: atacante - IP: 203.0.113.45
[2026-02-01 23:15:44] GET /api/expediente?dni=12345680C - User: atacante - IP: 203.0.113.45
                                                    ↑
               Accesos secuenciales a DNIs ajenos = patrón de enumeración IDOR

Elementos que documento en el informe pericial:

Línea temporal: Cuándo comenzaron las peticiones anómalas y cuándo cesaron
Volumen de exfiltración: Número de registros accedidos sin autorización
Perfil del atacante: IPs, sesiones, credenciales utilizadas, herramientas detectadas
Prueba de concepto: Demostración técnica reproducible de la vulnerabilidad
Impacto: Clasificación de datos expuestos y número de personas afectadas

¿Tu organismo público necesita auditoría de seguridad?

Auditorías ENS, pentesting IDOR, análisis forense post-brecha. Experiencia en administraciones públicas y cumplimiento normativo. Primera consulta gratuita.

Más información

¿Necesitas valorar los costes?

Si representas a una administración pública y necesitas una estimación orientativa antes de solicitar presupuesto formal, puedes usar la calculadora de precio de peritaje o consultar la checklist de 20 puntos para contratar un perito informático.

Preguntas frecuentes

¿Qué es exactamente la vulnerabilidad IDOR que se ha explotado?

IDOR (Insecure Direct Object Reference) es una vulnerabilidad de control de acceso donde una aplicación web permite acceder a datos de otros usuarios simplemente modificando un parámetro en la URL (por ejemplo, un DNI). Está catalogada dentro de A01:2021 - Broken Access Control del OWASP Top 10, la amenaza número 1 en seguridad de aplicaciones web. En el caso del Ministerio de Ciencia, el atacante habría cambiado secuencialmente el identificador en las peticiones para acceder a expedientes de otros estudiantes sin autorización.

¿Cómo sé si mis datos del Ministerio de Ciencia están afectados?

A fecha de 9 de febrero de 2026, el Ministerio no ha publicado un comunicado detallando el alcance exacto de la brecha ni una lista de sistemas afectados. Si solicitaste becas predoctorales, postdoctorales, ayudas I+D+i o participaste en convocatorias del Ministerio entre 2020-2026, deberías asumir un riesgo potencial. Puedes ejercer tu derecho de acceso según el Art. 15 del RGPD contactando con la Subdirección General de Tecnologías de la Información del Ministerio y exigir respuesta escrita sobre si tus datos están en los sistemas afectados.

¿Puede el Ministerio de Ciencia ser sancionado por esta brecha?

Si la brecha se confirma, el Ministerio estaría sujeto a sanciones de la AEPD conforme al RGPD y la LOPDGDD. Precedentes como las sanciones al Ayuntamiento de Madrid (150.000 EUR en 2022) o a la Junta de Andalucía (100.000 EUR en 2023) demuestran que las administraciones públicas no están exentas*. Además, funcionarios responsables de IT podrían enfrentar responsabilidad penal si se demuestra negligencia en la implementación de medidas ENS obligatorias (Art. 197.2-3 del Código Penal).

*Nota: las cifras de sanciones citadas provienen de resoluciones publicadas por la AEPD. Los importes exactos pueden variar según la fuente consultada.

¿Es cierto que se repite el mismo patrón que en Hacienda?

Sí, el patrón es prácticamente idéntico. En ambos casos se reporta explotación de vulnerabilidad IDOR combinada con credenciales filtradas para enumerar secuencialmente identificadores (DNI/NIE) y extraer datos de ciudadanos. Analicé el caso de Hacienda en este artículo. Las similitudes (mismo vector, misma semana, mismo tipo de víctima institucional) sugieren o bien un atacante explorando sistemáticamente administraciones públicas o bien múltiples actores explotando una vulnerabilidad generalizada en el sector público español.

¿Qué debe hacer un investigador si cree que su proyecto ha sido robado?

Lo prioritario es establecer prioridad temporal sobre tu investigación: publica resultados preliminares en repositorios de preprints (arXiv, bioRxiv, SSRN) para crear una fecha pública verificable. Si tu proyecto tiene potencial comercial, valora registrar propiedad industrial (patentes). Documenta todo tu timeline de investigación (cuadernos de laboratorio con fecha, emails, borradores). Si detectas plagio de tu proyecto posterior a la brecha, un informe pericial puede demostrar la relación temporal entre la brecha del Ministerio y la aparición del contenido plagiado.

¿El Esquema Nacional de Seguridad obligaba al Ministerio a prevenir esto?

Sí. El ENS (RD 311/2022) es de obligado cumplimiento para todas las administraciones públicas. Los portales del Ministerio que almacenan datos personales (DNI, IBAN, expedientes académicos) requieren como mínimo nivel MEDIO del ENS, con 114 controles de seguridad. Los controles op.acc.5 (autenticación) y op.acc.6 (autorización) están diseñados específicamente para prevenir IDOR. Además, el ENS exige auditorías externas cada 2 años (Art. 34). Si el Ministerio no cumplía estos requisitos, habría una infracción normativa directa.

¿Cómo puedo reportar una vulnerabilidad en un sistema público sin problemas legales?

El procedimiento recomendado es la revelación responsable: documenta la vulnerabilidad con una prueba de concepto mínima (sin exfiltrar datos reales), contacta con el CCN-CERT enviando la descripción técnica a su canal de vulnerabilidades, y espera un mínimo de 90 días antes de cualquier divulgación pública. La legislación española no protege explícitamente a investigadores de seguridad que actúen de buena fe, por lo que es fundamental no acceder a datos reales de ciudadanos ni exfiltrar información durante la prueba.

¿Qué diferencia hay entre el análisis forense en sector público y privado?

La principal diferencia es la cadena de custodia reforzada y la coordinación multi-agencia. En el sector público, la adquisición forense requiere presencia de funcionarios como testigos, precintado con firma de la Secretaría General, y el informe pericial puede derivar en responsabilidad penal de funcionarios (no solo civil como en el privado). Además, la investigación se coordina con CCN-CERT, INCIBE y potencialmente Policía Nacional, lo que alarga los plazos (3-6 meses vs. 2-4 semanas en el sector privado). Ofrezco análisis forense especializado en sector público con experiencia en estas particularidades.

Fuentes y referencias

Sobre el autor: Jonathan Izquierdo es perito informático forense especializado en análisis de brechas de seguridad, auditorías de vulnerabilidades y peritajes judiciales sobre protección de datos. Ex-CTO y 5x AWS Certified.

Última actualización: 9 de febrero de 2026

Enlaces relacionados: