Autenticazione RDP a livello di rete, modalità Admin con restrizioni, Active Directory: le tre impostazioni che decidono chi controlla la tua sessione

Ogni checklist di hardening di Remote Desktop finisce con gli stessi tre punti: autenticazione RDP a livello di rete, modalità Admin con restrizioni, Active Directory — credenziali in cache. Spuntare tutti e tre non rende di per sé sicura una sessione Remote Desktop. Due di questi sono vere vittorie difensive, e il terzo — la modalità Admin con restrizioni — protegge le credenziali che digiti, offrendo però a un attaccante che possiede già un hash un modo per entrare.

Questo articolo separa i tre parametri, mostra come si vincolano a vicenda, e fornisce i valori di registro, i percorsi di Group Policy e i campi degli eventi necessari per verificarli.

Autenticazione RDP a livello di rete, modalità Admin con restrizioni, Active Directory: le tre decisioni dell’hardening

Una connessione Remote Desktop verso un host aggiunto al dominio comporta tre decisioni indipendenti, ciascuna configurata in un punto diverso:

1. L’autenticazione a livello di rete (NLA) — l’utente viene autenticato prima che la sessione venga stabilita?
2. Il livello di sicurezza — come vengono autenticati e cifrati il canale stesso?
3. La modalità di delega delle credenziali — il client invia le credenziali all’host remoto, punto e basta?

Un quarto parametro, il numero di accessi in cache, decide quante credenziali restano sull’host in seguito. La maggior parte degli strumenti di audit riporta questi elementi come quattro caselle indipendenti. In pratica interagiscono: scegliere il livello di sicurezza sbagliato disabilita silenziosamente NLA, e attivare la modalità di delega "sicura" cambia ciò di cui un attaccante ha bisogno per accedere.

Il livello di sicurezza viene prima

I tre livelli di sicurezza

Microsoft documenta tre livelli di sicurezza per una connessione RD Session Host. La distinzione conta più di quanto sembri, perché uno dei tre è mutuamente esclusivo con NLA:

Quest’ultima frase è di Microsoft, tratta da Configure Server Authentication and Encryption Levels. È il motivo per cui un host può avere una policy "NLA richiesto" e comunque non avere NLA realmente in gioco: quando il livello negoziato ricade sulla crittografia RDP nativa, si applica l’esclusione stessa di Microsoft e l’autenticazione a livello di rete non può essere usata.

Il fatto che Negotiate sia il valore predefinito è il problema silenzioso, e non è un residuo del passato: il riferimento SecurityLayer attuale di Microsoft documenta ancora 1 (negotiate) come "il valore predefinito". Non impone TLS — accetta ciò che il client offre e degrada al livello di sicurezza RDP per un client che dichiara di non supportare TLS. Un attaccante che controlla il lato client dell’handshake controlla questa scelta.

Livelli di crittografia

Un parametro distinto, il livello di crittografia, governa la robustezza della chiave. Microsoft elenca quattro valori, con Client Compatible come predefinito:

Vale la pena dirlo chiaramente su Low: lascia il traffico server-verso-client — il contenuto dello schermo di una sessione amministrativa — in chiaro.

Tutte queste impostazioni si trovano sotto Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security, e Microsoft precisa che queste impostazioni di Group Policy "avranno la precedenza sulle impostazioni configurate in Remote Desktop Session Host Configuration, ad eccezione dell’impostazione di policy Server Authentication Certificate Template".

Perché l’autenticazione a livello di rete conta

NLA anticipa l’autenticazione dell’utente prima dello stabilimento della sessione. La descrizione originale di Microsoft resta la più chiara: "completa l’autenticazione dell’utente prima che venga stabilita una connessione Remote Desktop e appaia la schermata di accesso", e i vantaggi indicati sono che il computer remoto "usa un numero limitato di risorse prima di autenticare l’utente" e che questo "può aiutare a migliorare la sicurezza riducendo il rischio di attacchi denial-of-service" (Configure Network Level Authentication).

Il valore di questa barriera di pre-autenticazione non è teorico. Nelle mitigazioni pubblicate insieme al suo avviso per CVE-2019-0708, la vulnerabilità di esecuzione di codice remoto pre-autenticazione di Remote Desktop Services comunemente nota come BlueKeep, Microsoft ha scritto:

NLA ha trasformato un bug pre-autenticazione sfruttabile in modo "wormable" in uno post-autenticazione. È tutto l’argomento a favore della sua obbligatorietà — mette ogni futura vulnerabilità RDP pre-autenticazione dietro un controllo delle credenziali.

L’impostazione lato host è un singolo valore di registro:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication

1 richiede NLA, 0 lo disabilita. La guida Microsoft per la risoluzione dei problemi delle VM Azure usa esattamente questo valore per disabilitare e riabilitare temporaneamente NLA — il che è anche il motivo per cui tende a essere disattivato in modo permanente durante un incidente, senza mai essere riattivato.

Modalità Admin con restrizioni: il controllo a doppio taglio

La modalità Admin con restrizioni cambia ciò che il client invia. La documentazione Remote Credential Guard di Microsoft elenca con precisione i suoi benefici di sicurezza:

• Le credenziali non vengono inviate all’host remoto
• La sessione Remote Desktop si connette ad altre risorse con l’identità dell’host remoto
• Un attaccante non può agire per conto dell’utente, e qualsiasi attacco resta locale al server

La tabella comparativa di Microsoft indica che la modalità Admin con restrizioni previene il Pass-the-Hash, e per gli scenari di helpdesk la raccomanda esplicitamente: "le connessioni RDP dovrebbero essere avviate solo usando il parametro /RestrictedAdmin". Da notare anche che l’accesso RDP in modalità Admin con restrizioni è concesso dall’appartenenza al gruppo Administrators sull’host remoto, non al gruppo Remote Desktop Users.

Sia la modalità sia Remote Credential Guard dipendono da un unico valore lato host:

reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

L’inversione

Qui è dove le due letture divergono, e la distinzione è direzionale.

L’affermazione di Microsoft riguarda le credenziali che lasciano il client: con Admin con restrizioni, nulla arriva sull’host remoto, quindi nulla può essere raccolto lì e ripetuto. Questo è vero.

La conseguenza riguarda le credenziali che entrano nell’host. Poiché il client non invia più una password, l’accesso viene soddisfatto con materiale di credenziali che il client già possiede — il che significa che un hash NTLM è sufficiente. Una ricerca pubblica ha documentato questo lo stesso anno in cui la funzionalità è stata rilasciata. Portcullis Labs (autore MRL, 20 ottobre 2013) ha descritto il client che inviava "empty credentials in the TSPasswordCreds structure" su Windows 8.1 e Windows Server 2012 R2, e ha dimostrato l’autenticazione passando un hash al posto della password. Il loro proof of concept non era un client standard: richiedeva FreeRDP-pth, una versione patchata di FreeRDP il cui argomento -p porta un hash NT invece di una password.

# FreeRDP-pth, il client patchato del 2013 — -p porta l’hash NT
xfreerdp -u test -p 36374BD2767773A2DD4F6B010EC5EE0D 192.168.226.129

Un client standard non accetterà questo: tratta l’hash come una password in chiaro e l’accesso fallisce. FreeRDP attuale implementa questa capacità in modo nativo, con l’opzione documentata come "Pass the hash (restricted admin mode)":

xfreerdp3 /u:test /pth:36374BD2767773A2DD4F6B010EC5EE0D /v:192.168.226.129

Lo stesso articolo nota che la tecnica funziona solo per gli amministratori — i membri del gruppo Remote Desktop Users non possono autenticarsi in questo modo. Con il client Windows nativo, l’equivalente consiste nell’iniettare prima l’hash in una sessione di accesso:

sekurlsa::pth /user:Administrator /domain:CORP /ntlm:<hash> /run:"mstsc.exe /restrictedadmin"

Quindi entrambe le affermazioni sono valide contemporaneamente. La modalità Admin con restrizioni impedisce che le tue credenziali vengano rubate *dall’*host remoto, e abbassa la soglia per accedere a quell’host, facendola passare da una password in chiaro a un semplice hash. Se il pass-the-hash è già praticabile nel tuo ambiente, attivare la modalità Admin con restrizioni a livello di dominio la estende all’accesso RDP interattivo su ogni host dove è attivata.

C’è una seconda conseguenza. Poiché l’autenticazione viene valutata su un token anziché su una password digitata, i controlli applicati a destinazione possono essere aggirati. SpiderLabs (Apurva Goenka, 15 novembre 2023 — pubblicato sotto Trustwave, da allora acquisita da LevelBlue) ha documentato che l’autenticazione "non avviene sul server Remote Desktop ma sul client stesso", quindi "i fattori di autenticazione applicati sul server di destinazione, come MFA tramite Duo, Okta... risultano inefficaci" (Restricted Admin Mode – Circumventing MFA On RDP Logons).

Accessi in cache: cosa rimane indietro

Le credenziali di dominio in cache permettono a un utente di accedere quando non è raggiungibile alcun controller di dominio. La guida Microsoft su Interactive logon: Number of previous logons to cache (in case domain controller is not available) espone il rischio direttamente: "Un attaccante in grado di accedere al file system del server potrebbe individuare queste informazioni in cache e usarle in un attacco a forza bruta per tentare di determinare le password degli utenti." Le informazioni in cache "non scadono, ma possono essere sovrascritte".

Il valore predefinito è 10 accessi sui server membri e sui computer client, e l’intervallo accettato va da 0 a 50. La tabella dei valori predefiniti di Microsoft indica che il valore effettivo predefinito su un controller di dominio è Nessun effetto — l’impostazione semplicemente non si applica lì.

Bisogna citare la raccomandazione con cautela, perché la pagina stessa di Microsoft non è univoca. La sua sezione Countermeasure dice di configurare il valore a 0, disabilitando la cache locale. La sua sezione Best practices dice che le baseline di sicurezza Windows "non raccomandano di configurare questa impostazione" affatto. La sua sezione Potential impact suggerisce 2 per i computer degli utenti finali, così gli utenti mobili possono comunque accedere fuori rete. La posizione difendibile per un server membro Tier 0 è un valore basso; per i portatili, 0 interrompe completamente l’accesso offline. Una sfumatura regolarmente fraintesa: questa impostazione non si applica ai controller di dominio, il cui valore effettivo predefinito Microsoft elenca come "Nessun effetto" — i DC ospitano la directory e non mettono in cache gli accessi di dominio.

Rilevamento

L’evento 4624 porta i campi necessari per distinguere questi accessi. La versione 2 dell’evento (Windows 10 e successivi) ha aggiunto un campo RestrictedAdminMode, che secondo Microsoft viene "popolato solo per le sessioni di accesso di tipo RemoteInteractive" ed è un indicatore Sì/No che segnala se è stata usata la modalità Admin con restrizioni.

Questo dettaglio conta per scrivere una regola corretta: una sessione RDP in Admin con restrizioni resta Logon Type 10 (RemoteInteractive), non Type 3. La modalità è visibile nel flag, non nel tipo di accesso.

La raccomandazione di monitoraggio di Microsoft su quella stessa pagina merita di essere adottata alla lettera: se la modalità Admin con restrizioni deve essere usata da determinati account, monitora gli accessi di quegli account con Logon Type = 10 e Restricted Admin Mode = "Yes", e genera un avviso quando Restricted Admin Mode = "No" per loro. Invertirlo è altrettanto utile — avvisare quando RestrictedAdminMode = "Yes" per account che non dovrebbero mai usarlo, poiché gli strumenti degli attaccanti ricorrono a /restrictedadmin proprio perché accetta un hash.

Verifica della configurazione

Verificare la configurazione stessa è una lettura di registro su ciascun host:

$ts = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
Get-ItemProperty -Path $ts -Name UserAuthentication, SecurityLayer, MinEncryptionLevel
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name DisableRestrictedAdmin -ErrorAction SilentlyContinue

L’assenza del valore DisableRestrictedAdmin significa che la modalità non è attivata; un valore di 0 significa che lo è.

Mitigazione

1. Richiedere TLS come livello di sicurezza. Attiva Require use of specific security layer for remote (RDP) connections e seleziona SSL, sotto Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security. Emetti i certificati RD Session Host dalla tua CA interna anziché accettare il certificato autofirmato predefinito.

2. Richiedere NLA. Nello stesso percorso di policy, attiva Require user authentication for remote connections by using Network Level Authentication. Group Policy ha la precedenza sulla configurazione locale, il che è esattamente ciò che serve per controllare il drift di configurazione.

3. Alzare il livello di crittografia. Configura Set client connection encryption level su High in modo che il traffico sia a 128 bit in entrambe le direzioni, e conferma che nessun host resti a Low.

4. Decidere sulla modalità Admin con restrizioni in modo deliberato, per tier. Non attivarla a livello di dominio per riflesso. Dove gli amministratori si connettono a host meno affidabili, preferisci Remote Credential Guard tramite la policy Restrict delegation of credentials to remote servers impostata su Require Remote Credential Guard. Dove è realmente necessaria per il lavoro di helpdesk, attivala solo su quegli host e genera avvisi sul suo utilizzo altrove. Nota l’avvertenza di Microsoft: quando Restrict Credential Delegation è attivato, "il parametro /restrictedAdmin verrà ignorato" e viene usato Remote Credential Guard al suo posto.

5. Abilitare la delega di credenziali non esportabili sugli host remoti — richiesta sia per Admin con restrizioni sia per Remote Credential Guard — tramite Remote host allows delegation of nonexportable credentials.

6. Abbassare gli accessi in cache sui server. Configura Interactive logon: Number of previous logons to cache su un valore basso sotto Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Valida questo rispetto ai tuoi requisiti di accesso offline prima di applicarlo ai portatili.

7. Distribuire LAPS. Microsoft associa la sua guida sull’Admin con restrizioni a Windows LAPS, che "mitiga il rischio di escalation laterale" derivante da password amministratore locale condivise — esattamente la condizione che rende utile un singolo hash rubato su ogni host.

Verificare il risultato

Verifica il risultato invece di fidarti del report della GPO:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" |
    Select-Object UserAuthentication, SecurityLayer, MinEncryptionLevel

UserAuthentication dovrebbe essere 1 e SecurityLayer dovrebbe essere 2 (TLS).

Questi controlli si rafforzano a vicenda insieme al resto del tuo hardening dell’autenticazione — richiedere TLS su RDP è lo stesso ragionamento che richiedere la firma SMB e la firma LDAP sui percorsi di NTLM relay, e limitare chi può raggiungere Tier 0 via RDP è inseparabile dal limitare la delega Kerberos e la policy delle password.

Come EtcSec rileva questo

EtcSec verifica questi quattro parametri in modo indipendente, perché falliscono in modo indipendente. PA038_RDP_NLA_NOT_REQUIRED genera un finding quando nessuna GPO del dominio configura UserAuthentication a 1. PA038_RDP_SECURITY_LAYER_WEAK scatta a meno che una policy non fissi il livello di sicurezza su TLS, così anche il valore predefinito Negotiate, che può degradare silenziosamente, viene segnalato. TERMINAL_SERVICES_NOT_HARDENED copre la superficie più ampia di configurazione di Terminal Services e RDP, e CACHED_LOGONS_EXCESSIVE scatta quando Winlogon\CachedLogonsCount supera 4. Questi sono controlli a livello di policy: un risultato pulito significa che la policy esiste, e confermare che sia effettivamente applicata su ogni host resta la lettura di registro sopra indicata.