Warum ein Anruf zum Passkey-Update die Sitzung stiehlt – und nicht den Passkey

Die Suchintention in einem Satz beantworten

Ein Passkey hält den privaten Schlüssel nach WebAuthn auf diesem Gerät oder in einem synchronisierten Schlüsselbund und bindet ihn an den Ursprung der Relying Party. Ein gefälschter Anmeldehost kann diesen Schlüssel nicht exportieren. In diesem Rahmen ist „phishing-resistent“ wahr. Außerhalb dieses Rahmens gilt: Man hetzt Sie durch eine Anmeldung, und das Sitzungstoken landet bei der Gegenseite; oder Sie tippen einen Code, den sie Ihnen gegeben haben, auf einer echten Microsoft-Seite, und das Token wird an einen Client ausgegeben, den sie kontrollieren.

Diese Notiz richtet sich an alle, die schon einen Passkey hinterlegt haben und trotzdem den Anruf oder die SMS „bitte aktualisieren“ bekommen – und an Entwicklung und Betrieb, die erklären müssen, warum ein Passkey keine Freikarte gegen Vishing ist. Sie ersetzt nicht den Vorfallbericht von Microsoft und ist keine Anleitung zum Abschalten von Passkeys. Mitnehmen sollten Sie: Welche Schicht das Skript abdeckt, welche Schicht Sitzung und Gerätecode jeweils stehlen, warum ein Passwortwechsel nicht reicht, und was Sie auf diesem Gerät nach dem Auflegen prüfen können.

Welche Schichten Microsoft diesmal getrennt hat

Am 9. September 2026 hat Microsoft Security Research eine englische Lagebeschreibung veröffentlicht. Verfolgt werden laufende Cloud-Identitätsangriffe: ungewöhnliche Anmeldungen, danach Anmeldemethoden, die die Gegenseite hinzugefügt hat, starker Microsoft-Graph-Verkehr, Downloads aus SharePoint und OneDrive sowie das Einsammeln von Postfächern über REST-APIs. Der Text schreibt, diese Aktivität werde seit Mai 2026 beobachtet.

Am Anfang steht keine ausgefeilte Phishing-Mail. Am Anfang steht ein Anruf oder eine SMS auf die private Mobilnummer. Der Anrufer behauptet, vom Firmen-Helpdesk zu sein, und erzeugt Zeitdruck: Passkey, Mehrfaktor oder Single Sign-on müsse sofort aktualisiert werden, sonst falle das Konto aus. Der Link kommt oft in einer zweiten SMS auf dasselbe private Telefon. Microsoft ist knapp: Obwohl das Skript von Passkeys spricht, ist das Hinterlegen eines Passkeys oft nicht das eigentliche Ziel. Die Geschichte existiert, um jemanden in einen von zwei technischen Wegen zu führen – Adversary-in-the-Middle (AiTM) oder Gerätecode-Autorisierung.

Der AiTM-Weg fängt Zugangsdaten und Sitzungstoken. Beim Gerätecode redet man das Opfer dazu, einen kurzen Code auf der eigenen Microsoft-Anmeldeseite einzutippen; das Token geht an einen Client der Gegenseite, ein Browser-Cookie braucht sie nicht. Beide Wege können spätere Zugriffe ohne erneutes MFA durchlassen. Wird der Link auf einem privaten Telefon geöffnet, das nicht an Defender angebunden ist, kann die Endpunkttelemetrie fast leer sein. Dann ist die Erinnerung an Anruf oder SMS oft der früheste – und manchmal der einzige – Beleg, wo der Einstieg lag.

Die Infrastruktur ist auf Wiedererkennen gebaut. Thematische Hosts in der Beschreibung sind unter anderem passkeyhelpdesk.com, setupmypasskey.com, add-passkey.com und secure-passkey.com, dazu Firmennamen in der Subdomain, etwa contoso.add-passkey.com. Derselbe Firmenname kann auch unter einem SSO-thematischen Host wie integratedsso.com sitzen. Domains können Stunden nach der Registrierung live gehen; das Blockfenster ist kurz. In manchen Fällen nutzt die Gegenseite zusätzlich ein schon kompromittiertes Kollegenkonto und schickt dieselbe „Passkey aktualisieren“-Nachricht in Teams – internes Vertrauen oben auf den Anruf gelegt.

Microsoft knüpft den Erstzugriff an mehrere Cluster, darunter Storm-3121 und Storm-3032. Storm-3121 speist oft ShinyHunters- und Falcon-Erpressung. Storm-3032 wird als Abspaltung von BlackFile beschrieben, die jetzt unter Helix läuft. Das ist Ökologie, kein Beweis, dass jeder „IT-Anruf“ dieselbe Crew ist. In eine Übergabenotiz gehören das Skript plus die zwei technischen Wege – kein Gruppennname.

Ein Passkey stoppt die Fake-Seite. Er stoppt nicht die abgegebene Sitzung

„Phishing-resistent“ als „mich redet niemand mehr hinein“ zu lesen, schweißt die Zugangsdaten-Schicht an die Sitzungs-Schicht. Ein Passkey wird bei der Registrierung an den Seitenursprung gebunden. Eine Nachbildung der Microsoft-Anmeldung auf einem anderen Host zieht den privaten Schlüssel, den Sie für login.microsoftonline.com abgelegt haben, trotzdem nicht. Dieser Vorsprung gegenüber Passwortwiederverwendung ist echt. Man muss ihn nicht zurücknehmen.

Eine Zeitlinie in der Untersuchung zeigt, wo der Vorsprung endet. Bei T+0 Minuten trifft ein nicht verwalteter Kontext auf OfficeHome und bekommt Fehler 50074, der einen zweiten Faktor verlangt. Bei T+1 ist MFA durch – die Beschreibung nennt Adversary-in-the-Middle plus nicht phishing-resistentes MFA –, danach unterbricht 50140 „Angemeldet bleiben“. In derselben Minute gelingt die Authentifizierung, eine Sitzung steht. In der folgenden Stunde öffnet genau diese Sitzung My Apps, das Profil, die Genehmigungsverwaltung und Sicherheitsinformationen und läuft dann über Graph durch SharePoint und Outlook. Sobald die Sitzung existiert, brauchen sie Ihren Passkey nicht noch einmal.

„Ich nutze schon einen Passkey“ trägt deshalb nur einen engen Satz: Ein Fake-Host exportiert diesen privaten Schlüssel kaum. Er trägt nicht: Sie werden nicht auf einer Nachbildung durch Passwort oder SMS-Code gehetzt; ein AiTM-Kit kann das gerade geprägte Token nicht nehmen; unter Sicherheitsinformationen wächst deren Authenticator nicht. Für die letzten Sätze brauchen Sie andere Belege: ob der Hostname, den Sie geöffnet haben, ein offizieller Anmeldehost ist, und ob Sicherheitsinformationen ein Gerät zeigen, das Sie nicht hinzugefügt haben.

Warum der Gerätecode auf einem echten Host durchkommt

Adversary-in-the-Middle muss wenigstens eine Seite aufstellen, die nach Anmeldung aussieht. Der Gerätecode nimmt auch diese Schicht weg. Der offizielle Ablauf ist: Ein Client zeigt einen kurzen Code; Sie öffnen die Microsoft-Geräteanmeldungsseite im Browser; Sie tippen den Code; das gibt „jenem Client“ frei, in Ihrem Namen auf Ressourcen zuzugreifen. Die Seite ist echt. Das Zertifikat ist echt. Die Adresszeile übersteht „ist das Microsoft“. Der Trick wandert auf eine andere Frage: Wer hat diesen Code erzeugt, und welche App bekommt die Freigabe.

Die zweite Angriffsfolge in der Beschreibung ist genau das: Nach dem Passkey-Skript tippt das Opfer einen von der Gegenseite gelieferten Code auf einer legitimen Authentifizierungsseite, und das Token geht an deren Client. Danach spielen sie das Token erneut, enumerieren Verzeichnis und Dateien und überspringen sowohl den Cookie-Diebstahl als auch eine weitere MFA-Abfrage. Wer gelernt hat, Schloss und Hostname zu prüfen, erkennt das im Moment schwerer – die Schicht, die man prüfen sollte, ist grün.

„Die Adresszeile ist Microsoft“ trägt deshalb nur: Sie haben kein Passwort in eine Nachbildung wie add-passkey.com getippt. Es trägt nicht: Dieser Code gehört Ihrem eigenen Laptop; nach der Freigabe bleibt das Token in Ihrem Browser. Einen Code, den man Ihnen am Telefon, per SMS oder im Chat vorliest, behandeln Sie standardmäßig als deren Client – nicht als „offizielle Seite, also sicher“.

Warum ein Passwortwechsel den eingetragenen Authenticator nicht abdeckt

Nach dem Einstieg ist der erste Zug oft nicht mehr Dateisuche. Es ist das Einschreiben der eigenen Anmeldemethode in Ihre Identität. Die Beschreibung nennt eine neue Telefonnummer, eine Authenticator-App oder ein Software-Einmalkennwort-Token. Ein echtes Audit-Beispiel vom 4. September 2026 zeigt einen neu hinzugefügten Eintrag mit Gerätename NO_DEVICE, Geräte-Tag SoftwareTokenActivated und Hashfunktionsfeld hmacsha1. Das ist nicht „sie haben noch ein Passwort gesetzt“. Das ist „den nächsten zweiten Faktor können sie selbst erledigen“.

Microsofts Bereinigung für ein bestätigtes kompromittiertes Konto ist eine zusammenhängende Folge: aktive Sitzungen und Aktualisierungstoken widerrufen, Anmeldedaten zurücksetzen, die von ihnen eingetragenen Methoden löschen, Postfachregeln entfernen, die sie angelegt haben, und mit einer phishing-resistenten Methode neu hinterlegen. Wer das Passwort wechselt und Sicherheitsinformationen überspringt, lässt einen Schlüssel stecken, den sie schon eingepasst haben. Eine dritte Untersuchungsfolge zeigt, dass sie Tage später mit einem früher eingetragenen PhoneAppOTP zurückkommen und Graph mit einer Node.js-Automatisierung ablaufen – Passwort richtig, zweiter Faktor „bestanden“, und der Faktor gehört ihnen.

Lokales Passwortstärke prüfen vergleicht die Zeichenfolge mit einer öffentlichen Liste häufiger geleakter Passwörter. Das geprüfte Passwort wird nicht hochgeladen, und der Abgleich ist kein netzweites Have-I-Been-Pwned. Es kann Ihnen sagen, dass die Zeichenfolge zu häufig ist. Es kann Ihnen nicht sagen, ob unter Sicherheitsinformationen eine Zeile NO_DEVICE gewachsen ist, und es beweist nicht, dass der Anruf falsch war. Ein schwaches Passwort und eine gekaperte Sitzung sind nicht dieselbe Datenspalte. Ersetzen Sie die eine nicht durch die andere.

Nach dem Auflegen: welche Schichten Sie jetzt prüfen können

Ein Slogan ist kein Beleg. Prüfen Sie nur, was Sie steuern: ob der Anruf einen Kanal genutzt hat, dem Sie schon vertrauen, den Hostname, den Sie gleich öffnen, und ob unter Sicherheitsinformationen ein Gerät gewachsen ist. Nutzen Sie kein Produktionskonto, um den Link aus dem Anruf als Experiment zu öffnen.

1. Auflegen. Melden Sie sich bei der IT über das Ticketportal, die interne Seite oder die Rückrufnummer, die Ihre Firma schriftlich veröffentlicht hat. Rufen Sie nicht die Nummer zurück, die gerade geklingelt hat. Tippen Sie den SMS-Link nicht an. Microsoft rät Arbeitgebern, Beschäftigten einen geprüften Kanal für unaufgeforderte Authentifizierungsanfragen zu geben.
2. Haben Sie den Link schon geöffnet: Schauen Sie nur auf den Hostnamen. Ein Firmenname in der Subdomain mit einer Endung wie add-passkey.com, setupmypasskey.com oder secure-passkey.com ist kein Microsoft-Anmeldehost. Tippen Sie auf dieser Seite kein Passwort, keinen SMS-Code und keine Passkey-Bestätigung.
3. Will jemand, dass Sie „auf der offiziellen Seite einen Code eintippen“: Fragen Sie, welche App und welches Gerät ihn erzeugt hat. Ein Code, den Ihnen jemand anderes vorgelesen hat, ist deren Client. Die offizielle Gerätecode-Seite kann trotzdem echt sein, während die Freigabe auf deren App landet.
4. Nachdem Sie sich über einen Weg angemeldet haben, dem Sie vertrauen, öffnen Sie Sicherheitsinformationen / Meine Anmeldungen und lesen Sie jede Methode. Zusätzliche Telefonnummern, Authenticator und Software-Token – besonders ein Gerätename, der nicht Ihr Telefon ist – bekommen einen Sitzungswiderruf und eine Löschung über den Admin-Prozess. Hören Sie nicht beim Passwortwechsel auf.
5. Müssen Sie ein kurzes Einmalgeheimnis an eine bereits geprüfte Kollegin oder einen Kollegen übergeben, wechseln Sie auf einen Chiffretext-Weg. Öffnen Sie Burn-Link und schreiben Sie einen wegwerfbaren Canary, etwa canary-fp-20260921-passkey-lure. Öffnen Sie in den DevTools Network und setzen Sie Preserve log. Nach dem Erzeugen des Links suchen Sie nach diesem Canary: Der Körper von POST /secrets soll Chiffretext, Ablauf und Leseanzahl tragen – nicht den Klartext und nicht den Schlüssel hinter #. Die Linkform ist s.html?id={id}#{key}. RFC 9110 schließt das Fragment aus der Ziel-URI der Anfrage aus.

Die ersten vier Schritte schließen den Kanal, der die Identität übernimmt. Der fünfte Schritt betrifft einen anderen häufigen Fehler: „den Code, den die IT wollte“, oder ein temporäres Passwort als Screenshot in den Chat zu legen. Bildhoster und Alben behalten Pixel und oft OCR. Die vorige Notiz hat das beschrieben. Burn-Link lädt nur Chiffretext hoch; der Schlüssel bleibt hinter #. Mischen Sie die zwei Wege nicht – machen Sie keinen Screenshot in den Chat und kleben Sie danach nicht die volle Burn-URL auf dasselbe Bild.

Drei Arten, „Ich habe einen Passkey“ zu weit zu lesen

Erstens: phishing-resistent als resistent gegen Social Engineering zu lesen. Ein Passkey ist an den Ursprung gebunden. Das zielt auf eine gefälschte Anmeldeseite, die den privaten Schlüssel exportieren will. Ein Anruf, eine SMS oder ein interner Chat kann um diese Schicht herumführen und Sie in AiTM oder den Gerätecode setzen. Microsofts eigene Entschärfungsliste stellt Schulung gegen Sprach- und Mail-Phishing neben „phishing-resistentes MFA erzwingen“ und sagt außerdem, den Gerätecode-Flow zu sperren, wenn Sie ihn nicht brauchen.

Zweitens: „Die Seite ist offiziell“ als „die Freigabe gehört mir“ zu lesen. Die Gerätecode-Seite kann ein echter Host sein. Das Schloss-Symbol sagt Ihnen nicht, an wen das Token ausgegeben wird. Der Beleg ist die Herkunft des Codes: Eine Abfrage auf Ihrem eigenen Gerät und eine Zahl, die Ihnen jemand vorgelesen hat, sind nicht dasselbe Ereignis.

Drittens: einen Passwortwechsel als Abschluss zu lesen. Passwort, Sitzung, von ihnen eingetragene Authenticator und Postfach-Weiterleitungsregeln sind verschiedene Schalter. Die Beschreibung will sie zusammen behandeln. Ein neues Passwort lokal zu erzeugen deckt nur Dienste, die noch ein Passwort nutzen: Öffnen Sie den Passwort-Generator – sofort nutzbar, Länge 6–128, Standard 16, unter 8 Zeichen eine Warnung, Rechnung im Browser, nichts hochgeladen. Das widerruft keine Sitzungen. Das löscht keine Methode, die Sie nicht hinterlegt haben.

Häufige Fragen

Ich habe bereits einen Passkey hinterlegt. Kann dieser Anruf trotzdem greifen?

Ja, und oft nicht, weil der Passkey kopiert wurde. Das Skript benutzt Passkeys als Vorwand. Gewollt ist die Sitzung, die ein Adversary-in-the-Middle-Kit abgreift, oder der Gerätecode, den Sie auf einem echten Microsoft-Host für deren Client eintippen. Ein Passkey ist an den Ursprung der Relying Party gebunden. Das hindert eine gefälschte Anmeldeseite am Export des privaten Schlüssels. Es hindert Sie nicht daran, deren App freizugeben.

Wenn die Adresszeile nach Microsoft aussieht, darf ich den Gerätecode eingeben?

Die Gerätecode-Anmeldeseite soll ein echter Microsoft-Host sein. Das Risiko ist nicht „ist das eine Fake-Seite“. Es ist „wer hat diesen Code erzeugt, und welche App bekommt die Freigabe“. Ein Code, den man Ihnen am Telefon oder per SMS vorliest, autorisiert deren Client – nicht Ihre eigene Browsersitzung.

Ist der Vorfall vorbei, sobald ich das Passwort geändert habe?

Nein. Microsoft schreibt, dass die Gegenseite nach dem Einstieg die eigene Telefonnummer, einen Authenticator oder ein Software-Token einträgt. Wer nur das Passwort wechselt, Sitzungen aber nicht widerruft und diese Methoden nicht löscht, lässt einen Faktor stehen, den sie schon kontrollieren. Zusätzliche Geräte unter Sicherheitsinformationen müssen über die offiziellen Schritte weg.

Eine Kollegin will im Chat einen Einmalcode. Darf ich einen Screenshot schicken?

Legen Sie kein lebendes OTP und keinen Gerätecode in ein Chat-Album. Verschlüsseln Sie eine kurze Zeichenfolge in diesem Tab mit AES-256-GCM und schicken Sie sie über Burn-Link, mit dem Schlüssel hinter #. Die Form ist s.html?id={id}#{key}. Erstellen und Lesen sind sofort nutzbar, ohne Konto. Bestätigen Sie die Person über einen Kanal, den Ihre Firma schriftlich veröffentlicht hat – nicht über den Anruf, der gerade IT behauptet hat. Material über 32 KB gehört in Datei verschlüsseln: eine Datei höchstens 5 GB, Ausgabe .lock / .enc.

Ein kurzes Geheimnis auf den sofort nutzbaren Weg legen

Wenn Sie eine Seite wollen, die die Rechengrenze offen schreibt, damit Sie „ein Passwort zurückgeben, den Screenshot weglassen“ üben können, öffnen Sie Burn-Link von FastPwd. Keine Registrierung. Schreiben Sie den Canary oben, lassen Sie die Lesezahl bei 1, erzeugen Sie den Link und vergleichen Sie Network wie im fünften Schritt: Der Körper soll nur Chiffretext tragen – nicht den Klartext und nicht den Schlüssel hinter der Raute. Nutzen Sie diesen Weg erst, wenn die Kollegin oder der Kollege geprüft ist. Machen Sie vorher keinen Screenshot. Lesen Sie einem Fremden am Telefon keinen Gerätecode vor.

Liegen in einem Chatverlauf oder einem Ticket noch Telefonnummern und Ausweisnummern übereinander, führen Sie vor dem Senden eine regelbasierte Schwärzung unter Tracking entfernen aus. Die Bereinigung bleibt auf diesem Gerät. Der Ausgangstext wird nicht als Fachdaten hochgeladen und nicht in die Statistik geschrieben. Für Sites, die noch ein Passwort nutzen, erzeugen Sie lokal ein einziges. Wiederverwenden Sie nicht die Zeichenfolge, zu der der Anrufer Sie gedrängt hat. Passwortstärke prüfen beantwortet nur „ist das ein öffentlich häufiges schwaches Passwort“. Es beantwortet nicht „war dieser Anruf falsch“.

Beim nächsten Anruf „Passkey jetzt aktualisieren“ drei Sätze behalten. Erstens: Passkey im Skript ist oft nur der Vorwand; gewollt ist eine Sitzung oder eine Gerätecode-Freigabe. Zweitens: Ein echter Host hindert Sie nicht daran, ein Token an die App eines anderen auszugeben. Drittens: Abschluss sind Sicherheitsinformationen plus Sitzungswiderruf – nicht der Passwortwechsel allein. Diese drei Sätze dürfen in eine Übergabenotiz. „Ich habe Passkeys eingeschaltet, also kann ich den Anruf ignorieren“ darf das nicht.

Weiterlesen

Liegt ein Passwort als Ausschnitt auf einem Bildhoster, deckt ein Login-Hash weder OCR-Klartext noch eine Image-ID – siehe Warum OCR-Klartext und Image-IDs nach dem Screenshot-Upload auf einen Bildhoster gefährlicher sind als der Passwort-Hash. Ein Einmal-Link kann beweisen, dass der Server den Chiffretext gelöscht hat; er kann nicht beweisen, dass niemand einen Screenshot gemacht hat – siehe Warum ein Einmal-Link beweisen kann, dass der Server den Chiffretext gelöscht hat – aber nicht, dass niemand einen Screenshot gemacht hat. Warum der Teil hinter # nicht in HTTP geht – siehe Warum sich ein Schlüssel hinter der URL-Raute eignet – und wann der Schutz fällt.