Wie der Angriff funktioniert

Ein Angreifer beschafft sich große Listen echter Zugangsdaten aus dem Datenleck eines anderen Dienstes, aus Phishing oder aus Passwort-Dump-Seiten. Mit automatisierten Tools (z. B. Sentry MBA) werden diese Paare massenhaft gegen die Login-API vieler Websites geschickt.

Da es sich um real existierende, andernorts gültige Passwörter handelt, ist die Trefferquote deutlich höher als beim blinden Erraten. Erfolgreiche Logins zeigen dem Angreifer ein gültiges, wiederverwendetes Kontopaar - das übernommene Konto wird dann geleert, ausspioniert, für Spam/Phishing missbraucht oder weiterverkauft.

Abgrenzung (laut OWASP):

  • Brute Force: probiert viele Passwörter aus einem Wörterbuch gegen EIN Konto (Raten).
  • Password Spraying: probiert EIN schwaches Passwort gegen sehr viele Konten.
  • Credential Stuffing: nutzt dagegen bekannte, bereits geleakte Benutzername-/Passwort-PAARE gegen andere Dienste - es wird nicht geraten, sondern Passwort-Wiederverwendung ausgenutzt.

OWASP ordnet Credential Stuffing als Unterart der Brute-Force-Kategorie ein, der entscheidende Unterschied ist die Verwendung bekannter Paare.

Typische Schwachstellen, die den Angriff erst lohnend machen:

  • Keine oder zu simple Rate-Limits (gleiche, vorhersehbare Volumengrenze pro IP, die mit Proxy-Netzwerken umgangen wird).
  • Keine Multi-Faktor-Authentifizierung.
  • Keine Bot-/Headless-Browser-Abwehr.
  • Kein Abgleich gegen bekannte geleakte Passwörter.

Da die Tools meist nur direkte POST-Requests senden und kein JavaScript ausführen, hilft auch das Erkennen von Headless-Browsern.

1. AusgangslageListen geleakter Zugangsdaten
→
2. AngriffAutomatisiert gegen die Login-API durchprobieren
→
3. ErgebnisÜbernommene Konten (Account Takeover)

Wiederverwendete Passwörter plus fehlende Limits führen zur Kontoübernahme.

Beispiel

Anatomie eines Angriffs (nach OWASP Credential stuffing article), am Beispiel eines geleakten Paars spongebob@example.com / Sommer2023:

  1. Datenbank von acme.com wird kompromittiert; die Liste enthält u. a. spongebob@example.com mit Passwort Sommer2023.
  2. Der Angreifer füttert ein automatisiertes Tool mit der geleakten Liste und richtet es gegen die Login-API anderer Dienste (Social Media, Marktplätze, B2B-Portale).
  3. Das Tool sendet pro Paar einen Login-Request, schematisch: POST /api/login HTTP/1.1 Host: portal.beispiel-b2b.de Content-Type: application/json {"username":"spongebob@example.com","password":"Sommer2023"}
  4. Antwort bei wiederverwendetem Passwort: HTTP/1.1 200 OK mit einem gültigen Session-/Auth-Token - der Treffer. Bei nicht wiederverwendetem Passwort: HTTP/1.1 401 Unauthorized.
  5. Der Angreifer weiß nun, dass das Konto gültig ist (Account Takeover). Folgeschritte laut OWASP: gespeichertes Guthaben abziehen oder Käufe tätigen, sensible Daten abgreifen, das Konto für Phishing/Spam missbrauchen oder die bestätigten Zugangsdaten weiterverkaufen.

(Die E-Mail, das Passwort, der Host und das konkrete 200/401-HTTP-Schema sind illustrativ gewählt; der inhaltliche Ablauf - Beschaffung der Paare, automatisiertes Testen gegen viele Dienste, Verwertung erfolgreicher Treffer - folgt dem OWASP-Artikel.)

Auswirkung

Erfolgreiches Credential Stuffing führt zur Account Takeover: unbefugter Zugriff auf fremde Konten und deren Daten. Laut OWASP gehört es zu den häufigsten Kontoübernahme-Techniken und ist sowohl für Verbraucher als auch für Unternehmen gefährlich, da ein einzelnes Datenleck Folgeangriffe (Ripple-Effekt) auf viele andere Dienste auslöst.

Konkrete Folgen aus dem OWASP-Artikel:

  • Abziehen von gespeichertem Guthaben oder betrügerische Käufe.
  • Zugriff auf sensible Informationen (Kreditkartennummern, private Nachrichten, Bilder, Dokumente).
  • Missbrauch des Kontos zum Versand von Phishing/Spam.
  • Weiterverkauf der verifizierten Zugangsdaten.

OWASP nennt reale Beispiele wie Sony 2011, Yahoo 2012 und Dropbox 2012, bei denen wiederverwendete Passwörter die Angriffskette ermöglichten.

Hinweis: Die im ursprünglichen Text zusätzlich behauptete Nutzung von Telefonnummern/Sicherheitsfragen/Recovery-E-Mails aus dem Leck für Passwort-Resets wird von den drei Quellen nicht belegt und wurde entfernt.

So schützt man sich

  • Multi-Faktor-Authentifizierung (MFA) einsetzen - laut OWASP die mit Abstand wirksamste Maßnahme; eine Microsoft-Analyse legt nahe, dass MFA 99,9% der Kontoübernahmen verhindert hätte. Wo nicht für alle Nutzer durchsetzbar, mindestens für Administratoren und als 'Step-up'-Authentifizierung bei risikoreichen Aktionen oder verdächtigen Logins (Denylist-/Anonymisierungs-IPs wie Proxy/VPN).
  • Eingegebene/neue Passwörter gegen bekannte geleakte Datensätze prüfen (OWASP ASVS v4.0, Provision 2.1.7), z. B. über den kostenlosen Dienst Pwned Passwords (selbst gehostet oder via API) - so wird die Wiederverwendung kompromittierter Passwörter unterbunden.
  • Abgestufte, intelligente IP-Mitigation statt eines einzelnen festen Volumenlimits: kurze (Burst-) und lange Zeitfenster betrachten, IP-Klassifizierung (Residential vs. Hosting) und Geolocation einbeziehen, Hosting-/Proxy-IP-Intelligence nutzen (Tools wie Sentry MBA verteilen Requests über Proxy-Netzwerke und umgehen einfache Rate-Limits). Sperren stets temporär halten.
  • Bot-Abwehr und Anti-Automation: Geräte- und Connection-Fingerprinting (z. B. JA3, HTTP/2-Fingerprinting, Header-Reihenfolge) zur Erkennung von Skripten; CAPTCHA - idealerweise nur bei verdächtigen/risikoreichen Logins, um echte Nutzer nicht zu stören.
  • JavaScript-Ausführung erzwingen und Headless-Browser blockieren: Da die meisten Angriffstools nur direkte POST-Requests senden und kein JS ausführen (Tokens generieren), erschwert dies den Angriff (Barrierefreiheit beachten - Blockieren von Nutzern ohne JS kann Screenreader-Nutzer ausschließen).
  • Login-Prozess erschweren: mehrstufiger Login (Benutzername und Passwort nacheinander, erst CSRF-Token holen) verdoppelt die nötigen Requests; dabei aber User-Enumeration vermeiden. Optional 'Degradation' (Proof-of-Work, künstliche Verzögerungen) zur Rate-Begrenzung.
  • Wiederverwendung von Benutzernamen erschweren: eigene, unvorhersehbare Benutzernamen statt der E-Mail-Adresse verlangen, da viele Leak-Listen nur E-Mails enthalten.
  • Defense in Depth und Metriken: mehrere Schichten kombinieren (clientseitige Abwehr kann gespooft werden), pro Abwehrmechanismus Volumenmetriken zu erkannten/abgewehrten Angriffen erfassen und überwachen.
  • Nutzer bei ungewöhnlichen Sicherheitsereignissen benachrichtigen (z. B. korrektes Passwort, aber fehlgeschlagene MFA-Prüfung); bei mehrfachen Passwort-Resets von verschiedenen Geräten/IPs den weiteren Zugriff auf das Konto bis zur Nutzerverifikation sperren.

Quellen

Weiterlesen
ÜbersichtOWASP API Security Top 10 AngriffCORS-Fehlkonfiguration