Vulnerabilità RDP in Windows: accesso remoto con vecchie password

Un attaccante potrebbe sfruttare la vulnerabilità RDP di Windows per accedere a un sistema remoto utilizzando credenziali ormai cambiate.

Un recente articolo di Tom’s Hardware (2 maggio 2025) ha portato all’attenzione una grave vulnerabilità nei sistemi Windows relativa al Remote Desktop Protocol (RDP). In sintesi, un utente malintenzionato può accedere via desktop remoto utilizzando una password obsoleta – cioè già cambiata dal legittimo proprietario dell’account – senza che Windows glielo impedisca. Questa scoperta, fatta dal ricercatore Daniel Wade, rivela che dopo un cambio password Windows continua a riconoscere valide anche le credenziali precedenti per le connessioni RDP, creando un “accesso secondario” permanente non disattivabile dall’utente. In pratica, cambiare la password del proprio account Microsoft/Azure su Windows non invalida le sessioni RDP avviate con la vecchia password, lasciando di fatto una porta aperta invisibile. Microsoft, da parte sua, non considera questo comportamento un difetto di sicurezza e ha dichiarato di non avere intenzione di modificarlo, classificandolo come funzionalità voluta. Di seguito esaminiamo nel dettaglio come funziona RDP, i particolari tecnici della vulnerabilità, le ragioni della scelta di Microsoft, i potenziali impatti per utenti privati e aziende, e le contromisure possibili.

Come funziona il protocollo RDP di Windows

Remote Desktop Protocol (RDP) è il protocollo proprietario Microsoft che consente di controllare un computer Windows da remoto, vedendone il desktop e interagendo come se si fosse fisicamente presenti. RDP segue un’architettura client-server: un servizio di Desktop Remoto in ascolto sul computer host riceve la connessione dal client remoto e trasmette input e output tra le due macchine. In pratica, il software instrada l’output video del desktop e gli input da tastiera/mouse verso la macchina remota, permettendo all’utente remoto di lavorare sul sistema come in locale. RDP è ampiamente usato per amministrazione di sistemi e supporto tecnico.

Caratteristiche chiave del funzionamento RDP:

• Porta di comunicazione: di default RDP utilizza la porta TCP 3389 per le connessioni. Questo significa che, salvo configurazioni specifiche, il servizio di Desktop Remoto attende incoming sulla porta 3389/TCP del host Windows. (È possibile usare porte alternative o un gateway RDP su HTTPS/443, ma per impostazione predefinita 3389 è la porta nota.)
• Autenticazione e NLA: Windows richiede credenziali valide per consentire l’accesso remoto. Dalle versioni più recenti, RDP supporta Network Level Authentication (NLA), che esige l’autenticazione dell’utente prima di avviare la sessione grafica. Il client RDP invia quindi username e password al server, che li valida usando i meccanismi standard di Windows (locale o di dominio) prima di presentare il desktop remoto. Solo con credenziali corrette l’utente ottiene l’accesso.
• Integrazione con account Windows: RDP sfrutta lo stesso sistema di login di Windows. È possibile autenticarsi con account locali, account di dominio (Active Directory) o account Microsoft/Azure AD associati al PC. L’esperienza di login remoto replica quella interattiva: se l’account remoto ha diritti sufficienti (ad es. è membro del gruppo Utenti desktop remoto), Windows crea una sessione utente proprio come un login locale, e il desktop viene reso disponibile via rete.
• Cifratura e sicurezza: Il traffico RDP è crittografato (utilizza protocolli come TLS) per proteggere i dati trasmessi. Tuttavia, se esposto direttamente a Internet sulla porta 3389, RDP può rappresentare un bersaglio, tanto che sono note vulnerabilità gravi (es. BlueKeep, CVE-2019-0708) e tentativi di forza bruta sulle credenziali. Le best practice consigliano infatti di limitare l’accesso RDP attraverso VPN o firewall.
• Cache delle credenziali: Importante per comprendere la vulnerabilità in oggetto, Windows implementa una cache delle credenziali per consentire l’accesso anche quando la macchina non può contattare il servizio di autenticazione online (ad esempio il controller di dominio o i server di Microsoft). Questo significa che Windows memorizza in locale hash/verificatori delle credenziali usate con successo, così da poter autenticare l’utente offline. Questa feature è storicamente utile per i portatili aziendali fuori rete e per gli account Microsoft su PC non sempre connessi.

In condizioni normali, la cache delle credenziali non è un problema: se usiamo un account locale, la password è solo locale (cambiarla aggiorna direttamente la credenziale memorizzata nel Security Account Manager del PC). In scenari domain, la cache offline consente login con l’ultima password nota se il controller di dominio non è raggiungibile. Tuttavia, per account cloud (Microsoft Azure AD o account Microsoft personali), entra in gioco la sincronizzazione tra cloud e PC locale: qui la cache locale può divergere dalla realtà se la password viene cambiata nel cloud e il PC non aggiorna immediatamente il suo record. Ed è proprio su questo meccanismo che si innesta la vulnerabilità.

Dettagli tecnici della vulnerabilità RDP segnalata

La vulnerabilità consiste nel fatto che Windows permette l’accesso RDP con credenziali ormai revocate, a causa del meccanismo di caching delle autenticazioni. In altre parole, *dopo che un utente modifica la propria password online, un aggressore può comunque autenticarsi via RDP usando la *vecchia* password*, sfruttando il fatto che quella password risulta ancora valida nel cache locale del sistema bersaglio. Questo comportamento anomalo è stato osservato principalmente con account Microsoft e Azure AD associati a Windows 10/11.

Vediamo più in dettaglio come si presenta il problema:

• Cache delle credenziali non aggiornata: quando si effettua un primo login con un account Microsoft/Azure su un PC Windows, il sistema verifica le credenziali online (sui server Microsoft) e poi conserva localmente un token o hash verificatore crittografato. In seguito, per i login successivi – inclusi quelli via RDP – Windows tende a usare la copia locale invece di interrogare ogni volta il server remoto. Se dunque la password dell’account viene cambiata nel frattempo (ad es. tramite portal Microsoft o da un altro dispositivo), il PC potrebbe non sapere che la password è cambiata finché non si sincronizza di nuovo. Il risultato è che qualsiasi password precedentemente valida e presente nella cache continuerà ad essere accettata per l’accesso remoto, anche se teoricamente revocata.
• Validità di più password vecchie: in alcuni casi estremi, sono state riportate situazioni in cui più password storiche di un account rimangono funzionanti via RDP, mentre paradossalmente la password più recente potrebbe non essere ancora stata recepita dal sistema remoto. Ciò dipende da quanto tempo il dispositivo è rimasto offline o senza effettuare un login interattivo con la nuova credenziale. Finché il cache locale non viene aggiornato (ad esempio tramite un login interattivo riuscito con la nuova password), le vecchie credenziali restano utili. Questo significa che un aggressore con qualunque vecchia password di quell’utente (ottenuta magari da un leak precedente) potrebbe provarle sull’RDP e riuscire ad entrare.
• Assenza di alert e bypass delle protezioni: aggravando il quadro, l’uso di una password vecchia per accedere via RDP non genera allarmi visibili. Windows non avvisa l’utente che un login remoto è avvenuto con una password superata, né strumenti di sicurezza standard come Windows Defender, Microsoft Entra ID (Azure AD) o i log di eventi segnalano esplicitamente l’anomalia. Inoltre questo metodo di accesso remoto bypassa misure di sicurezza avanzate come l’autenticazione multi-fattore (MFA) e i criteri di accesso condizionato, che normalmente verrebbero applicati durante un’autenticazione online. Poiché l’RDP utilizza la verifica offline, eventuali requisiti di secondo fattore configurati sull’account Microsoft (ad esempio via Azure AD) non intervengono affatto. In sostanza, viene a crearsi una backdoor remota silenziosa: un canale di accesso nascosto che ignora le normali regole di sicurezza cloud.
• Riproduzione dell’exploit: il ricercatore Daniel Wade ha documentato la vulnerabilità con un esempio pratico. In uno scenario tipico, un utente accede in RDP al proprio PC Windows 11 con account Microsoft. Successivamente cambia la password dell’account (magari perché ha rilevato attività sospette o per normale rotazione). A questo punto, Wade ha mostrato che è ancora possibile avviare una nuova sessione RDP sullo stesso PC usando la password precedente, ottenendo l’accesso completo come utente. Tale accesso rimane possibile finché il PC remoto non viene aggiornato con la nuova password (cosa che potrebbe avvenire solo con un login interattivo diretto o dopo un certo tempo). In alcuni casi l’accesso con la vecchia password ha continuato a funzionare per giorni o settimane. Questo rappresenta chiaramente un fallimento del modello di fiducia: comunemente si presume che cambiare una password revochi immediatamente tutte le sessioni e credenziali precedenti, ma qui non avviene.

Il rischio concreto è notevole. Se un aggressore entra in possesso di una password vecchia di un account Windows (ad esempio tramite data breach o phishing), potrebbe sfruttare questa “caratteristica” per entrare nel sistema della vittima via RDP anche dopo che la password è stata modificata per sicurezza. In un contesto ideale, il cambio password dovrebbe prevenire ogni ulteriore accesso con le credenziali compromesse; in questo caso invece l’attaccante può continuare ad agire indisturbato finché la porta RDP è aperta. Wade ha definito la situazione “non solo un bug, ma un crollo della fiducia nel meccanismo di sicurezza delle password”, perché mina uno dei principi cardine della protezione degli account. Molti esperti di sicurezza concordano, arrivando a paragonare questa funzionalità a una backdoor intenzionale inserita nel sistema.

La scelta di Microsoft: “non è una vulnerabilità”

Dal punto di vista di Microsoft, sorprendentemente, quanto descritto non è un bug bensì un comportamento voluto. L’azienda di Redmond ha confermato di essere a conoscenza della segnalazione (la prima risale ad agosto 2023) ma ha deliberatamente deciso di non modificare il funzionamento dell’RDP in questo frangente. La motivazione ufficiale fornita è che si tratta di una “decisione di design” pensata per garantire che almeno un account utente possa sempre accedere al sistema, indipendentemente da quanto tempo il dispositivo sia rimasto offline. In altre parole, Microsoft vuole evitare scenari in cui un legittimo proprietario resti completamente bloccato fuori dal proprio PC solo perché magari ha cambiato la password mentre il computer era offline. Permettendo al sistema di accettare ancora la vecchia password in cache, si assicura un percorso di accesso “di emergenza” nel caso in cui la nuova password non sia sincronizzata.

Figura – Il logo Microsoft presso il campus aziendale. L’azienda ha difeso la scelta di mantenere la cache delle credenziali RDP come comportamento intenzionale.
Microsoft ha ribadito che, secondo i suoi criteri, questa situazione non rientra nella definizione di vulnerabilità di sicurezza. Infatti, l’azienda non ha assegnato alcun bollettino CVE né rilasciato patch, trattandola come funzionalità by-design. Di fronte alle critiche, Microsoft ha aggiornato la documentazione ufficiale per esplicitare (seppur in modo non vistoso) questo comportamento: una nota nei documenti Windows spiega ora che se un dispositivo è offline e l’utente cambia la password nel cloud, la cache locale non viene aggiornata e quindi l’utente potrà ancora accedere con la vecchia password. È una sorta di disclaimer che prima mancava.

Internamente, Microsoft aveva inizialmente valutato un cambio di codice per alterare questa logica, ma in seguito – riesaminando le specifiche – si è deciso di non procedere perché un cambiamento potrebbe impattare la compatibilità con molte applicazioni esistenti. Probabilmente vari servizi e scenari enterprise si basano sul fatto che Windows permetta login cache offline (ad esempio script che eseguono operazioni su account memorizzati). Cambiare il comportamento di colpo poteva rompere questi casi d’uso, creando disservizi a clienti enterprise. Pertanto, Microsoft ha preferito mantenere lo status quo.

Riassumendo la posizione Microsoft: l’accettazione di vecchie password in RDP è voluta per evitare blocchi offline, e l’azienda non la considera un errore di sicurezza grave. Questa giustificazione, tuttavia, è stata accolta con forte scetticismo dalla comunità. Molti esperti fanno notare che la soluzione proposta da Microsoft – “fa parte del design” – di fatto ignora il problema di sicurezza introdotto, dando priorità alla continuità di accesso rispetto alla protezione. È un bilanciamento discutibile: se da un lato è vero che un utente potrebbe aver bisogno di entrare nel PC dopo molto tempo offline, dall’altro qualunque aggressore con credenziali trafugate può sfruttare la stessa porta aperta. Inoltre l’utente non ha alcun controllo: non esiste alcuna opzione o impostazione di sistema per disabilitare questa caratteristica. Gli amministratori attenti alla sicurezza si trovano dunque spiazzati, in quanto non possono forzare Windows a invalidare immediatamente le vecchie password per RDP. Alcuni osservatori hanno commentato polemicamente che chiamarla “feature” non riduce il rischio: “quella che viene presentata come misura di sicurezza per non rimanere chiusi fuori, assomiglia molto a una backdoor permanente a disposizione di chiunque ottenga una vecchia password”. Non a caso, l’episodio ha sollevato interrogativi sulle priorità di sicurezza di Microsoft, alimentando il dibattito tra chi accusa Redmond di trascurare la sicurezza in favore della comodità.

Impatti potenziali per utenti domestici e aziende

La vulnerabilità in questione ha implicazioni diverse a seconda del contesto d’uso – utenza consumer vs. ambienti aziendali – anche se il principio di fondo rimane lo stesso. Di seguito analizziamo i due scenari:

• Utenti domestici e piccoli uffici: per l’utente medio casalingo, fortunatamente, l’esposizione immediata a questo problema è relativamente bassa. Su Windows Home, ad esempio, il server RDP non è nemmeno disponibile, mentre su Windows Pro è disabilitato di default. Ciò significa che molti PC domestici non hanno attivo Desktop Remoto a meno che l’utente non lo abbia esplicitamente configurato. Inoltre, l’accesso RDP non funziona con account Microsoft se è attiva la modalità “passwordless” (Windows Hello): Windows 11, ad esempio, scoraggia l’uso della password per il login locale con account Microsoft, richiedendo PIN o biometria, e in tale configurazione l’RDP tradizionale con password potrebbe non essere utilizzabile. In breve, se un utente domestico non ha mai attivato Desktop Remoto o non ha aperto manualmente la porta 3389 sul router, la sua macchina non è raggiungibile via RDP da Internet. Questo riduce drasticamente le possibilità di exploit remoto diretto. Tuttavia, “relativamente bassa” non significa zero: alcuni utenti avanzati abilitano RDP per accedere al proprio PC di casa da fuori, oppure utilizzano account Microsoft per comodità. In tali casi, se un attaccante ottenesse la vecchia password dell’account, potrebbe collegarsi indisturbato. Scenario pratico: pensiamo a un utente che riutilizza la password Microsoft in altri servizi e questa viene trafugata; l’utente la cambia sul suo account, ma dimentica che il PC di casa ha RDP attivo. Un aggressore potrebbe individuarne l’IP (ad esempio tramite l’ID Skype o altri servizi Microsoft collegati) e provare la vecchia password via RDP, riuscendo ad entrare. Per quanto improbabile, è uno scenario possibile e grave: l’intruso avrebbe accesso completo al computer di casa, ai file, webcam, microfono, etc., senza che la vittima se ne accorga subito. Dunque anche i singoli utenti devono essere consapevoli del rischio, specie se usano RDP. In ambito small office/home office, dove magari un professionista configura Desktop Remoto per lavoro da remoto, l’impatto può essere simile a quello enterprise (perdita di dati, accesso non autorizzato a sistemi critici, ransomware, ecc.), con la differenza che spesso le risorse per monitorare intrusioni sono minori.
• Organizzazioni e aziende: negli ambienti corporate la situazione è potenzialmente più delicata. Molte aziende utilizzano RDP per amministrare server o permettere assistenza remota. Se i PC aziendali sono uniti ad Azure AD o usano account Microsoft, sono soggetti a questa vulnerabilità esattamente come le macchine consumer. Immaginiamo uno scenario di hybrid work: un dipendente lavora da casa sul laptop aziendale (Azure AD join) e si autentica con il suo account aziendale Microsoft. In caso di compromissione delle credenziali (un attaccante le ruba), l’azienda potrebbe forzare un reset password. Eppure l’attaccante, conoscendo la vecchia password, potrebbe ancora collegarsi via RDP al laptop dell’utente (se raggiungibile in rete) perché quel laptop potrebbe accettare la vecchia credenziale in cache. Questo vanificherebbe le contromisure di emergenza post-breach, esponendo dati aziendali sensibili. Ancora peggio, i controlli di sicurezza avanzati che tante imprese adottano – login con Azure AD MFA, enforcement di device compliance, log centralizzati – verrebbero aggirati. Un malintenzionato potrebbe ottenere una persistenza nascosta all’interno della rete aziendale usando vecchie credenziali non revocate in RDP. Da lì, potrebbe muoversi lateralmente, installare malware, o lanciare ransomware, sfruttando il fatto che il suo accesso viene visto dal sistema come un normale login utente. Questo scenario preoccupa in particolare i team di sicurezza (SOC/DFIR), perché rende più complessa la gestione degli incidenti: dopo una violazione, cambiare le password potrebbe non essere sufficiente a estromettere l’intruso. Bisognerebbe anche spegnere/riavviare o isolare i sistemi per invalidare le cache, con conseguente downtime. Va detto che nelle aziende ben gestite, l’RDP diretto da Internet spesso non è consentito: si usa una VPN o un gateway terminal centralizzato, riducendo la superficie d’attacco. Inoltre, gli amministratori di dominio conoscono il meccanismo di cached credentials e in ambienti ad alta sicurezza possono aver già impostato policy restrittive (es. numero di login cache ridotto o disabilitato). Nonostante ciò, l’esperto Will Dormann ha evidenziato che la comunicazione di Microsoft sul problema è stata troppo nascosta: molti amministratori potrebbero non rendersi conto subito di questo comportamento e non sapere come mettere in sicurezza RDP in caso di account compromessi. In definitiva, per le aziende la vulnerabilità rappresenta un ulteriore vettore di attacco e richiede un ripensamento delle strategie di accesso remoto. Non a caso, c’è chi ha suggerito ai CISO di riesaminare l’uso di RDP come strumento di telelavoro alla luce di questa falla, valutando soluzioni alternative o aggiuntive.

Misure di mitigazione consigliate

Non essendo disponibile una patch ufficiale, gli utenti e gli amministratori devono attuare misure di mitigazione per proteggersi da questo comportamento indesiderato. Ecco alcune soluzioni temporanee, workaround e accorgimenti suggeriti dagli esperti per ridurre il rischio:

• Limitare l’esposizione di RDP: Prima di tutto, non esporre mai il servizio RDP direttamente su Internet se non strettamente necessario. Ciò significa tenere chiusa la porta 3389 sul router/firewall e consentire connessioni remote solo tramite rete privata (VPN) o altri canali sicuri. Molti attacchi RDP avvengono scansionando Internet alla ricerca di host aperti – eliminare questa superficie è fondamentale. Se RDP è indispensabile, posizionarlo dietro una VPN aziendale o utilizzare il servizio Remote Desktop Gateway su TLS (porta 443) con autenticazione forte.
• Usare account locali o di dominio per RDP: Una mitigazione pratica è evitare di usare account Microsoft/Azure per il login RDP, preferendo account locali o account di dominio tradizionali. Gli account locali non soffrono di questo problema perché la password risiede solo sul PC: cambiandola, la vecchia viene sovrascritta e non rimane alcuna cache separata. Anche per account di dominio Active Directory, se il PC è connesso alla rete aziendale al momento del login, la verifica avviene online con il controller di dominio (che conosce solo la nuova password). In generale, configurare l’accesso RDP in modo che autentichi contro credenziali locali riduce la dipendenza dal cache cloud. Ad esempio, in un ambiente Azure AD, si potrebbe creare un utente amministrativo locale sul PC da usare per RDP, invece dell’account Azure AD dell’utente. Ciò ovviamente va ponderato con la gestione centralizzata (gli account locali possono sfuggire al controllo IT se non gestiti o rotati correttamente).
• Forzare la sincronizzazione delle password prima dell’uso in RDP: Se si sospetta che un account abbia cambiato password mentre il dispositivo era offline, eseguire un login interattivo con la nuova password sul dispositivo (direttamente o via VPN) prima di riabilitare l’accesso RDP. In questo modo si aggiorna la cache locale. Purtroppo questo non è sempre fattibile, specie se l’utente è lontano; ma ad esempio un amministratore può pianificare un riavvio o un logout forzato dell’utente remoto, richiedendone la nuova autenticazione. Allo stesso modo, riavviare il sistema può aiutare, poiché costringe alla nuova autenticazione (anche se in alcuni casi la cache persiste attraverso reboot). È utile anche ridurre il cache lifetime: in ambienti Azure AD sembra esserci un periodo (es. 14 giorni) oltre il quale le credenziali cache devono essere riconfermate online – ma questa informazione può variare e non è documentata chiaramente da Microsoft per account Microsoft consumer.
• Policy di sicurezza sui cached logon: In domini Windows tradizionali esiste una policy di gruppo “Interactive logon: Number of previous logons to cache”. Impostarla a 0 disabilita di fatto i login in cache offline (il che impedisce accessi senza contatto col DC). Tuttavia, per Azure AD e account Microsoft non esiste un controllo equivalente facilmente accessibile all’utente finale. Microsoft non fornisce opzioni per disabilitare la cache locale per gli account cloud. Un amministratore enterprise potrebbe valutare di passare i dispositivi a Hybrid Azure AD Join (uniti anche a un dominio AD on-prem) in modo da poter sfruttare policy AD tradizionali per gestire la cache, ma è una soluzione complessa e non confermata.
• Abilitare l’MFA a livello di sistema operativo o terze parti: Considerare l’uso di soluzioni che aggiungono un secondo fattore all’accesso Windows stesso. Ad esempio, prodotti come Duo Security offrono un’aggiunta al logon di Windows/RDP che richiede l’approvazione su smartphone dopo la password. Anche se la vecchia password venisse accettata, l’attaccante sarebbe fermato dal secondo fattore. Questo non risolve il bug alla radice, ma mitiga grandemente il rischio di exploit riuscito. In ambienti Azure AD, valutare Windows Hello for Business: se tutti gli utenti usano autenticazione forte (PIN/biometrico legato a un certificato o chiave TPM) e si disabilita la possibilità di login con password, di fatto non c’è una password tradizionale riutilizzabile in RDP. Naturalmente, implementare WHfB a tappeto richiede pianificazione e potrebbe non essere retrocompatibile con alcuni scenari RDP.
• Monitorare gli accessi RDP e i cambi password: Fino a quando la situazione non verrà risolta, è prudente aumentare la sorveglianza. Abilitare il logging dettagliato degli eventi di logon RDP sul sistema e raccoglierli centralmente può aiutare a individuare anomalie (ad esempio accessi in orari insoliti o da IP non attesi). Sebbene i log non indichino se la password usata fosse vecchia o nuova, almeno consentono di sapere chi e quando è entrato via RDP. Allo stesso modo, tenere traccia dei cambi password degli utenti e verificare che i dispositivi siano allineati. Strumenti di EDR (Endpoint Detection & Response) potrebbero rilevare attività sospette post-accesso (es. dump di memoria, movimenti laterali) anche se l’entrata iniziale non viene segnalata come breach.
• Soluzioni alternative al Desktop Remoto: Come suggerito dallo stesso articolo di Tom’s Hardware, valutare l’uso di VPN o di software di accesso remoto di terze parti in sostituzione (o a protezione) di RDP. Ad esempio, una VPN sempre attiva assicurerebbe che il PC sia considerato “online” verso l’azienda quando avviene un cambio password, evitando discrepanze di cache. Oppure, software come TeamViewer, AnyDesk, ecc., gestiscono autonomamente l’autenticazione e possono offrire 2FA integrato, scongiurando questo specifico problema (pur introducendo altri rischi, quindi vanno scelti con cura). L’uso di un jump-host o bastion host per RDP (ad esempio un server intermedio a cui ci si collega con credenziali aggiornate, e da lì si accede ai bersagli) è un’altra strategia enterprise per aggiungere un livello di controllo.

In mancanza di una patch, queste misure ridurranno la probabilità di successo di un exploit o almeno ne limiteranno gli effetti. È essenziale che chiunque utilizzi RDP – dal privato al reparto IT aziendale – sia consapevole di questa anomalia. Microsoft per ora non mostra segnali di voler intervenire, quindi la responsabilità di proteggere sistemi e dati ricade sugli utenti e gli amministratori. Tenere RDP spento quando non serve, aggiungere livelli di sicurezza e cambiare le proprie abitudini di gestione degli account cloud sono passi obbligati per mitigare quella che, a tutti gli effetti, è una grave falla di design. Come sintetizzato da Daniel Wade, “non è solo un bug, ma una rottura del modello di fiducia”: fino a quando non verrà ripristinata la fiducia nel cambio password, conviene agire con prudenza e mettere in campo ogni strumento di difesa disponibile.

Numero di utenti potenzialmente vulnerabili?

Windows è uno dei sistemi operativi più utilizzati nel mondo. Secondo diverse fonti, Windows detiene circa il 75-80% del mercato globale dei sistemi operativi per desktop.

• Distribuzione globale di Windows:
• Secondo NetMarketShare, Windows detiene circa 76% di quota di mercato nel settore desktop (fonte: NetMarketShare, StatCounter).
• Se consideriamo che Windows 10 e 11 sono attualmente i sistemi operativi principali utilizzati (oltre 1 miliardo di dispositivi nel 2023), possiamo supporre che una grande parte degli utenti di Windows sia potenzialmente soggetta a questa vulnerabilità.

2. Adoption di RDP

Secondo un report di Microsoft, oltre 200 milioni di persone usano l’accesso remoto tramite RDP in vari settori (amministrazione IT, supporto remoto, professionisti, ecc.). Tuttavia, non tutti gli utenti Windows utilizzano attivamente RDP, e RDP non è disponibile in tutte le versioni di Windows. Le versioni Windows Home non supportano RDP, quindi la vulnerabilità riguarda principalmente chi utilizza Windows Professional, Enterprise, e Windows Server.

• Stima degli utenti vulnerabili: possiamo assumere che circa il 25% degli utenti Windows, che sono nelle edizioni Professional o Enterprise, sia a rischio di questa vulnerabilità.

3. Stima del numero di utenti potenzialmente vulnerabili

Dalla combinazione di queste informazioni, possiamo fare alcune stime. Se consideriamo circa 1 miliardo di dispositivi Windows nel mondo, e assumiamo che circa il 20-25% di questi siano nelle versioni Professional o Enterprise (e quindi abilitati a usare RDP), possiamo stimare che tra 200 e 250 milioni di dispositivi siano vulnerabili a questo tipo di errore.

4. Fattori aggiuntivi

• Utenti aziendali e organizzazioni: Le aziende e le organizzazioni che utilizzano Windows Server o hanno ambienti Windows 10/11 Professional (con RDP abilitato per l’accesso remoto) rappresentano una quota significativa di questi dispositivi vulnerabili. Inoltre, molte piccole e medie imprese (SMB) possono essere esposte, in quanto spesso usano RDP per accessi remoti da casa o in filiali distaccate.
• Frequenza dell’uso di RDP: Non tutti gli utenti Windows Professional o Enterprise usano RDP attivamente, quindi non tutti saranno colpiti da questa vulnerabilità. La percentuale di utilizzo di RDP potrebbe essere inferiore al 100%, ma la vulnerabilità è un rischio per chiunque abbia configurato RDP.

5. Conclusioni

La stima approssimativa è che 200-250 milioni di utenti potrebbero essere vulnerabili alla vulnerabilità RDP descritta, ma la percentuale esatta dipende dalla diffusione specifica delle edizioni di Windows, la configurazione del servizio RDP e quanto sia attivamente utilizzato nelle organizzazioni.

Fonti: l’analisi è basata sulle informazioni riportate da Tom’s Hardware Italia, Tom’s Hardware (US), Cybersecurity News, Ars Technica (ripreso da heise online), nonché sulla documentazione Microsoft aggiornata e contributi di esperti di sicurezza. Le misure di mitigazione sono state dedotte da raccomandazioni di professionisti del settore e best practice consolidate in ambito IT.