Resumen: robo de credenciales
- Robo frente a stuffing: el robo es cómo los atacantes consiguen credenciales válidas. El stuffing es lo que hacen después. Señales distintas, pilas de detección distintas.
- El punto ciego del MFA: el MFA estándar no detiene las cuatro técnicas dominantes: páginas de phishing, proxies AiTM tipo Evilginx, scripts de terceros comprometidos y malware infostealer.
- Tu propia página de acceso: tu superficie peor defendida es tu propia página de acceso. Un script de terceros comprometido lee el formulario mientras tu usuario escribe, y los controles del servidor nunca lo ven.
¿Poco tiempo? Consulta la detección de apropiación de cuentas de cside. Cubre todo lo de abajo en un solo despliegue.
El robo de credenciales no es credential stuffing (y la diferencia importa)
Supón que un proveedor antifraude te dice que «detiene los ataques de credenciales». Pregúntale cuál de las dos mitades, robo o stuffing. Si no sabe responder con claridad, te está vendiendo limitación de peticiones disfrazada de plataforma de amenazas.
El robo está en la parte alta del embudo. Los atacantes recopilan credenciales válidas. El stuffing está en la parte baja. Los atacantes prueban esas credenciales contra sitios objetivo. Una sola operación de robo alimenta miles de campañas de stuffing. Una sola credencial robada puede probarse contra cualquier comercio de internet.
Las señales de detección son distintas:
- El robo aparece en TU sitio como actividad sospechosa de scripts en la página de acceso, o como exfiltración de datos hacia un dominio de terceros desconocido.
- El stuffing aparece en TU sitio como intentos de acceso masivos, velocidad por IP y patrones distribuidos de bajo perfil.
La limitación de peticiones detiene el stuffing. No toca el robo. Si tu única defensa frente a ataques de credenciales es un límite de peticiones en /api/login, estás cazando la segunda mitad del ataque y dejando la primera sin oposición.
Cuatro técnicas de robo de 2026 que tu MFA no detiene
1. Páginas de phishing (siguen siendo el vector número uno)
Los atacantes registran un dominio parecido (consulta nuestro artículo sobre ataques homográficos y el truco de los caracteres cirílicos), clonan el HTML de tu acceso y dirigen tráfico por SMS o correo. El usuario escribe su contraseña en una página idéntica a la tuya. La credencial va al atacante.
El MFA estándar reduce el valor de la contraseña robada, pero no a cero. Si el usuario reutiliza esa contraseña en otros sitios (alrededor del 65 % lo hace, según todos los estudios de reutilización), el atacante acaba de conseguir acceso a su correo, su banco o su conjunto de SaaS.
2. Adversario en el medio tipo Evilginx (AiTM)
Evilginx es un framework de phishing de código abierto que ejecuta un proxy inverso entre la víctima y la página de acceso real. La víctima escribe su contraseña. Evilginx la reenvía al sitio real. El sitio real devuelve la petición de MFA. La víctima resuelve el MFA. Evilginx lo reenvía. El sitio real devuelve la cookie de sesión. Evilginx roba la cookie de sesión.
Esto derrota al MFA por TOTP, OTP por SMS y notificación push. No derrota a las passkeys ni a las llaves hardware FIDO2, porque estas se vinculan criptográficamente al dominio de origen y se niegan a autenticar en un sitio proxificado.
Si tu base de usuarios no usa MFA resistente al phishing en 2026, los ataques de clase Evilginx salen tremendamente baratos para los atacantes. El framework es de código abierto, las plantillas de phishing son mercancía común y la recompensa es saltarse toda implementación de MFA que no sea FIDO2.
3. Script de terceros comprometido en tu propia página de acceso
Este es el que la mayoría de defensas pasa por alto. Tu página de acceso está limpia. Tu código de servidor está limpio. Tus certificados son válidos.
Pero tu página de acceso carga scripts. Google Tag Manager. Un widget de chat. Analítica. Tests A/B. Cualquiera de ellos, o cualquiera de sus dependencias transitivas, puede ser actualizado por su propietario sin avisarte. Cuando uno se ve comprometido, ya sea por un ataque a la cadena de suministro como Polyfill[.]io (más de 490.000 sitios afectados en 2024) o por un cambio en una regla del gestor de etiquetas, el script comprometido pasa a ejecutarse en el mismo contexto JavaScript que tu formulario de acceso.
Puede leer los campos del formulario. Puede añadir un listener al evento de envío. Puede enviar las credenciales a un dominio controlado por el atacante antes incluso de que tu endpoint de acceso vea la petición.
Tu WAF no ve esto. Tus registros de servidor no ven esto. Tu SIEM no ve esto. El único lugar donde la exfiltración es visible es dentro de la sesión del navegador del visitante, en el momento en que ocurre.
4. Malware infostealer en el dispositivo del usuario
Los infostealers como RedLine, Raccoon y LummaC2 extraen contraseñas guardadas de los navegadores, cookies de los almacenes de sesión locales y tokens MFA de las apps de autenticación. Una vez instalados en el dispositivo de la víctima, se ejecutan de forma continua y envían las credenciales recopiladas a la infraestructura del atacante.
No puedes detener este ataque desde tu lado del cable. Lo que SÍ puedes hacer es detectar el uso posterior: una autenticación que tiene éxito desde una huella de dispositivo o un origen geográfico incoherentes con el historial de la cuenta.
El conjunto de datos que los atacantes usan de verdad en 2026
RockYou2024 es el corpus de referencia. Publicado a mediados de 2024, contiene unos 10.000 millones de contraseñas únicas en texto plano. Un agregado de todas las recopilaciones de filtraciones relevantes anteriores, deduplicado y normalizado. Cualquier recopilación previa (Collections #1 a #5, Pwned Passwords de Have I Been Pwned, las distintas filtraciones «COMB») es un subconjunto.
Los atacantes no lanzan 10.000 millones de credenciales contra tu acceso. Eso dispararía cualquier límite de peticiones. Lo que hacen es:
- Filtrar a las credenciales que coinciden con tu dominio (por los metadatos de la filtración de origen)
- Filtrar a las credenciales creadas en los últimos 24 meses (más probabilidad de seguir siendo válidas)
- Filtrar a las contraseñas que superan heurísticas básicas de fortaleza (los atacantes asumen que el usuario reutilizó una contraseña «real», no
password123) - Probar el subconjunto filtrado en lotes lentos y distribuidos desde IP residenciales
Por eso la reputación de IP no te sirve para cazar el credential stuffing moderno. La IP es la de un ISP residencial. La velocidad por IP son 2 o 3 intentos por hora. Solo la correlación entre cuentas lo detecta.
Qué detecta realmente el robo de credenciales
Cuatro fuentes de señal, por orden de retorno.
1. Monitorización en sesión de tu página de acceso
La única defensa que caza la técnica número tres (script de terceros comprometido) es observar qué leen realmente los scripts del formulario de acceso en la sesión del navegador de un usuario real. Esto es lo que hace la plataforma de seguridad del lado del cliente de cside. Un sensor propio observa las lecturas del DOM, el acceso a campos del formulario y la actividad de red saliente en cada sesión real, y marca cualquier script que toque los campos de credenciales sin estar en la lista autorizada.
Esto no puedes montártelo por tu cuenta como algo puntual. Necesitas observación continua en todas las sesiones reales, porque el atacante solo activará la exfiltración en un subconjunto de visitantes (geografía concreta, navegador concreto, tipo de cuenta concreto) para esquivar los escáneres de detección.
2. Inteligencia de dispositivo en el acceso
En el endpoint de acceso, calcula una huella de dispositivo a partir de atributos del navegador, huella TLS o JA y cadencia de comportamiento. Compárala con el historial de dispositivos de la cuenta. Un dispositivo nuevo desde una geografía nueva intentando autenticarse es una señal fuerte de que algo va mal, ya venga de un AiTM tipo Evilginx o de un robo reciente por infostealer.
Nuestra introducción a la inteligencia de dispositivo recorre la pila de señales. La versión corta: más de 40 atributos del navegador combinados en un ID de dispositivo estable que sobrevive al borrado de cookies y a las ventanas privadas.
3. Consulta a Have I Been Pwned en el acceso (o mejor, en el registro)
Have I Been Pwned publica una API de consulta por rango que permite comprobar si una contraseña aparece en algún corpus de filtraciones conocido sin enviar la contraseña real (mediante prefijo SHA-1 con k-anonimato). Esto debería ser un paso en todo flujo de acceso por encima de cierta puntuación de riesgo.
Si un usuario se autentica con una contraseña que aparece en RockYou2024, trátalo como evidencia prima facie de robo. Fuerza un restablecimiento de contraseña y escala a MFA resistente al phishing en su siguiente acceso.
4. Correlación entre cuentas
La señal más fiable es que el mismo dispositivo, la misma huella o el mismo patrón de comportamiento intente autenticarse contra varias cuentas de tu plataforma en una ventana corta. La limitación por cuenta no lo ve. La limitación por IP tampoco, porque los proxies residenciales rotan cada 30 segundos. Solo la correlación de señales de dispositivo lo detecta.
Dónde sigue ayudando el MFA (y dónde no)
El MFA resistente al phishing (WebAuthn, llaves hardware FIDO2, passkeys) sí detiene los casos de página de phishing y de Evilginx. Si tu base de usuarios no lo tiene a finales de 2026, estás manteniendo un anacronismo.
Pero el MFA resistente al phishing no ayuda contra:
- Scripts de terceros comprometidos en tu propia página de acceso (el script comprometido lee el campo de contraseña sea cual sea el tipo de MFA)
- Malware infostealer en el dispositivo del usuario (el malware exfiltra la semilla de la passkey o la cookie de sesión tras la autenticación)
- Ataques de correlación entre cuentas (la credencial ya es válida; el MFA en el primer acceso no es el cuello de botella)
La detección por capas (MFA más monitorización en sesión más inteligencia de dispositivo más consulta a HIBP) es lo que cierra los cuatro huecos. No un control aislado.
Qué respondemos a quien pregunta si cside es «otro proveedor de MFA»
No lo somos. El MFA es lo que pasa en tu endpoint de acceso. cside es lo que pasa en la sesión del navegador, en los siete segundos entre que el usuario escribe su contraseña y pulsa enviar. Vemos los scripts que leen el formulario. Vemos las llamadas de red salientes. Vemos los intentos de exfiltración que nunca llegan a tus registros de servidor.
Si tu defensa se detiene en el endpoint de acceso, no estás viendo la técnica número tres. Ese es el caso de aproximadamente el 90 % de los accesos de comercio electrónico, fintech y SaaS en 2026. Arréglalo y cerrarás el mayor hueco desatendido de la cadena de ataque a credenciales.
Lecturas relacionadas
- Credential stuffing: cómo detectarlo y detenerlo en el acceso
- Qué es el fingerprinting de dispositivo: la guía definitiva de 2026
- Prevención del fraude por apropiación de cuentas: la guía completa de 2026
- Cómo Polyfill[.]io comprometió 490.000 sitios (ataque a la cadena de suministro del navegador)
- Ataques homográficos: el problema de аpple.com
