Passkeys und das Phishing-Relais: warum Origin-Binding gegen Einmal-Codes gewinnt
Phishing-Kits, die sich zwischen Nutzer und echter Login-Seite schieben, sind zu einer der zuverlässigsten Methoden geworden, um Multi-Faktor-Authentifizierung auszuhebeln. Die Nutzerin tippt einen Einmal-Code, das Kit leitet ihn innerhalb von Sekunden an die echte Seite weiter, und der Angreifer behält die Session, die zurückkommt. Ein Passkey bricht dieses Relais auf eine Weise, die kein codebasiertes Verfahren schafft: Auf dem Bildschirm gibt es schlicht nichts zu kopieren.
Wie AiTM-Kits Einmal-Codes abgreifen
Die Mechanik dokumentiert Microsoft im Detail: Der Anbieter verfolgte eine Kampagne, die ab September 2021 mehr als 10.000 Organisationen traf. Der Angreifer betreibt einen Reverse-Proxy, der eine pixelgenaue Kopie der echten Anmeldeseite unter eigener Domäne ausliefert und zwei TLS-Sitzungen hält: eine mit dem Opfer, eine mit der echten Seite. Passwörter und Session-Cookies fließen durch die Mitte, und der Angreifer meldet sich als Nutzer an. Microsoft betonte, dass das keine Schwachstelle in MFA ist; der Code ist echt, der Login ist echt, und das Kit behält einfach, was der Nutzer aushändigt (Microsoft). Die Technik ist nicht verschwunden. Im Januar 2026 beschrieben Microsoft-Forscher eine mehrstufige AiTM-Kampagne gegen Organisationen des Energiesektors, die über missbrauchte SharePoint-Links kam und in Business Email Compromise endete (Microsoft). Ein Jahr Kaspersky-Telemetrie, veröffentlicht im August 2026, zählte über 390.000 Phishing-Seiten auf seriösen Cloud-Plattformen, viele mit Open-Source-Proxy-Bibliotheken und Browser-in-the-Browser-Fenstern, die die Adressleiste fälschen (Kaspersky). Das moderne Kit leitet Code, Push-Freigabe und den resultierenden Cookie in Echtzeit weiter. Alles außer der URL ist echt.Origin-Binding: Die Domäne ist Teil der Credential
WebAuthn, der Standard hinter Passkeys, funktioniert anders. Bei der Registrierung erzeugen Seite und Browser ein Public-Private-Key-Paar, das an eine Relying-Party-ID gebunden ist - praktisch die Domäne der Seite. Der private Schlüssel verlässt das Gerät nie, und der Browser bietet eine Credential nur an, wenn der Origin der Seite mit dieser ID übereinstimmt. Mozillas Dokumentation bringt das Ergebnis auf den Punkt: Wer eine gefälschte Login-Website baut, kann sich nicht als Nutzer anmelden, weil sich die Signatur mit dem Origin der Website ändert (Mozilla). Die FIDO Alliance beschreibt Passkeys als je Website oder Anwendung einzigartig - genau das entzieht auch Credential Stuffing die Grundlage (FIDO Alliance). Cisco Talos hat gezeigt, was das für Proxy-Kits bedeutet: Ein Opfer, das auf einer gefälschten Domäne landet, die seine Bank imitiert, kann die WebAuthn-Zeremonie gar nicht abschließen, weil der Browser eine an die echte Domäne gebundene Credential auf der falschen nicht anbietet. Die Authentifizierung scheitert, bevor irgendwelche Geheimnisse übertragen werden (Cisco Talos).Ein Proxy-Kit kann alles weiterleiten, was der Nutzer tippt. Eine Credential, die der Browser nie anbietet, kann es nicht weiterleiten.Selbst wo die Zeremonie läuft, kreuzt nichts Wiederverwertbares die Leitung. Der Server sendet eine große zufällige Challenge, der Authenticator signiert sie mit dem privaten Schlüssel, und die Signatur weist den Besitz nach, ohne ein Geheimnis preiszugeben, wie Mozillas Spezifikation vermerkt. Ein Proxy kann diese Signatur weiterleiten, aber die echte Seite sähe dann eine Antwort, die einen Origin behauptet, den sie nie ausgeliefert hat, mit einer Credential, deren Relying-Party-ID sie genau für diesen Fall prüft. Es gibt keinen Code, der gegen eine Dreißig-Sekunden-Uhr rennt, und keinen Cookie, der auf der Angreiferseite geprägt wird.