Identity theft and account takeover: attacks and protective measures

Account Takeover (ATO) is the first step in most successful cyberattacks. Once an attacker gains control of an account—especially privileged accounts—they can move laterally, exfiltrate data, and deploy ransomware. Understanding these attacks is the first step toward prevention.

Account Takeover - Attack Methods

Credential Stuffing

How it works:
  1. Attacker purchases data breach lists (billions of email/password pairs)
  2. Automated testing against your login pages
  3. Password reuse: same passwords on other platforms

Tools:
  OpenBullet / SentryMBA: automated credential stuffing tools
  Residential Proxies: rotate IPs to bypass detection
  CAPTCHA bypass: 2Captcha, anti-CAPTCHA services

Statistics:
  23 billion credential pairs in circulation (Have I Been Pwned, 2024)
  85% of users reuse passwords (LastPass Survey 2023)

Detection:
  → Many failed login attempts from a single IP / multiple IPs
  → Logins from unusual geographic locations
  → Successful login after 1,000 failed attempts
  → Unusually rapid login attempts (bot timing)

Password Spraying

How it works:
  Instead of many passwords for one account → one password for ALL accounts
  Goal: Bypass account lockouts (Standard: 5–10 attempts before lockout)

  Attack:
    Account 1: Winter2024! → failed
    Account 2: Winter2024! → failed
    Account 3: Winter2024! → SUCCESS! (weak password!)
    ...
    Wait 30 minutes → next round with "Spring2024!"

Why it’s dangerous:
  → Lockout thresholds are never reached
  → Can go undetected for months
  → Particularly effective against AD environments

Popular spray passwords:
  Company name + year: "AWARE7_2024!", "Mustermann24"
  Seasonal passwords: "Winter2024!", "Summer2025#"
  Keyboard patterns: "Qwerty123!", "Password1"
  Default passwords: "Welcome1", "Changeme1"

Detection:
  → Many failed login attempts on DIFFERENT accounts
  → But few attempts per account (< lockout threshold)
  → Regular time intervals (bot pattern)
  → Azure AD sign-in logs: "Account Lockout" → Indicator

SIM Swapping

How it works:
  1. Attacker gathers OSINT on victim (name, date of birth, address)
  2. Phone call to mobile carrier: "My phone is broken"
  3. Social engineering of customer service → Transfer SIM to new card
  4. All SMS messages for the number → now go to the attacker
  5. "Forgot password" → SMS OTP sent to the attacker
  6. Account taken over!

Known victims:
  → Twitter CEO Jack Dorsey (2019): Twitter account hijacked
  → Crypto investors: hundreds of millions stolen

Why phone-based MFA is insecure:
  → SS7 vulnerabilities (telephone networks): SIM swap isn’t the only method
  → SMS can be intercepted
  → Therefore: Use FIDO2/authenticator app instead of SMS OTP!

Prevention:
  → Enable PIN/PUK with your provider for SIM swap protection
  → Use an authenticator app instead of SMS OTP (Google Authenticator, Microsoft Authenticator)
  → Use a FIDO2 hardware token for maximum security (YubiKey)

MFA bypass techniques

Accounts can still be compromised even with MFA:

MFA Fatigue (Prompt Bombing):
  Attacker has password → sends MFA push requests
  → Victim receives 50+ notifications in a row
  → Frustrated victim eventually presses "Approve"
  → Account taken over!

  Real-world case: Uber (2022) - MFA Bombing + Social Engineering
  Attacker: "Hi, I'm IT Support, please confirm the request"

Evilginx / Adversary-in-the-Middle (AiTM):
  Reverse proxy between victim and genuine service
  → Victim sees genuine login page (proxy redirects)
  → Attacker steals session cookie AFTER successful MFA
  → Session cookie = full access without re-authentication!

  Detection: Token Protection (Microsoft Conditional Access)
  → Bind session to device (no cookie theft abuse)

OAuth Consent Phishing:
  → Fake app requests OAuth permissions
  → Victim clicks "Allow" → App gains access to mailbox
  → No password required, no MFA prompt!
  → Microsoft 365: Admin can block risky apps

Pass-the-Cookie / Token Theft:
  → Stealer malware steals browser session cookies
  → Attacker imports cookie → logged in without MFA
  → Known malware: Raccoon Stealer, Redline, Vidar

Countermeasures for all MFA bypasses:
  → Phishing-resistant MFA: FIDO2 / Passkeys (AiTM fails!)
  → Conditional Access: known/compliant devices only
  → Anomaly detection: UEBA / Microsoft Identity Protection
  → Session token binding to device (Token Protection)

Protective Measures: Identity-Based Defense in Depth

Password Hardening

# Active Directory: Check password policy
Get-ADDefaultDomainPasswordPolicy

# Fine-Grained Password Policy for privileged accounts
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: Check Passwords Against Breach Lists
# Tool: DSInternals or Specops Password Auditor
Import-Module DSInternals
Test-PasswordQuality -WeakPasswordsFile C:\wordlists\top1million.txt `
    -IncludeDisabledAccounts | Where-Object {$_.WeakPassword} |
    Select-Object SamAccountName, WeakPassword

Microsoft Conditional Access

Key Conditional Access Policies:

Policy 1: MFA for Everyone
  Users: Everyone except break-glass accounts
  Apps: All cloud apps
  Conditions: All
  Grant: Require MFA
  Block: If device is non-compliant

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

Policy 3: Device Compliance
  Conditions: All apps, unconfigured devices
  Grant: Require Hybrid Azure AD joined OR Compliant device
  → Only managed devices have access

Policy 4: Country Block
  Conditions: Locations → All countries except Germany/EU
  Block: All logins from high-risk countries

Policy 5: Privileged Accounts
  Users: Admins (Global Admin, Exchange Admin, etc.)
  Conditions: All
  Grant: Require phishing-resistant MFA (FIDO2 or Certificate)
  Block: If no privileged access from PAW

FIDO2 / Passkeys - Phishing-Resistant MFA

Why FIDO2 is the solution:
  → Hardware token (YubiKey) or passkey (device binding)
  → Domain-bound: Attackers cannot spoof the login URL!
  → AiTM (Evilginx) fails: wrong domain → no login
  → SMS-OTP and TOTP ARE susceptible to phishing - FIDO2 is not!

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

Passkeys (FIDO2 in operating system):
  → Windows Hello (TPM-based, no external hardware)
  → Apple Face ID / Touch ID
  → Google Android Passkeys
  → All passkeys are FIDO2-compatible

NIST SP 800-63B: Level AAL3 (highest level) only with FIDO2!
BSI Recommendation: FIDO2 for privileged access

Account Takeover Detection

Azure AD / Microsoft Sentinel Detection

// KQL - Impossible Travel (Login from two distant locations)
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
// Additional filtering: Calculate distance

// KQL - Password Spray Detection (many users, few attempts per user)
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == "50126"  // Incorrect password
| summarize AttemptedUsers=dcount(UserPrincipalName),
            FailureCount=count() by IPAddress
| where AttemptedUsers > 10 and FailureCount < 5 * AttemptedUsers
| sort by AttemptedUsers desc

// KQL - MFA Fatigue (many MFA denials followed by approval)
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  // Many denials followed by sudden approval

After an account compromise

Immediate actions (first 30 minutes):
  1. Revoke all sessions:
     Azure AD → Users → [User] → Revoke all sessions
     PowerShell: Revoke-AzureADUserAllRefreshToken -ObjectId<id>

  2. Reset password (from a secure device!)
     Check/reset MFA methods

  3. Check email rules:
     → Attackers create forwarding rules
     → Exchange: Get-InboxRule -Mailbox user@firma.de

  4. Check delegations:
     → No unknown mailbox delegations
     → No unknown OAuth permissions

  5. Activity check:
     → What data was sent/read?
     → What actions were performed?
     → Office Activity Logs (minimum 90-day retention)

  GDPR check:
     → Was personal data exfiltrated?
     → If yes: 72-hour reporting obligation to the supervisory authority!
```</id>