Zusammenfassung
CVE-2025-50154 ist eine Sicherheitslücke im Windows-Datei-Explorer, durch die sensible Authentifizierungsdaten über das Netzwerk offengelegt werden können. Microsoft stuft das Problem als Spoofing ein, wobei die zugrunde liegende Schwachstelle CWE-200 (Offenlegung sensibler Informationen) zugeordnet ist.
In betroffenen Konfigurationen kann Windows Explorer während der Verarbeitung von Metadaten zu Verknüpfungen eine Netzwerkauthentifizierung initiieren. Wenn das referenzierte Remote-Ziel vom Angreifer kontrolliert wird, kann dieser NTLM-Challenge-Response-Material erfassen. Je nach den Sicherheitskontrollen des Unternehmens kann dies zu Folgeangriffen wie NTLM-Relay oder Offline-Passwort-Erraten führen.
In diesem Blog untersuchen wir CVE-2025-50154 auf der Grundlage von Forschungsarbeiten, die von Doktoranden durchgeführt wurden, die am OPSWAT Fellowship Program teilnehmen, und wir geben praktische Hinweise zur Risikominderung, um das Risiko einer erzwungenen NTLM-Authentifizierung zu verringern.
Auswirkungen und Risiken
CVE-2025-50154 wurde am 12. August 2025 bekannt gegeben und betrifft mehrere unterstützte Windows-Client- und Server-Versionen (Windows 10/11 und Windows Server ) vor den korrigierten Build-Levels. Die Schwachstelle wird mit CVSS v3.1 6.5 (mittel) bewertet.
Die wichtigste Sicherheitsfolge ist die Offenlegung von Anmeldedaten: Ein Angreifer kann NTLM-Challenge-Response-Material erhalten, indem er Explorer dazu veranlasst, sich bei einem vom Angreifer kontrollierten Endpunkt zu authentifizieren. Je nach Umgebung kann dies für folgende Zwecke genutzt werden:
• NTLM-Relay (Spoofing): Authentifizierung bei anderen Diensten als das Opfer, wenn Relay-Schutzmaßnahmen fehlen oder falsch konfiguriert sind.
• Offline-Passwort-Erraten/Knacken: Versuch, schwache Passwörter aus erfasstem Challenge-Response-Material wiederherzustellen.
Die Machbarkeit hängt stark von Unternehmenskontrollen wie SMB-Signierung, NTLM-Einschränkungen, Netzwerksegmentierung und serverseitiger Absicherung ab.
Angriffsszenario
CVE-2025-50154 ist ein Problem mit erzwungener Authentifizierung. Wenn Windows Explorer eine Verknüpfung verarbeitet, die auf einen Remote-SMB/UNC-Speicherort verweist, kann es während der normalen Darstellung oder Pfadvalidierung eine SMB-Verbindung initiieren. Infolgedessen kann der Remote-Endpunkt NTLM-Authentifizierungsdaten empfangen, die während der Sitzungs Einrichtung generiert wurden.
Ein repräsentatives Angriffsszenario sieht wie folgt aus:
- Angreifer-Staging: Der Angreifer kontrolliert einen SMB-Server und bereitet eine Freigabe vor, auf die die Verknüpfung verweist.
- Platzierung der Verknüpfung: Eine .lnk-Datei, die auf den vom Angreifer kontrollierten SMB-Pfad verweist, wird über gängige Kanäle (z. B. Phishing-Anhänge, synchronisierte Ordner, gemeinsam genutzte Datei-Repositorys oder einen bestehenden Zugangspunkt) in die Umgebung des Opfers übertragen.
- Durch Explorer ausgelöster Zugriff: Wenn das Opfer ein Verzeichnis mit der Verknüpfung durchsucht, analysiert Windows Explorer die Metadaten der Verknüpfung und versucht möglicherweise, das Remoteziel als Teil der routinemäßigen UI-Verarbeitung aufzulösen.
- Implizite Authentifizierung: Während des Aufbaus einer SMB-Sitzung authentifiziert sich Windows im Kontext des Benutzers (oft über NTLM). Das Opfer muss das Ziel der Verknüpfung nicht ausführen, damit der Authentifizierungsaustausch stattfinden kann.
- Ergebnisse nach der Erfassung (umgebungsabhängig): Je nach den Kontrollen der Umgebung kann erfasstes NTLM-Material für NTLM-Relay oder Offline-Passwort-Cracking genutzt werden. Die praktische Durchführbarkeit wird durch Faktoren wie SMB-Signierung, NTLM-Einschränkungen und Netzwerksegmentierung beeinflusst.
Technischer Hintergrund
Windows Explorer und Darstellung von Verknüpfungen
Der Windows Explorer (explorer.exe) ist der Windows-Shell-Prozess, der den Inhalt von Verzeichnissen auflistet und die Benutzeroberfläche des Datei-Explorers rendert. Dabei ruft er Shell-Komponenten (z. B. Icon-/Overlay-/Miniaturbild-Handler) auf, um Symbole, Overlays und Miniaturbilder abzurufen und anzuzeigen.
Eine Windows-Verknüpfung (.lnk) ist kein einfacher Textzeiger, sondern ein strukturiertes Metadatenformat, in dem ein Zielpfad (lokaler Pfad oder UNC/SMB-Pfad), optionale Argumente und ein Arbeitsverzeichnis sowie eine separate Symbolreferenz gespeichert werden können. Beim normalen Durchsuchen von Ordnern analysiert der Explorer die Metadaten der Verknüpfung, um die Verknüpfung in der Benutzeroberfläche anzuzeigen (z. B. durch Auflösen des Symbols und Überprüfen des Ziels). Je nach referenziertem Ziel und den zugehörigen Metadaten kann diese Verarbeitung dazu führen, dass der Explorer im Rahmen der routinemäßigen Darstellung oder Pfadüberprüfung einen Netzwerkzugriff versucht.
NTLM-Authentifizierung über SMB
Bei der Windows-Dateifreigabe bevorzugt die SMB-Authentifizierung in Domänenumgebungen in der Regel Kerberos, aber NTLM kann weiterhin ausgehandelt werden, wenn Kerberos nicht verfügbar oder nicht ausgewählt ist. NTLM ist ein Challenge-Response-Protokoll: Der Client gibt zunächst seine Fähigkeiten bekannt, der Server sendet eine Challenge (Nonce) zurück, und der Client antwortet mit einer Authentifizierungsnachricht, die aus der Challenge und dem Geheimnis des Benutzers abgeleitet wird – ohne das Klartext-Passwort zu senden.
NTLM-Varianten und Sicherheitsstatus (NTLMv1 vs. NTLMv2)
NTLM hat mehrere Varianten. Moderne Windows-Umgebungen basieren in der Regel auf NTLMv2 und sollten Legacy-LM/NTLMv1 nach Möglichkeit vermeiden.
NTLMv1 wurde aus mehreren wichtigen Gründen als unsicher anerkannt (schwache Verschlüsselung, Schlüssel mit geringer Entropie, Relay-Sicherheitslücke, Risiko des Offline-Crackings usw.).
Um dies zu verbessern, führte Microsoft NTLMv2 ein, das die Berechnung der Antwort verstärkt. In der Praxis ersetzt NTLMv2 die ältere DES-artige Antwortkonstruktion durch ein HMAC-MD5-basiertes Schema und integriert zusätzlichen Kontext in die Antwort, wodurch es gegenüber mehreren Klassen von Offline-Wiederherstellungstechniken deutlich robuster ist als NTLMv1.
Selbst mit NTLMv2 sollten Unternehmen NTLM im Vergleich zu Kerberos weiterhin als Authentifizierungsprotokoll mit höherem Risiko betrachten und umfassende Sicherheitskontrollen (z. B. SMB-Signierung und Segmentierung) anwenden, um die Auswirkungen von Szenarien mit erzwungener Authentifizierung zu minimieren.
Warum NTLM nach wie vor ein häufiges Ziel ist
Obwohl NTLM ein Challenge-Response-Protokoll ist, bleibt es für Angreifer attraktiv, da der Authentifizierungsaustausch unter feindlichen Netzwerkbedingungen direkt nutzbar ist. Während des Aufbaus einer SMB-Sitzung empfängt der Remote-Endpunkt Authentifizierungsmetadaten und die Challenge-Response-Werte, die zur Authentifizierung des Clients erforderlich sind. Wenn ein Angreifer den Zielendpunkt (z. B. einen von ihm kontrollierten SMB-Server) bedienen oder die Verbindung während der Übertragung abfangen/beenden kann, kann er NTLM-Austauschmaterial erfassen und je nach den Schutzmaßnahmen der Umgebung Folgeangriffe wie NTLM-Relay oder Offline-Passwort-Erraten versuchen.
Windows integriert NTLM auch in seine Single-Sign-On-Funktion (SSO). Aus dem Geheimnis des Benutzers abgeleitete Anmeldedaten werden von LSASS verwaltet und können zur Authentifizierung bei Netzwerkressourcen (z. B. SMB-Freigaben) verwendet werden, ohne dass der Benutzer wiederholt dazu aufgefordert wird. Dies verbessert zwar die Benutzerfreundlichkeit, vergrößert jedoch die Angriffsfläche für Szenarien mit erzwungener Authentifizierung: Wenn eine .lnk-Verknüpfung auf einen Remote-SMB-Pfad verweist, kann Windows Explorer während der routinemäßigen Verarbeitung der Verknüpfung eine SMB-Verbindung initiieren und automatisch die Authentifizierung aushandeln.
Im Zusammenhang mit CVE-2025-50154 bedeutet dies, dass NTLM-Authentifizierungsdaten an einen vom Angreifer kontrollierten SMB-Endpunkt gesendet werden können, ohne dass das Opfer das referenzierte Ziel ausführt, wodurch während des normalen Durchsuchens von Ordnern ein stiller Weg zur Offenlegung von Anmeldedaten entsteht.
Technische Analyse
Darstellung von Explorer-Symbolen und Verarbeitung von Verknüpfungen
Wenn ein Ordner im Datei-Explorer geöffnet wird, listet der Explorer den Inhalt des Verzeichnisses auf und bestimmt den Typ jedes Elements anhand seiner registrierten Dateizuordnung (in der Regel anhand der Dateierweiterung). Windows verwendet dann die entsprechende Shell-Klassenregistrierung (z. B. über die zugehörigen CLSID/ProgID-Zuordnungen in der Registrierung), um den geeigneten Shell-Handler zu finden – in der Regel eine COM-Komponente, die für die Extraktion und Darstellung von Symbolen zuständig ist. Der Explorer ruft die entsprechenden Schnittstellen auf, um das Symbol abzurufen und anzuzeigen.
Bei .lnk-Dateien (Shell-Verknüpfungen) rendert Explorer standardmäßig in der Regel kein generisches Verknüpfungssymbol. Stattdessen analysiert es die Metadaten der Verknüpfung, versucht, das referenzierte Ziel (und die zugehörigen Symbolinformationen) aufzulösen, und rendert dann das Symbol, das mit diesem aufgelösten Ziel verknüpft ist.
Wenn Explorer eine .lnk-Datei rendert, bestimmt er das Symbol durch Aufruf von CShellLink::GetIconLocation, wodurch ermittelt wird, woher das Symbol geladen werden soll (z. B. aus der Zielbinärdatei, einem expliziten Symbolpfad oder einem Standardsystemsymbol). Als Teil dieses Ablaufs initialisiert Explorer die Symbol-Extraktion (_InitExtractIcon) und führt dann die Kernlogik zur Auflösung (_GetExtractIcon) aus, die die Symbolquelle (über _CheckExtractLocation) auswertet.
• Wenn die Verknüpfung einen lokalen Speicherort für das Symbol angibt (z. B. eine ausführbare Datei oder eine DLL auf der Festplatte), lädt Explorer das Symbol direkt aus dieser Ressource.
• Wenn sich das Symbol an einer Remote-URL befindet, lädt Explorer das Symbol möglicherweise in seinen lokalen Cache herunter (z. B. mithilfe von URLDownloadToCacheFileW) und lädt es anschließend aus der zwischengespeicherten Kopie.
• Wenn keine gültige Symbolquelle verfügbar ist, greift Explorer auf ein vom System-Handler bereitgestelltes Standardsymbol zurück.
Nach der Auflösung der Metadaten für Symbole fährt Explorer mit CShellLink::Extract fort, das das Ziel der Verknüpfung verarbeitet und den Extraktionsworkflow abschließt. Als Teil dieses Pfads ruft Explorer CShellLink::_ShortNetTimeout auf, um kürzere Netzwerk-Timeouts anzuwenden, wenn die Verknüpfung auf einen Remote-Speicherort verweist. Dadurch werden Verzögerungen in der Benutzeroberfläche reduziert, wenn das Netzwerkziel langsam oder nicht erreichbar ist.
Wenn das Ziel als Netzwerkpfad (UNC) identifiziert wird, führt Explorer eine asynchrone Zielüberprüfung durch. Es wird ein Worker-Thread gestartet, der CShellLink::_VerifyPathThreadProc ausführt, wodurch überprüft wird, ob das referenzierte Ziel vorhanden ist.
Innerhalb dieser Routine ruft Explorer PathFileExistsAndAttributesW auf, um die Existenz und die grundlegenden Attribute des Ziels (z. B. Datei oder Verzeichnis) abzufragen, was wiederum einen Netzwerkzugriffsversuch für SMB/UNC-Ziele erfordert.
Grundursache der Schwachstelle
Im Rahmen des oben beschriebenen Ablaufs zur Darstellung von Verknüpfungen sind zwei ausgehende Vorgänge relevant:
• Abrufen von Symbolen über URLDownloadToCacheFileW (wenn die Symbolquelle der Verknüpfung eine Remote-URL ist).
• Zielvalidierung über PathFileExistsAndAttributesW (wenn das Ziel der Verknüpfung ein UNC/SMB-Pfad ist).
Um das Verhalten von URLDownloadToCacheFileW zu validieren, haben wir die API einem minimalen, eigenständigen Test überprüft.
Die Netzwerkaktivität bestand aus einem herkömmlichen HTTP-Abruf, und unseren Beobachtungen zufolge wurden dabei keine für diese Schwachstelle relevanten Anmeldedaten offengelegt.
Das bedeutendere Verhalten tritt bei PathFileExistsAndAttributesW auf, wenn der ausgewertete Pfad ein UNC/SMB-Ziel ist. Während des Debuggens haben wir beobachtet, dass diese Überprüfung die Einrichtung einer SMB-Sitzung initiieren und die Authentifizierung unter dem aktuellen Benutzerkontext aushandeln kann.
Da Explorer diese Validierung während der Verarbeitung einer .lnk-Datei automatisch aufrufen kann, kann ein von einem Angreifer kontrollierter SMB-Endpunkt NTLM-Authentifizierungsdaten empfangen, ohne dass das Opfer die referenzierte Datei ausführt, wodurch während des routinemäßigen Durchsuchens von Ordnern ein stiller Weg zur Offenlegung von Anmeldedaten entsteht.
Konzeptnachweis
In einem isolierten Labor haben die Teilnehmer unseres OPSWAT Fellowship CVE-2025-50154 mithilfe einer Verknüpfung (.lnk) validiert, die auf einen Remote-SMB/UNC-Pfad verwies. Auf einem anfälligen Windows-System löste das einfache Durchsuchen des Ordners im Windows Explorer während der normalen Verknüpfungsverarbeitung eine SMB-Verbindung aus, wodurch NTLM-Authentifizierungsdaten an den Remote-Endpunkt gesendet wurden – ohne dass das Opfer das Ziel der Verknüpfung ausgeführt hatte.
Sanierung
Unternehmen müssen sicherstellen, dass ihre Betriebssysteme und Anwendungen regelmäßig gepatcht und auf dem neuesten Stand gehalten werden, um bekannte Schwachstellen zu minimieren. Dazu gehört das Anwenden aller relevanten Microsoft-Sicherheitsupdates und die Überprüfung, ob auf allen Endgeräten die korrigierten und neuesten Windows-Build-Levels ausgeführt werden. Parallel dazu sollten Unternehmen ihre Angriffsfläche reduzieren, indem sie den ausgehenden SMB-Zugriff gegebenenfalls einschränken und die NTLM/SMB-Härtungskontrollen entsprechend ihrer Umgebung verstärken.
MetaDefender unterstützt diese Bemühungen und hilft dabei, sie in großem Maßstab umzusetzen, indem es einen klaren Überblick über die Gefährdung und die Patch-Bereitschaft bietet. Mit robusten Funktionen zum Schwachstellen- und Patch-Management, die mehr als 1.100 Anwendungen unterstützen, identifiziert MetaDefender Endpoint Endpunkte, auf denen nicht gepatchte oder veraltete Windows-Versionen sowie Anwendungen von Drittanbietern laufen, und liefert empfohlene Korrekturen.
Darüber hinaus erhalten Administratoren über die Verwaltungskonsole in My OPSWAT Central Management eine zentralisierte, einheitliche Übersicht über den Sicherheitsstatus der Endpunkte, die Schwachstellen und das Patch-Management – alles auf einer einzigen Plattform, auf der Sicherheitsrichtlinien für das gesamte Unternehmen definiert und durchgesetzt werden können. Administratoren können auch benutzerdefinierte Skripte auf Endpunkten erstellen und bereitstellen, auf denen MetaDefender Endpoint , um Maßnahmen zur Absicherung im Zusammenhang mit dem SMB-Zugriff und der NTLM-Nutzung zu automatisieren. Dieser Ansatz optimiert die Durchsetzung von Sicherheitsmaßnahmen und liefert gleichzeitig klares Feedback zu den Ausführungsergebnissen, sodass Administratoren schnell Endpunkte identifizieren können, die möglicherweise einer weiteren Untersuchung oder manuellen Intervention bedürfen.
Endpoint MetaDefender Endpoint Sicherheits- und IT-Teams Rollouts priorisieren, die Behebung von Sicherheitslücken beschleunigen, die Sicherheitslage des Unternehmens kontinuierlich überwachen und letztendlich das Risiko von Common Vulnerabilities and Exposures (CVEs) wie CVE-2025-50154 und ähnlichen Endpunkt-basierten Bedrohungen reduzieren.
