Chi gestisce ambienti Windows aziendali potrebbe aver notato, nelle ultime settimane, che i propri utenti si trovano davanti a finestre di avviso insolite quando aprono i file .rdp. Non si tratta di un malfunzionamento: è una modifica intenzionale introdotta da Microsoft con le patch cumulative di aprile 2026, in risposta a una vulnerabilità di sicurezza sfruttata attivamente.
In questo articolo analizziamo cosa è cambiato, perché è cambiato e soprattutto come adeguare i propri ambienti per continuare a usare i file RDP in modo fluido e sicuro.
La vulnerabilità alla base del cambiamento: CVE-2026-26151
Le patch cumulative KB5083769 (Windows 11) e KB5082200 (Windows 10) introducono nuove protezioni per i file di connessione Remote Desktop (.rdp). La motivazione è la CVE-2026-26151, una vulnerabilità di spoofing RDP sfruttata attivamente in ambienti reali.
Il gruppo russo APT29 (noto anche come Cozy Bear), legato all’SVR (servizio di intelligence estero russo), ha distribuito file .rdp malevoli tramite campagne di phishing mirate. Questi file, apparentemente innocui, erano in grado di:
- Redirigere unità locali e periferiche verso sistemi remoti controllati dagli attaccanti
- Modificare silenziosamente le impostazioni di connessione
- Ingannare gli utenti inducendoli a connettersi a sistemi non previsti
- Esfiltrare credenziali e dati locali
I file RDP sono da sempre un vettore di attacco sottovalutato: non sono eseguibili nel senso tradizionale del termine, quindi gli utenti tendono a fidarsi di essi, ma possono comunque influenzare in modo significativo il comportamento di una sessione remota.
Cosa cambia concretamente
Con le nuove patch, Windows tratta i file .rdp non firmati digitalmente come non attendibili per impostazione predefinita. Le conseguenze pratiche sono:
- La prima volta che si apre un file
.rdpdopo l’aggiornamento, compare un “educational dialog” che spiega i rischi dei file RDP e del phishing - Aprendo un file non firmato, appare un avviso con banner “Caution: Unknown remote connection” e il campo Publisher impostato a “Unknown publisher”
- Alcune funzionalità (come la redirezione degli appunti o delle unità locali) possono essere bloccate o richiedono conferma esplicita ad ogni uso
Nota importante: queste restrizioni si applicano solo ai file .rdp. Chi si connette digitando manualmente l’hostname nel client mstsc.exe o tramite riga di comando con mstsc /v:hostname non vedrà alcun avviso aggiuntivo.
Come risolvere: la firma digitale dei file RDP
La soluzione raccomandata da Microsoft è firmare digitalmente i file .rdp con un certificato di code signing attendibile. Una volta firmato, Windows può verificare l’autenticità e l’integrità del file, eliminando gli avvisi e ripristinando le funzionalità complete.
Lo strumento nativo per la firma è rdpsign.exe, incluso in Windows. Il comando base è:
rdpsign.exe /sha256 <thumbprint_certificato> <percorso_file.rdp>Esempio pratico:
rdpsign.exe /sha256 A1B2C3D4E5F6... "C:\RDP\ServerAziendale.rdp"Qualsiasi modifica al file dopo la firma invalida la firma stessa, garantendo l’integrità del documento.
Quale certificato usare?
Esistono tre opzioni principali, ciascuna adatta a scenari diversi:
- Certificato self-signed: gratuito, utile per ambienti di test o reti interne piccole. Deve essere distribuito manualmente su ogni macchina client come certificato attendibile.
- Certificato da Enterprise CA (Active Directory): la scelta ideale per ambienti di dominio. I certificati emessi dalla CA aziendale sono automaticamente attendibili su tutte le macchine domain-joined. Nessun costo aggiuntivo se si dispone già di una PKI interna.
- Certificato commerciale (DigiCert, ecc.): la scelta per ambienti con utenti esterni o macchine non domain-joined. Attendibile di default su tutti i sistemi Windows, ma comporta un costo annuale.
In alternativa, Microsoft Azure offre il servizio Trusted Signing, integrato con Entra ID e RBAC, come soluzione economica e moderna rispetto ai certificati commerciali tradizionali.
Automatizzare la firma con PowerShell: RDPFileSigner.ps1
Michael Morten Sonne ha rilasciato uno script PowerShell open-source chiamato RDPFileSigner.ps1 che automatizza l’intero flusso, dalla creazione del certificato alla firma, verifica e integrazione con Windows Explorer. Lo script è disponibile su GitHub.
Le principali modalità operative:
# Setup iniziale: crea/riusa il certificato, lo installa nei trust store
# e registra il menu contestuale per i file .rdp
.\RDPFileSigner.ps1
# Firmare un singolo file
.\RDPFileSigner.ps1 -Sign -RdpFile "C:\RDP\Server.rdp"
# Firmare tutti i file .rdp in una cartella (incluse sottocartelle)
.\RDPFileSigner.ps1 -Sign -RdpFolder "C:\RDP" -Recurse
# Usare un certificato Enterprise CA
.\RDPFileSigner.ps1 -Setup -CertTemplate "CodeSigning"
# Importare un certificato commerciale da .pfx
.\RDPFileSigner.ps1 -Setup -ImportPfxPath "C:\Certs\commercial.pfx"
# Verificare la firma su tutti i file in una cartella con report CSV
.\RDPFileSigner.ps1 -Verify -RdpFolder "C:\RDP" -ExportCsvPath "C:\Report\rdp-status.csv"
Lo script supporta anche la registrazione di un Scheduled Task che controlla automaticamente una cartella ogni 5 minuti e firma tutti i file .rdp presenti: utile quando i file vengono generati dinamicamente da soluzioni PAM o portali helpdesk:
.\RDPFileSigner.ps1 -TaskRegister -WatchFolder "C:\RDP" -CertThumbprint "A1B2C3..."
La modalità -Verify effettua una verifica crittografica completa: ricostruisce il blob firmato originale, decodifica la firma PKCS#7 incorporata nel file e invoca CheckSignature() per rilevare qualsiasi modifica post-firma. Il codice di uscita 2 in caso di firme non valide lo rende utilizzabile in pipeline CI/CD o script di monitoraggio.
Disabilitare temporaneamente le protezioni (sconsigliato)
Microsoft ha documentato un workaround tramite registro di sistema per disabilitare temporaneamente le nuove protezioni, ma lo sconsiglia esplicitamente e potrebbe rimuovere questo supporto in aggiornamenti futuri:
HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client
Nome: RedirectionWarningDialogVersion
Tipo: REG_DWORD
Valore: 1
Questa opzione non dovrebbe mai essere usata in produzione: bypassa una protezione pensata per contrastare attacchi reali e già sfruttati attivamente.
Raccomandazioni operative
Al di là della firma digitale, è buona pratica cogliere l’occasione per rivedere più in generale la gestione dei file RDP nell’organizzazione:
- Evitare la distribuzione via email: preferire portali interni attendibili o soluzioni di Remote Desktop Gateway
- Ridurre le redirections al minimo necessario: ogni redirezione abilitata è una potenziale superficie di attacco
- Formare gli utenti: spiegare il significato degli avvisi e quando è sicuro procedere evita la “warning fatigue”
- Automatizzare il rinnovo dei certificati: integrare la firma nel processo di generazione dei file RDP per non dover intervenire manualmente a ogni scadenza
Conclusioni
La modifica introdotta con le patch di aprile 2026 non è un bug né una scelta arbitraria: è la risposta di Microsoft a una vulnerabilità concretamente sfruttata da attori di threat intelligence statali. Per i team IT, il percorso più corretto è implementare la firma digitale dei file RDP, scegliendo il tipo di certificato più adatto al proprio ambiente.
Chi gestisce ambienti di dominio troverà probabilmente nella Enterprise CA la soluzione più rapida e senza costi aggiuntivi. Chi ha utenti esterni o macchine non domain-joined dovrebbe valutare Azure Trusted Signing come alternativa economica ai certificati commerciali tradizionali.