Hacienda investiga alerta de ciberataque IDOR: ¿47 millones de españoles expuestos?

El 2 de febrero de 2026, la firma de ciberseguridad Hackmanac lanzó una alerta que hizo saltar todas las alarmas: un actor de amenaza bajo el alias “HaciendaSec” afirmaba haber accedido a servidores centrales del Ministerio de Hacienda, exponiendo datos personales, bancarios y fiscales de 47,3 millones de ciudadanos españoles.

Al día siguiente, Hacienda descartó el ataque. Pero la investigación continúa.

Como perito informático forense, he participado en la investigación de múltiples incidentes similares. En este artículo analizo técnicamente qué ha ocurrido, qué es la vulnerabilidad IDOR que supuestamente se explotó, y por qué verificar la veracidad de estas alertas es más complejo de lo que parece.

Qué sabemos (y qué no) del incidente

La alerta de Hackmanac

El 2 de febrero, Hackmanac publicó una alerta detectando actividad sospechosa en foros clandestinos de la dark web:

• Un actor usando el alias “HaciendaSec” ofrecía en venta una base de datos actualizada
• Afirmaba contener información de prácticamente toda la población con obligaciones fiscales en España
• El método: explotación de vulnerabilidad IDOR + credenciales previamente filtradas
• La técnica: enumeración secuencial de DNI/NIE

El desmentido oficial

El 3 de febrero, Hacienda descartó el ataque:

“No se han detectado indicios de acceso no autorizado tras las comprobaciones de seguridad realizadas en todos los departamentos.”

El Ministerio argumenta:

• Las revisiones técnicas no muestran evidencias de intrusión
• El actor “HaciendaSec” no tiene historial previo de ataques
• La cuenta desde la que se publicó la alerta fue creada hace apenas un mes
• Continúan monitorizando sistemas por precaución

El precedente de octubre 2025

Este no es el primer incidente. En octubre de 2025, el grupo ransomware Qilin afirmó haber comprometido 238.799 archivos de Hacienda. La Agencia Tributaria también lo desmintió.

Posteriormente se confirmó que los datos provenían de empresas de asesoría fiscal comprometidas, no de sistemas internos del Ministerio.

Qué es IDOR y por qué es tan peligroso

Definición técnica

IDOR (Insecure Direct Object Reference) es una vulnerabilidad que ocurre cuando una aplicación web expone referencias directas a objetos internos sin verificar autorización.

Ejemplo simplificado:

# URL legítima para ver TU declaración
https://hacienda.es/declaracion?id=12345678A

# Atacante cambia el DNI en la URL
https://hacienda.es/declaracion?id=87654321B
                                        ↑
                            DNI de otra persona

# Si no hay control de acceso... ¡bingo!

Por qué es crítica

Según OWASP, IDOR está clasificada dentro de Broken Access Control, la vulnerabilidad #1 del OWASP Top 10.

Sus características:

El supuesto método de ataque

Según la alerta, el atacante:

1. Obtuvo credenciales válidas (posiblemente de filtraciones anteriores)
2. Identificó endpoints vulnerables a IDOR en el sistema de Hacienda
3. Automatizó la enumeración de DNI/NIE con un script
4. Extrajo información de hasta 47,3 millones de registros

Si esto es cierto, el ataque sería devastador pero técnicamente trivial de ejecutar.

Cómo se investiga forenses este tipo de incidentes

Como perito informático, cuando me contratan para analizar un posible ataque IDOR, sigo este proceso:

1. Análisis de logs del servidor

# Buscar patrones de enumeración secuencial
grep "declaracion?id=" /var/log/apache2/access.log | \
  awk '{print $1, $7}' | \
  sort | uniq -c | sort -rn

# Resultado sospechoso:
# 47.300.000 requests desde misma IP en 72 horas
# IDs incrementales: 12345678A → 59999999Z

Indicadores de ataque IDOR:

• Volumen anómalo de peticiones desde misma IP/rango
• Enumeración secuencial de identificadores
• Respuestas HTTP 200 (éxito) en lugar de 403 (prohibido)
• Tiempo de respuesta constante (no hay validación de permisos)

2. Revisión de controles de acceso

Analizamos el código fuente para verificar si existe validación:

# VULNERABLE (sin control de acceso)
@app.route('/declaracion')
def get_declaracion():
    dni = request.args.get('id')
    data = db.query("SELECT * FROM declaraciones WHERE dni = ?", dni)
    return jsonify(data)  # ❌ No verifica si el usuario puede ver este DNI

# CORRECTO (con control de acceso)
@app.route('/declaracion')
@require_auth
def get_declaracion():
    dni = request.args.get('id')
    user_dni = get_current_user_dni()

    if dni != user_dni and not is_admin():
        return jsonify({"error": "Unauthorized"}), 403  # ✅ Validación

    data = db.query("SELECT * FROM declaraciones WHERE dni = ?", dni)
    return jsonify(data)

3. Análisis de tráfico de red

Si hay EDR (Endpoint Detection and Response) o herramientas de monitorización:

• Identificar picos de tráfico hacia endpoints específicos
• Correlacionar con direcciones IP sospechosas
• Analizar si hay exfiltración de datos (volumen saliente anómalo)

4. Verificación de credenciales comprometidas

Comprobamos si las credenciales usadas provienen de filtraciones anteriores:

# Buscar en bases de datos de filtraciones
haveibeenpwned.com API
dehashed.com
leaked-databases archives

5. Hash de evidencias

Todo el proceso se documenta con cadena de custodia rigurosa:

# Hash SHA-256 de logs originales
sha256sum access.log > evidence.hash

# Imagen forense del servidor
dd if=/dev/sda of=server_image.dd bs=4M
sha256sum server_image.dd >> evidence.hash

Por qué es tan difícil verificar la veracidad

El dilema del perito externo

Cuando investigo un incidente en una empresa privada, tengo acceso completo:

• Logs del servidor
• Código fuente de la aplicación
• Configuración de firewalls
• Datos de EDR/SIEM
• Entrevistas con el equipo técnico

Con organismos públicos, la situación es diferente:

Señales contradictorias

Argumentos a favor de que hubo ataque:

• Hackmanac tiene reputación en detección de amenazas
• El método IDOR + credenciales filtradas es técnicamente plausible
• 47,3 millones coincide con población con obligaciones fiscales
• La enumeración de DNI es trivial de automatizar

Argumentos en contra:

• Hacienda no detectó indicios de intrusión en sus revisiones
• “HaciendaSec” no tiene historial previo (posible hoax)
• Cuenta creada hace solo un mes (muy reciente)
• Precedente de Qilin fue también una falsa alarma

El problema de la muestra

En casos normales, pedimos al supuesto atacante que demuestre el acceso proporcionando una muestra de datos que solo podría tener si la brecha es real.

Pero aquí surge un dilema ético y legal:

• Si proporciona datos reales → confirma el ataque, pero comete un delito
• Si no los proporciona → puede ser un bulo, pero también precaución legal

Qué hacer como ciudadano afectado

Aunque Hacienda ha descartado el ataque, te recomiendo tomar estas precauciones:

1. Monitoriza tus cuentas

✅ Revisa extractos bancarios semanalmente
✅ Activa alertas de movimientos en tu banco
✅ Comprueba que no hay domiciliaciones extrañas
✅ Revisa tu declaración de la renta en sede electrónica

2. Verifica si tus datos están filtrados

Herramientas gratuitas para comprobar filtraciones:

• Have I Been Pwned
• DeHashed
• Firefox Monitor

3. Refuerza tu seguridad

• Cambia tu contraseña de la Sede Electrónica de Hacienda
• Activa autenticación de dos factores siempre que sea posible
• No uses la misma contraseña en múltiples servicios
• Usa un gestor de contraseñas (Bitwarden, 1Password)

4. Atento a phishing

Los ciberdelincuentes aprovechan estas noticias para lanzar campañas de phishing:

5. Solicita un informe a Hacienda

Puedes ejercer tu derecho RGPD y solicitar:

Asunto: Solicitud de acceso a datos personales (Art. 15 RGPD)

Solicito copia de mis datos personales almacenados en sus sistemas,
así como confirmación de si han sido objeto de alguna brecha de seguridad
en los últimos 12 meses.

Hacienda tiene un mes para responder.

Conclusión: la importancia del peritaje independiente

Este caso ilustra perfectamente por qué el peritaje forense independiente es crucial:

Los desmentidos oficiales no siempre cuentan toda la historia

• En el caso Equifax 2017, la empresa negó inicialmente la brecha. Resultaron ser 147 millones de afectados.
• En Yahoo 2013, la compañía reconoció “1 millón” de cuentas. Años después admitieron: 3.000 millones.
• Con Qilin en octubre 2025, Hacienda desmintió… pero los datos provenían de asesoras fiscales comprometidas.

No sugiero que Hacienda esté mintiendo. Pero la historia nos enseña que las confirmaciones independientes son esenciales.

¿Cuándo necesitas un perito informático?

Contacta conmigo si:

• Sospechas que tus datos han sido comprometidos
• Recibes notificaciones extrañas de Hacienda que no solicitaste
• Detectas movimientos fiscales o bancarios que no reconoces
• Necesitas evidencia forense para un proceso legal
• Tu empresa colabora con Hacienda y teme ser el origen de una filtración

Como perito forense, puedo:

• ✅ Analizar si tus datos aparecen en filtraciones de la dark web
• ✅ Realizar análisis forense de tus sistemas si eres empresa afectada
• ✅ Elaborar informes periciales con validez judicial
• ✅ Asesorarte técnicamente para reforzar tu seguridad

Referencias y recursos

• Infobae: Hacienda investiga posible ciberataque
• EscudoDigital: Hacienda descarta el ciberataque
• OWASP: IDOR Prevention Cheat Sheet
• Have I Been Pwned
• Unsplash: Data Breach Images

Actualización: Este artículo se publicó el 4 de febrero de 2026. La situación continúa en desarrollo. Actualizaré con nueva información según se confirmen detalles adicionales.

Descargo de responsabilidad: El análisis presentado se basa en información pública disponible. No tengo acceso a sistemas internos de Hacienda ni a datos clasificados. Las conclusiones son técnicas, no legales.