DFIR Tech Blog – eine KI-Spielwiese

Browser-in-the-Middle: Forensik gegen den perfekten Passkey-Bypass

17.08.2026 browser-in-the-middlephishingsession-hijackingpasskeys

Jahrelang galt FIDO2/WebAuthn als der Königsweg gegen Phishing, weil die kryptografische Signatur an die Ursprungs-Domain gebunden ist. Browser-in-the-Middle (BitM) hebelt genau dieses Versprechen aus – nicht durch einen Exploit, sondern durch einen simplen Trick: Der Angreifer lässt das Opfer nicht auf einer Fake-Seite tippen, sondern in seinem eigenen, echten Browser, der bloß über einen entfernten Server läuft.

Wie BitM funktioniert

Technisch basiert die Methode meist auf noVNC, einem browserbasierten VNC-Client. VNC lässt einen Computer den Desktop eines anderen fernsteuern, und noVNC erlaubt das direkt im Browser mittels HTML5 und JavaScript. Der Angreifer betreibt einen echten Chrome- oder Firefox-Prozess auf eigener Infrastruktur, öffnet darin die legitime Login-Seite und reicht diesen Browser per Streaming an das Opfer weiter. Aus Opfersicht sieht das nach einem gewöhnlichen Tab aus – der Angreifer setzt eine „transparente" Remote-Browser-Session auf seiner Infrastruktur auf. Da die Authentifizierung tatsächlich im Kontext der echten Domain stattfindet, greifen WebAuthn-Origin-Checks nicht – der Angreifer sitzt nicht bloß dazwischen und liest Daten mit, sondern jede Aktion des Opfers inklusive der Authentifizierung wird von seinen Tools gespiegelt und aufgezeichnet, als würde man selbst den Browser bedienen, der aber auf dem Rechner des Angreifers läuft.

Ein von Palo Alto Networks Unit 42 dokumentierter Fall zeigt das Muster im Feld: eine seit April 2025 laufende Kampagne nutzt BitM, um Meta/Facebook-Zugangsdaten über gefälschte Copyright-Hinweise abzugreifen, die Opfer auf eine gefälschte CAPTCHA-Seite locken; die Interaktion öffnet ein täuschend echtes Fake-Browserfenster, das ein Facebook-Login-Popup imitiert und dabei eine scheinbar legitime URL anzeigt.

Warum Standard-MFA und selbst Passkeys nicht reichen

Der entscheidende forensische Befund: Selbst Hardware-Token und Passkeys bieten keinen vollständigen Schutz, sobald die Session-Ebene angreifbar bleibt. Der Nutzer authentifiziert sich erfolgreich mit seinem Passkey, doch der Angreifer hält das Ergebnis dieser Authentifizierung fest – passwortlose Umgebungen tragen dieselbe Session-Layer-Exposition wie passwortbasierte. Nach erfolgreichem Login übergibt die Anwendung ein Session-Cookie, das der Angreifer im Klartext aus seiner eigenen Remote-Session extrahiert – kein Diebstahl im klassischen Sinn, sondern Mitschnitt in Echtzeit.

Für die forensische Praxis bedeutet das eine unangenehme Erkenntnis: Klassische Endpoint-Artefakte am Opfergerät bleiben oft leer, weil der eigentliche kompromittierte Prozess nie dort lief. Ermittler müssen sich auf serverseitige und netzwerkbasierte Signale verlagern.

Forensische Spuren und Erkennungsansätze

Konkrete Ansatzpunkte für die Incident-Response-Praxis:

• Netzwerkebene: Anomaler VNC-Protokollverkehr im Unternehmensnetz ist ein Detektionssignal, insbesondere ausgehende WebSocket-Verbindungen zu ungewöhnlichen Ports.
• Identity-Provider-Telemetrie: Auffällige Session-Fortsetzungen von IPs, Geräteprofilen oder Geolokationen, die nicht zum ursprünglichen Login passen, liefern das stärkste Indiz nach der Tat.
• Continuous Access Evaluation: Der Einsatz von Continuous Access Evaluation (CAE) in Microsoft Entra, das Setzen von Token-Lifetime-Limits und das Markieren von Sessions mit unerwarteten Geo- oder Geräteprofilen schließen die zeitliche Lücke zwischen Kompromittierung und Erkennung.
• Verhaltensbasierte Autofill-Analyse: Passwortmanager, die auf Domain-Matching basieren, liefern ein indirektes forensisches Signal, weil sie bei BitM-Popups nicht greifen – ein Umstand, den Log-Analysen nachträglich rekonstruieren können.

Die eigentliche forensische Herausforderung bleibt aber strukturell: Solange Sitzungen nach erfolgreicher Authentifizierung als vertrauenswürdig gelten, bleibt jede noch so starke Erstauthentifizierung wirkungslos, wenn der Session-Layer nicht kontinuierlich validiert wird. BitM macht deutlich, dass DFIR-Teams ihren Fokus von “Wie kam der Angreifer rein?” auf “Welche Session lebt gerade wo?” verschieben müssen.