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. La encuesta de seguridad online de Google y Harris Poll —3.000 adultos residentes en Estados Unidos, trabajo de campo de diciembre de 2018— la desglosa con precisión: un 52 % repite contraseña en varias (pero no todas) sus cuentas y un 13 % la repite en todas. El «65 %» que suele citarse es la suma de ambos grupos.

Para el atacante, el grupo que cuenta es ese 13 %: una sola credencial filtrada le abre la vida digital entera de la víctima. Por eso cada brecha convierte contraseñas antiguas en llaves de servicios que nunca fueron atacados.

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 el volcado de LinkedIn de 2021 —700 millones de perfiles según quien los vendía, 125,7 millones verificados por Have I Been Pwned—. La diferencia importa: la cifra que circula en los titulares es la del vendedor, y quien la cita en un informe está citando publicidad de un delincuente.
• 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:

(No se dan aquí importes por cuenta: los que circulan proceden de listas de precios de vendedores concretos, no de una medición, y varían entre foros y momentos. Lo que sostiene el análisis es el orden relativo, que es estable.) | Redes sociales | Suplantación, ingeniería social, spam | 5-100 EUR | | Cloud/SaaS | Acceso a datos corporativos, ransomware | 1 000-50 000 EUR | | VPN corporativa | Punto de entrada a red interna | 5 000-100 000 EUR |

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

• 53.300 millones de registros de identidad distintos recapturados por SpyCloud solo en 2024, un 22 % más que en 2023. ⚠️ Figuraban aquí «24.000+ millones de credenciales filtradas circulando en la dark web», atribuidos a SpyCloud: son de una edición anterior de su informe y además cambian la unidad —un registro de identidad no es un par usuario-contraseña— y el verbo: SpyCloud dice lo que recaptura, no lo que circula.
• 34 % de los intentos de login en la plataforma de identidad de Okta son credential stuffing (Okta, State of Secure Identity; edición sin cotejar).
• 193 000 millones de intentos de credential stuffing detectados en 2020 solo por Akamai.
• Tasa de éxito: es baja por definición —el ataque funciona por volumen, no por acierto—, pero no se da un rango: las horquillas que circulan no identifican muestra, sector ni periodo, y varían con la calidad del combo list y con las defensas del servicio atacado.
• ⚠️ Figuraba aquí un «coste medio de 6 millones de dólares anuales por credential stuffing, según el Ponemon Institute», sin enlace ni año. El Ponemon publica estudios de coste por tipo de ataque, así que el dato es de los que sí produce; pero una cifra de coste sin edición ni enlace no se puede contrastar, y el propio nombre —«coste medio por incidente… anuales»— mezcla dos unidades distintas.

Brechas de datos que alimentan el credential stuffing

Estadísticas sobre reutilización de contraseñas

Todas salen de la misma fuente, y su alcance conviene leerlo antes de usarlas: encuesta de seguridad online de Google y Harris Poll, 3.000 adultos residentes en Estados Unidos, campo de diciembre de 2018. Es una muestra estadounidense y de consumo: no es española, no es corporativa y ya no es reciente.

• 52 % reutiliza la misma contraseña en varias (pero no todas) sus cuentas; 13 % la reutiliza en absolutamente todas. La suma de ambos es el «65 %» de uso corriente.
• 35 % usa una contraseña distinta en cada cuenta.
• Solo el 24 % utiliza un gestor de contraseñas, «pese a que muchos dicen necesitar una forma mejor de llevar la cuenta de sus contraseñas».
• 55 % sabe definir correctamente qué es un gestor de contraseñas, y solo el 32 % define bien los tres términos que se le preguntan (phishing, gestor y verificación en dos pasos).

⚠️ Figuraba aquí un «59 % incluye información personal en sus contraseñas» sin fuente propia, rodeado de cifras que sí la llevaban: por vecindad se leía como de Google/Harris Poll. En esa encuesta el 59 % mide otra cosa —quienes creen que sus cuentas están más seguras que las del usuario medio—. Y donde se escribía «23 % usa gestor de contraseñas», la fuente dice 24 %.

Casos reales de Credential Stuffing

Zoom (abril 2020)

Durante la pandemia de COVID-19 circularon en foros credenciales de Zoom obtenidas por credential stuffing. Las cifras concretas que suelen citarse —500.000 cuentas, 0,002 dólares por unidad— proceden de un informe que no se ha podido abrir para comprobarlas, así que no se reproducen aquí. Lo que sí consta y basta para el argumento: Zoom no sufrió una brecha propia: los atacantes utilizaron credenciales filtradas de otros servicios.

Impacto forense:

• Lo que Zoom sí hizo público es que comprueba las credenciales aparecidas en brechas externas y fuerza el restablecimiento de las coincidentes. El inventario exacto de campos expuestos que circula no está acreditado.
• 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)

Se documentó el hallazgo de una base de datos Elasticsearch expuesta con credenciales de Spotify validadas mediante credential stuffing. Las cifras que acompañan al caso —350.000 credenciales, 72 GB— proceden de un informe que no se ha podido abrir para verificarlas, así que no se dan aquí como dato. El patrón sí es el relevante: 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.
• Puntos del programa de fidelización VIPeak.

La notificación oficial remitida al Departamento de Justicia de California es explícita en lo que no quedó expuesto: el atacante «was not able to view your payment card number, expiration date, nor your CVV». Los «números de tarjeta parcialmente visibles» que suelen citarse no figuran en la notificación, y el programa se llamaba VIPeak, no 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. Los valores que siguen son orientativos y deben calibrarse contra la línea base del propio sistema: no proceden de un estudio que los valide en servicios heterogéneos, y un corte aislado nunca es prueba pericial por sí mismo —una tasa de fallos alta puede deberse a un despliegue defectuoso, y una baja no descarta un ataque bien dosificado—.

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 249 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:

• Art. 197 bis 1 CP: el acceso con credenciales ajenas es acceso no autorizado aunque las credenciales sean técnicamente válidas, porque el tipo castiga acceder «sin autorización» y «vulnerando las medidas de seguridad» — y usar la contraseña de otro sin su consentimiento es justamente sortear la medida, no cumplirla.
• Art. 197.1 CP: apoderarse de los mensajes de correo de otro para vulnerar su intimidad; y art. 197 bis si el acceso al sistema se logra vulnerando sus medidas de seguridad, que es lo que hace el relleno de 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 concretos— que se compran hechas. Los precios que circulan no proceden de una medición y varían por foro y momento, así que no se reproducen: lo relevante es que existe un mercado, es decir, que atacar un servicio concreto no exige saber programar.
• Los servicios de resolución de CAPTCHA permiten automatizar ese paso a escala, lo que explica por qué el CAPTCHA por sí solo no detiene la campaña.

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

Se atribuye a los atacantes el uso de IA para las tres cosas que siguen. No se ha localizado una fuente primaria que lo documente como práctica observada, así que se enuncian como capacidades técnicamente plausibles y no como hechos medidos:

• 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)

Escenario ilustrativo con datos sintéticos

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

# Una tasa de éxito baja frente a un volumen enorme de intentos es el patrón
# característico. El porcentaje concreto no es un umbral: hay que compararlo
# con la línea base del propio sistema, no con una cifra de referencia.
# (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:

| Iberdrola | 2022 | 1,3 millones de clientes | Datos personales de clientes energéticos | | Banco Santander | 2024 | Datos de clientes de España, Chile y Uruguay | Información bancaria parcial | | Ticketmaster | 2024 | 560 millones de registros globales | Usuarios españoles con entradas compradas | | Collection #1-5 | 2019 | 2 200 millones de emails | Porcentaje significativo de .es y .com de españoles |

Sectores expuestos y qué busca el atacante en cada uno

(No se presenta como un ranking: ordenar sectores por prevalencia exige incidentes clasificados, periodo y denominador, y no hay serie publicada para España que lo permita.)

(Esta tabla llevaba una columna de «porcentaje de ataques» por sector cuyos valores sumaban exactamente 100. Se retira: no hay ningún organismo que publique el reparto sectorial de los ataques —ni el INCIBE ni el CCN-CERT desglosan sus incidentes por sector, como este mismo sitio explica en otros artículos—, y un reparto que suma 100 clavado delata que se construyó, no que se midió. Lo que sí se sostiene es el orden y el motivo: por qué cada sector resulta atractivo, que es lo que permite anticipar el riesgo.)

Recomendaciones específicas para el contexto español

Para particulares:

• Comprobar filtraciones en Have I Been Pwned con la dirección de correo. (La búsqueda por número de teléfono no es una función general del servicio: se habilitó para brechas concretas, así que no debe darse por disponible.)
• 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. Sobre el riesgo de que el propio gestor sufra un incidente, conviene contarlo con precisión. En el de LastPass de 2022, la propia compañía indicó que la copia sustraída contenía campos «fully-encrypted», entre ellos los nombres de usuario y las contraseñas: no quedaron expuestas en claro. Lo que sí quedó expuesto fueron campos no cifrados como las URL de los sitios, y el riesgo real dependía de la fortaleza de la contraseña maestra y de los parámetros de derivación de clave. Es una diferencia importante: obliga a cambiar contraseñas por prudencia, no porque estuvieran a la vista.

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

Sí, y en algunos despliegues concretos ofrecen menos resistencia que la interfaz web. Conviene no generalizarlo —una API bien protegida no es más débil que una web mal protegida—, pero estas son las razones por las que suele ocurrir:

• 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: 18 de agosto de 2026 Categoría: Ciberataques Código: CIB-060