Credential Stuffing

¿Qué es el Credential Stuffing?

El credential stuffing es un tipo de ciberataque automatizado en el que los atacantes utilizan combinaciones reales de nombre de usuario y contraseña obtenidas de filtraciones de datos anteriores para intentar acceder de forma fraudulenta a cuentas en otros servicios y plataformas.

La eficacia de este ataque se fundamenta en un problema endémico de la seguridad informática: la reutilización de contraseñas. Según estudios de Google y Harris Poll, el 65 % de los usuarios reutiliza la misma contraseña en múltiples servicios. Esto significa que cuando un servicio sufre una brecha de datos, las credenciales filtradas pueden utilizarse para comprometer cuentas en docenas de plataformas diferentes.

A diferencia de otros ataques como el fuerza bruta (que prueba combinaciones aleatorias) o el password spraying (que prueba contraseñas comunes contra muchos usuarios), el credential stuffing utiliza credenciales que ya fueron válidas en algún momento, lo que le confiere una tasa de éxito significativamente superior.

Diferencias con otros ataques de autenticación

Para comprender correctamente el credential stuffing, es fundamental diferenciarlo de otros vectores de ataque contra sistemas de autenticación:

¿Por qué el credential stuffing es más peligroso?

El credential stuffing es especialmente peligroso por tres razones:

1. Usa credenciales reales: al tratarse de contraseñas que efectivamente pertenecieron a un usuario, el ataque genera menos alertas de seguridad que un fuerza bruta.
2. Escala masiva: con herramientas automatizadas, un atacante puede probar millones de combinaciones en pocas horas.
3. Difícil de atribuir: el uso de proxies rotativos y redes de bots dificulta rastrear el origen del ataque.

Cómo funciona un ataque de Credential Stuffing

Fase 1: Obtención de credenciales (Combo Lists)

El punto de partida de todo ataque de credential stuffing es la obtención de bases de datos de credenciales filtradas, conocidas como combo lists o combolists. Estas listas se obtienen de diversas fuentes:

Fuentes de combo lists:

• Brechas de datos públicas: filtraciones masivas como Collection #1 (773 millones de registros), COMB (3 200 millones de registros) o la filtración de LinkedIn (700 millones de perfiles).
• Dark web y foros underground: mercados como Genesis Market (desmantelado en 2023), Russian Market o foros como BreachForums donde se comercializan credenciales.
• Infostealers: malware especializado como RedLine, Raccoon Stealer o Vidar que roba credenciales directamente del navegador de las víctimas.
• Pastes y dumps públicos: publicaciones en Pastebin, Ghostbin o servicios similares donde se filtran credenciales.

Formato típico de una combo list:

email:contraseña
usuario@gmail.com:MiContraseña123
otro.usuario@hotmail.com:password2024
empresa@corporativo.es:Verano2023!

Las listas se clasifican y venden según criterios como:

Fase 2: Preparación del ataque

Antes de lanzar el ataque, los ciberdelincuentes configuran la infraestructura necesaria:

Herramientas de automatización:

Los atacantes utilizan software especializado diseñado específicamente para credential stuffing:

• OpenBullet / OpenBullet 2: la herramienta más popular y versátil. Es de código abierto y permite crear «configuraciones» personalizadas (llamadas configs o stacker configs) para cada sitio web objetivo. Soporta:

  • Peticiones HTTP/HTTPS personalizadas
  • Parsing de respuestas (HTML, JSON, regex)
  • Gestión de proxies rotativos
  • Resolución de CAPTCHAs (vía servicios como 2Captcha o Anti-Captcha)
  • Multithreading para máxima velocidad

• SentryMBA: herramienta veterana con interfaz gráfica, popular por su facilidad de uso.

• STORM / Silverbullet / Black Bullet: variantes con funcionalidades similares a OpenBullet.

• Scripts personalizados: atacantes avanzados desarrollan herramientas propias en Python, Go o Node.js utilizando librerías como Selenium, Puppeteer o Playwright para emular navegadores reales.

Infraestructura de proxies:

Para evitar la detección por IP, los atacantes utilizan:

Proxies residenciales  →  IPs de usuarios reales (difíciles de bloquear)
Proxies datacenter     →  Más rápidos pero más fáciles de detectar
Proxies rotativos      →  Cambian de IP cada petición o cada N segundos
Botnets                →  Miles de dispositivos infectados como proxies
VPNs residenciales     →  Servicios como Luminati/Bright Data (uso legítimo desviado)

Fase 3: Ejecución del ataque

El proceso de ejecución sigue un flujo automatizado:

Ejemplo de flujo técnico:

POST /api/v1/auth/login HTTP/1.1
Host: servicio-objetivo.com
Content-Type: application/json
X-Forwarded-For: 83.42.xxx.xxx (proxy rotativo)
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...

{
  "email": "victima@gmail.com",
  "password": "MiContraseña123"
}

→ Respuesta 200 OK + token JWT = HIT (cuenta comprometida)
→ Respuesta 401 Unauthorized   = BAD (credenciales inválidas)
→ Respuesta 429 Too Many Req   = RETRY (rate limiting activado)
→ Respuesta 403 Forbidden      = BANNED (IP bloqueada)

Fase 4: Explotación y monetización

Una vez obtenidas las cuentas comprometidas, los atacantes las explotan de diversas formas:

Estadísticas y magnitud del problema

El credential stuffing no es un ataque marginal: constituye una de las amenazas más prevalentes en internet.

Cifras globales

• 24 000+ millones de credenciales filtradas circulan en la dark web (SpyCloud, 2024).
• 34 % de todos los intentos de login en internet son credential stuffing (Okta, 2024).
• 193 000 millones de intentos de credential stuffing detectados en 2020 solo por Akamai.
• Tasa de éxito media: entre el 0,1 % y el 2 % de los intentos resultan exitosos.
• Coste medio por incidente de credential stuffing para una empresa: 6 millones de dólares anuales (Ponemon Institute).

Brechas de datos que alimentan el credential stuffing

Estadísticas sobre reutilización de contraseñas

• 65 % de los usuarios reutiliza la misma contraseña en múltiples sitios (Google/Harris Poll).
• 13 % utiliza la misma contraseña para absolutamente todas sus cuentas.
• 59 % incluye información personal en sus contraseñas (nombre, fecha de nacimiento).
• Solo el 23 % de los usuarios utiliza un gestor de contraseñas.

Casos reales de Credential Stuffing

Zoom (abril 2020)

Durante la pandemia de COVID-19, más de 500 000 cuentas de Zoom fueron comprometidas mediante credential stuffing y puestas a la venta en foros de la dark web por tan solo 0,002 dólares cada una. Zoom no sufrió una brecha propia: los atacantes utilizaron credenciales filtradas de otros servicios.

Impacto forense:

• Las cuentas comprometidas incluían emails corporativos, contraseñas, URLs de reuniones personales y claves de host.
• Permitía a los atacantes unirse a reuniones sin autorización (Zoom-bombing).
• Zoom respondió implementando contraseñas obligatorias en reuniones y salas de espera.

Nintendo (abril 2020)

Nintendo confirmó que 300 000 cuentas fueron comprometidas a través de credential stuffing utilizando el sistema de login NNID (Nintendo Network ID). Los atacantes accedieron a información personal, historial de compras y, en algunos casos, realizaron compras fraudulentas con los métodos de pago asociados.

Impacto:

• Compras no autorizadas en la Nintendo eShop.
• Acceso a datos personales (nombre, fecha de nacimiento, email, país).
• Nintendo desactivó el login vía NNID y forzó el restablecimiento de contraseñas.

Spotify (noviembre 2020)

Investigadores de vpnMentor descubrieron una base de datos Elasticsearch con más de 350 000 credenciales de Spotify validadas mediante credential stuffing. La base de datos, que pesaba 72 GB, contenía credenciales verificadas como válidas en la plataforma de streaming.

Detalles técnicos:

• Los atacantes utilizaron credenciales de brechas previas para verificar cuáles funcionaban en Spotify.
• Las cuentas verificadas se almacenaban en Elasticsearch para posterior venta o explotación.
• Spotify forzó el cambio de contraseña en todas las cuentas afectadas.

HSBC (octubre 2018)

El banco HSBC notificó a sus clientes en Estados Unidos que un ataque de credential stuffing había permitido el acceso no autorizado a cuentas bancarias durante un período de 11 días (del 4 al 14 de octubre de 2018).

Información comprometida:

• Nombres completos, direcciones, fechas de nacimiento.
• Números de cuenta y saldos.
• Historial de transacciones.
• Datos de beneficiarios de transferencias.

Dunkin’ Donuts (2015-2019)

La cadena de restaurantes sufrió múltiples ataques de credential stuffing reiterados entre 2015 y 2019, comprometiendo las cuentas del programa de fidelización DD Perks. Los atacantes accedían a las cuentas para robar el saldo de las tarjetas de regalo asociadas.

Consecuencias legales:

• La empresa fue demandada por el fiscal general de Nueva York.
• Se determinó que Dunkin’ no había implementado medidas razonables de detección.
• Acuerdo de 650 000 dólares en multas y obligación de implementar protecciones.

The North Face (octubre 2020)

La marca de ropa outdoor confirmó que cuentas de su sitio web thenorthface.com fueron comprometidas mediante credential stuffing. Los atacantes accedieron a:

• Nombres y direcciones de envío.
• Historial de compras.
• Números de tarjetas parcialmente visibles.
• Puntos del programa de fidelización XPLR Pass.

Análisis forense de Credential Stuffing

Indicadores de compromiso (IoC)

Un perito informático busca los siguientes indicadores al investigar un posible ataque de credential stuffing:

En logs de autenticación:

# Patrón horizontal: misma IP prueba muchas cuentas
2026-03-15 10:22:01 FAIL user1@email.com    IP: 91.234.x.x
2026-03-15 10:22:02 FAIL user2@email.com    IP: 91.234.x.x
2026-03-15 10:22:02 OK   user3@email.com    IP: 91.234.x.x  ← HIT
2026-03-15 10:22:03 FAIL user4@email.com    IP: 91.234.x.x

# Patrón distribuido: muchas IPs prueban la misma secuencia
2026-03-15 10:22:01 FAIL user1@email.com    IP: 185.42.x.x
2026-03-15 10:22:01 FAIL user2@email.com    IP: 92.108.x.x
2026-03-15 10:22:01 FAIL user3@email.com    IP: 77.55.x.x
2026-03-15 10:22:02 FAIL user4@email.com    IP: 203.91.x.x

Indicadores en metadatos de sesión:

Metodología de investigación forense

Herramientas de análisis forense

Ejemplo de análisis con Python

import pandas as pd
from collections import Counter

# Cargar logs de autenticación
logs = pd.read_csv('auth_logs.csv', parse_dates=['timestamp'])

# Identificar IPs con ratio anómalo de fallos
ip_stats = logs.groupby('ip_address').agg(
    total=('result', 'count'),
    failures=('result', lambda x: (x == 'FAIL').sum()),
    successes=('result', lambda x: (x == 'OK').sum()),
    unique_users=('username', 'nunique'),
    first_seen=('timestamp', 'min'),
    last_seen=('timestamp', 'max')
)
ip_stats['fail_rate'] = ip_stats['failures'] / ip_stats['total']
ip_stats['duration_seconds'] = (
    ip_stats['last_seen'] - ip_stats['first_seen']
).dt.total_seconds()

# Filtrar IPs sospechosas de credential stuffing
suspicious = ip_stats[
    (ip_stats['total'] > 50) &           # Más de 50 intentos
    (ip_stats['fail_rate'] > 0.9) &       # Más del 90% fallos
    (ip_stats['unique_users'] > 10) &     # Muchos usuarios distintos
    (ip_stats['duration_seconds'] < 3600)  # En menos de 1 hora
]

print(f"IPs sospechosas de credential stuffing: {len(suspicious)}")
print(suspicious.sort_values('total', ascending=False).head(20))

Análisis de timing para detectar automatización

# Calcular intervalos entre peticiones consecutivas por IP
for ip in suspicious.index:
    ip_logs = logs[logs['ip_address'] == ip].sort_values('timestamp')
    intervals = ip_logs['timestamp'].diff().dt.total_seconds().dropna()

    # Bots tienen intervalos muy regulares (baja desviación estándar)
    mean_interval = intervals.mean()
    std_interval = intervals.std()
    cv = std_interval / mean_interval if mean_interval > 0 else 0

    # CV < 0.3 indica alta regularidad (bot)
    # CV > 0.5 indica comportamiento más humano
    if cv < 0.3:
        print(f"IP {ip}: PROBABLE BOT "
              f"(media={mean_interval:.3f}s, CV={cv:.3f})")

Detección y prevención del Credential Stuffing

Para empresas y desarrolladores

Autenticación multifactor (MFA)

La medida más efectiva contra el credential stuffing es la autenticación multifactor, que añade una capa adicional de verificación que el atacante no puede obtener de una combo list:

Rate Limiting inteligente

El rate limiting básico por IP es insuficiente contra credential stuffing distribuido. Las implementaciones efectivas incluyen:

Rate Limiting por IP:
  → Máximo 10 intentos fallidos / 15 minutos / IP
  → Bloqueo progresivo: 5 min → 15 min → 1 hora → 24 horas

Rate Limiting por cuenta:
  → Máximo 5 intentos fallidos / 30 minutos / cuenta
  → Notificación al usuario tras 3 intentos fallidos

Rate Limiting global:
  → Monitorizar tasa global de fallos de autenticación
  → Si supera el 5 % en 5 minutos → activar CAPTCHA para todos
  → Si supera el 20 % → activar modo de emergencia

Rate Limiting por fingerprint:
  → Agrupar por combinación de User-Agent + resolución + idioma
  → Detectar patrones de rotación de fingerprint

CAPTCHAs progresivos

Los CAPTCHAs no deben aplicarse a todos los usuarios de forma indiscriminada, sino progresivamente en función del riesgo:

• Riesgo bajo (usuario conocido, IP habitual, dispositivo reconocido): sin CAPTCHA.
• Riesgo medio (nueva IP, primer intento fallido): CAPTCHA invisible (reCAPTCHA v3, hCaptcha).
• Riesgo alto (múltiples fallos, IP sospechosa): CAPTCHA interactivo.
• Riesgo muy alto (patrón de credential stuffing detectado): bloqueo + verificación por email.

Monitorización de credenciales comprometidas

Implementar verificación proactiva de contraseñas contra bases de datos de filtraciones:

# Ejemplo usando la API de Have I Been Pwned (k-Anonymity)
1. Usuario establece contraseña "MiContraseña123"
2. Calcular SHA-1: 7C6A180B36896A65C4C...
3. Enviar prefijo (5 chars): 7C6A1
4. API devuelve todos los hashes que empiezan por 7C6A1
5. Buscar si el hash completo está en la lista
6. Si aparece → avisar al usuario de que la contraseña está filtrada

Servicios de monitorización:

Detección de anomalías de comportamiento

Implementar análisis de comportamiento para distinguir usuarios legítimos de bots:

Bloqueo de herramientas conocidas

Implementar detección de herramientas de credential stuffing:

# User-Agents sospechosos de herramientas de credential stuffing
OpenBullet → No envía User-Agent o usa strings genéricos
SentryMBA  → Patrones de conexión TCP reconocibles
Selenium   → navigator.webdriver = true
Puppeteer  → Ausencia de plugins estándar del navegador
cURL       → User-Agent "curl/X.X.X"

# Cabeceras HTTP ausentes en bots
Accept-Language: (ausente en muchos bots)
Sec-Ch-Ua:      (ausente en automatizaciones sin Chromium)
Sec-Fetch-Dest: (ausente en peticiones no-navegador)

Para usuarios

Contraseñas únicas para cada servicio

La defensa más efectiva contra el credential stuffing a nivel de usuario es no reutilizar contraseñas nunca:

• Utilizar un gestor de contraseñas (Bitwarden, 1Password, KeePassXC).
• Generar contraseñas aleatorias de al menos 16 caracteres.
• Nunca basar contraseñas en datos personales (nombre, fecha, mascota).

Activar MFA en todos los servicios

Priorizar la activación de autenticación multifactor en:

1. Email principal (puerta de acceso a todos los demás servicios).
2. Banca online (impacto económico directo).
3. Redes sociales (suplantación de identidad).
4. Servicios cloud (almacenamiento de datos sensibles).
5. E-commerce (métodos de pago guardados).

Monitorización de filtraciones

• Registrarse en Have I Been Pwned para recibir alertas si su email aparece en una filtración.
• Utilizar la función de comprobación de contraseñas de Google Chrome o Firefox.
• Revisar periódicamente la sección de seguridad de las cuentas principales.

Marco legal en España

Delitos aplicables al Credential Stuffing

El credential stuffing puede constituir varios delitos tipificados en el Código Penal español:

Artículo 197 bis del Código Penal (acceso ilícito)

El artículo más directamente aplicable al credential stuffing es el 197 bis, que castiga a quien:

«por cualquier medio o procedimiento, vulnerando las medidas de seguridad establecidas para impedirlo, y sin estar debidamente autorizado, acceda o facilite a otro el acceso al conjunto o una parte de un sistema de información»

Elementos del tipo penal aplicados al credential stuffing:

• Vulneración de medidas de seguridad: el sistema de autenticación (usuario/contraseña) es una medida de seguridad. Utilizar credenciales robadas constituye una vulneración.
• Sin autorización: el atacante no tiene autorización para acceder con credenciales que no le pertenecen, aunque estas sean técnicamente «válidas».
• Acceso al sistema: el login exitoso en la cuenta de otro usuario constituye acceso al sistema.

Artículo 248 del Código Penal (estafa)

Cuando el credential stuffing se utiliza para obtener un beneficio económico (compras fraudulentas, transferencias, uso de saldos), aplica el tipo de estafa informática:

«los que, con ánimo de lucro, utilizaren engaño bastante para producir error en otro, induciéndole a realizar un acto de disposición en perjuicio propio o ajeno»

El artículo 248.2 extiende específicamente la estafa a las manipulaciones informáticas.

Normativa de protección de datos (RGPD)

Las empresas que sufren un ataque de credential stuffing tienen obligaciones bajo el RGPD:

• Notificación a la AEPD: en un plazo máximo de 72 horas tras tener conocimiento de la brecha (artículo 33 RGPD).
• Notificación a los afectados: si la brecha entraña un alto riesgo para sus derechos y libertades (artículo 34 RGPD).
• Evaluación de impacto: documentar la brecha, sus efectos y las medidas adoptadas.
• Posibles sanciones: si se determina que la empresa no implementó medidas de seguridad adecuadas, la AEPD puede imponer multas de hasta el 4 % de la facturación anual global.

Jurisprudencia relevante

Si bien la jurisprudencia específica sobre credential stuffing en España es aún limitada, existen sentencias relevantes sobre acceso ilícito a sistemas y uso fraudulento de credenciales:

• STS 364/2020: establece que el acceso a un sistema informático con credenciales ajenas, aunque sean técnicamente válidas, constituye acceso no autorizado si no se tiene el consentimiento del titular.
• SAP Madrid 127/2019: condena por acceso ilícito a cuentas de correo utilizando credenciales obtenidas ilícitamente, aplicando el artículo 197 bis.
• Directiva NIS2 (UE 2022/2555): obliga a las entidades esenciales e importantes a implementar medidas de gestión de riesgos de ciberseguridad, incluyendo la protección contra credential stuffing.

El papel del Perito Informático

En la investigación de un ataque

El perito informático desempeña un papel fundamental en la investigación de ataques de credential stuffing:

1. Determinación del vector de ataque:

• Confirmar que se trata de credential stuffing (no de fuerza bruta, insider threat u otro vector).
• Identificar la fuente probable de las credenciales filtradas (qué brecha previa).
• Determinar las herramientas y la infraestructura utilizadas por el atacante.

2. Análisis de alcance e impacto:

• Cuantificar el número exacto de cuentas comprometidas.
• Identificar qué datos fueron accedidos o exfiltrados.
• Determinar si hubo movimiento lateral (uso de las cuentas comprometidas para acceder a otros sistemas).
• Evaluar el daño económico directo e indirecto.

3. Preservación de evidencia digital:

• Adquisición forense de logs, bases de datos y sistemas afectados.
• Garantía de la cadena de custodia.
• Generación de hashes criptográficos (SHA-256) de toda la evidencia.
• Documentación del proceso con timestamps verificables.

4. Elaboración de informe pericial:

• Descripción técnica del ataque y su metodología.
• Timeline detallado de los eventos.
• Evidencias que vinculan el ataque con las IPs, herramientas y tácticas utilizadas.
• Evaluación de las medidas de seguridad implementadas por la empresa víctima.
• Conclusiones sobre la diligencia de la empresa y/o la negligencia del atacante.

En la defensa de víctimas

El perito también puede actuar en defensa de las víctimas individuales de credential stuffing:

• Demostrar que la contraseña fue filtrada: correlacionar la contraseña de la víctima con bases de datos de filtraciones conocidas para demostrar que el compromiso no fue por negligencia del usuario.
• Evaluar la sofisticación del ataque: documentar que el ataque utilizó técnicas avanzadas (proxies rotativos, herramientas especializadas) que hacen indetectable el compromiso para un usuario medio.
• Cuantificar daños: documentar las pérdidas económicas, el tiempo invertido en recuperar cuentas y el impacto en la privacidad.

En la evaluación de responsabilidad empresarial

El perito puede evaluar si la empresa víctima implementó medidas de seguridad adecuadas:

Tendencias y evolución

Credential Stuffing as a Service (CSaaS)

La industrialización del credential stuffing ha dado lugar a servicios «llave en mano» donde:

• Los atacantes pueden alquilar infraestructura (proxies, herramientas, combo lists) por horas o días.
• Existen marketplaces de configs (configuraciones de OpenBullet para sitios específicos) que se venden por 5-50 dólares cada una.
• Los servicios de resolución de CAPTCHAs (2Captcha, Anti-Captcha, CapMonster) permiten automatizar el bypass de CAPTCHAs a escala.

Infostealers como fuente primaria

La evolución más preocupante es el auge de los infostealers como fuente de credenciales frescas:

• A diferencia de las brechas masivas (que pueden tener meses o años de antigüedad), los infostealers proporcionan credenciales en tiempo real.
• Malware como RedLine, Raccoon Stealer o Vidar roba credenciales directamente del navegador, incluyendo cookies de sesión que permiten bypass de MFA.
• Genesis Market (antes de su desmantelamiento en 2023) vendía «identidades digitales» completas (credenciales + cookies + fingerprint del navegador) que permitían suplantar completamente a un usuario.

Inteligencia artificial en credential stuffing

Los atacantes están comenzando a utilizar IA para:

• Generar variaciones de contraseñas: si la contraseña filtrada es «Verano2023», la IA puede generar «Verano2024», «Verano2023!», «verano2023», etc.
• Evadir detección: entrenamiento de modelos que emulan patrones de comportamiento humano para evitar sistemas de detección basados en comportamiento.
• Priorización de objetivos: clasificación automática de cuentas comprometidas por valor potencial.

Passkeys y el fin de las contraseñas

La adopción de Passkeys (basadas en FIDO2/WebAuthn) promete eliminar el credential stuffing al reemplazar las contraseñas por:

• Claves criptográficas vinculadas al dispositivo (no transferibles ni reutilizables).
• Autenticación biométrica (huella, reconocimiento facial) como factor local.
• Sin secretos compartidos: el servidor nunca almacena la contraseña, por lo que no hay nada que filtrar.

Sin embargo, la adopción completa de Passkeys tardará años, durante los cuales el credential stuffing seguirá siendo una amenaza vigente.

Glosario de términos relacionados

Recursos y referencias

Fuentes técnicas

• OWASP: Credential Stuffing Prevention Cheat Sheet
• NIST SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management
• Have I Been Pwned: https://haveibeenpwned.com — verificación de credenciales comprometidas
• SpyCloud Annual Identity Exposure Report: estadísticas actualizadas sobre credenciales filtradas

Fuentes legales

• Código Penal español: artículos 197, 197 bis, 248, 264, 401
• RGPD (Reglamento UE 2016/679): artículos 32, 33, 34 sobre medidas de seguridad y notificación de brechas
• Directiva NIS2 (UE 2022/2555): requisitos de ciberseguridad para entidades esenciales
• LOPDGDD (LO 3/2018): complementa al RGPD en el ordenamiento jurídico español

Herramientas de verificación

• Have I Been Pwned: https://haveibeenpwned.com
• Firefox Monitor: https://monitor.firefox.com
• Google Password Checkup: integrado en Chrome y cuenta de Google
• Dehashed: https://dehashed.com — motor de búsqueda de filtraciones (de pago)

Caso práctico: Investigación forense de Credential Stuffing

Escenario

Una empresa española de comercio electrónico detecta actividad anómala en las cuentas de sus usuarios. Durante un fin de semana, más de 12 000 cuentas fueron accedidas desde ubicaciones inusuales, y se realizaron compras fraudulentas con los métodos de pago guardados en 340 de ellas, por un importe total de 47 000 EUR.

Investigación del perito

Fase 1: Análisis de logs de autenticación

# Resumen del análisis de logs (período: viernes 18:00 - domingo 06:00)

Total intentos de login:          1 247 893
Intentos fallidos:                1 234 412  (98,92 %)
Intentos exitosos:                   13 481  (1,08 %)
IPs únicas utilizadas:              48 729
User-Agents únicos:                   1 247
Cuentas comprometidas (login OK):   12 341
Cuentas con actividad posterior:       340

# Tasa de éxito del 1,08 % = consistente con credential stuffing
# (Las credenciales provienen de filtraciones reales)

Fase 2: Análisis de infraestructura del atacante

# Distribución geográfica de IPs atacantes
País          | IPs     | % total
--------------|---------|---------
Brasil        | 12 847  | 26,4 %
Vietnam       | 8 921   | 18,3 %
Indonesia     | 7 234   | 14,8 %
India         | 6 128   | 12,6 %
Nigeria       | 4 892   | 10,0 %
Otros (23)    | 8 707   | 17,9 %

# Análisis de ASN: 87 % de IPs pertenecen a proveedores
# de proxies residenciales conocidos (Luminati, 911.re, Oxylabs)

Fase 3: Correlación con filtraciones

# Verificación de credenciales comprometidas contra HIBP
De las 12 341 cuentas comprometidas:
- 11 287 (91,5 %) utilizaban contraseñas presentes en
  filtraciones conocidas (Collection #1-5, LinkedIn, Adobe)
- 892 (7,2 %) utilizaban variaciones simples de contraseñas filtradas
- 162 (1,3 %) no se encontraron en filtraciones públicas
  (posible origen: infostealers)

Fase 4: Análisis de la herramienta utilizada

# Patrones identificativos del software de credential stuffing

Intervalo medio entre peticiones: 0,847 s (σ = 0,023)
→ Coeficiente de variación: 0,027 → ALTAMENTE AUTOMATIZADO

User-Agent más frecuente:
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
→ User-Agent genérico de OpenBullet (config por defecto)

Headers ausentes en el 99,7 % de peticiones:
  Sec-Ch-Ua, Sec-Ch-Ua-Mobile, Sec-Fetch-Dest
→ Ausencia consistente con herramienta automatizada, no navegador real

Patrón de rotación de proxies:
  Cada IP se usa para 25-30 intentos antes de rotar
→ Consistente con configuración típica de OpenBullet

Informe pericial

El informe pericial concluyó:

1. Naturaleza del ataque: credential stuffing automatizado utilizando OpenBullet o herramienta similar, con una combo list de aproximadamente 1,2 millones de credenciales.

2. Origen de las credenciales: el 91,5 % de las cuentas comprometidas utilizaban contraseñas presentes en filtraciones de datos previas. Los usuarios reutilizaban contraseñas.

3. Infraestructura: red de proxies residenciales con 48 729 IPs distribuidas en más de 25 países, lo que evidencia una operación profesionalizada.

4. Impacto cuantificado: 12 341 cuentas comprometidas, 340 con perjuicio económico directo (47 000 EUR en compras fraudulentas), datos personales de 12 341 usuarios accedidos (nombre, dirección, historial de compras).

5. Evaluación de medidas de seguridad: la empresa no tenía implementada autenticación multifactor (ni siquiera como opción), el rate limiting estaba configurado a 100 intentos/IP/hora (insuficiente para credential stuffing distribuido), y no monitorizaba credenciales comprometidas.

6. Recomendaciones: implementación urgente de MFA, rate limiting por cuenta (no solo por IP), integración con API de HIBP para bloquear contraseñas filtradas, y despliegue de sistema de detección de anomalías de comportamiento.

Credential Stuffing en el contexto español

Filtraciones que afectan a usuarios españoles

Varias brechas de datos han afectado significativamente a usuarios con cuentas en servicios españoles:

Sectores más atacados por credential stuffing en España

Recomendaciones específicas para el contexto español

Para particulares:

• Comprobar filtraciones en Have I Been Pwned (buscar con email y con número de teléfono español +34…).
• Activar la verificación en dos pasos en la Sede Electrónica (Cl@ve PIN o Cl@ve Permanente + SMS).
• No reutilizar la contraseña de banca online en ningún otro servicio.
• Consultar el INCIBE (017) ante cualquier sospecha de compromiso de cuentas.

Para empresas españolas:

• Cumplir con las obligaciones del RGPD en materia de seguridad de datos (artículo 32).
• Implementar MFA en todos los servicios que manejen datos personales.
• Monitorizar proactivamente filtraciones que afecten a empleados y clientes.
• Notificar a la AEPD en 72 horas si se detecta un ataque de credential stuffing exitoso que afecte a datos personales.

Preguntas frecuentes técnicas

¿El credential stuffing es ilegal si las credenciales son públicas?

Sí, es ilegal. Aunque las credenciales circulen públicamente en la dark web, utilizarlas para acceder a cuentas ajenas constituye acceso ilícito a sistemas informáticos (artículo 197 bis CP). El hecho de que las credenciales sean «públicas» no autoriza su uso. Es análogo a encontrar una llave perdida: que esté en el suelo no te autoriza a entrar en la casa.

¿Qué diferencia hay entre credential stuffing y account takeover?

El credential stuffing es la técnica (probar credenciales filtradas de forma automatizada). El account takeover (ATO) es el resultado (la cuenta queda bajo control del atacante). El credential stuffing es una de las múltiples técnicas que pueden llevar a un account takeover (otras incluyen phishing, SIM swapping, malware, etc.).

¿Es efectivo el CAPTCHA contra el credential stuffing?

Los CAPTCHAs son una barrera, pero no una solución completa. Los atacantes utilizan servicios de resolución de CAPTCHAs (2Captcha, Anti-Captcha, CapMonster) donde humanos o IA resuelven CAPTCHAs a un coste de 1-3 dólares por mil resoluciones. Para ser efectivo, el CAPTCHA debe combinarse con rate limiting, detección de bots y MFA.

¿Un gestor de contraseñas me protege completamente del credential stuffing?

Un gestor de contraseñas (Bitwarden, 1Password, KeePassXC) que genere contraseñas únicas y aleatorias para cada servicio elimina la reutilización de contraseñas, que es el fundamento del credential stuffing. Si cada servicio tiene una contraseña diferente, una filtración en un servicio no compromete los demás. Sin embargo, si el propio gestor de contraseñas es comprometido (como ocurrió con LastPass en 2022), todas las contraseñas quedan expuestas.

¿Las APIs también son vulnerables al credential stuffing?

Sí. Los endpoints de autenticación de APIs son frecuentemente más vulnerables que las interfaces web porque:

• Muchas APIs no implementan CAPTCHA.
• El rate limiting suele ser más permisivo en APIs.
• Las APIs móviles a veces no validan correctamente los tokens.
• Es más fácil automatizar peticiones contra APIs que contra interfaces web con JavaScript complejo.

Conclusión

El credential stuffing es uno de los ciberataques más prevalentes y efectivos de la actualidad, alimentado por miles de millones de credenciales filtradas y la persistente costumbre de los usuarios de reutilizar contraseñas. Su naturaleza automatizada permite a los atacantes comprometer miles de cuentas con un esfuerzo mínimo.

Desde la perspectiva forense, la investigación de ataques de credential stuffing requiere un análisis meticuloso de logs de autenticación, patrones de acceso y correlación con filtraciones conocidas. El perito informático puede determinar el vector de ataque, cuantificar el alcance del compromiso y evaluar si las medidas de seguridad implementadas eran adecuadas.

La prevención efectiva pasa por una combinación de medidas técnicas (MFA, rate limiting, detección de bots) y concienciación de usuarios (contraseñas únicas, gestores de contraseñas, monitorización de filtraciones). La adopción progresiva de Passkeys promete mitigar este vector de ataque en el futuro, pero mientras tanto, empresas y usuarios deben permanecer vigilantes.

Última actualización: 30 de marzo de 2026 Categoría: Ciberataques Código: CIB-060