Credential Stuffing: warum Ihr Login unauffällig aussieht und trotzdem leckt

Der Angriff, und warum er kein Brute Force ist

Credential Stuffing rät keine Passwörter. Es spielt sie erneut ab. Jemand nimmt Nutzername-Passwort-Paare aus dem Leck eines fremden Dienstes und probiert jedes Paar einmal an Ihrem Login — in der Wette darauf, dass ein erheblicher Anteil der Menschen Zugangsdaten wiederverwendet.

Dieser eine Unterschied hebelt fast alles aus, was Sie im Einsatz haben. Brute Force ist laut: viele Versuche gegen ein Konto, leicht zu drosseln, leicht zu sperren. Stuffing ist ein Versuch je Konto über Tausende von Konten, verteilt über Stunden und mit rotierenden Adressen.

Die Erfolgsquote ist niedrig — üblicherweise zwischen einem Zehntelprozent und wenigen Prozent — und das reicht vollkommen. Gegen eine Liste von einer Million Paaren sind ein Zehntelprozent tausend funktionierende Konten.

Und der erfolgreiche Login ist nach jedem technischen Maßstab, der Ihrer Anwendung zur Verfügung steht, korrekt. Das Passwort stimmte. Es gibt nichts abzulehnen.

Wie es in Ihren Logs aussieht

Der Grund, warum das wochenlang unbemerkt bleibt, ist, dass kein einzelnes Signal alarmierend wirkt. Das Muster existiert nur in der Summe.

• Fehlerquote, nicht Fehlerzahl. Ihre absolute Zahl fehlgeschlagener Logins bewegt sich vielleicht kaum, aber das Verhältnis von Fehlschlägen zu Erfolgen verschiebt sich — weil die Versuche über Konten streuen, die meist nicht existieren oder nicht passen.
• Ein Versuch je Konto. Ein auf das Konto geschlüsselter Rate-Limiter greift nie. Ein auf die Adresse geschlüsselter greift nur, wenn der Angreifer die Rotation vergessen hat.
• Adressverteilung. Die Versuche kommen aus Residential-Proxy-Pools, also von Adressen, die wie gewöhnliche Kunden aussehen und nicht wie ein Rechenzentrum.
• Zu gleichmäßiges Timing. Menschlicher Login-Traffic folgt dem Tagesrhythmus Ihrer Kunden. Ein Stuffing-Lauf ist über die Nacht hinweg flach.
• Ein stiller Anstieg von Erfolgen aus unbekannten Adressen. Das ist das Entscheidende und genau das, worauf niemand alarmiert, weil ein erfolgreicher Login kein Fehler ist.

Warum die üblichen Kontrollen ihn verfehlen

Jede davon ist es wert, eingesetzt zu werden, und keine stoppt diesen Angriff für sich allein.

Rate Limiting ist auf das Falsche geschlüsselt. Kontobezogene Limits lösen bei einem Versuch je Konto nie aus. Adressbezogene Limits werden durch Rotation über einen Residential-Proxy-Pool ausgehebelt, und der ist eine Massenware.

Kontosperren sind hier schlimmer als nutzlos und aktiv gefährlich. Sie können bei einem Versuch nicht auslösen, und an einem öffentlichen Login erlauben sie jedem, die Konten Ihrer Kunden auf Zuruf abzuschalten.

CAPTCHAs sind Kosten je Versuch, die der Angreifer bereits eingeplant hat. Solver-Dienste rechnen je tausend ab, und bei 0,1 % Erfolgsquote geht die Rechnung bequem auf.

Passwort-Komplexitätsregeln bringen nichts. Das abgespielte Passwort ist bereits gültig — es erfüllt die Regeln des anderen Dienstes und wahrscheinlich auch Ihre.

Mehrfaktor-Authentifizierung ist die eine Kontrolle, die den Angriff wirklich bricht, und jeder Aufwand für ihre Einführung lohnt sich. Sie hilft allerdings nicht bei Konten, die sie nicht eingerichtet haben — und das sind bei einem Consumer-Produkt die meisten.

Was ihn tatsächlich fängt

Weil der Angriff in keinem einzelnen Request sichtbar ist, muss die Erkennung auf Ebene der Sitzung und der Adresse arbeiten.

Signale auf Sitzungsebene. Ein Stuffing-Lauf automatisiert das Formular: Felder füllen sich ohne das Timing des Tippens, der Fokus bewegt sich anders, als eine menschliche Hand es erzeugt, und der Absenden-Request kommt schneller, als eine Person plausibel ausfüllen konnte. Das ist dieselbe Verhaltensschicht, die jede unsichtbare Bot-Erkennung liest, und sie ist schon beim allerersten Versuch sichtbar.

Transport-Fingerabdrücke. Das Werkzeug muss eine TLS-Verbindung aufbauen, und sein Stack zeigt sich. Ein JA3/JA3N-Fingerabdruck, der nicht zu dem Browser passt, für den sich die Sitzung ausgibt, ist ein starkes Signal — und der Angreifer kann das nicht durch Ändern eines Headers beheben.

Reputation über Versuche hinweg. Ein Versuch je Konto gibt Ihnen je Konto nichts, aber dieselbe Adresse mit je einem Versuch gegen vierhundert verschiedene Konten ist eindeutig. Diese Summe entsteht nur, wenn etwas die Adresse bewertet und nicht den Request zählt.

Mandantenübergreifende Reputation. Stuffing-Listen werden in derselben Kampagne gegen viele Websites abgespielt. Eine Adresse, die gestern Nacht eine Liste gegen ein fremdes Login laufen ließ, sollte gestoppt werden, bevor sie bei Ihnen anfängt — was nur möglich ist, wenn dieses Wissen geteilt wird.

Ein belastbares Setup

Geordnet danach, wie stark jeder Schritt das Ergebnis bestimmt.

Führen Sie MFA ein und treiben Sie die Aktivierung voran. Nichts anderes auf dieser Liste bricht den Angriff für sich. Machen Sie es zur Voreinstellung für neue Konten und fordern Sie bestehende nach einem erfolgreichen Login von einer neuen Adresse dazu auf.

Alarmieren Sie auf erfolgreiche Logins aus unbekannten Adressen. Das ist billig, nutzt Daten, die Sie schon haben, und ist das Signal dafür, dass ein Stuffing-Lauf zu wirken begonnen hat.

Bewerten Sie die Sitzung, nicht den Request. Verhaltens- und Transportsignale fangen die Automatisierung beim ersten Versuch, bevor sich das Summenmuster überhaupt bilden konnte.

Setzen Sie am Gateway durch. Eine in Seiten-JavaScript angewandte Entscheidung ist eine Entscheidung, die das Werkzeug des Angreifers nie ausführt.

Prüfen Sie Zugangsdaten beim Setzen und beim Login gegen bekannte Leaks. Steht das abgespielte Passwort bereits in einem öffentlichen Korpus, können Sie es ablehnen, bevor es zu irgendjemandes Problem wird.

Halten Sie Ihre Allow-Liste aktuell. Ihre eigene QA-Automatisierung und Lasttests sehen exakt aus wie dieser Angriff, und sie an einem Release-Tag zu blockieren, ist eine eigene Art von Vorfall.

Wo Karma steht

Karma deckt Punkt drei und vier ab: Es bewertet jede Sitzung anhand von Verhaltens- und Transportsignalen, führt eine mandantenbezogene Reputationsbasis, sodass eine Adresse über viele Konten hinweg als ein Akteur sichtbar wird, und bietet eine optionale geteilte Sperrliste, damit eine branchenweit abgespielte Liste bekannt ist, bevor sie Ihr Login erreicht.

Das Verdict geht an Ihr Gateway, das den Request stoppt, bevor Ihre Anwendung das Passwort überhaupt prüft — der Versuch kostet Sie also nichts und taucht nie als erfolgreicher Login auf, den Sie untersuchen müssten.

Es ersetzt MFA nicht, und diese Seite behauptet das auch nicht. MFA ist die Kontrolle, die ein abgespieltes Passwort wertlos macht; alles hier dreht sich darum, den Traffic zu stoppen, der testet, welche Passwörter noch funktionieren.