MFA-Fatigue und Session-Hijacking: So hebeln Angreifer Ihre 2FA aus

Sie haben 2FA aktiviert und der Geschäftsleitung gemeldet, das Thema sei erledigt. Ist es nicht. Angreifer kämpfen längst nicht mehr gegen Ihre Login-Maske, sie umgehen sie. Das Passwort spielt weiterhin eine Rolle, aber die beiden Techniken, die derzeit die meisten Vorfälle treiben, MFA-Fatigue und Session-Hijacking, behandeln Ihren zweiten Faktor als Bodenwelle, nicht als Mauer.

Warum 2FA nicht mehr ausreicht

Klassisches Phishing stiehlt ein Passwort. MFA war die Antwort: Selbst mit dem Passwort fehlt dem Angreifer der zweite Faktor. Diese Logik trug, bis die Angreifer das Ziel wechselten.

Zwei Verschiebungen haben das Modell gebrochen:

• Der Mensch ist ermüdet. Push-basierte MFA verlangt von einer Person eine Freigabe. Menschen geben den ganzen Tag Dinge frei. Angreifer haben gelernt, genau diesen Reflex zur Waffe zu machen.
• Die Sitzung wurde zur Beute. Nach der Authentifizierung stellt der Server Ihrem Browser ein Session-Token aus. Dieses Token, nicht Ihr Passwort, beweist bei jedem folgenden Request, dass Sie Sie sind. Wer das Token stiehlt, überspringt das Passwort, den MFA-Prompt, alles.

Beide Angriffe haben dieselbe Wurzel: Authentifizierung ist ein Ereignis, Zugriff ist ein Zustand. Wir investieren massiv in das Ereignis und fast nichts in den Zustand, der danach Stunden oder Tage weiterlebt. Die ausführliche Fassung dieses Arguments finden Sie in unserem Beitrag zur Zero-Trust-Architektur. Die Kurzfassung: Vertrauen Sie keiner Sitzung, nur weil ein Login irgendwann einmal erfolgreich war.

MFA-Fatigue, auch Push-Bombing genannt

Die Mechanik ist primitiv und wirksam. Der Angreifer besitzt das Passwort bereits (aus einem Breach-Dump, einem Phishing-Kit oder von einem Infostealer). Er meldet sich an. Auf dem Smartphone des Opfers leuchtet eine Freigabeanfrage auf. Er meldet sich erneut an. Und wieder. Zehn Anfragen. Fünfzig Anfragen. Um zwei Uhr nachts.

Irgendwann tritt einer von drei Fällen ein:

1. Der Nutzer tippt auf Bestätigen, damit endlich Ruhe ist.
2. Der Nutzer vermutet Wartungsarbeiten der IT und bestätigt.
3. Der Angreifer ruft an, gibt sich als IT-Support aus und führt den Nutzer durch die Freigabe.

Das ist der ganze Angriff. Kein Zero-Day, keine Malware. Er funktioniert, weil ein nacktes „Bestätigen / Ablehnen" keinerlei Kontext transportiert und die Zustimmung den Nutzer nichts kostet.

Maßnahmen, die die Quote wirklich verschieben

• Number Matching. Der Anmeldebildschirm zeigt eine zweistellige Zahl, die der Nutzer in der App eintippen muss. Ein Angreifer, der den Anmeldebildschirm nicht sieht, kann die Zahl nicht liefern. Allein das beendet den Pfad der blinden Freigabe.
• Kontext im Prompt. Zeigen Sie Standort, Anwendung und IP an. „Anmeldung aus Lagos an Ihrer Gehaltsabrechnung" bestätigt niemand aus Versehen, ein leerer Bestätigen-Button schon.
• Rate Limiting und Sperre bei wiederholten Pushes. Drei abgelehnte oder ignorierte Anfragen in kurzer Zeit sollten neue Prompts einfrieren und Ihr SOC alarmieren. Push-Bombing ist naturgemäß laut. Detektieren Sie das Volumen.
• Für hochwertige Konten ganz weg von Push. Number Matching ist ein Patch. Phishing-resistente Faktoren sind die Therapie (dazu gleich mehr).

Number Matching ist in den meisten Identity-Plattformen inzwischen Standard. Aktivieren Sie es. Wenn Ihr Anbieter für privilegierte Nutzer weiterhin schlichtes Bestätigen/Ablehnen zulässt, ist das ein Auditbefund, keine Geschmacksfrage. Und wenn Sie ohnehin an der Konfiguration Ihres Identity-Providers arbeiten: Klären Sie im selben Zug, wo Anmelde- und Sitzungsdaten verarbeitet werden. Datenresidenz in der EU und ein sauberer Auftragsverarbeitungsvertrag sind für DACH-Unternehmen keine Kür, sondern DSGVO-Grundhygiene.

Session-Hijacking: Token stehlen statt Login knacken

Diese Familie ist die gefährlichere, denn sie schlägt auch gute MFA. Selbst ein perfekter Login mit Number Matching endet damit, dass ein Session-Token ausgestellt wird. Bekommt der Angreifer dieses Token, hat Ihre MFA nie ein Mitspracherecht.

Drei Wege zum Token sind verbreitet.

1. Adversary-in-the-Middle-Phishing (AiTM)

Das ist die Technik hinter den meisten modernen MFA-Umgehungen. Der Angreifer betreibt einen Reverse Proxy (Evilginx und ähnliche Kits haben daraus ein Point-and-Click-Werkzeug gemacht) zwischen dem Opfer und der echten Website.

Der Ablauf:

1. Das Opfer klickt auf einen Phishing-Link und landet auf dem Proxy des Angreifers. Der sieht pixelgenau echt aus, weil er die echte Website schlicht durchreicht.
2. Das Opfer tippt das Passwort ein. Der Proxy leitet es an die echte Website weiter.
3. Die echte Website löst den MFA-Prompt aus. Das Opfer schließt ihn ab. Number Matching, TOTP, SMS: alles erfüllt, denn hier meldet sich tatsächlich ein echter Mensch an.
4. Die echte Website stellt ein gültiges Session-Cookie aus. Der Proxy fängt es im Transit ab.
5. Der Angreifer importiert das Cookie in seinen eigenen Browser und ist drin, vollständig authentifiziert, MFA bereits erledigt.

Das Opfer hat alles richtig gemacht und trotzdem verloren. Deshalb ist „wir haben MFA" keine Antwort auf die Frage „sind wir Phishing-resistent".

2. Infostealer-Malware und Cookie-Diebstahl

Wer die Festplatte des Opfers lesen kann, braucht keinen Proxy. Infostealer (RedLine, Lumma und der Rest dieses Markts) greifen Browser-Cookie-Stores, gespeicherte Tokens und lokale Sitzungsdateien ab und verkaufen sie weiter. Der Käufer lädt Ihre laufende Sitzung und spaziert hinein. Keine Passwortabfrage, keine MFA, denn das Token ist bereits geprägt.

Deshalb gilt: Eine Endpoint-Kompromittierung ist immer auch eine Identitätskompromittierung. Das sind keine zwei getrennten Vorfälle.

3. Token-Diebstahl in OAuth- und API-Flows

Langlebige Refresh Tokens und falsch konfigurierte OAuth-Apps sind eine stille Goldgrube. Ein gestohlenes Refresh Token kann wochenlang neue Access Tokens prägen. Überprivilegierte Tokens machen aus einem einzigen Leck einen mandantenweiten Zugriff. Wenn Ihre Plattform Tokens an Drittintegrationen ausgibt, ist jede davon ein Credential, das Sie vermutlich nicht rotieren. Scoping und Rotation behandeln wir ausführlich in API-Sicherheit: Best Practices.

Die Verteidigung, die tatsächlich hält: Phishing-resistente MFA

Jetzt die unbequeme Wahrheit. Number Matching hilft gegen Fatigue. Gegen AiTM hilft es gar nichts, denn der Mensch übergibt weiterhin ein echtes Credential an eine echte Website, nur eben durch einen Proxy hindurch. Um AiTM zu schlagen, brauchen Sie einen Faktor, der an den Origin gebunden ist und sich nicht weiterreichen lässt.

Dieser Faktor ist FIDO2 / WebAuthn, ausgeliefert als Passkeys oder Hardware-Sicherheitsschlüssel. Auch das BSI empfiehlt für exponierte Konten seit Langem hardwaregestützte, Phishing-resistente Verfahren statt OTP.

Warum das AiTM widersteht: Der Authenticator signiert eine Challenge, die den Origin (die echte Domain) enthält. Ein Proxy auf einer Lookalike-Domain erzeugt den falschen Origin, die Signatur validiert nicht. Es gibt keinen Code zum Abphishen und kein Cookie, zu dessen Weitergabe man den Menschen überreden könnte. Die Kryptographie verweigert außerhalb der legitimen Domain schlicht die Arbeit.

Wenn Sie nur einen ergänzenden Beitrag lesen, dann diesen: Passkeys und passwortlose Authentifizierung. Für Admins, Finance und alle mit Produktionszugriff sollte Phishing-resistente MFA Pflicht sein, nicht Option.

Rangfolge der MFA-Stärke:
  1. FIDO2 / Passkeys / Hardware-Keys     (Phishing-resistent, stoppt AiTM)
  2. Push mit Number Matching + Kontext   (stoppt Fatigue, nicht AiTM)
  3. TOTP-Authenticator-Apps              (per Proxy phishbar)
  4. SMS- / Sprach-OTP                    (phishbar + SIM-Swap-Risiko)

Rollen Sie nicht nur die oberste Stufe aus. Rollen Sie sie zuerst aus, und zwar für die Konten, deren Kompromittierung Ihr Quartal beenden würde.

Die Sitzung selbst schützen

Phishing-resistente MFA schützt den Login. Das Token müssen Sie nach der Ausstellung trotzdem schützen, denn Malware und Fehlkonfigurationen greifen es direkt ab.

Das Token an das Gerät binden

Die stärkste Kontrolle ist Token Binding: Die Sitzung wird kryptographisch an das Gerät gebunden, das sich authentifiziert hat. Ein gestohlenes Cookie ist damit auf einer anderen Maschine wertlos. Zwei Mechanismen sollten Sie kennen:

• DPoP (Demonstrating Proof of Possession) für OAuth. Der Client beweist bei jedem Request den Besitz eines privaten Schlüssels. Ein kopiertes Token ohne den Schlüssel ist bei Ankunft tot.

POST /api/orders HTTP/1.1
Authorization: DPoP eyJ...access_token...
DPoP: eyJ...signed_proof_bound_to_request_and_key...

• Device-bound Sessions auf Browser-Ebene. Junge Standards (häufig als Device Bound Session Credentials vermarktet) erneuern Cookies über einen gerätegebundenen Schlüssel. Ein exfiltriertes Cookie läuft dadurch schnell ab und lässt sich anderswo nicht wiederverwenden.

Cookies härten, die unspektakuläre Pflichtübung

Der Großteil des Session-Diebstahls nutzt schlampiges Cookie-Handling aus. Auf die Defaults kommt es an:

Set-Cookie: session=...;
  HttpOnly;          // für JavaScript unlesbar, entschärft XSS-Diebstahl
  Secure;            // wird nie über unverschlüsseltes HTTP gesendet
  SameSite=Lax;      // begrenzt Cross-Site-Versand, reduziert CSRF
  Path=/;
  Max-Age=3600       // kurze Lebensdauer, kleiner Schadensradius

HttpOnly allein stoppt eine große Klasse von Cookie-Exfiltration über Cross-Site-Scripting. Wenn Ihr Session-Cookie aus JavaScript lesbar ist, beheben Sie das vor allem anderen auf dieser Seite.

Begrenzen, was ein gestohlenes Token anrichten kann

• Kurze Access-Token-Laufzeiten. Minuten, nicht Stunden. Erzwingen Sie häufige Re-Validierung.
• Refresh-Token-Rotation mit Reuse Detection. Jeder Refresh stellt ein neues Token aus und invalidiert das alte. Taucht ein altes Token wieder auf, ist das Diebstahl: Beenden Sie die gesamte Session-Familie.
• Eng gefasster Token-Scope. Least Privilege pro Token. Ein geleaktes Read-only-Token ist ein Vorfall. Ein geleaktes Allmacht-Token ist ein Breach, im Zweifel mit Meldepflicht nach Art. 33 DSGVO.

Den Hijack erkennen, den Sie nicht verhindern konnten

Gehen Sie davon aus, dass ein Token entkommt. Ihre Aufgabe ist es, sein Leben kurz und laut zu machen.

• Continuous Access Evaluation (CAE). Statt einem Token bis zum Ablauf zu vertrauen, werden die Bedingungen nahezu in Echtzeit nachgeprüft. Passwort-Reset, deaktiviertes Konto, riskanter Standort: Widerruf mitten in der Sitzung, nicht erst in der nächsten Stunde.
• Impossible Travel und Geräteanomalien. Eine Sitzung um 14:00 Uhr in Frankfurt und um 14:10 Uhr in Manila ist kein Pendler. Markieren, Step-up erzwingen oder beenden.
• User-Agent- und IP-Drift innerhalb einer Sitzung. Ein Token, das vom Fingerprint eines Firmen-Laptops auf eine beliebige Cloud-VM springt, ist gestohlen. Alarmieren Sie auf den Wechsel.
• Loggen Sie den Sitzungslebenszyklus, nicht nur Logins. Token-Ausstellung, Refresh und Widerruf gehören in Ihre Telemetrie. Was nie aufgezeichnet wurde, lässt sich nicht untersuchen. Ja, Session-Telemetrie enthält personenbezogene Daten wie IP-Adressen: Sicherheitslogging lässt sich über das berechtigte Interesse sauber begründen, definieren Sie aber Zweckbindung und Löschfristen und dokumentieren Sie beides. Das größere Bild liefert Observability: Logs, Metriken und Traces.

Wenn ein Alarm auslöst, brauchen Sie eine geprobte Reaktion: Sitzungen widerrufen, Tokens rotieren, Phishing-resistente Re-Registrierung erzwingen. Schreiben Sie das auf, bevor Sie es brauchen. Und behalten Sie die Uhr im Blick: Betrifft die gekaperte Sitzung personenbezogene Daten, läuft ab Kenntnis die 72-Stunden-Frist für die Meldung an die Aufsichtsbehörde. Unser Incident-Response-Playbook behandelt die Schritte zum Token-Widerruf, die den meisten Teams erst um drei Uhr nachts einfallen.

Ein Entscheidungsrahmen für dieses Quartal

Sie können nicht alles auf einmal umsetzen. Priorisieren Sie nach Schadensradius.

1. Privilegierte Zugriffe inventarisieren. Admins, Finance, Produktion und alle, die Geld oder Daten bewegen können. Das ist Ihre Stufe eins.
2. Phishing-resistente MFA für Stufe eins verpflichtend machen. Passkeys oder Hardware-Keys. Keine Ausnahmen, kein TOTP-Fallback für diese Konten.
3. Number Matching und Prompt-Kontext überall sonst aktivieren. Das ist Ihr Fatigue-Patch für die breite Belegschaft.
4. Cookie- und Token-Hygiene als Policy festschreiben. HttpOnly, Secure, SameSite, kurze Laufzeiten, Refresh-Rotation mit Reuse Detection. Verifiziert im Code Review, nicht im Wiki.
5. CAE und Session-Anomalieerkennung aktivieren. Hören Sie auf, Tokens für ihre volle Lebensdauer zu vertrauen.
6. Widerruf proben. Spielen Sie ein Tabletop durch, in dem ein Token gestohlen wird. Stoppen Sie die Zeit, bis jede Sitzung beendet ist. Wenn Sie die Zahl nicht kennen, ist genau das der Befund.

Das Muster: Verhindern Sie mit Kryptographie, was sich verhindern lässt. Begrenzen Sie den Rest mit kurzlebigen, gebundenen, widerrufbaren Sitzungen.

Checkliste für das schnelle Selbstaudit

• Privilegierte Konten nutzen FIDO2 / Passkeys, nicht Push oder TOTP.
• Number Matching und Anmeldekontext sind für alle Nutzer aktiv.
• Session-Cookies sind HttpOnly, Secure und SameSite.
• Access Tokens laufen in Minuten ab; Refresh Tokens rotieren.
• Refresh-Token-Reuse löst den vollständigen Sitzungswiderruf aus.
• Token Binding (DPoP oder Device-bound Sessions) ist für sensible APIs im Einsatz.
• CAE oder ein Äquivalent widerruft Sitzungen bei Risikoereignissen mitten in der Sitzung.
• Ausstellung, Refresh und Widerruf von Sitzungen werden geloggt und sind alarmfähig.
• Sie haben in den letzten 90 Tagen eine Sitzungswiderrufs-Übung mit Stoppuhr durchgeführt.

Ob diese Kontrollen einem echten Operator standhalten, zeigt erst ein sauber aufgesetzter Angriffstest. Wie ein AiTM- und Token-Diebstahl-Szenario Ende zu Ende durchgespielt wird, lesen Sie in Penetrationstests: die Grundlagen.

Wie Innovation T unterstützt

Wir bauen und härten die Authentifizierungsschicht, die Teams tatsächlich ausliefern: Passkey-Rollouts, Phishing-resistente MFA für privilegierte Zugriffe, Token Binding, Refresh-Token-Rotation und Session-Anomalieerkennung, verdrahtet mit Ihrem Logging. Keine Foliensätze. Funktionierende Kontrollen, getestet gegen exakt die oben beschriebenen Angriffe.

Wenn Ihre 2FA nur einen überzeugenden Proxy von der vollständigen Sitzungsübernahme entfernt ist, lassen Sie uns das unter realen Bedingungen prüfen und die Lücke schließen. Sehen Sie sich unsere Leistungen an oder kontaktieren Sie das Team. Wir zeichnen Ihren schnellsten Weg von „wir haben MFA" zu „wir sind Phishing-resistent".