Account Takeover (ATO) - Kontoübernahme

Account Takeover (ATO) ist eine der häufigsten und wirtschaftlich schädlichsten Angriffsformen: Angreifer übernehmen legitime Nutzerkonten und missbrauchen sie für Betrug, Datenleckagen oder als Einstiegspunkt für weiterführende Angriffe. Im Gegensatz zu technischen Schwachstellen-Exploits erfordert ATO oft keine direkten Systemlücken - Angreifer nutzen geleakte Credentials, Social Engineering oder schwache Authentifizierungsmechanismen.

ATO-Angriffsvektoren

Methode 1 - Credential Stuffing (häufigste Methode)

Ausgangspunkt: Millionen geleakter Username/Passwort-Paare

• HaveIBeenPwned: 14+ Milliarden geleakte Credentials
• Dunkle Marktplätze: frische Leaks werden verkauft

Angriff:

1. Angreifer kauft/lädt Credential-Liste (10 Millionen E-Mail+Passwort)
2. Automatisiertes Testing gegen Ziel-Login:
   • Tool: Sentry MBA, SNIPR, OpenBullet
   • Proxy-Rotation (um IP-Blocking zu umgehen)
   • User-Agent-Rotation
   • CAPTCHA-Solver (externe Services)
3. Hit-Rate: 0.1-3% (1000-30000 erfolgreiche Logins aus 1 Million!)
4. Erfolgreiche Logins werden automatisiert monetarisiert

Warum so erfolgreich:

• Passwort-Wiederverwendung: 65%+ der Nutzer verwenden gleiche Passwörter
• “Ich hab ja nichts zu verbergen” → selbes Passwort für Bank und Forum

Methode 2 - Brute Force und Password Spraying

• Brute Force: alle Passwörter für einen Account ausprobieren - bei fehlendem Lockout effektiv für kurze/schwache Passwörter
• Password Spraying (subtiler): wenige häufige Passwörter gegen viele Accounts (“Sommer2024!” gegen 100.000 Accounts), vermeidet Lockout-Trigger (1-3 Versuche pro Account), effektiv da 2-5% der Nutzer triviale Passwörter verwenden

Methode 3 - Phishing + MFA-Bypass (AiTM)

MFA allein schützt nicht gegen modernes Phishing!

Adversary-in-the-Middle (AiTM):

1. Angreifer sendet Phishing-E-Mail mit Link zu: login-microsoft.evil-domain.com
2. evil-domain.com proxied microsoft.com (via Evilginx/Modlishka)
3. Opfer gibt Credentials + MFA-Code ein (glaubt auf echter Seite zu sein)
4. Evilginx leitet an echtes Microsoft weiter (Login erfolgreich!)
5. Angreifer stiehlt: Session-Cookie (POST-MFA!)
6. Session-Cookie = vollständiger Zugang ohne MFA

Verteidigung: Phishing-resistente MFA (FIDO2/WebAuthn/Passkeys) - FIDO2 ist kryptografisch an die Domain gebunden, ein Phishing-Proxy hilft daher nicht.

Methode 4 - Password-Reset-Schwachstellen

Unsichere Reset-Flows:

• Reset-Code via SMS (SIM-Swapping möglich!)
• Reset-Link zu vorhersagbarer E-Mail (kein Token-Ablauf)
• Sicherheitsfragen (Mutter Geburtsname = public OSINT)
• Host-Header-Injection: Reset-Link geht zu falscher Domain
• Kurzer Token (6 Ziffern) → brute-forcebar

Host-Header-Injection im Password-Reset:

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

Server generiert: https://evil.com/reset?token=SECRET - die E-Mail geht zu victim@example.com, der Link zeigt aber auf evil.com (Angreifer-kontrolliert), so erhält der Angreifer den Reset-Token.

Methode 5 - Session-Hijacking

Wege zum Session-Cookie:

• XSS: gespeicherter Angriff stiehlt Cookies (ohne HttpOnly!)
• MITM: HTTP (kein HTTPS) → Cookie im Klartext
• Log-Dateien: Session-ID in URL → Logs lesen
• Subdomain-Takeover + CORS: Cookies von Hauptdomain

Methode 6 - SIM-Swapping

Social Engineering gegen Telekommunikationsanbieter:

1. Angreifer ruft Telco an: “Ich möchte meine SIM auf neue Karte portieren”
2. Mit gefälschten Ausweis-Daten + OSINT: Authentifizierung bestehen
3. Alle SMS (inkl. MFA-Codes) gehen zur Angreifer-SIM
4. SMS-basierte 2FA = vollständig umgangen

ATO-Erkennung

1. Impossible Travel

Login aus Deutschland 08:00 Uhr → Login aus Brasilien 08:05 Uhr - 5 Minuten = physisch unmöglich. Alert: parallele Sessions aus verschiedenen Kontinenten.

SELECT * FROM logins WHERE user_id = ?
  AND timestamp > NOW() - INTERVAL 10 MINUTE;
-- Mehrere Länder in 10 Minuten? → Suspicious Login Alert!

2. Device-Fingerprinting-Anomalie

• Browser-Fingerprint (User-Agent, Screen-Resolution, Plugins) geändert
• Neue IP + neues Device nach Jahren gleichem Setup
• Verdächtig: Login von Tor-Exit-Node, VPN, Datacenter-IP

3. Velocity-Checks (Credential Stuffing)

• 100+ Logins in 1 Minute von 1 IP → Blocking + Alert
• Viele Logins mit falschen Credentials → Brute Force Detection
• Viele Accounts mit gleichem Passwort ausprobiert → Password Spraying

4. Verhaltensanomalien nach Login

• Passwort geändert < 5 Minuten nach Login (Angreifer sichert Account)
• E-Mail-Adresse geändert (Angreifer übernimmt Account dauerhaft)
• Ungewöhnliche API-Calls (Massendaten-Export, Admin-Funktionen)
• Login + sofortige Zahlung an neue Adresse

5. Multi-Source-Korrelation (SIEM)

• Login-Erfolg nach 50 fehlgeschlagenen Versuchen
• Session aus Land X + gleichzeitig echte Session des Users in Land Y
• Account-Login 1 Stunde nach bekanntem Credential-Leak dieses Users

Schutzmaßnahmen

1. Multi-Faktor-Authentifizierung (PFLICHT)

• FIDO2/WebAuthn/Passkeys: phishing-resistent (empfohlen!)
• TOTP (Google Authenticator, Authy): besser als SMS
• SMS/E-Mail: schwach (SIM-Swap, Phishing)
• Kein 2FA = Einladung zu Credential Stuffing

2. Passwort-Richtlinien

• Minimum 12 Zeichen (nicht 8!)
• Gegen bekannte Leaks prüfen: HIBP API
• NIEMALS Sicherheitsfragen (OSINT)
• Password Manager empfehlen (kein Passwort wiederverwenden)

3. Rate Limiting und Lockout

• Login: max 5-10 Versuche pro Account in 15 Minuten
• Password Spraying: IP-Level-Limits + User-Level-Limits
• Kein permanentes Lockout (DoS!): temporäres Lockout + CAPTCHA
• Progressive Delays: 1s → 2s → 4s → 8s…

4. Bot-Detection

• CAPTCHA nach Fehlversuchen (reCAPTCHA v3, hCaptcha)
• JavaScript-Challenge (Headless-Browser-Detection)
• Device Fingerprinting (FingerprintJS)
• IP-Reputation (AbuseIPDB-Integration)
• Behavioral Biometrics: Tipp-Geschwindigkeit, Mausbewegung

5. Session-Security

• Kurze Session-Lifetime (max. 24h, Idle: 30min)
• Session-Invalidation bei Passwort-/E-Mail-Änderung
• Alle aktiven Sessions bei Kompromittierung beenden
• HttpOnly + Secure + SameSite=Strict für Session-Cookies
• Session-ID in URL: NIEMALS

6. Password-Reset-Härtung

• Token min. 128-Bit Entropie (nicht 6-Ziffern!)
• Token-Ablauf: max. 15 Minuten
• Single-Use: Token nach Verwendung invalidieren
• Kein Host-Header-Redirect (Domain hardcoden!)
• Reset via Authenticator-App (nicht nur E-Mail/SMS)

7. Monitoring und Response

• Impossible Travel → automatische Re-Authentifizierung
• Unbekanntes Device → Bestätigungs-E-Mail an registrierte Adresse
• Suspicious Login → Nutzer-Benachrichtigung (Push/E-Mail)
• ATO bestätigt → sofortige Session-Invalidation + Nutzer informieren