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

Der Ablauf: Angreifer kaufen Datenbreach-Listen (Milliarden von E-Mail/Passwort-Paaren), testen diese automatisiert gegen Login-Seiten und nutzen die weit verbreitete Passwort-Wiederverwendung aus. Werkzeuge dafür sind OpenBullet und SentryMBA als automatisierte Stuffing-Tools, Residential Proxies zum IP-Rotieren sowie CAPTCHA-Bypass-Services (2Captcha, Anti-Captcha).

Statistischer Kontext: 23 Milliarden Credential-Paare zirkulieren laut Have I Been Pwned (2024), und 85% der Nutzer verwenden Passwörter wieder (LastPass Survey 2023).

Erkennungsmerkmale: viele fehlgeschlagene Logins von einer oder vielen IPs, Logins aus ungewöhnlichen Geografien, ein erfolgreicher Login nach 1.000 fehlgeschlagenen Versuchen sowie auffällig schnelle Login-Versuche mit Bot-typischem Timing.

Password Spraying

Statt vieler Passwörter gegen einen Account testet Password Spraying ein einziges Passwort gegen alle Accounts - und umgeht so Account-Lockout-Schwellen (Standard: 5-10 Versuche vor Lockout). Der Angreifer wartet nach jeder Runde 30 Minuten, bevor er mit dem nächsten Passwort weitermacht.

Beliebte Spray-Passwörter sind Firmenname + Jahr ("AWARE7_2024!"), saisonale Passwörter ("Winter2024!", "Sommer2025#"), Keyboard-Pattern ("Qwerty123!", "Password1") und typische Default-Passwörter ("Welcome1", "Changeme1").

Die Gefährlichkeit liegt darin, dass Lockout-Schwellen nie erreicht werden, der Angriff monatelang unentdeckt bleibt und er besonders effektiv gegen Active-Directory-Umgebungen ist.

Erkennungsmerkmale: viele fehlgeschlagene Logins gegen verschiedene Accounts, aber wenige Versuche pro Account (unterhalb des Lockout-Thresholds), regelmäßige Zeitintervalle mit Bot-typischem Muster sowie "Account Lockout"-Ereignisse in den Azure AD Sign-In Logs.

SIM-Swapping

Der Ablauf: Der Angreifer sammelt OSINT über das Opfer (Name, Geburtsdatum, Adresse), ruft beim Mobilfunkanbieter an ("Mein Handy ist kaputt"), manipuliert den Kundendienst per Social Engineering zur SIM-Übertragung auf eine neue Karte. Alle SMS für die Nummer - inklusive SMS-OTPs - gehen nun an den Angreifer. Ein "Passwort vergessen" genügt zur vollständigen Account-Übernahme.

Bekannte Opfer: Twitter-CEO Jack Dorsey (2019) und zahlreiche Krypto-Investoren mit hunderten Millionen gestohlen.

SMS als MFA ist strukturell unsicher: SS7-Schwachstellen ermöglichen zusätzliche Abfangtechniken jenseits des SIM-Swaps. Prävention: SIM-Swap-PIN beim Anbieter aktivieren, Authenticator-App (Google Authenticator, Microsoft Authenticator) statt SMS-OTP, FIDO2-Hardware-Token (YubiKey) für höchste Sicherheit.

MFA-Bypass-Techniken

Vier MFA-Bypass-Techniken sind in der Praxis besonders relevant:

MFA Fatigue (Prompt Bombing): Der Angreifer kennt das Passwort und sendet massenhaft MFA-Push-Anfragen. Nach 50+ Notifications gibt das genervte Opfer irgendwann nach und drückt "Approve". Realer Fall: Uber (2022) mit kombiniertem MFA-Bombing und Social Engineering ("Hi, ich bin IT-Support, bitte bestätigen Sie die Anfrage").

Evilginx / Adversary-in-the-Middle (AiTM): Ein Reverse-Proxy positioniert sich zwischen Opfer und echtem Service. Das Opfer sieht die echte Login-Seite und durchläuft erfolgreich die MFA - der Proxy stiehlt den Session-Cookie danach. Dieser Cookie ermöglicht vollen Zugriff ohne erneute MFA. Gegenmaßnahme: Token Protection (Microsoft Conditional Access) bindet Sessions an das Gerät.

OAuth-Consent-Phishing: Eine gefälschte App beantragt OAuth-Permissions. Ein Klick auf "Erlauben" gibt der App Zugriff auf die Mailbox - kein Passwort, kein MFA-Prompt nötig. In Microsoft 365 können Admins riskante Apps blockieren.

Pass-the-Cookie / Token Theft: Stealer-Malware (Raccoon Stealer, Redline, Vidar) stiehlt Browser-Session-Cookies. Der Angreifer importiert den Cookie und ist ohne MFA eingeloggt.

Gegenmaßnahmen für alle MFA-Bypasses: phishing-resistente MFA (FIDO2/Passkeys - AiTM scheitert, weil FIDO2 domain-gebunden ist), Conditional Access (nur bekannte/konforme Geräte), Anomalie-Erkennung (UEBA, Microsoft Identity Protection) sowie Session-Token-Bindung an das 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

Die fünf wichtigsten Conditional Access Policies:

Policy 1: MFA für alle - alle Nutzer außer Break-Glass-Accounts, alle Cloud-Apps, Grant: Require MFA.
Policy 2: Risikobasiertes MFA (Microsoft Identity Protection) - User Risk Medium: Passwortänderung erzwingen; Sign-in Risk Medium: MFA erzwingen; Sign-in Risk High: blockieren.
Policy 3: Geräte-Compliance - Grant: Require Hybrid Azure AD joined oder Compliant device. Nur verwaltete Geräte erhalten Zugriff.
Policy 4: Länder-Block - alle Logins aus Ländern außerhalb Deutschland/EU blockieren.
Policy 5: Privilegierte Konten - alle Admin-Accounts (Global Admin, Exchange Admin usw.) müssen phishing-resistente MFA (FIDO2 oder Certificate) verwenden; Zugriff nur von privilegierten Workstations (PAW).

FIDO2 / Passkeys - Phishing-resistente MFA

FIDO2 ist phishing-resistent, weil es domain-gebunden ist: Ein Angreifer kann die Login-URL nicht faken, AiTM-Angriffe (Evilginx) scheitern, weil eine gefälschte Domain keinen gültigen FIDO2-Login ermöglicht. SMS-OTP und TOTP sind phishbar - FIDO2 nicht.

FIDO2 in Microsoft 365: unter Azure AD → Authentication Methods → FIDO2 Security Keys aktivieren, erlaubte Keys konfigurieren (YubiKey usw.) und Nutzer registrieren ihre Keys unter aka.ms/mysecurityinfo.

Passkeys sind FIDO2 im Betriebssystem: Windows Hello (TPM-basiert, keine externe Hardware), Apple Face ID/Touch ID sowie Google Android Passkeys - alle FIDO2-kompatibel.

NIST SP 800-63B vergibt Level AAL3 (höchste Authentifizierungsstufe) ausschließlich für FIDO2. Das BSI empfiehlt FIDO2 für alle privilegierten 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):

Alle Sessions revoken: Azure AD → Benutzer → [User] → Alle Sitzungen widerrufen, oder per PowerShell: Revoke-AzureADUserAllRefreshToken -ObjectId <id>
Passwort zurücksetzen (von sicherem Gerät!), MFA-Methoden prüfen und zurücksetzen.
E-Mail-Weiterleitungsregeln prüfen - Angreifer legen regelmäßig Weiterleitungsregeln an (Get-InboxRule -Mailbox user@firma.de in Exchange).
Delegierungen prüfen: keine unbekannten Mailbox-Delegierungen oder OAuth-Berechtigungen.
Aktivitätsprüfung anhand der Office Activity Logs (mindestens 90 Tage Aufbewahrung): Welche Daten wurden gesendet, gelesen oder welche Aktionen durchgeführt?

DSGVO-Prüfung: Wurden personenbezogene Daten exfiltriert? Falls ja, greift die 72-Stunden-Meldepflicht an die Aufsichtsbehörde nach DSGVO Art. 33.