Sintesi
CVE-2025-50154 è una vulnerabilità di Windows File Explorer che può esporre materiale di autenticazione sensibile sulla rete. Microsoft classifica il problema come spoofing, con la vulnerabilità sottostante mappata su CWE-200 (Esposizione di informazioni sensibili).
Nelle configurazioni interessate, Windows Explorer potrebbe avviare l'autenticazione di rete durante l'elaborazione dei metadati relativi ai collegamenti. Se la destinazione remota di riferimento è controllata dall'autore dell'attacco, quest'ultimo potrebbe acquisire il materiale di challenge-response NTLM. A seconda dei controlli di sicurezza dell'organizzazione, ciò potrebbe consentire abusi successivi, come il relay NTLM o il tentativo di indovinare la password offline.
In questo blog, analizziamo CVE-2025-50154 sulla base delle ricerche condotte dagli studenti laureati che partecipano al programma OPSWAT Fellowship Program e forniamo indicazioni pratiche per ridurre il rischio di autenticazione NTLM forzata.
Impatto e rischio
CVE-2025-50154 è stata resa nota il 12 agosto 2025 e riguarda diverse versioni supportate di client e server Windows ( Server Windows 10/11 e Windows Server ) precedenti ai livelli di build corretti. La vulnerabilità è classificata CVSS v3.1 6.5 (media).
La conseguenza principale in termini di sicurezza è l'esposizione delle credenziali: un aggressore può ottenere materiale di sfida-risposta NTLM facendo sì che Explorer esegua l'autenticazione su un endpoint controllato dall'aggressore. A seconda dell'ambiente, ciò può essere utilizzato per:
• NTLM relay (spoofing): autenticazione ad altri servizi come vittima in assenza di protezioni relay o in caso di configurazione errata delle stesse.
• Indovinare/decifrare password offline: tentativo di recuperare password deboli da materiale challenge-response acquisito.
La fattibilità dipende in larga misura dai controlli aziendali quali la firma SMB, le restrizioni NTLM, la segmentazione della rete e il rafforzamento dei servizi.
Scenario di attacco
CVE-2025-50154 è un problema di autenticazione forzata. Quando Windows Explorer elabora un collegamento che fa riferimento a una posizione SMB/UNC remota, può avviare una connessione SMB durante il normale rendering o la convalida del percorso. Di conseguenza, l'endpoint remoto può ricevere il materiale di scambio di autenticazione NTLM generato durante l'impostazione della sessione.
Uno scenario di attacco rappresentativo è il seguente:
- Preparazione dell'attacco: l'avversario controlla un server SMB e prepara una condivisione a cui fa riferimento il collegamento.
- Posizionamento del collegamento: un file .lnk che punta al percorso SMB controllato dall'autore dell'attacco viene inviato all'ambiente della vittima tramite canali comuni (ad esempio allegati di phishing, cartelle sincronizzate, archivi di file condivisi o un punto d'appoggio esistente).
- Accesso attivato da Explorer: quando la vittima naviga in una directory contenente il collegamento, Windows Explorer analizza i metadati del collegamento e può tentare di risolvere la destinazione remota come parte dell'elaborazione ordinaria dell'interfaccia utente.
- Autenticazione implicita: durante la configurazione della sessione SMB, Windows esegue l'autenticazione nel contesto dell'utente (spesso tramite NTLM). La vittima non deve eseguire il collegamento per l'autenticazione.
- Risultati post-acquisizione (dipendenti dall'ambiente): a seconda dei controlli dell'ambiente, il materiale NTLM acquisito può essere utilizzato per il relay NTLM o il cracking delle password offline. La fattibilità pratica è influenzata da fattori quali la firma SMB, le restrizioni NTLM e la segmentazione della rete.
Contesto tecnico
Windows Explorer e rendering dei collegamenti
Windows Explorer (explorer.exe) è il processo della shell di Windows che elenca i contenuti delle directory e rende l'interfaccia utente di Esplora file, richiamando i componenti della shell (ad esempio, gestori di icone/sovrapposizioni/miniature) per ottenere e visualizzare icone, sovrapposizioni e miniature.
Un collegamento di Windows (.lnk) non è un semplice puntatore di testo, ma un formato di metadati strutturato in grado di memorizzare un percorso di destinazione (percorso locale o percorso UNC/SMB), argomenti opzionali e directory di lavoro, oltre a un riferimento separato all'icona. Durante la normale navigazione nelle cartelle, Explorer analizza i metadati del collegamento per visualizzarlo nell'interfaccia utente (ad esempio, risolvendo l'icona e convalidando la destinazione). A seconda della destinazione a cui si fa riferimento e dei metadati correlati, questa elaborazione può indurre Explorer a tentare l'accesso alla rete come parte della routine di rendering o della verifica del percorso.
Autenticazione NTLM su SMB
Nella condivisione file di Windows, l'autenticazione SMB preferisce in genere Kerberos negli ambienti di dominio, ma NTLM può comunque essere negoziato quando Kerberos non è disponibile o non è selezionato. NTLM è un protocollo di tipo challenge-response: il client prima comunica le proprie capacità, il server restituisce una sfida (nonce) e il client risponde con un messaggio di autenticazione derivato dalla sfida e dalla chiave segreta dell'utente, senza inviare la password in chiaro.
Varianti NTLM e livello di sicurezza (NTLMv1 vs NTLMv2)
NTLM ha diverse varianti. Gli ambienti Windows moderni si basano generalmente su NTLMv2 e dovrebbero evitare, ove possibile, il vecchio LM/NTLMv1.
NTLMv1 è stato ampiamente riconosciuto come non sicuro per diversi motivi fondamentali (crittografia debole, chiavi a bassa entropia, vulnerabilità di inoltro, rischio di cracking offline, ecc.).
Per migliorare questo aspetto, Microsoft ha introdotto NTLMv2, che rafforza il calcolo della risposta. In pratica, NTLMv2 sostituisce la vecchia struttura della risposta in stile DES con uno schema basato su HMAC-MD5 e incorpora un contesto aggiuntivo nella risposta, rendendola significativamente più robusta rispetto a NTLMv1 contro diverse classi di tecniche di recupero offline.
Anche con NTLMv2, le organizzazioni dovrebbero comunque considerare NTLM come un protocollo di autenticazione a rischio più elevato rispetto a Kerberos e applicare controlli di difesa approfonditi (ad esempio, firma SMB e segmentazione) per ridurre il raggio d'azione degli scenari di autenticazione forzata.
Perché NTLM rimane un bersaglio frequente
Sebbene NTLM sia un protocollo challenge-response, rimane interessante per gli aggressori perché lo scambio di autenticazione è direttamente utilizzabile in condizioni di rete ostili. Durante la configurazione della sessione SMB, l'endpoint remoto riceve i metadati di autenticazione e i valori di sfida-risposta necessari per autenticare il client. Se un avversario è in grado di gestire l'endpoint di destinazione (ad esempio, un server SMB controllato dall'aggressore) o può intercettare/interrompere la connessione in transito, può acquisire il materiale di scambio NTLM e tentare abusi successivi come il relay NTLM o la violazione della password offline, a seconda delle protezioni dell'ambiente.
Windows integra anche NTLM nella sua esperienza Single Sign-On (SSO). Il materiale di credenziali derivato dal segreto dell'utente è gestito da LSASS e può essere utilizzato per l'autenticazione alle risorse di rete (ad esempio, condivisioni SMB) senza richiedere ripetutamente all'utente di inserire le credenziali. Sebbene ciò migliori l'usabilità, amplia la superficie di attacco per scenari di autenticazione forzata: quando un collegamento .lnk fa riferimento a un percorso SMB remoto, Windows Explorer può avviare una connessione SMB durante l'elaborazione di routine del collegamento e negoziare automaticamente l'autenticazione.
Nel contesto di CVE-2025-50154, ciò significa che il materiale di scambio dell'autenticazione NTLM potrebbe essere inviato a un endpoint SMB controllato dall'autore dell'attacco senza che la vittima esegua il target di riferimento, creando un percorso silenzioso di esposizione delle credenziali durante la normale navigazione delle cartelle.
Analisi tecnica
Rendering delle icone Explorer ed elaborazione dei collegamenti
Quando una cartella viene aperta in Esplora file, Explorer elenca i contenuti della directory e determina il tipo di ciascun elemento in base alla sua associazione file registrata (in genere determinata dall'estensione del file). Windows utilizza quindi la registrazione della classe shell corrispondente (ad esempio, tramite le mappature CLSID/ProgID associate nel registro) per individuare il gestore shell appropriato, solitamente un componente COM responsabile dell'estrazione e del rendering delle icone. Explorer richiama le interfacce pertinenti per recuperare e visualizzare l'icona.
Per i file .lnk (Shell Link), Explorer in genere non visualizza un'icona di collegamento generica per impostazione predefinita. Analizza invece i metadati del collegamento, tenta di risolvere il target di riferimento (e le informazioni relative all'icona) e quindi visualizza l'icona associata al target risolto.
Quando Explorer esegue il rendering di un file .lnk, determina l'icona chiamando CShellLink::GetIconLocation, che identifica da dove deve essere caricata l'icona (ad esempio, il file binario di destinazione, un percorso esplicito dell'icona o un'icona di sistema predefinita). Come parte di questo flusso, Explorer inizializza l'estrazione dell'icona (_InitExtractIcon) e quindi esegue la logica di risoluzione principale (_GetExtractIcon), che valuta l'origine dell'icona (tramite _CheckExtractLocation).
• Se il collegamento specifica una posizione locale dell'icona (ad esempio, un eseguibile o una DLL sul disco), Explorer carica l'icona direttamente da quella risorsa.
• Se la posizione dell'icona è un URL remoto, Explorer potrebbe scaricare l'icona nella cache locale (ad esempio, utilizzando URLDownloadToCacheFileW) e quindi caricare l'icona dalla copia memorizzata nella cache.
• Se non è disponibile alcuna fonte di icone valida, Explorer ricorre a un'icona predefinita fornita dal gestore di sistema.
Dopo aver risolto i metadati relativi alle icone, Explorer procede tramite CShellLink::Extract, che gestisce la destinazione del collegamento e completa il flusso di lavoro di estrazione. Come parte di questo percorso, Explorer richiama CShellLink::_ShortNetTimeout per applicare timeout di rete più brevi quando il collegamento fa riferimento a una posizione remota, riducendo i ritardi dell'interfaccia utente se la destinazione di rete è lenta o irraggiungibile.
Quando il target viene identificato come percorso di rete (UNC), Explorer esegue la convalida del target in modo asincrono. Genera un thread di lavoro che esegue CShellLink::_VerifyPathThreadProc, che verifica se il target di riferimento esiste.
All'interno di questa routine, Explorer chiama PathFileExistsAndAttributesW per verificare l'esistenza dell'obiettivo e gli attributi di base (ad esempio, file o directory), il che a sua volta richiede un tentativo di accesso alla rete per gli obiettivi SMB/UNC.
Vulnerabilità Causa principale
Nel flusso di rendering delle scorciatoie descritto sopra, sono rilevanti due operazioni in uscita:
• Recupero delle icone tramite URLDownloadToCacheFileW (quando l'origine dell'icona del collegamento è un URL remoto).
• Convalida della destinazione tramite PathFileExistsAndAttributesW (quando la destinazione del collegamento è un percorso UNC/SMB).
Per convalidare il comportamento di URLDownloadToCacheFileW, abbiamo eseguito API un test minimo e autonomo.
L'attività di rete consisteva in un tradizionale recupero HTTP e, dalle nostre osservazioni, non ha esposto credenziali rilevanti per questa vulnerabilità.
Il comportamento più significativo si verifica con PathFileExistsAndAttributesW quando il percorso valutato è una destinazione UNC/SMB. Durante il debug, abbiamo osservato che questo controllo può avviare la configurazione della sessione SMB e negoziare l'autenticazione nel contesto dell'utente corrente.
Poiché Explorer può richiamare automaticamente questa convalida durante l'elaborazione di un file .lnk, un endpoint SMB controllato dall'autore dell'attacco può ricevere materiale di scambio di autenticazione NTLM senza che la vittima esegua il file di riferimento, creando un percorso silenzioso di esposizione delle credenziali durante la normale navigazione nelle cartelle.
Prova di concetto
In un laboratorio isolato, i partecipanti al nostro programma OPSWAT Fellowship hanno convalidato CVE-2025-50154 utilizzando un collegamento (.lnk) che faceva riferimento a un percorso SMB/UNC remoto. Su un sistema Windows vulnerabile, la semplice navigazione nella cartella in Esplora risorse ha attivato una connessione SMB durante la normale elaborazione del collegamento, causando l'invio del materiale di scambio dell'autenticazione NTLM all'endpoint remoto, senza che la vittima eseguisse il collegamento di destinazione.
Bonifica
Le organizzazioni devono garantire che i propri sistemi operativi e le proprie applicazioni siano regolarmente aggiornati con patch e mantenuti aggiornati per mitigare le vulnerabilità note. Ciò include l'applicazione di tutti gli aggiornamenti di sicurezza Microsoft pertinenti e la verifica che tutti gli endpoint eseguano i livelli di build Windows corretti e più recenti. Parallelamente, le organizzazioni dovrebbero ridurre la propria superficie di attacco rafforzando l'accesso SMB in uscita, ove opportuno, e potenziando i controlli di rafforzamento NTLM/SMB in linea con il proprio ambiente.
MetaDefender supporta questi sforzi e contribuisce a renderli operativi su larga scala, fornendo una chiara visibilità sull'esposizione e sulla disponibilità delle patch. Grazie a solide funzionalità di gestione delle vulnerabilità e delle patch che supportano oltre 1.100 applicazioni, MetaDefender Endpoint identificaEndpoint gli endpoint che eseguono versioni di Windows non aggiornate o obsolete, nonché applicazioni di terze parti, e fornisce le correzioni consigliate.
Inoltre, attraverso la console di gestione in My OPSWAT Central Management, gli amministratori ottengono una visione centralizzata e unificata dello stato di sicurezza degli endpoint, dell'esposizione alle vulnerabilità e della gestione delle patch, il tutto all'interno di un'unica piattaforma per la definizione e l'applicazione delle politiche di sicurezza in tutta l'organizzazione. Gli amministratori possono anche creare e distribuire script personalizzati sugli endpoint con MetaDefender Endpoint per automatizzare le azioni di rafforzamento relative all'accesso SMB e all'utilizzo di NTLM. Questo approccio semplifica l'applicazione della sicurezza fornendo al contempo un feedback chiaro sui risultati dell'esecuzione, consentendo agli amministratori di identificare rapidamente gli endpoint che potrebbero richiedere ulteriori indagini o interventi manuali.
MetaDefender Endpoint ai team IT e di sicurezza di dare priorità alle implementazioni, accelerare la risoluzione dei problemi, monitorare costantemente lo stato di sicurezza dell'organizzazione e, in ultima analisi, ridurre l'esposizione alle vulnerabilità e alle esposizioni comuni (CVE), come CVE-2025-50154 e minacce simili basate sugli endpoint.
