Account Takeover (ATO) - Kontoübernahme

Account Takeover (ATO) is one of the most common and economically damaging types of attacks: Attackers take over legitimate user accounts and misuse them for fraud, data breaches, or as a point of entry for further attacks. Unlike exploits of technical vulnerabilities, ATO often does not require direct system vulnerabilities—attackers use leaked credentials, social engineering, or weak authentication mechanisms.

ATO Attack Vectors

Method 1 - Credential Stuffing (most common method)

Starting Point: Millions of leaked username/password pairs

• HaveIBeenPwned: 14+ billion leaked credentials
• Dark web marketplaces: fresh leaks are sold

Attack:

1. Attacker purchases/downloads a credential list (10 million email+password pairs)
2. Automated testing against target login:
   • Tools: Sentry MBA, SNIPR, OpenBullet
   • Proxy rotation (to bypass IP blocking)
   • User-agent rotation
   • CAPTCHA solvers (external services)
3. Hit rate: 0.1–3% (1,000–30,000 successful logins out of 1 million!)
4. Successful logins are automatically monetized

Why so successful:

• Password reuse: 65%+ of users use the same passwords
• "I have nothing to hide" → same password for bank and forum

Method 2 - Brute Force and Password Spraying

• Brute Force: trying all possible passwords for an account - effective for short/weak passwords when there is no lockout
• Password Spraying (more subtle): using a few common passwords against many accounts ("Summer2024!" against 100,000 accounts), avoids triggering lockouts (1–3 attempts per account), effective since 2–5% of users use trivial passwords

Method 3 - Phishing + MFA Bypass (AiTM)

> MFA alone does not protect against modern phishing!

Adversary-in-the-Middle (AiTM):

1. Attacker sends phishing email with link to: login-microsoft.evil-domain.com
2. evil-domain.com proxies microsoft.com (via Evilginx/Modlishka)
3. Victim enters credentials + MFA code (believing they are on the real site)
4. Evilginx redirects to the real Microsoft site (login successful!)
5. Attacker steals: session cookie (POST-MFA!)
6. Session cookie = full access without MFA

Defense: Phishing-resistant MFA (FIDO2/WebAuthn/Passkeys) - FIDO2 is cryptographically bound to the domain, so a phishing proxy does not help.

Method 4 - Password Reset Vulnerabilities

Insecure Reset Flows:

• Reset code via SMS (SIM swapping possible!)
• Reset link sent to predictable email address (no token expiration)
• Security questions (mother’s maiden name = public OSINT)
• Host header injection: Reset link redirects to the wrong domain
• Short token (6 digits) → susceptible to brute-force attacks

Host header injection in password reset:

POST /reset-password
Host: evil.com
Body: email=victim@example.com

Server generates: https://evil.com/reset?token=SECRET - the email goes to victim@example.com, but the link points to evil.com (attacker-controlled), so the attacker receives the reset token.

Method 5 - Session Hijacking

Ways to obtain the session cookie:

• XSS: stored attack steals cookies (without HttpOnly!)
• MITM: HTTP (no HTTPS) → cookie in plain text
• Log files: session ID in URL → read logs
• Subdomain takeover + CORS: cookies from main domain

Method 6 - SIM Swapping

Social engineering against telecommunications providers:

1. Attacker calls the telco: "I want to port my SIM to a new card"
2. Using fake ID data + OSINT: Pass authentication
3. All SMS messages (including MFA codes) go to the attacker’s SIM
4. SMS-based 2FA = completely bypassed

ATO Detection

1. Impossible Travel

Login from Germany at 8:00 AM → Login from Brazil at 8:05 AM - 5 minutes = physically impossible. Alert: parallel sessions from different continents.

SELECT * FROM logins WHERE user_id = ?
  AND timestamp > NOW() - INTERVAL 10 MINUTE;
-- Multiple countries in 10 minutes? → Suspicious Login Alert!

2. Device Fingerprinting Anomaly

• Browser fingerprint (User-Agent, screen resolution, plugins) changed
• New IP + new device after years of the same setup
• Suspicious: Login from Tor exit node, VPN, data center IP

3. Velocity Checks (Credential Stuffing)

• 100+ logins in 1 minute from 1 IP → Blocking + Alert
• Many logins with incorrect credentials → Brute Force Detection
• Many accounts tried with the same password → Password spraying

4. Behavioral anomalies after login

• Password changed < 5 minutes after login (attacker secures account)
• Email address changed (attacker permanently takes over account)
• Unusual API calls (mass data export, admin functions)
• Login + immediate payment to a new address

5. Multi-source correlation (SIEM)

• Successful login after 50 failed attempts
• Session from Country X + simultaneous genuine session by the user in Country Y
• Account login 1 hour after a known credential leak involving this user

Protective measures

1. Multi-factor authentication (MANDATORY)

• FIDO2/WebAuthn/Passkeys: phishing-resistant (recommended!)
• TOTP (Google Authenticator, Authy): better than SMS
• SMS/Email: weak (SIM swap, phishing)
• No 2FA = an invitation to credential stuffing

2. Password Policies

• Minimum 12 characters (not 8!)
• Check against known leaks: HIBP API
• NEVER use security questions (OSINT)
• Recommend a password manager (do not reuse passwords)

3. Rate Limiting and Lockout

• Login: max 5–10 attempts per account in 15 minutes
• Password spraying: IP-level limits + user-level limits
• No permanent lockout (DoS!): temporary lockout + CAPTCHA
• Progressive delays: 1s → 2s → 4s → 8s...

4. Bot Detection

• CAPTCHA after failed attempts (reCAPTCHA v3, hCaptcha)
• JavaScript challenge (headless browser detection)
• Device fingerprinting (FingerprintJS)
• IP reputation (AbuseIPDB integration)
• Behavioral biometrics: typing speed, mouse movement

5. Session Security

• Short session lifetime (max. 24h, idle: 30min)
• Session invalidation upon password/email change
• Terminate all active sessions upon compromise
• HttpOnly + Secure + SameSite=Strict for session cookies
• Session ID in URL: NEVER

6. Password Reset Hardening

• Token min. 128-bit entropy (not 6 digits!)
• Token expiration: max. 15 minutes
• Single-use: Invalidate token after use
• No host header redirect (hardcode domain!)
• Reset via authenticator app (not just email/SMS)

7. Monitoring and Response

• Impossible Travel → automatic re-authentication
• Unknown device → confirmation email to registered address
• Suspicious login → user notification (push/email)
• ATO confirmed → immediate session invalidation + inform user