Hacienda investiga un posible ciberataque IDOR que habría expuesto datos de 47,3 millones de españoles

El 2 de febrero de 2026, la Agencia Estatal de Administración Tributaria (AEAT) anunció que está investigando una alerta de seguridad reportada por el grupo de ciberseguridad Hackmanac. Según esta alerta, un actor malicioso identificado como “HaciendaSec” habría accedido a servidores centrales de Hacienda explotando una vulnerabilidad IDOR (Insecure Direct Object Reference) y credenciales filtradas, comprometiendo información personal, bancaria y fiscal de aproximadamente 47,3 millones de ciudadanos españoles.

Al día siguiente, el 3 de febrero, Hacienda descartó oficialmente el ataque, afirmando que “no se ha producido ninguna brecha de seguridad”. Sin embargo, la investigación continúa.

Como perito informático forense, analizo en este artículo la plausibilidad técnica del ataque, por qué es tan difícil verificar si hubo filtración real, y qué implicaciones tiene para la ciudadanía.

¿Qué pasó? Cronología de la alerta y el desmentido

2 de febrero: La alerta de Hackmanac

El grupo de ciberseguridad Hackmanac reportó que un actor conocido como “HaciendaSec” afirmaba haber comprometido los sistemas de la Agencia Tributaria. Según el reporte:

3 de febrero: El desmentido oficial

Hacienda emitió un comunicado descartando el ciberataque, tal como reportó Escudo Digital:

“Tras la investigación preliminar, no se ha detectado evidencia de acceso no autorizado a los sistemas centrales ni extracción masiva de datos.”

Sin embargo, el comunicado también confirma que la investigación continúa con la participación del CCN-CERT (Centro Criptológico Nacional).

¿Qué es IDOR y cómo funciona?

IDOR (Insecure Direct Object Reference) es una vulnerabilidad de control de acceso catalogada como A01:2021 – Broken Access Control en el OWASP Top 10 2021.

Concepto técnico

Una vulnerabilidad IDOR ocurre cuando una aplicación web expone referencias directas a objetos internos (archivos, registros de base de datos, claves) sin validar adecuadamente si el usuario tiene permiso para acceder a ellos.

Ejemplo simplificado:

Sistema vulnerable:

https://hacienda.gov/api/declaracion?id=12345678A
                                          ↑
                                 Tu DNI en la URL

Si el sistema no valida que el usuario autenticado es realmente el titular del DNI 12345678A, un atacante puede cambiar manualmente el parámetro:

https://hacienda.gov/api/declaracion?id=12345679B  ← Otro DNI
https://hacienda.gov/api/declaracion?id=12345680C  ← Enumeración
https://hacienda.gov/api/declaracion?id=12345681D  ← Automatizada

Ataque de enumeración secuencial

Según la alerta de Hackmanac, el actor habría utilizado enumeración secuencial de DNI/NIE. Esto significa:

Por qué IDOR es tan peligroso

Perspectiva del perito forense: Cómo se investiga esto

Como perito informático, ante una alegación de este tipo, mi metodología forense incluiría:

1. Análisis de logs del servidor

Qué buscaría:

• Patrones de peticiones secuenciales desde la misma IP o sesión
• Picos anómalos de tráfico en endpoints sensibles
• Peticiones de recursos que no corresponden al usuario autenticado
• Intentos de acceso a datos de múltiples DNI/NIE en corto periodo

Indicador forense clave:

[2026-02-01 23:15:42] GET /api/declaracion?id=12345678A - User: juan.perez - IP: 203.0.113.45
[2026-02-01 23:15:43] GET /api/declaracion?id=12345679B - User: juan.perez - IP: 203.0.113.45
[2026-02-01 23:15:44] GET /api/declaracion?id=12345680C - User: juan.perez - IP: 203.0.113.45
                                                    ↑
                    Usuario accediendo a DNIs que no son el suyo

2. Revisión de controles de acceso

Realizaría una auditoría técnica del código:

// ❌ Código VULNERABLE a IDOR
app.get('/api/declaracion', isAuthenticated, (req, res) => {
  const dni = req.query.id;
  const data = database.getDeclaracion(dni);
  res.json(data); // ¡No valida si el usuario puede ver este DNI!
});

// ✅ Código SEGURO con validación
app.get('/api/declaracion', isAuthenticated, (req, res) => {
  const dni = req.query.id;
  const userDNI = req.session.userDNI;

  if (dni !== userDNI) {
    return res.status(403).json({ error: 'Acceso no autorizado' });
  }

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

3. Análisis de bases de datos

Evidencias a buscar:

• Registros de auditoría de consultas SQL
• Usuarios que han accedido a registros no autorizados
• Exportaciones masivas de datos
• Conexiones inusuales a bases de datos

4. Forense de red

• Captura de tráfico: Si existe PCAP de los días sospechosos, analizar patrones de peticiones HTTP/HTTPS
• Exfiltración de datos: Buscar transferencias masivas salientes inusuales
• Conexiones externas: Identificar IPs que realizaron peticiones anómalas

Precedentes: El caso Qilin (octubre 2025)

Este no es el primer susto de Hacienda en los últimos meses.

Alegación de Qilin Ransomware

En octubre de 2025, el grupo de ransomware Qilin afirmó haber:

• Comprometido sistemas de Hacienda
• Extraído datos sensibles de millones de contribuyentes
• Amenazado con publicar la información si no se pagaba un rescate

Desmentido oficial

Al igual que ahora, Hacienda negó rotundamente el ataque tras una investigación interna.

Lo que esto significa

Dos escenarios posibles:

1. Falsos positivos: Grupos criminales hacen afirmaciones falsas para ganar notoriedad o manipular mercados
2. Detección tardía: Los sistemas fueron comprometidos pero las investigaciones internas no detectaron evidencias concluyentes

Como perito, debo reconocer que detectar un ataque IDOR después de meses es extremadamente difícil si:

• Los logs se rotan periódicamente (borrado de evidencias)
• El atacante usó credenciales legítimas robadas
• Las peticiones parecían actividad normal de usuarios

Por qué es difícil verificar si hubo filtración real

1. Los logs se pierden

La mayoría de organizaciones rotan logs cada 30-90 días por razones de almacenamiento. Si el ataque ocurrió hace meses:

[octubre 2025] ← Logs borrados
[noviembre 2025] ← Logs borrados
[diciembre 2025] ← Logs disponibles
[febrero 2026] ← Investigación inicia

Resultado: No hay evidencia forense del ataque original.

2. Tráfico cifrado (HTTPS)

Si las peticiones usaban HTTPS, el contenido está cifrado. Los sistemas de monitoreo de red solo ven:

IP origen → hacienda.gov (puerto 443)
↑                         ↑
Visible            Contenido cifrado (no visible sin certificados)

3. Credenciales legítimas

Si el atacante usó credenciales robadas de usuarios reales, las peticiones parecen completamente legítimas:

Usuario: [email protected]
Sesión válida: Sí
Autenticado: Sí
Permisos: Funcionario con acceso a datos
                        ↓
            ¿Cómo distinguir entre uso legítimo y malicioso?

4. Falta de alertas proactivas

Muchas organizaciones no tienen sistemas de detección de anomalías que alerten sobre:

• Un usuario accediendo a 1.000 registros en 1 hora
• Peticiones secuenciales de DNIs consecutivos
• Accesos fuera del horario laboral habitual
• Descargas masivas de datos

Implicaciones para los ciudadanos

Si la filtración fue real (aunque Hacienda lo descarta), las implicaciones son graves:

Datos potencialmente expuestos

Según Hackmanac, la información comprometida incluiría:

Riesgos inmediatos

1. Phishing ultra-dirigido: Con datos fiscales reales, los estafadores pueden crear correos/SMS extremadamente convincentes

   "Sr. Juan Pérez, DNI 12345678A:
   
   Detectamos una discrepancia en su declaración 2025
   (Base imponible: 45.320€, Retenciones: 8.245€).
   
   Debe verificar sus datos en el siguiente enlace..."

2. Suplantación de identidad: Solicitar créditos, contratos o servicios a tu nombre

3. Extorsión: “Sabemos que tienes bienes no declarados… paga X o lo publicamos”

4. Fraudes financieros: Intentos de transferencias con tus datos bancarios completos

Qué hacer como ciudadano afectado

Aunque Hacienda descarta el ataque, toda la población española debe considerarse potencialmente afectada:

Medidas inmediatas

Derechos legales

En caso de confirmarse la filtración, los ciudadanos afectados tendrían derecho a:

• Notificación oficial: Hacienda debería notificar individualmente (Art. 33 RGPD)
• Medidas de protección: Servicios gratuitos de monitoreo de identidad
• Compensación: Posible indemnización por daños y perjuicios
• Acciones colectivas: Demandas de clase por negligencia en protección de datos

Conclusiones desde la perspectiva forense

Como perito informático forense, extraigo las siguientes conclusiones de este caso:

1. Las vulnerabilidades IDOR son reales y peligrosas

No es una vulnerabilidad “teórica”. Organismos públicos y empresas siguen desplegando sistemas con estos fallos críticos de control de acceso.

2. La detección post-mortem es muy difícil

Si un ataque IDOR ocurrió hace meses:

• Los logs pueden haberse borrado
• Las evidencias digitales se degradan
• Distinguir entre acceso legítimo y malicioso es complejo

3. Los desmentidos no son concluyentes

Un “no se ha detectado evidencia” no equivale a “no ocurrió”. Solo significa que la investigación con los datos disponibles no encontró pruebas concluyentes.

4. La prevención debe ser proactiva

Organizaciones que manejan datos sensibles deben implementar:

• Validación de autorización en cada acceso a recursos
• Referencias indirectas (UUIDs, tokens) en lugar de identificadores predecibles
• Sistemas de detección de anomalías en tiempo real
• Auditoría continua de logs de acceso
• Retención de logs extendida (mínimo 1 año)

5. Todos somos potenciales víctimas

Hasta que no haya una auditoría externa independiente con metodología forense rigurosa, debemos actuar como si nuestros datos fiscales hubieran sido expuestos.

Fuentes consultadas:

• Infobae - Hacienda investiga un posible ciberataque
• Escudo Digital - Hacienda descarta el ciberataque
• OWASP - IDOR Prevention Cheat Sheet
• OWASP Top 10 2021 - A01:2021 Broken Access Control

Sobre el autor: Jonathan Izquierdo es perito informático forense con experiencia en análisis de brechas de seguridad, auditorías de vulnerabilidades y peritajes judiciales sobre protección de datos.

Última actualización: 4 Febrero 2026