Sichere MFA trotz Reverse Proxy: Was 2026 wirklich noch schützt

Vom Angriff zur Verteidigung

In zwei früheren Beiträgen haben wir die Angriffsseite beschrieben: einmal zu Modlishka als flexiblem HTTP Reverse Proxy für Phishing-Simulationen, einmal zum Vergleich von EvilnoVNC mit klassischen Reverse Proxies. Beide Artikel zeigen, wie Adversary-in-the-Middle-Phishing in unseren Audits aufgesetzt wird. Was sich seitdem geändert hat: AiTM ist kein Werkzeug für Red Teams mehr, sondern Mainstream im kriminellen Markt. Die Defensive muss nachziehen, und seit dem ENISA Technical Implementation Guide aus dem ersten Quartal 2026 ist sie auch regulatorisch in der Pflicht.

Dieser Beitrag beschreibt, was 2026 vor Reverse-Proxy-Phishing tatsächlich schützt, was die NIS-2-Umsetzung dazu konkret verlangt und welche Implementierungsfehler wir in Audits regelmäßig sehen.

Warum klassische MFA nicht mehr reicht

Reverse-Proxy-Phishing ist heute kein Nischenthema. Das Geschäftsmodell heißt Phishing-as-a-Service, und es ist hochgradig professionalisiert. Tycoon 2FA hält in den aktuellen Lagebildern rund drei Viertel des Marktes, EvilProxy und Open-Source-Frameworks wie Evilginx teilen sich den Rest. Public-Reports rechnen den überwiegenden Teil aller Account-Compromise-Vorfälle inzwischen auf solche Kits.

Der Angriff selbst ist kompakt. Der Angreifer registriert eine Domain wie login-microsoft365-secure.example und betreibt darauf einen Reverse Proxy, der die echte Microsoft-Login-Seite spiegelt. Das Opfer öffnet eine Phishing-Mail, klickt, gibt Passwort und MFA-Faktor ein. Der Proxy reicht beides an die echte Seite weiter und schneidet das daraus entstehende Session-Cookie mit. Die technische Tiefe steht in den verlinkten Pentester-Artikeln.

Die zentrale Beobachtung ist die Verschiebung des Angriffsziels. AiTM zielt nicht auf den zweiten Faktor, sondern auf die Session, die aus erfolgreicher MFA entsteht. Sobald der Angreifer das gültige Cookie hat, ist der zweite Faktor irrelevant. Der Login ist abgeschlossen, die Session ist legitim, der Angreifer arbeitet als der Mitarbeiter. Was klassische MFA-Verfahren liefern, ist eine zeitlich begrenzte Bestätigung. Der Reverse Proxy stiehlt nicht die Bestätigung, er übernimmt das Ergebnis.

Was „phishing-resistent" technisch bedeutet

Der Begriff ist in den letzten zwei Jahren strapaziert worden. Eindeutig ist er erst seit dem ENISA-Implementation-Guide aus Q1 2026: Phishing-resistent ist eine Methode, die durch Origin Binding sicherstellt, dass die Anmeldung nur an die echte, vom Anwender registrierte Domain möglich ist.

Methode	Phishing-resistent	Begründung
FIDO2 Hardware Key	Ja	Domain in der Signatur-Challenge
Device-bound Passkey	Ja	Origin-gebunden in Secure Enclave
Smartcard plus PIN	Ja	Domain-Bindung über Zertifikatskette
Push mit Number Matching	Bedingt	Schützt gegen MFA-Fatigue, nicht gegen AiTM
TOTP per Authenticator-App	Nein	Code ist nicht origin-gebunden
SMS-Code	Nein	Code ist nicht origin-gebunden
E-Mail-Code	Nein	Code ist nicht origin-gebunden

Das Muster in der rechten Spalte ist die eigentliche Aussage. Phishing-resistent ist, was den Reverse Proxy nicht passiert. Alles andere kann live durchgereicht werden.

Ein FIDO2-Authenticator verlässt sich auf zwei Dinge: einen privaten Schlüssel, der das Gerät nie verlässt, und die Domain-Information aus dem Browser-Kontext. Wenn ein Anwender bei login.microsoftonline.com registriert wird, speichert der Authenticator den Public Key zusammen mit genau dieser Domain. Bei der nächsten Anmeldung schickt der Browser eine Challenge-Anfrage. Der Authenticator signiert nur dann, wenn die Domain in der Anfrage zur registrierten Domain passt. Wenn ein Reverse Proxy unter einer anderen Domain denselben Inhalt anzeigt, sieht der Authenticator eine andere Domain im Browser-Kontext und verweigert die Signatur. Der Angriff scheitert nicht am User, nicht am Antivirus und nicht am Mail-Filter, sondern am Authenticator selbst. Diese Eigenschaft ist nicht eine zusätzliche Härtung, sondern die definierende Architektur-Eigenschaft von WebAuthn und FIDO2.

Der NIS-2-Rahmen und ENISA Q1 2026

Mit dem NIS-2-Umsetzungsgesetz vom 06.12.2025 ist die Pflicht zu einem dokumentierten Risikomanagement formell etabliert. §30 BSIG listet zehn Mindestmaßnahmen, eine davon ist Authentifizierung. Was „angemessen" hier konkret bedeutet, war bis Anfang 2026 offen.

Die ENISA hat im ersten Quartal 2026 mit dem Technical Implementation Guide nachgeschärft. Für privilegierte Zugriffe, Remote-Zugriffe und externe Vendor-Accounts ist phishing-resistente MFA der erwartete Standard. SMS-OTP und Push werden explizit als nicht ausreichend benannt.

§38 BSIG legt die Folgen fest. Geschäftsleitungen müssen Risikomanagement-Maßnahmen freigeben, ihre Umsetzung überwachen und sich selbst regelmäßig schulen. Verzicht auf diese Pflicht über Satzung oder Gesellschaftsvertrag ist gesetzlich ausgeschlossen, Verstöße werden gegen das Privatvermögen der Geschäftsführung gesichert. Bußgelder erreichen 10 Millionen Euro oder 2 Prozent Jahresumsatz für besonders wichtige Einrichtungen. In der Summe ist phishing-resistente MFA für Admins 2026 keine technische Empfehlung mehr, sondern eine Compliance-Pflicht mit persönlicher Geschäftsführerhaftung.

Dazu kommt eine strukturelle Anforderung: Organisationen müssen ein Identity Risk Inventory führen, in dem jede Account-Klasse klassifiziert, mit MFA-Methode dokumentiert und regelmäßig überprüft wird. Auditoren erwarten dieses Dokument. Wer es nicht hat, hat keinen sauberen Compliance-Nachweis, unabhängig davon, wie sicher die technische Umsetzung tatsächlich ist.

Implementierung in Microsoft Entra

Microsoft Entra ID hat seit Mitte 2025 alle relevanten Bausteine. Drei Konfigurationen müssen zusammen wirken. Auf Tenant-Ebene legt die Authentication Methods Policy fest, welche Methoden überhaupt zugelassen sind. SMS und Push werden für privilegierte Rollen explizit deaktiviert. Microsoft definiert eine Built-in Authentication Strength namens „Phishing-resistant MFA", die FIDO2, Windows Hello for Business und zertifikatsbasierte Authentifizierung umfasst. Eine Conditional-Access-Policy verlangt für alle Mitglieder privilegierter Rollen genau diese Strength, eine zweite Policy setzt sie für die Anmeldung an die Microsoft-Admin-Portals durch, unabhängig von der Rollenzuweisung.

Wer Entra-Passkeys auf Windows einsetzen möchte: Die Funktion ist seit April 2026 in General Availability, eingebettet in Windows Hello for Business. Damit wird die Hardware-Token-Frage für reine Office-Nutzer entschärft, ohne den Sicherheitsanspruch zu senken. In hybriden Umgebungen oder bei externen Vendor-Zugängen bleibt der Hardware-Token die saubere Lösung, gerade dort, wo das Endgerät nicht der eigenen Verwaltung unterliegt.

Häufige Bypass-Pfade aus Pentest-Erfahrung

Eine korrekt konfigurierte Authentication-Strength-Policy ist notwendig, aber nicht hinreichend. In Audits sehen wir regelmäßig dieselben Bypässe. Ein klassischer Fall ist der Self-Service-Password-Reset ohne phishing-resistente Authentifizierung. Der Angreifer phisht den schwächeren Reset-Pfad, erzeugt sich neue Credentials und umgeht die eigentliche Anmelde-Policy vollständig. Conditional Access muss auch SSPR-Flows abdecken, nicht nur den normalen Login.

Ähnlich häufig sehen wir nicht abgeschaltete Legacy-Authentication. SMTP, IMAP, POP3 und Exchange ActiveSync mit Basic Auth umgehen Conditional Access vollständig. Microsoft hat Basic Auth tenantseitig abgeschaltet, aber Lizenz-Sonderfälle und Hybrid-Konfigurationen lassen das immer wieder offen. Cross-Tenant-Trusts mit alter MFA sind ein verwandtes Problem: Federated Trusts erlauben oft eine schwächere Anmeldung im Heimat-Tenant, die im Ziel-Tenant als ausreichend akzeptiert wird. Die Policy im eigenen Tenant nutzt nichts, wenn die Vertrauensgrenze sie nicht abdeckt.

Schwache Fallback-Methoden sind die nächste Falle. Wer Authentication Strength nicht enforced, sondern nur „preferred" konfiguriert, öffnet die Hintertür. Im Real-World-Test ist die „preferred"-Konfiguration nicht effektiv. Und schließlich der Help-Desk: Der Angreifer ruft an und bittet um Reset einer FIDO-Registrierung. Wenn der Help-Desk-Prozess kein Out-of-Band Verification kennt, ist der Angriff trivial. Mehrere große Vorfälle 2024 und 2025 sind genau so gelaufen, am bekanntesten in der Casino-Branche in den USA. Diese Pfade sind genau die, die wir in unseren Social-Engineering-Assessments ausnutzen.

Migration in sechs Wochen

Die Umstellung von klassischer MFA auf phishing-resistente Faktoren ist machbar. Ein realistischer Plan für eine mittelständische Organisation läuft über sechs Wochen.

1. Inventory. Alle privilegierten Rollen identifizieren, externe Accounts erfassen, Service Accounts kategorisieren, Break-Glass-Accounts dokumentieren. Identity Risk Inventory aufsetzen.
2. Pilot. Drei bis fünf IT-Admins erhalten FIDO2-Tokens, registrieren sie und arbeiten zwei Wochen damit. Probleme dokumentieren, Help-Desk-Skripte für Reset und Verlust schreiben.
3. Conditional Access für Admin-Rollen. Strength-Policy aktivieren, exklusiv für Mitglieder privilegierter Rollen. Break-Glass-Accounts werden mit FIDO2 vorbereitet, aber von der Policy ausgeschlossen, um Lockout zu vermeiden.
4. Roll-Out an Standard-Nutzer. Passkey-Aktivierung über Authenticator-App oder Windows Hello. Help-Desk-Schulung. User-Dokumentation, FAQ, kurze Video-Anleitung.
5. Legacy-Auth-Block. Alte Auth-Endpoints abschalten, SSPR-Pfade härten, Cross-Tenant-Trusts auditieren, schwache Fallback-Methoden entfernen.
6. Audit und Compliance-Dokumentation. Identity Risk Inventory mit Review-Daten versehen, Conditional-Access-Policies dokumentieren, Penetration Test gegen die neuen Login-Flows planen.

Wer eine größere Organisation oder eine regulierte Vertikale hat, multipliziert die Wochen, aber das Schema bleibt identisch.

Fazit

Reverse-Proxy-Phishing ist 2026 keine Bedrohung am Rand mehr, sondern Standard. Klassische MFA scheitert daran nicht versehentlich, sondern systematisch. Die Defense, die heute noch wirkt, ist Origin-Binding-basierte Authentifizierung über FIDO2 oder device-bound Passkeys. Die regulatorische Dimension ist erstmals deckungsgleich mit der technischen. NIS-2 §30 BSIG verlangt angemessenes Risikomanagement, ENISA Q1 2026 konkretisiert das auf phishing-resistente MFA für privilegierte Zugriffe, §38 BSIG macht Geschäftsleitungen persönlich haftbar. Wer die Defense aufbaut, beginnt mit dem Identity Risk Inventory und arbeitet sich entlang der sechs Wochen. Wer prüfen will, wo der Angriff in der eigenen Umgebung heute noch durchkommt, plant einen Penetrationstest gegen die Login-Flows ein.