MFA-Umgehung ist Alltag. Die Firewall ist die letzte Identitätskontrolle.

Wenn sechzehn Milliarden Zugangsdaten durchsickern und gestohlene Sessions direkt an der Multi-Faktor-Authentifizierung vorbeilaufen, hört die Firewall auf, der langweilige Perimeter zu sein, und wird zur letzten Kontrolle, die noch hält. Identität hat als Eindämmungsgrenze leise versagt: Der Angreifer kommt mit einer gültigen Session, der Login gelingt also, und der zweite Faktor feuert nie. Was unter Ihrer Kontrolle bleibt, ist das Netzwerk. Egress-Filterung bricht den Rückkanal und den Abfluss, von denen der Angriff abhängt, Segmentierung begrenzt den Wirkungsradius, und das Firewall-Änderungsmanagement macht jede überstürzte Verschärfung gegenüber einem Prüfer im Nachhinein verteidigbar.

Das ist kein Aufruf, Identitätskontrollen aufzugeben. Es ist die Anerkennung, wo die Last jetzt liegt. 2026 ist nicht mehr das Passwort das, was gestohlen wird, sondern die authentifizierte Session. Das verlagert die Bürde auf die Ebene, der es egal ist, ob eine Session „legitim“ ist, und die nur fragt, ob Verkehr das Netz verlassen darf und wohin. Für Firewall-Teams ist das vertrautes Terrain, und genau darum geht es hier.

Warum gestohlene Zugangsdaten das Schloss nicht mehr auslösen

Die gestohlene Einheit ist eine Ebene nach oben gewandert. Angreifer jagen keine Passwörter mehr, sie heben die authentifizierte Session: das Cookie oder Bearer-Token, das beweist, dass der Login bereits erfolgt ist. Dieses Artefakt lebt über die Multi-Faktor-Abfrage hinaus, sein erneutes Abspielen überspringt die Authentifizierung also komplett. Die Sammlung aus rund sechzehn Milliarden Datensätzen, die Cybernews 2026 meldete, war kein einzelner Einbruch, sondern eine Aggregation von Infostealer-Logs, und Infostealer-Logs erfassen neben den Passwörtern auch Session-Tokens, und genau das ist der Teil, auf den es ankommt.

Deshalb wird Multi-Faktor-Authentifizierung laufend umgangen, ohne dass jemand den zweiten Faktor anrührt. Ein Adversary-in-the-Middle-Proxy oder Schadsoftware, die ein Token vom Host liest, fängt die laufende Session ab und nutzt sie erneut. Der Login ist längst geschehen, das Token ist gültig, und die Kontrollen, die auf fehlgeschlagene Logins oder Passwortwechsel achten, sehen nichts, weil nichts fehlschlug und nichts sich änderte. Die Erkennung, die einen Brute-Force gefangen hätte, ist blind für ein Replay. Genau diese Lücke muss die Netzwerkebene schließen.

Was die Firewall noch kontrolliert, wenn Identität versagt

Eine gestohlene Session ist mächtig, aber sie muss im Netz immer noch etwas Beobachtbares tun, und dort gewinnen Sie die Kontrolle zurück. Die kompromittierte Session muss nach Hause telefonieren, sich seitwärts bewegen und Daten hinausschaffen, und jeder dieser Schritte überquert eine Grenze, die eine Firewall besitzt. Dass die Zugangsdaten gültig sind, macht den Verkehr nicht erlaubt.

• Egress-Filterung. Infostealer und Session-Replay-Werkzeuge brauchen beide einen ausgehenden Pfad zu einem Command-and-Control-Endpunkt und eine Route, um Erbeutetes abzuziehen. Eine Default-Deny-Egress-Policy, die nur bekannte Ziele zulässt, macht aus einer vollen Kompromittierung eine eingegrenzte. Das ist dieselbe Disziplin wie im Praxisleitfaden zur Egress-Filterung, jetzt neu gerahmt als Ihre wichtigste Kontrolle beim Identitätsversagen.
• Mikrosegmentierung. Eine gekaperte Session in einer Zone sollte die Datenbankschicht, das Management-Netz oder den Backup-Speicher nicht erreichen können. Mikrosegmentierung entscheidet, wie weit eine gültige, aber gestohlene Session reisen kann, bevor sie auf eine Wand trifft, durch die sie nicht sprechen kann.
• Bedingter und geobewusster Zugriff. Eine Session, die plötzlich aus einem unerwarteten ASN, Land oder Geräteprofil stammt, lässt sich am Netzrand abweisen, selbst wenn das Token kryptografisch perfekt ist. Das ist nicht narrensicher, aber es erhöht die Kosten, gestohlene Sessions von überall außer dem eigenen Egress des Opfers zu nutzen.

Keine dieser Kontrollen fragt, ob die Session „echt“ ist. Sie fragen nach Quelle, Ziel und Richtung, und genau das kodiert ein Firewall-Regelwerk. Wenn Identität sich mit einem gestohlenen Cookie fälschen lässt, sind diese drei Fakten die letzten, die ein Angreifer durch den Besitz eines Tokens nicht fälschen kann.

Welche Ebene noch hält, wenn MFA umgangen wird

Es hilft, klar zu sagen, was jede Ebene kann und nicht kann, sobald eine gültige Session in den falschen Händen ist. Die folgende Tabelle ist die ehrliche Arbeitsteilung, nachdem die Zugangsdaten bereits versagt haben.

Auch die eigene Session der Firewall ist ein Ziel

Die unbequeme Ecke dieser Geschichte ist, dass die Management-Ebene der Firewall auf derselben Art Session läuft, die überall sonst gestohlen wird. Ein Administrator, der sich an einer Hersteller-Management-Konsole oder einem VPN-Portal anmeldet, hält ein Session-Cookie, das ein Infostealer genauso liest wie jedes andere. Eine Welle von Authentifizierungs-Bypass- und Session-Diebstahl-Schwachstellen in Edge-Geräten über 2025 und 2026 machte deutlich, dass das Sicherheitsgerät nicht ausgenommen ist, sondern ein besonders hochwertiges Ziel, gerade weil seine Session alles andere steuert.

Die Management-Ebene braucht also die Kontrollen, die Sie von jedem Kronjuwel-System verlangen würden: Management-Schnittstellen nur aus einem gehärteten Administrationsnetz erreichbar, kurze administrative Session-Lebensdauern und dieselbe Default-Deny-Egress-Regel, angewandt auf die Appliances selbst. Behandeln Sie Administratoren so, wie man nicht-menschliche Identitäten behandelt, mit begrenztem Zugriff und einer protokollierten Spur, denn eine gestohlene Admin-Session ist diejenige, die aus einem eingegrenzten Vorfall einen vollständigen macht.

DBSC repariert den Browser, nicht das Netzwerk

Es gibt eine echte Antwort auf der Identitätsseite, und es lohnt sich, sie zu verstehen, damit Sie sich nicht zu sehr darauf verlassen. Device Bound Session Credentials, die Google 2026 in Chrome 146 unter Windows allgemein verfügbar machte, binden eine Session an einen nicht exportierbaren Schlüssel im Trusted Platform Module des Geräts und beweisen alle paar Minuten erneut den Besitz, sodass ein gestohlenes Cookie nicht von einer anderen Maschine abgespielt werden kann. Der Mechanismus ist in der DBSC-Referenz von Chrome dokumentiert.

Das ist echter Fortschritt und es ist nicht Ihre Kontrolle. DBSC schützt interaktive Browser-Sessions auf Hardware mit TPM, in Browsern, die es ausgeliefert haben, gegen den spezifischen Trick, ein Cookie auf ein anderes Gerät zu kopieren. Es tut nichts für Dienst-zu-Dienst-Tokens, kopflose Workloads, VPN-Clients oder die lange Liste von Fat-Client-Anwendungen, die sich ganz ohne Browser authentifizieren. Und wie ein Forscher nach dem Start trocken anmerkte, drängt die Gerätebindung Angreifer dazu, die laufende Session auf der Maschine des Opfers selbst zu kontrollieren, statt das Cookie zu stehlen, und das ist ein Problem, das der Endpunkt und das Netzwerk fangen müssen, nicht der Browser. Die Verteidigung, die menschlichen Logins hilft, reicht nicht an die Orte, an denen sich Ihr Risiko tatsächlich ballt, die Netzwerkebene bleibt also im Spiel.

Jede Notfalländerung prüffähig machen

Wenn die Zugangsdaten-Ebene öffentlich versagt, reagieren Firewall-Teams schnell: Egress verschärfen, ein Ziel ziehen, ein Segment isolieren, einen Admin-Pfad kappen. Diese Geschwindigkeit ist richtig, und sie ist auch der Punkt, an dem ungeprüfte Änderungen einsickern. Eine in Panik verschärfte Regel, die nie dokumentiert wird, wird zum Policy-Drift, der Ihr nächstes Audit reißen lässt, und ein Rollback, den niemand festhielt, wird zum Ausfall, den niemand erklären kann.

Das ist der Teil, der eindeutig Firewall-Änderungsmanagement ist. Jede unter Druck vorgenommene Eindämmungsänderung braucht trotzdem einen Beleg, was sich änderte, warum, wer es freigab und wie man es zurückrollt. Zero Trust ersetzt das Change Management nicht, und ein Identitätsversagen-Vorfall braucht es mehr, nicht weniger, denn die Kontrollen, die Sie in der ersten Stunde hinzufügen, sind die, die eine Aufsichtsbehörde, ein Versicherer oder ein Incident-Reviewer von Ihnen begründet sehen will. Knüpfen Sie jede Notfall-Egress-Änderung an die Bedrohung, die sie auslöste, bewahren Sie die Threat Intelligence, die sie rechtfertigte, und Sie verwandeln eine hektische Nacht in eine verteidigbare Chronik. Dieselbe Logik, die die Autorisierung eines KI-Agenten steuert, steuert Ihre eigene Notfallreaktion: Die Handlung ist nur vertrauenswürdig, wenn sie begrenzt, protokolliert und umkehrbar ist.

Die Erkenntnis ist nicht, dass Identität tot ist und die Firewall gewinnt. Sie ist, dass in einem Jahr, in dem eine gültige Session das verlässlichste Werkzeug des Angreifers ist, die Kontrollen, die entscheiden, wohin Verkehr darf, und die Disziplin, die diese Kontrollen prüffähig hält, die Last tragen. Das ist die älteste Aufgabe des Firewall-Änderungsmanagements, und sie war selten wichtiger.