Identitätsdiebstahl und Account Takeover: Angriffe und Schutzmaßnahmen

Account Takeover (ATO) ist der erste Schritt in den meisten erfolgreichen Cyberangriffen. Sobald ein Angreifer einen Account kontrolliert - besonders privilegierte Accounts - kann er sich lateral bewegen, Daten exfiltrieren und Ransomware deployen. Diese Angriffe zu verstehen ist der erste Schritt zur Prävention.

Account Takeover - Angriffsmethoden

Credential Stuffing

Funktionsweise:
  1. Angreifer kauft Datenbreach-Listen (Milliarden von Email/Passwort-Paaren)
  2. Automatisierte Tests gegen Ihre Login-Seiten
  3. Passwort-Wiederverwendung: gleiche Passwörter auf anderen Plattformen

Werkzeuge:
  OpenBullet / SentryMBA: automatisierte Credential-Stuffing-Tools
  Residential Proxies: rotieren IPs um Detection zu umgehen
  CAPTCHA-Bypass: 2Captcha, Anti-Captcha Services

Statistik:
  23 Milliarden Credential-Paare im Umlauf (Have I Been Pwned, 2024)
  85% der Nutzer wiederverwenden Passwörter (LastPass Survey 2023)

Erkennung:
  → Viele fehlgeschlagene Logins von einer IP / verschiedenen IPs
  → Logins aus ungewöhnlichen Geografien
  → Erfolgreicher Login nach 1000 fehlgeschlagenen Versuchen
  → Auffällig schnelle Login-Versuche (Bot-Timing)

Password Spraying

Funktionsweise:
  Statt viele Passwörter auf einen Account → ein Passwort auf ALLE Accounts
  Ziel: Account-Lockouts umgehen (Standard: 5-10 Versuche vor Lockout)

  Angriff:
    Account 1: Winter2024! → fehlgeschlagen
    Account 2: Winter2024! → fehlgeschlagen
    Account 3: Winter2024! → ERFOLG! (schwaches Passwort!)
    ...
    Warte 30 Minuten → nächste Runde mit "Spring2024!"

Warum gefährlich:
  → Lockout-Schwellen werden nie erreicht
  → Monatelang unentdeckt möglich
  → Besonders effektiv gegen AD-Environments

Beliebte Spray-Passwörter:
  Firmenname + Jahr: "AWARE7_2024!", "Mustermann24"
  Saisonale Passwörter: "Winter2024!", "Sommer2025#"
  Keyboard-Pattern: "Qwerty123!", "Password1"
  Default-Passwörter: "Welcome1", "Changeme1"

Erkennung:
  → Viele fehlgeschlagene Logins auf VERSCHIEDENE Accounts
  → Aber wenige Versuche pro Account (< Lockout-Threshold)
  → Regelmäßige Zeitintervalle (Bot-Pattern)
  → Azure AD Sign-In Logs: "Account Lockout" → Anzeichen

SIM-Swapping

Funktionsweise:
  1. Angreifer sammelt OSINT über Opfer (Name, Geburtsdatum, Adresse)
  2. Telefonanruf beim Mobilfunkanbieter: "Mein Handy kaputt"
  3. Social Engineering des Kundendienstes → SIM auf neue Karte übertragen
  4. Alle SMS für die Nummer → nun beim Angreifer
  5. "Passwort vergessen" → SMS-OTP kommt zum Angreifer
  6. Account übernommen!

Bekannte Opfer:
  → Twitter-CEO Jack Dorsey (2019): Twitter-Account gekapert
  → Krypto-Investoren: hunderte Millionen gestohlen

Warum Telefon-MFA unsicher ist:
  → SS7-Schwachstellen (Telefonetze): SIM-Swap nicht einzige Methode
  → SMS kann abgefangen werden
  → Daher: FIDO2/Authenticator-App statt SMS-OTP!

Prävention:
  → PIN/PUK beim Anbieter für SIM-Swap-Schutz aktivieren
  → Authenticator-App statt SMS-OTP (Google Authenticator, Microsoft Authenticator)
  → FIDO2-Hardware-Token für höchste Sicherheit (YubiKey)

MFA-Bypass-Techniken

Auch mit MFA können Accounts kompromittiert werden:

MFA Fatigue (Prompt Bombing):
  Angreifer hat Passwort → sendet MFA-Push-Anfragen
  → Opfer erhält 50+ Notifications in Folge
  → Genervtes Opfer drückt irgendwann "Approve"
  → Account übernommen!

  Realer Fall: Uber (2022) - MFA Bombing + Social Engineering
  Angreifer: "Hi, ich bin IT-Support, bitte bestätigen Sie die Anfrage"

Evilginx / Adversary-in-the-Middle (AiTM):
  Reverse-Proxy zwischen Opfer und echtem Service
  → Opfer sieht echte Login-Seite (Proxy leitet weiter)
  → Angreifer stiehlt Session-Cookie NACH erfolgreicher MFA
  → Session-Cookie = voller Zugriff ohne erneute MFA!

  Erkennung: Token Protection (Microsoft Conditional Access)
  → Session an Gerät binden (kein Cookie-Theft-Missbrauch)

OAuth-Consent-Phishing:
  → Gefälschte App beantragt OAuth-Permissions
  → Opfer klickt "Erlauben" → App hat Zugriff auf Mailbox
  → Kein Passwort nötig, kein MFA-Prompt!
  → Microsoft 365: Admin kann riskante Apps blockieren

Pass-the-Cookie / Token Theft:
  → Stealer-Malware stiehlt Browser-Session-Cookies
  → Angreifer importiert Cookie → eingeloggt ohne MFA
  → Bekannte Malware: Raccoon Stealer, Redline, Vidar

Gegenmaßnahmen für alle MFA-Bypasses:
  → Phishing-resistente MFA: FIDO2 / Passkeys (AiTM scheitert!)
  → Conditional Access: bekannte/konforme Geräte only
  → Anomalie-Erkennung: UEBA / Microsoft Identity Protection
  → Session-Token-Bindung an Gerät (Token Protection)

Schutzmaßnahmen: Identitätsbasierte Defense in Depth

Passwort-Härtung

# Active Directory: Passwort-Richtlinie prüfen
Get-ADDefaultDomainPasswordPolicy

# Fine-Grained Password Policy für privilegierte Konten
New-ADFineGrainedPasswordPolicy -Name "Admin-Policy" `
    -Precedence 10 `
    -MinPasswordLength 16 `
    -PasswordHistoryCount 24 `
    -ComplexityEnabled $true `
    -LockoutThreshold 3 `
    -LockoutObservationWindow "00:30:00" `
    -LockoutDuration "01:00:00" `
    -MaxPasswordAge "30.00:00:00"

Add-ADFineGrainedPasswordPolicySubject "Admin-Policy" -Subjects "Domain Admins"

# HIBP-Integration: Passwörter gegen Breach-Listen prüfen
# Tool: DSInternals oder Specops Password Auditor
Import-Module DSInternals
Test-PasswordQuality -WeakPasswordsFile C:\wordlists\top1million.txt `
    -IncludeDisabledAccounts | Where-Object {$_.WeakPassword} |
    Select-Object SamAccountName, WeakPassword

Microsoft Conditional Access

Wichtigste Conditional Access Policies:

Policy 1: MFA für alle
  Users: Alle außer Break-Glass-Accounts
  Apps: Alle Cloud-Apps
  Conditions: Alle
  Grant: Require MFA
  Block: wenn nicht konformes Gerät

Policy 2: Risikobasiertes MFA (Microsoft Identity Protection)
  User Risk: Medium → Require password change
  Sign-in Risk: Medium → Require MFA
  Sign-in Risk: High → Block

Policy 3: Geräte-Compliance
  Conditions: Alle Apps, unkonfigurierte Geräte
  Grant: Require Hybrid Azure AD joined ODER Compliant device
  → Nur verwaltete Geräte haben Zugriff

Policy 4: Länder-Block
  Conditions: Locations → Alle Länder außer Deutschland/EU
  Block: alle Logins aus Hochrisiko-Ländern

Policy 5: Privilegierte Konten
  Users: Admins (Global Admin, Exchange Admin, etc.)
  Conditions: Alle
  Grant: Require phishing-resistant MFA (FIDO2 oder Certificate)
  Block: wenn kein privilegierter Zugriff aus PAW

FIDO2 / Passkeys - Phishing-resistente MFA

Warum FIDO2 die Lösung ist:
  → Hardware-Token (YubiKey) oder Passkey (Gerätebindung)
  → Domain-gebunden: Angreifer kann Login-URL nicht faken!
  → AiTM (Evilginx) scheitert: falsche Domain → kein Login
  → SMS-OTP und TOTP SIND phishing-bar - FIDO2 nicht!

FIDO2 in Microsoft 365:
  1. Azure AD → Authentication Methods → FIDO2 Security Keys
  2. Enable + erlaubte Keys konfigurieren (YubiKey, etc.)
  3. Users registrieren Keys: aka.ms/mysecurityinfo

Passkeys (FIDO2 in Betriebssystem):
  → Windows Hello (TPM-basiert, keine externe Hardware)
  → Apple Face ID / Touch ID
  → Google Android Passkeys
  → Alle Passkeys sind FIDO2-kompatibel

NIST SP 800-63B: Level AAL3 (höchste Stufe) nur mit FIDO2!
BSI-Empfehlung: FIDO2 für privilegierte Zugriffe

Erkennung von Account Takeover

Azure AD / Microsoft Sentinel Detection

// KQL - Impossible Travel (Login aus zwei weit entfernten Orten)
SigninLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, UserPrincipalName, IPAddress, Location, RiskState
| summarize Locations=make_set(Location), IPs=make_set(IPAddress),
            LoginCount=count() by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1
// Weitere Filterung: Entfernung berechnen

// KQL - Password Spray Detection (viele User, wenige Versuche pro User)
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == "50126"  // Falsches Passwort
| summarize AttemptedUsers=dcount(UserPrincipalName),
            FailureCount=count() by IPAddress
| where AttemptedUsers > 10 and FailureCount < 5 * AttemptedUsers
| sort by AttemptedUsers desc

// KQL - MFA Fatigue (viele MFA-Ablehnungen gefolgt von Zustimmung)
SigninLogs
| where TimeGenerated > ago(2h)
| where AuthenticationRequirement == "multiFactorAuthentication"
| summarize
    Denied=countif(Status.additionalDetails == "MFA denied; user declined the authentication"),
    Approved=countif(ResultType == "0")
    by UserPrincipalName, IPAddress
| where Denied > 5 and Approved > 0  // Viele Ablehnungen dann plötzlich Zustimmung

Nach einer Account-Kompromittierung

Sofortmaßnahmen (erste 30 Minuten):
  1. Alle Sessions revoken:
     Azure AD → Benutzer → [User] → Alle Sitzungen widerrufen
     PowerShell: Revoke-AzureADUserAllRefreshToken -ObjectId <id>

  2. Passwort zurücksetzen (von sicherem Gerät!)
     MFA-Methoden prüfen/zurücksetzen

  3. E-Mail-Regeln prüfen:
     → Angreifer erstellen Weiterleitungsregeln
     → Exchange: Get-InboxRule -Mailbox user@firma.de

  4. Delegierungen prüfen:
     → Keine unbekannten Mailbox-Delegierungen
     → Keine unbekannten OAuth-Berechtigungen

  5. Aktivitätsprüfung:
     → Welche Daten wurden gesendet/gelesen?
     → Welche Aktionen wurden durchgeführt?
     → Office Activity Logs (90 Tage Aufbewahrung min.)

  DSGVO-Prüfung:
     → Wurden personenbezogene Daten exfiltriert?
     → Falls ja: 72h-Meldepflicht an Aufsichtsbehörde!