• Guide, Sicurezza, Sistemi Operativi
• 13 Maggio 2026

Quando si parla di nuove versioni di Windows Server, il rischio è sempre lo stesso: scambiare l’evoluzione della piattaforma per una protezione automatica.

Windows Server 2025 porta con sé miglioramenti importanti, soprattutto sul fronte della sicurezza, dell’hardening e dell’integrazione con scenari moderni di gestione. Credential Guard, Virtualization-based Security, protezioni aggiuntive per LSA, Attack Surface Reduction e Microsoft Defender for Endpoint fanno ormai parte del vocabolario quotidiano di chi amministra infrastrutture Microsoft.

Ma c’è una distinzione che vale la pena ribadire subito: una funzionalità disponibile non è necessariamente una funzionalità attiva, verificata, monitorata e coerente con il rischio dell’ambiente.

È qui che LSASS torna al centro del discorso.

Il Local Security Authority Subsystem Service, cioè lsass.exe, è uno dei processi più sensibili di Windows. Gestisce autenticazione, policy locali, credenziali, segreti, token e materiale legato ai meccanismi di autenticazione. Per un amministratore è un componente di sistema. Per un attaccante è spesso una cassaforte.

E come tutte le casseforti, il problema non è solo quanto sia robusta. Il problema è anche dove si trova, chi può avvicinarsi, chi può aprirla, chi sta guardando e chi si accorge se qualcuno prova a forzarla.

Il test: cosa è stato verificato davvero

Il punto di partenza è una ricerca pubblicata da Osher Jacobs nel repository AD-Lab-Research, dedicata alla possibilità di generare e analizzare offline un minidump di LSASS su Windows Server 2025.

Il test è interessante non perché dimostri una vulnerabilità nuova, ma perché fotografa uno scenario realistico di baseline:

• Windows Server 2025;
• build 26100, UBR 1742;
• Microsoft Defender attivo;
• Credential Guard non configurato;
• RunAsPPL non abilitato;
• host standalone in workgroup;
• accesso amministrativo locale già disponibile.

Questo ultimo punto è fondamentale. Non si parla di initial access, non si parla di escalation iniziale, non si parla di bypass remoto “magico”. L’assunzione è quella classica dell’assumed breach: l’attaccante ha già privilegi amministrativi locali sulla macchina.

Da lì la domanda diventa più interessante per chi difende: se un attaccante è già amministratore locale, Windows Server 2025 impedisce comunque l’estrazione e l’analisi dei segreti presenti in LSASS?

Nel test specifico, la risposta è: non necessariamente.

Il dump è stato creato, trasferito e analizzato offline con tooling open source. L’output ha mostrato che WDigest non espone password in chiaro, come atteso nelle configurazioni moderne, ma che materiale sensibile come NT hash e master key DPAPI può ancora essere presente e interpretabile in assenza di protezioni più robuste.

Questa è la parte importante: non serve trasformare il test in un titolo sensazionalistico. Non siamo davanti a “Windows Server 2025 bucato”. Siamo davanti a una dimostrazione molto più utile: senza Credential Guard, senza LSA Protection e senza controlli di accesso alla memoria di LSASS, una macchina aggiornata può comunque esporre materiale utile al movimento laterale.

Perché LSASS resta un obiettivo così appetibile

LSASS non è un processo qualsiasi. È coinvolto in operazioni fondamentali per l’identità del sistema: autenticazione locale, autenticazione di dominio, validazione delle credenziali, gestione di segreti e interazione con provider come NTLM, Kerberos, WDigest e DPAPI.

In un ambiente Active Directory, il furto di materiale da LSASS può consentire scenari molto diversi tra loro:

• recupero di hash NTLM;
• furto o abuso di ticket Kerberos;
• accesso a materiale DPAPI;
• movimento laterale;
• impersonificazione;
• escalation indiretta tramite credenziali già presenti sulla macchina;
• persistenza o accesso a risorse interne.

Naturalmente il risultato dipende dal contesto. Un server standalone in workgroup non contiene ticket Kerberos di dominio. Un server membro, un jump server, una workstation amministrativa o un server usato da account privilegiati possono invece raccontare una storia molto diversa.

Ed è proprio qui che il tema diventa architetturale.

Non tutte le macchine hanno lo stesso valore. Non tutti gli accessi amministrativi hanno lo stesso impatto. Non tutte le sessioni interattive sono uguali. Un conto è compromettere un server periferico. Un altro è compromettere una macchina dove si autentica chi amministra il dominio.

È il solito dettaglio minuscolo che poi diventa un incidente grosso come un armadio rack.

Cosa ha funzionato e cosa no

Nel test analizzato emergono tre elementi interessanti.

Il primo: WDigest non ha restituito password in chiaro. Questo è un buon segnale. Le versioni moderne di Windows non mantengono più, per impostazione predefinita, le credenziali WDigest in chiaro come avveniva in scenari legacy. Da questo punto di vista, la protezione attesa si comporta correttamente.

Il secondo: il materiale MSV/NTLM è risultato ancora interessante. In assenza di Credential Guard e LSA Protection, l’attaccante può trovarsi davanti a dati ancora utili, anche senza password in chiaro. Ed è qui che molti sottovalutano il problema: l’assenza della password leggibile non equivale all’assenza di rischio.

Il terzo: il test non aveva Credential Guard e non aveva RunAsPPL. Quindi non ha verificato un ambiente realmente hardened. Ha verificato una baseline non protetta da quei controlli specifici.

Questo cambia completamente il modo in cui va letto il risultato.

Non bisogna concludere: “Windows Server 2025 non protegge LSASS.”

La conclusione più corretta è: Windows Server 2025 può offrire protezioni importanti, ma bisogna verificare che siano realmente abilitate, applicabili al ruolo del server e monitorate nel tempo.

Figura 1 – msinfo32 – Credential Guard disabilitato

Credential Guard: disponibile non significa sempre attivo

Credential Guard è una delle mitigazioni più importanti in questo scenario. La sua funzione è isolare i segreti tramite Virtualization-based Security, riducendo la possibilità che malware o processi con privilegi amministrativi nel sistema operativo possano estrarre credenziali protette.

Con Windows Server 2025, Microsoft ha introdotto un comportamento più aggressivo rispetto al passato: Credential Guard può essere abilitato di default sui sistemi che rispettano determinati requisiti, in particolare sui server domain-joined che non sono Domain Controller e che soddisfano i prerequisiti hardware, firmware e software.

Questa è una novità positiva, ma non deve generare falsa sicurezza. Ci sono almeno quattro motivi per cui va verificata:

• il server potrebbe non soddisfare i requisiti;
• Credential Guard potrebbe essere stato disabilitato esplicitamente;
• il ruolo del server potrebbe non essere compatibile o raccomandato;
• un upgrade da una configurazione precedente può mantenere scelte già definite.

Inoltre, Microsoft stessa segnala che Credential Guard non è raccomandato sui Domain Controller e non protegge direttamente il database di Active Directory o il SAM. Questo è un passaggio spesso ignorato: la protezione dei segreti in memoria su un server membro non risolve magicamente tutti i problemi dell’identità in Active Directory.

Credential Guard è una difesa fondamentale, ma non è una gomma da cancellare per il rischio architetturale.

Questo comando PowerShell è stato eseguito su un DC. Il risultato è il seguente:

Figura 2 – PowerShell Credential Guard Disabilitato

LSA Protection e RunAsPPL

Un altro controllo centrale è la protezione aggiuntiva di LSA, spesso associata alla configurazione RunAsPPL.

Quando LSA Protection è abilitata, LSASS viene eseguito come processo protetto. Questo rende molto più difficile, per processi non protetti, leggere la memoria di LSASS o iniettare codice nel processo. In pratica, si alza la barriera tra “sono amministratore locale” e “posso leggere comodamente quello che voglio da LSASS”.

È una distinzione essenziale.

In molti ambienti si continua a ragionare come se l’amministratore locale fosse un dio minore della macchina. Storicamente, in parte, lo era. Ma la sicurezza moderna di Windows cerca proprio di ridurre il valore assoluto di quel privilegio, soprattutto quando si parla di segreti e identità.

RunAsPPL non elimina tutti i rischi. Non sostituisce una corretta gestione degli account privilegiati. Non impedisce ogni tecnica avanzata. Ma cambia il costo dell’attacco e blocca molte tecniche standard basate sull’apertura del processo LSASS e sulla lettura della memoria.

Nel test di baseline, RunAsPPL non era abilitato. Questo significa che il risultato va letto come una conferma del rischio in assenza del controllo, non come un fallimento del controllo stesso.

Attack Surface Reduction: il controllo spesso dimenticato

Microsoft Defender offre anche una regola ASR specifica per bloccare il furto di credenziali dal sottosistema Local Security Authority, cioè da lsass.exe.

Questa regola ha un comportamento preciso: non blocca necessariamente l’esecuzione del processo che tenta l’accesso, ma blocca l’accesso alla memoria di LSASS. È un dettaglio importante, perché nei log e nei report può sembrare che un processo sia stato “colpito” dalla regola, quando in realtà è stato bloccato solo il tentativo di accesso a LSASS.

Microsoft indica anche che, se LSA Protection è già abilitata, la regola ASR non aggiunge ulteriore protezione perché i due meccanismi lavorano in modo simile. Se invece LSA Protection non può essere abilitata per ragioni di compatibilità, la regola ASR può rappresentare un controllo equivalente o comunque molto utile.

Anche qui, però, serve maturità operativa.

Le regole ASR non vanno semplicemente “accese tutte” in produzione sperando che l’infrastruttura sopravviva. Vanno testate, portate in audit dove ha senso, analizzate, escluse con attenzione solo quando necessario e poi applicate con progressività.

La sicurezza fatta bene non è “clicca tutto su block”. Quella è più una forma di ottimismo armato.

Defender: visibilità non significa enforcement

Uno degli aspetti più interessanti della ricerca è l’analisi della telemetria di Microsoft Defender.

Secondo il test, Defender non ha generato eventi operativi classici di detection/remediation durante la finestra osservata, nonostante l’attività sia stata ricostruita successivamente attraverso tracce ETW e classificazioni interne.

Questo passaggio è fondamentale per chi fa detection engineering.

Molte organizzazioni ragionano ancora così:

• “Se succede qualcosa, l’EDR lo vede.”

In realtà la domanda dovrebbe essere molto più precisa:

• lo vede?
• lo classifica?
• lo blocca?
• genera un evento?
• genera un alert?
• l’alert arriva al SOC?
• il SOC lo capisce?
• qualcuno agisce in tempo?

Sono otto domande diverse. E no, non hanno automaticamente la stessa risposta.

Un motore di sicurezza può osservare un comportamento senza bloccarlo. Può classificarlo internamente senza generare un alert utile. Può produrre telemetria non immediatamente visibile nei log operativi più consultati. Può richiedere Defender for Endpoint e Advanced Hunting per essere letto con il livello di dettaglio necessario.

Questa è una delle lezioni più importanti del test: la protezione non si misura solo sulla presenza del prodotto, ma sulla catena completa che va dalla prevenzione alla visibilità, dalla visibilità all’alerting, dall’alerting alla risposta.

Cosa verificare in un ambiente reale

Per trasformare questo tema in attività concreta, la domanda non è “pypykatz funziona ancora?”.

La domanda corretta è: Nel mio ambiente, un tentativo di accesso a LSASS verrebbe impedito, rilevato e investigato?

Da qui nasce una checklist molto più utile..

1. Verificare lo stato di Credential Guard

Non dare per scontato che sia attivo solo perché il server è Windows Server 2025.

Verificare:

• requisiti hardware e firmware;
• stato di Virtualization-based Security;
• stato effettivo di Credential Guard;
• eventuali configurazioni esplicite di disable;
• compatibilità applicativa;
• differenza tra server membri, Domain Controller e ruoli particolari.

2. Verificare LSA Protection

Controllare se LSASS è eseguito come processo protetto.

Valutare l’abilitazione di RunAsPPL, considerando:

• compatibilità con plug-in LSA;
• password filter;
• smart card provider;
• software legacy;
• driver o componenti che interagiscono con LSA.

L’obiettivo non è abilitare una chiave di registro e sperare. L’obiettivo è introdurre un controllo stabile, testato e misurabile.

Figura 3 – Chiave RunAsPPL

0 significa non attiva. 1 con UEFI lock, 2 senza UEFI lock.

LSA Protection riduce la possibilità che processi non protetti leggano la memoria di LSASS o iniettino codice.

3. Valutare la regola ASR per LSASS

La regola “Block credential stealing from the Windows local security authority subsystem” dovrebbe essere considerata nei baseline di sicurezza, soprattutto dove LSA Protection non è attiva o non è immediatamente applicabile.

Va verificato:

• stato della regola;
• modalità audit o block;
• compatibilità con software presenti;
• volume degli eventi;
• integrazione con Microsoft Defender for Endpoint;
• query di hunting disponibili.

4. Controllare gli eventi di detection e remediation

Nel mondo Defender, eventi come 1116 e 1117 sono spesso usati per capire se una minaccia è stata rilevata e se è stata intrapresa un’azione.

Ma non bisogna fermarsi lì.

Un test serio deve includere:

• Microsoft-Windows-Windows Defender/Operational;
• eventi ASR;
• Defender for Endpoint Advanced Hunting;
• DeviceEvents;
• eventuali eventi Sysmon;
• PowerShell logging;
• process creation;
• accessi sospetti a LSASS;
• anomalie su Task Scheduler;
• trasferimenti anomali da percorsi temporanei o amministrativi.

5. Ridurre l’esposizione degli account privilegiati

La protezione di LSASS non può compensare una cattiva igiene degli account.

Serve evitare che account privilegiati si autentichino dove non dovrebbero.

Questo significa:

• tiering amministrativo;
• jump server controllati;
• PAW o workstation amministrative dedicate;
• limitazione degli accessi interattivi;
• separazione tra account utente e account amministrativi;
• protezione dei server dove transitano credenziali sensibili.
• Il principio è semplice: se una credenziale non arriva mai su una macchina compromessa, non deve essere protetta da LSASS su quella macchina. Non è poesia, ma funziona.

6. Validare con test controllati

Non basta dichiarare che “siamo protetti”.

Bisogna dimostrarlo.

In laboratorio, o in ambienti controllati, si possono costruire scenari di validazione per rispondere a domande precise:

• il tentativo di accesso a LSASS viene bloccato?
• quale controllo lo blocca?
• quale evento viene generato?
• l’evento arriva nel SIEM?
• il SOC lo correla correttamente?
• l’incidente produce una procedura di risposta?
• esistono eccezioni che riducono l’efficacia del controllo?

Questa è la differenza tra hardening documentale e hardening operativo. Il primo finisce in un Excel. Il secondo ferma gli incidenti.

Il ruolo dei Domain Controller

Un’attenzione particolare va dedicata ai Domain Controller.

Credential Guard non è raccomandato sui Domain Controller e non aggiunge protezione al database di Active Directory. Questo non significa che i Domain Controller vadano lasciati “comodi”. Significa che richiedono un modello di protezione diverso.

Per i Domain Controller diventano ancora più importanti:

• riduzione estrema del software installato;
• accesso amministrativo limitato;
• baseline dedicate;
• auditing avanzato;
• protezione fisica e virtuale;
• controllo dei backup;
• monitoraggio delle modifiche privilegiate;
• protezione degli account di servizio;
• patching controllato;
• segmentazione;
• eliminazione di accessi interattivi non necessari.

Il Domain Controller non è “un server un po’ più importante”. È l’autorità dell’identità. Se lo trattiamo come un file server nervoso, poi non possiamo stupirci se l’incidente prende brutte pieghe.

La lezione principale

La lezione più utile di questo test non è che un determinato tool riesca o non riesca a parsare un dump su una specifica build.

Questa è una fotografia tecnica interessante, ma destinata a cambiare. Cambiano le build, cambiano le firme, cambiano le strutture interne di LSASS, cambiano i parser, cambiano i comportamenti del motore di sicurezza.

La lezione vera è più stabile: proteggere LSASS richiede una strategia, non una speranza.

Una strategia significa:

• ridurre la possibilità di accesso alla memoria di LSASS;
• isolare i segreti quando possibile;
• impedire che account privilegiati lascino materiale sensibile su macchine non affidabili;
• attivare controlli preventivi coerenti;
• verificare che la telemetria esista;
• misurare se gli alert arrivano;
• testare la risposta;
• documentare eccezioni e limiti.

Windows Server 2025 aiuta. Ma non decide da solo quale sia il tuo modello amministrativo. Non sa quali server siano critici per la tua organizzazione. Non sa se il tuo jump server viene usato anche per aprire allegati di posta. Non sa se una vecchia applicazione ha costretto qualcuno a disabilitare una protezione sei mesi fa e nessuno se lo ricorda più.

La piattaforma può offrire i controlli. L’architettura deve renderli efficaci.

Conclusioni

Windows Server 2025 rappresenta un passo avanti importante per la sicurezza degli ambienti Microsoft. Ma l’idea che una nuova versione del sistema operativo renda automaticamente irrilevante il credential theft è pericolosa. LSASS rimane un obiettivo critico.

Credential Guard, LSA Protection, RunAsPPL, ASR, Defender for Endpoint e una buona strategia di detection sono tasselli fondamentali. Ma vanno abilitati, verificati, monitorati e integrati in un modello coerente di amministrazione sicura.

La domanda da portarsi a casa non è: Windows Server 2025 è sicuro?

La domanda migliore è: Nel mio ambiente Windows Server 2025, cosa succede davvero se qualcuno prova ad accedere a LSASS?

Se non conosciamo la risposta, non abbiamo una protezione. Abbiamo una supposizione. E in cybersecurity le supposizioni hanno un brutto vizio: di solito funzionano benissimo fino al giorno prima dell’incidente.

Stay tuned!