Rate Limit Bypass

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Rate limit bypass techniques

Exploring Similar Endpoints

Se deben intentar ataques de fuerza bruta en variaciones del endpoint objetivo, como /api/v3/sign-up, incluyendo alternativas como /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up, etc.

Incorporating Blank Characters in Code or Parameters

Insertar bytes en blanco como %00, %0d%0a, %0d, %0a, %09, %0C, %20 en código o parámetros puede ser una estrategia útil. Por ejemplo, ajustar un parámetro a code=1234%0a permite extender los intentos mediante variaciones en la entrada, como añadir caracteres de nueva línea a una dirección de email para eludir las limitaciones de intentos.

Manipulating IP Origin via Headers

Modificar los headers para alterar el origen IP percibido puede ayudar a evadir el rate limiting basado en IP. Headers como X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host, incluyendo el uso de múltiples instancias de X-Forwarded-For, pueden ajustarse para simular solicitudes desde diferentes IPs.

X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Host: 127.0.0.1
X-Forwared-Host: 127.0.0.1

# Double X-Forwarded-For header example
X-Forwarded-For:
X-Forwarded-For: 127.0.0.1

Cambiar otros encabezados

Se recomienda alterar otros encabezados de la solicitud, como el user-agent y las cookies, ya que también pueden usarse para identificar y rastrear patrones de peticiones. Cambiar estos encabezados puede evitar el reconocimiento y el seguimiento de las actividades del solicitante.

Aprovechar el comportamiento de API gateways

Algunas pasarelas de API están configuradas para aplicar rate limiting basándose en la combinación de endpoint y parámetros. Variando los valores de los parámetros o añadiendo parámetros no significativos a la solicitud, es posible eludir la lógica de rate-limiting de la pasarela, haciendo que cada petición parezca única. Por ejemplo /resetpwd?someparam=1.

Iniciar sesión en tu cuenta antes de cada intento

Iniciar sesión en una cuenta antes de cada intento, o antes de cada conjunto de intentos, puede reiniciar el contador de rate limit. Esto es especialmente útil al testear funcionalidades de login. Utilizar un Pitchfork attack en herramientas como Burp Suite, para rotar credenciales cada pocos intentos y asegurarse de marcar ‘follow redirects’, puede reiniciar eficazmente los contadores de rate limit.

Utilizar redes de proxies

Desplegar una red de proxies para distribuir las solicitudes entre múltiples direcciones IP puede eludir eficazmente los rate limits basados en IP. Al enrutar el tráfico a través de distintos proxies, cada petición aparenta originarse desde una fuente diferente, diluyendo la eficacia del rate limit.

Dividir el ataque entre diferentes cuentas o sesiones

Si el sistema objetivo aplica rate limits por cuenta o por sesión, distribuir el ataque o la prueba entre múltiples cuentas o sesiones puede ayudar a evitar la detección. Este enfoque requiere gestionar múltiples identidades o tokens de sesión, pero puede distribuir eficazmente la carga para mantenerse dentro de los límites permitidos.

Seguir intentándolo

Ten en cuenta que incluso si hay un rate limit en vigor, deberías intentar comprobar si la respuesta es diferente cuando se envía el OTP válido. En esta publicación, el bug hunter descubrió que incluso si se desencadena un rate limit después de 20 intentos fallidos respondiendo con 401, si se enviaba el válido se recibía una respuesta 200.

Abusar de HTTP/2 multiplexing & request pipelining (2023-2025)

Las implementaciones modernas de rate–limiter frecuentemente cuentan TCP connections (or even individual HTTP/1.1 requests) en lugar del number of HTTP/2 streams que contiene una conexión. Cuando se reutiliza la misma conexión TLS, un atacante puede abrir cientos de streams paralelos, cada uno llevando una solicitud separada, mientras que la gateway solo descuenta one request de la cuota.

# Send 100 POST requests in a single HTTP/2 connection with curl
seq 1 100 | xargs -I@ -P0 curl -k --http2-prior-knowledge -X POST \
-H "Content-Type: application/json" \
-d '{"code":"@"}' https://target/api/v2/verify &>/dev/null

Si el limitador protege solo /verify pero no /api/v2/verify, también puedes combinar path confusion con HTTP/2 multiplexing para un brute-forcing de OTP o credenciales a velocidad extremadamente alta.

🐾 Consejo: PortSwigger’s Turbo Intruder soporta HTTP/2 y te permite ajustar maxConcurrentConnections y requestsPerConnection para automatizar este ataque.

GraphQL aliases y operaciones por lotes

GraphQL permite al cliente enviar varias consultas o mutaciones lógicamente independientes en una sola solicitud prefijándolas con aliases. Dado que el servidor ejecuta cada alias pero el limitador suele contar solo una solicitud, esto es un bypass fiable para la limitación de intentos en login o restablecimiento de contraseña.

mutation bruteForceOTP {
a: verify(code:"111111") { token }
b: verify(code:"222222") { token }
c: verify(code:"333333") { token }
# … add up to dozens of aliases …
}

Observa la respuesta: exactamente un alias devolverá 200 OK cuando se acierte el código correcto, mientras que los demás están rate-limited.

La técnica fue popularizada por la investigación de PortSwigger sobre “GraphQL batching & aliases” en 2023 y ha sido responsable de muchos pagos recientes de bug-bounty.

Abuso de batch o bulk REST endpoints

Algunas APIs exponen endpoints auxiliares como /v2/batch o aceptan un array of objects en el cuerpo de la petición. Si el limitador se coloca solo frente a los endpoints legacy, agrupar múltiples operaciones dentro de una única solicitud bulk puede eludir por completo la protección.

[
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"123"}},
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"456"}}
]

Timing the sliding-window

Un limitador clásico token-bucket o leaky-bucket resets en un límite de tiempo fijo (por ejemplo, cada minuto). Si se conoce la ventana (p. ej., mediante mensajes de error como X-RateLimit-Reset: 27), envía el número máximo permitido de requests justo antes de que el bucket se reinicie y, acto seguido, lanza otra ráfaga completa.

|<-- 60 s window ‑->|<-- 60 s window ‑->|
######                 ######

Esta simple optimización puede más que duplicar tu rendimiento sin tocar ninguna otra técnica de bypass.

Actualizar a WebSockets / gRPC streaming después del handshake

Muchos rate-limiters en el edge solo inspeccionan la solicitud HTTP inicial. Una vez que la conexión se actualiza a WebSocket (HTTP 101) o a gRPC bidirectional streaming, los mensajes posteriores a menudo evaden los contadores de request-per-second porque ya no son solicitudes HTTP separadas. La propia documentación de Cloudflare señala que solo la solicitud de upgrade inicial está sujeta a las reglas de WAF/rate-limiting; los frames enviados después son opacos.

Flujo de trabajo práctico:

# Flood 1,000 OTP guesses through a single WebSocket connection
seq -w 000000 000999 | websocat -n ws://target.tld/api/verify-ws

# gRPC streaming: send multiple Verify requests in one stream
grpcurl -d @ -plaintext target.tld:50051 service.VerifyOTP/Stream <<'EOF'
{ "code": "111111" }
{ "code": "222222" }
{ "code": "333333" }
EOF

Si el endpoint de login/OTP expone tanto variantes HTTP como WebSocket/gRPC, establece primero el canal actualizado y luego spray codes dentro de esa única conexión para evadir los per-request throttles.

Explotando contadores PoP‑sharded de CDN

Algunas CDNs fragmentan los contadores de rate-limit por data center/PoP en lugar de globalmente. Cloudflare indica explícitamente que los contadores no se comparten entre data centers. Al enrutar peticiones a través de nodos de egress en muchas regiones (residential proxy pools, anycast VPNs, o cloud VMs asignadas a distintos continentes), multiplicas el throughput permitido: cada PoP mantiene un bucket independiente para la misma key.

Quick and dirty layout using open proxies (example with proxychains + a country‑rotating list):

for p in $(cat proxies.txt); do
HTTPS_PROXY=$p curl -s -X POST https://target/api/login -d @payload.json &
done
wait

Asegúrate de que la clave del limitador no sea por cuenta; de lo contrario rota también los IDs de usuario / tokens de sesión.

Herramientas

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: Herramienta de fuzzing que soporta la aleatorización de headers, listas de palabras por fragmentos y rotación round-robin de proxies.
  • https://github.com/ustayready/fireprox: Crea automáticamente endpoints desechables en AWS API Gateway para que cada petición se origine desde una IP diferente — perfecto para derrotar la limitación basada en IP.
  • Burp Suite – IPRotate + extension: Usa un conjunto de proxies SOCKS/HTTP (o AWS API Gateway) para rotar la IP de origen de forma transparente durante ataques Intruder y Turbo Intruder.
  • Turbo Intruder (BApp): Motor de ataque de alto rendimiento que soporta multiplexación HTTP/2; ajusta requestsPerConnection a 100-1000 para colapsar cientos de peticiones en una sola conexión.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks