Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Succede spesso nei reparti IT: si automatizza tutto, si riduce il lavoro manuale e le installazioni scorrono lisce. Windows Deployment Services è nato proprio per questo. Avviare macchine in rete e distribuire Windows senza interventi umani… comodo, quasi magico.
Eppure quella comodità, in certi casi, può diventare una porta socchiusa. Non sempre visibile, anzi. Ma abbastanza da far drizzare le antenne agli amministratori di sistema quando è emersa la vulnerabilità legata al file Unattend.xml.
Il problema nasce dal meccanismo chiamato hands-free deployment, una funzione di Windows Deployment Services che usa il file Unattend.xml – spesso definito anche Answer file – per automatizzare le schermate di installazione. Dentro quel file possono comparire impostazioni delicate, persino credenziali.
Il punto critico? Se il file viene trasmesso attraverso un canale RPC non autenticato, qualcuno sulla stessa rete potrebbe intercettarlo. E da lì il passo successivo non è difficile da immaginare: furto di credenziali o persino esecuzione di codice remoto. Non serve un attacco sofisticato, basta trovarsi sulla stessa rete.
Per ridurre il rischio, Microsoft ha deciso di cambiare il comportamento di default di Windows Deployment Services. La transizione avviene in due fasi. Dal 13 gennaio 2026 la funzione hands-free continua a esistere, ma gli amministratori possono disattivarla esplicitamente per migliorare la sicurezza.
In questa prima fase compaiono anche nuovi eventi nei log e alcune chiavi di registro che permettono di scegliere tra modalità sicura e modalità non sicura. In pratica è l’inizio della dismissione progressiva del deployment completamente automatico tramite questo meccanismo.
Da aprile 2026 cambia il comportamento predefinito. Il sistema diventa secure-by-default: il deployment hands-free viene disabilitato automaticamente. Se un amministratore vuole continuare a usarlo deve riattivarlo tramite la chiave di registro AllowHandsFreeFunctionality impostata a 1.
Ma qui arriva la parte interessante… e un po’ scomoda. Il sistema segnalerà nei log che si sta usando una configurazione non sicura e che file sensibili potrebbero essere intercettati. Insomma, funziona ancora, ma con un cartello luminoso sopra.
Verso la fine del processo di aggiornamento, l’indicazione è abbastanza chiara: rivedere la configurazione WDS, individuare dove viene usato Unattend.xml e prepararsi a soluzioni alternative. L’intero intervento di sicurezza è stato documentato da Microsoft insieme alle istruzioni tecniche e al riferimento alla vulnerabilità CVE-2026-0386.
Per la community di Red Hot Cyber: questa vicenda ricorda qualcosa che gli amministratori sanno bene ma che ogni tanto si dimentica. Le automazioni sono potenti… finché restano sotto controllo. Appena una configurazione espone file sensibili sulla rete, anche solo per comodità operativa, la superficie di attacco cresce. E parecchio.
