Eine aktuelle Sicherheitsanalyse zeigt, wie Windows Hello for Business unter bestimmten Umständen zu einem Baustein für anhaltenden Cloud-Zugriff werden kann. Anders als bei klassischem Credential-Diebstahl geht es nicht darum, einen geheimen Schlüssel zu extrahieren oder den Nutzer aktiv mit neuen Eingaben zu konfrontieren. Stattdessen kann Code, der bereits im Browser- oder Desktop-Kontext einer angemeldeten Windows-Sitzung läuft, die vorhandene Vertrauensstellung der Sitzung ausnutzen.
Im Kern beschreibt der Sicherheitsforscher Dirk-jan Mollema ein Szenario, in dem Malware, die auf dem betroffenen Gerät bereits läuft und in der laufenden Benutzersitzung ausgeführt wird, stillschweigend den Windows Hello for Business-Schlüssel verwendet, um sich bei Microsoft Entra ID zu authentifizieren. Aus dieser scheinbar harmlosen Beobachtung folgt eine ganze Kette: Cloud-Zugriff, Geräte-Registrierung und weitere Schritte, sofern die Tenant-Richtlinien dies zulassen.
Was Malware in einer angemeldeten Sitzung auslösen kann
Mollema demonstriert, dass die Authentifizierung gegen Entra ID auch dann funktionieren kann, wenn der Angreifer keinen direkten Zugriff auf den privaten Schlüssel oder zusätzliche Benutzerinteraktionen erzwingt. Entscheidend ist: Die Technik setzt voraus, dass die Malware Code in der bereits angemeldeten Windows-Sitzung ausführt.
In diesem Zustand kann Windows Aufgaben für kryptografische Signaturen bereitstellen, ohne dass der Nutzer erneut sichtbar bestätigen muss. In der Analyse wird dabei hervorgehoben, dass auf TPM-gestützten Systemen kein Extrahieren des privaten Schlüssels erfolgt. Ebenso müssen PINs nicht wiederhergestellt werden und es wird kein Biometrie-Prompt ausgelöst.
Von der Windows-Authentifizierung zu längerem Cloud-Zugriff
Der Angriffsweg beginnt damit, dass der kompromittierte Client den Windows Hello for Business-Schlüssel nutzt, um sich bei Entra ID zu authentifizieren. Dadurch kann der Angreifer längere Zugriffsfenster aufbauen und anschließend weitere Schritte durchführen, darunter:
- die Registrierung eines Geräts, das der Angreifer kontrolliert,
- das Erlangen eines Primary Refresh Token (PRT),
- das Hinzufügen weiterer Authentifizierungsmethoden, sofern die Richtlinien im Tenant das erlauben.
Das Ziel ist nicht nur ein kurzfristiger Token-Refresh, sondern ein persistenter Zugriff über Zeit. Hintergrund: Microsoft beschreibt, dass ein PRT etwa 90 Tage gültig bleibt und fortlaufend verlängert wird, während der Nutzer das Gerät aktiv nutzt.
Warum Biometrie und Schlüssel-Extraktion nicht zwingend sind
Im beschriebenen Szenario liegt die besondere Brisanz darin, dass die Malware den kryptografischen Prozess über Windows anstoßen kann, sobald der Nutzer interaktiv angemeldet ist. Das reduziert die Angriffsoberfläche: Der Angreifer muss weder eine PIN kennen noch den Nutzer erneut in einen sichtbaren Authentifizierungsdialog treiben.
Mollema ordnet das Verhalten als Folge der Arbeitsweise von Windows Hello for Business ein. Gleichzeitig betont er, dass dieses Verhalten in der Analyse nicht als aktueller, wild aktiver Angriff mit nachgewiesenen Opfern dargestellt wird.
Neue Erkenntnisse: Schlüssel als „FIDO2-Passkey“ via WebAuthn
Die Forschung baut auf einer zuvor bekannten Idee auf, bei der es bereits möglich war, kryptografische Assertion-Signaturen zu erzeugen. In der neueren Arbeit wird die Eintrittshürde reduziert: Mollema behandelt den Windows Hello for Business-Schlüssel in einem WebAuthn-Kontext als eine Art FIDO2-Passkey.
Dabei spielt auch die Art der Challenge eine Rolle. Der Forscher beschreibt, dass die Entra-ID-Challenge innerhalb von fünf Minuten erfolgt und dabei nicht an eine Sitzung, den Benutzer oder den Tenant gebunden ist. Dadurch kann der kompromittierte Endpunkt die Signatur auch dann für eine Anfrage erstellen, wenn der Request auf einem anderen Host erfolgt.
Mehr als nur Tokens: Browserzugriff und ROADtools
Aus der Möglichkeit, signierte Assertion-Daten zu erhalten, entsteht praktischer Missbrauch: Ein Angreifer kann nicht nur Tokens anfordern, sondern unter bestimmten Bedingungen auch eine Browser-Sitzung für sich öffnen.
Als Beispiel nennt Mollema ein Framework, das er im Umfeld von ROADtools veröffentlicht hat. Ziel ist es, Entra-ID-Interaktionen zu erleichtern. In der Analyse wurden Dateien wie fido_assertion.ps1 und hellopoc.ps1 im Repository gefunden.
Relevanter Punkt für Detect-and-Response: Gerätbindung fehlt
Ein zentraler Befund in der Recherche ist, dass das dabei resultierende Token keine device ID-Anspruchsinformation trägt. Für Defender bedeutet das: Ein Token ohne diese Gerätebindung kann dazu genutzt werden, ein neues Gerät beim Dienst zu registrieren, anschließend ein PRT für dieses neue Setup anzufordern und so den Weg in Microsoft Cloud-Dienste fortzusetzen.
Allerdings ist die Kette nicht in jedem Tenant identisch erfolgreich. Separate Regeln wie Device-State oder Compliance können den Prozess unterbrechen.
Conditional Access: Warum phishing-resistente Stärke nicht genügt
Ein weiterer Abschnitt der Analyse adressiert Conditional Access. Mollema findet, dass der WebAuthn-ähnliche Sign-in-Prozess Authentifizierungsstärke liefern kann, die in Richtlinien als phishing-resistent bewertet wird. Zusätzlich kann diese Anmeldung als frische Multi-Faktor-Authentifizierung zählen.
Das kann Auswirkungen auf die zweite Phase einer Attacke haben: Wenn Richtlinien das Hinzufügen zusätzlicher Passkeys oder Windows Hello for Business-Methoden auf einem neuen Gerät erlauben, kann ein Angreifer diese Logik ausnutzen.
Wichtig ist: Die gesamte Persistenz-Route wird nicht automatisch in jeder Umgebung funktionieren. Trotzdem zeigt die Beobachtung eine echte Grenze: Selbst hardwaregebundene und nicht exportierbare Credentials können innerhalb einer kompromittierten, bereits angemeldeten Sitzung so „verwendbar“ werden, dass sie ihre Schutzwirkung gegen Phishing auf diesem Weg nicht vollständig ausspielen.
Was zur Einordnung fehlt: konkrete Builds und Deployment-Modelle
In der Disclosure werden nicht alle technischen Details offengelegt. Der Bericht nennt keine exakten Windows-Builds oder konkreten Deployment-Modelle von Windows Hello for Business, die im Test verwendet wurden. Auch in öffentlichen Sicherheitsdatenbanken wurde zum Zeitpunkt der Recherche kein passender Eintrag wie ein CVE oder eine Microsoft-Sicherheitsmitteilung gefunden.
Der Rechercheur beschreibt außerdem, dass Microsoft und er selbst bereits in Kontakt waren. Zum Zeitpunkt der Veröffentlichung lagen noch keine endgültigen Antworten vor.
Monitoring-Ideen: Anzeichen erkennen, bevor es zu spät ist
Für die praktische Verteidigung empfiehlt Mollema vor allem Monitoring bei unerwarteten Gerätere gistrierungen. Zusätzlich nennt er einen konkreten Suchansatz für Erkennungsläufe:
- Windows-Hello-for-Business-Anmeldungen mit einem leeren device ID Muster beobachten.
Dabei ist wichtig, dass ein solches Muster nicht nur auf Angriffe hinweisen muss. Der Bericht weist darauf hin, dass auch legitime Browser-Sitzungen, etwa Inkognito-Modi oder nicht-SSO-basierte Sessions, ähnliche Muster erzeugen können. Daher sollten Teams nicht nur „Alarm ja/nein“ betrachten, sondern die Anomalien im Kontext von Benutzerverhalten, Geräten und Zeitfenstern bewerten.
Fazit: Windows Hello for Business ist stark – aber nicht gegen jede Sitzungslücke
Die Forschung macht deutlich: Windows Hello for Business bleibt ein wichtiges Sicherheitsmerkmal, das Schlüssel oft hardwaregebunden und nicht exportierbar macht. Dennoch zeigt die Analyse eine Schwachstelle in der Praxislogik: Wenn Malware bereits im Rahmen einer angemeldeten Windows-Sitzung Code ausführen kann, kann sie die vorhandene Vertrauenskette zu Entra ID nutzen.
Für Organisationen heißt das, den Schutz nicht nur auf Passwort- und Phishing-Resistenz zu reduzieren, sondern auch Sitzungskompromittierung, Token-Flows, Geräte-Lifecycle und Conditional-Access-Verhalten in die Monitoring-Strategie einzubauen.
Wenn du deine Umgebung absichern willst, starte mit genau den Indikatoren, die in der Recherche genannt werden: unerwartete Gerätere gistrierungen und Anmeldeereignisse, bei denen Windows Hello for Business ohne device ID auffällt. So erkennst du verdächtige Umgehungsversuche früher – und kannst schneller reagieren.
Quelle: https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html
