Credential stuffing

La entrada es una lista de pares, no un diccionario. Sale de los corpus de brechas que llevan años intercambiándose y republicándose, y cada vez más de registros de infostealer, que son distintos y más peligrosos: son credenciales sacadas del navegador de una máquina infectada, así que están al día, incluyen el sitio exacto al que pertenece cada una y muchas veces vienen con las cookies de sesión incluidas.

El atacante automatiza el acceso, reparte las peticiones por proxies residenciales para que las direcciones de origen parezcan clientes normales, rota los agentes de usuario y dosifica los intentos para que ninguna cuenta ni ninguna dirección destaque. Cuando hay un endpoint de API que acepta credenciales sin las comprobaciones de navegador que aplica el formulario web, se usa ese. Las trastiendas de aplicaciones móviles y las rutas de autenticación heredadas son las elecciones habituales.

La economía funciona por escala y por reutilización. La proporción de pares que aciertan es pequeña. La lista es enorme, el coste por intento es casi cero y una cuenta conseguida vale algo de inmediato: medios de pago guardados, saldos de fidelización, historial de pedidos para una llamada posterior convincente, o un buzón desde el que montar un business email compromise.

Lo que sigue a un acierto no suele ser el abuso inmediato. La cuenta se valida, se clasifica y se vende. Ese intervalo entre la toma y el uso es la razón de que el evento de acceso y el evento de fraude aparezcan con semanas de diferencia en los registros, y de que los equipos que investigan el fraude nunca miren lo bastante atrás para encontrar la causa.

La defensa que falla con más regularidad es el bloqueo de cuenta, porque es un control pensado para otro ataque. El stuffing no prueba muchas contraseñas contra una cuenta; prueba una contraseña contra muchas cuentas. Los contadores por cuenta no saltan nunca. Peor todavía: un atacante que quiera hacer daño en vez de entrar puede usar el bloqueo a propósito, y el incidente lo absorbe el servicio de atención.

El segundo fallo es la cobertura. Un equipo fortifica el acceso web, y la trastienda móvil, el endpoint heredado, la integración con el partner y el flujo de restablecimiento de contraseña aceptan credenciales sin ninguna de esas protecciones. En nuestros proyectos buscamos primero la segunda puerta: existe en casi todos los parques y suele ser la que no tiene ningún límite de peticiones.

El tercero es que todo lo que un atacante necesita para pasar desapercibido se puede alquilar. Las redes de proxies residenciales dejan el bloqueo por dirección casi inservible, y hay servicios para resolver los desafíos que debían demostrar que había un humano detrás. Cualquier control que dependa de que la petición tenga mal aspecto es un control con precio de compra.

El cuarto es el que decide si el stuffing importa o no: cuánto vale la cuenta una vez tomada. Cuando un acceso correcto da acceso inmediato a medios de pago guardados y a una función de cambio de dirección sin volver a autenticar, una credencial es un fraude. Cuando las acciones sensibles exigen una comprobación nueva, esa misma credencial es una alerta.

Los tres se agrupan como ataques a contraseñas y se defienden como si fueran lo mismo. Tienen entradas distintas, firmas distintas y contramedidas distintas.

La consecuencia para el defensor es que los tres hay que vigilarlos a niveles de agregación distintos. La fuerza bruta se ve por cuenta. El password spraying solo se ve contando entre cuentas dentro de una ventana de tiempo. El stuffing solo se ve contando la tasa de fallo por origen y por campaña. Una vigilancia que solo cuente fallos por cuenta ve el primero y se pierde los otros dos por completo.

Confiar en el bloqueo de cuenta. Ni salta, ni deja de ser en sí mismo una primitiva de denegación de servicio.

Bloquear por dirección. Las bolsas de proxies residenciales rotan por direcciones legítimas de consumidores. Bloquear por dirección bloquea a tus clientes.

Dar por hecho que el MFA lo cierra. Cierra la mayor parte, y aun así los códigos y las aprobaciones por notificación se pueden retransmitir, y el ataque se va por las rutas donde no se exige. La cobertura de la exigencia importa más que el factor elegido.

Imponer reglas de complejidad en vez de comprobar la reutilización. Las reglas empujan a los usuarios hacia transformaciones predecibles. Comprobar la contraseña propuesta contra un corpus de credenciales filtradas ataca el mecanismo de verdad.

No avisar al usuario. Una notificación de acceso desde un dispositivo nuevo, y de cambio de correo o de datos de pago, convierte una toma silenciosa en una llamada a atención al cliente, que es un desenlace mucho mejor que una devolución de cargo.

Comprueba las credenciales contra corpus de filtraciones conocidas en el alta, en el cambio de contraseña y, si la plataforma lo permite, de forma periódica para las cuentas existentes. Eso ataca el mecanismo de forma directa y no sus síntomas. Cuando se sepa que la credencial de una cuenta está expuesta, fuerza el cambio en vez de anotar una puntuación de riesgo.

Despliega factores ligados al origen en las cuentas que tienen valor, y haz que la exigencia sea uniforme en todas las rutas de autenticación, incluidas las trastiendas móviles y cualquier endpoint heredado. Un parque con autenticación fuerte en la web y una API desnuda no está protegido.

Después, haz que la cuenta valga menos. Vuelve a autenticar antes de cambiar el correo, el teléfono, los datos de pago o la dirección de entrega, y avisa al usuario por otro canal cuando cambie cualquiera de los cuatro. Casi toda la pérdida de una toma de cuenta sale de esas cuatro operaciones, y ponerles puerta una a una es barato.

Aplica rate limiting al nivel de campaña y no por cuenta: tasa de fallo por origen, por rango de direcciones, por huella de dispositivo, por agente de usuario. Y vigila la forma de una tanda de stuffing en vez del volumen a secas. La señal más clara es una proporción anómala: miles de intentos con una tasa de fallo casi total, repartidos lo bastante fino como para que no salte ningún contador. Esa proporción no es el aspecto del tráfico normal.

Probamos la superficie de autenticación en vez de lanzar una campaña de stuffing real contra producción. Las preguntas son qué endpoints aceptan credenciales, qué protecciones aplica cada uno, si las respuestas distinguen un usuario válido de uno inválido, y a qué llega un acceso correcto antes de que haya ninguna comprobación más.

La evidencia es la petición y la respuesta de cada ruta, incluidas las diferencias de tiempo y de mensaje que permiten enumerar cuentas, y una demostración de lo que puede hacer sin volver a autenticarse una sesión obtenida con una credencial válida. Cuando usamos credenciales expuestas del cliente, salen de un trabajo de vigilancia que el propio cliente ha encargado, se manejan bajo las reglas del proyecto y no se reproducen en el informe.

La severidad se escribe contra la consecuencia, no contra la existencia de un formulario de acceso. Que falte el límite de peticiones en un endpoint con factores fuertes y con reautenticación en las acciones sensibles es un hallazgo moderado. Ese mismo hueco donde una sesión enseña de inmediato los datos de pago es un hallazgo grave.

La exposición de las credenciales en sí es otra pregunta, y es la que responde la vigilancia de credenciales filtradas de la organización: si los pares de tus usuarios ya están en las listas que se están reproduciendo.

¿En qué se diferencia el credential stuffing de la fuerza bruta? La fuerza bruta adivina contraseñas de una cuenta. El credential stuffing no adivina: cada par que prueba era válido en algún otro servicio. Por eso le basta un intento por cuenta, por eso el bloqueo no lo caza, y por eso la solución va de reutilización y no de robustez de la contraseña.

¿El MFA detiene el credential stuffing? Detiene la toma de cuenta en toda ruta donde se exija, que es la mayor mejora disponible de una sola pieza. No detiene los intentos, no ayuda en las rutas donde no se exige, y los códigos y las aprobaciones por notificación se pueden retransmitir con un proxy de phishing.

¿De dónde salen las listas de credenciales? De corpus históricos de brechas que circulan y se recombinan, y de registros de infostealer de máquinas infectadas. El segundo tipo hace más daño porque las credenciales están al día y vienen etiquetadas con el servicio exacto al que pertenecen.

¿Se puede detectar si el atacante va despacio y repartido? Con contadores por cuenta, no. Se detecta agregando: tasa de fallo por origen y por rango, aparición repentina de muchos dispositivos nuevos, y accesos correctos sin historial de sesión previo. El nivel de campaña es el único nivel en el que el patrón existe.