Con le build più recenti di Windows 11 26H2, Microsoft ha fatto un passo che molti amministratori di sistema aspettavano da anni: Sysmon, lo storico strumento di System Monitor di Sysinternals, è ora integrato direttamente nel sistema operativo come funzionalità opzionale. Non serve più scaricare l’eseguibile da Microsoft Sysinternals, accettare l’EULA a riga di comando e gestirne manualmente l’aggiornamento su ogni macchina: Sysmon diventa un componente nativo di Windows, installabile e configurabile con gli stessi strumenti che si usano già per le altre feature opzionali.

Per chi si occupa di hardening, detection engineering o semplicemente di avere una visibilità decente sui propri endpoint, questa è una notizia rilevante: significa poter distribuire una baseline di monitoraggio coerente via Intune, Group Policy o Configuration Manager, senza dipendere da un binario di terze parti da tenere aggiornato fuori dal normale ciclo di patching di Windows.

Cos’è Sysmon e perché è diverso da un semplice Event Log

Sysmon è un servizio di sistema e un driver che osserva l’attività del sistema operativo a un livello molto più granulare di quanto non facciano i log di sicurezza standard di Windows. In particolare registra, con un dettaglio che il Security Log nativo non offre:

• creazione di processi, con riga di comando completa, hash del binario e processo padre;
• connessioni di rete, incluse porta e processo che le ha originate;
• modifiche agli orari di creazione dei file (un indicatore classico di timestomping);
• caricamento di driver e DLL;
• modifiche al registro di sistema;
• creazione di named pipe, accessi WMI e molto altro, in base alla configurazione XML applicata.

Questi eventi finiscono in un log dedicato, visibile in Visualizzatore eventi > Registri applicazioni e servizi > Microsoft-Windows-Sysmon/Operational, e sono la materia prima su cui si basano la maggior parte delle regole SIGMA, delle query Sentinel/Splunk per il threat hunting e delle configurazioni pubbliche più note, come la celebre sysmon-config di SwiftOnSecurity.

La versione integrata in Windows 11 non è un prodotto diverso: è lo stesso motore Sysinternals, reso disponibile come optional feature del sistema operativo. Cambia il meccanismo di distribuzione e di lifecycle, non la logica di funzionamento né il formato della configurazione XML, che resta pienamente compatibile con quella usata finora.

Prerequisiti

Prima di procedere, verifica due cose:

1. Se sulla macchina è già installata una copia “classica” di Sysmon scaricata da Sysinternals, va disinstallata (sysmon64 -u o sysmon -u a seconda della versione) prima di abilitare la feature integrata, per evitare conflitti tra driver.
2. La build di Windows 11 deve includere la feature. Al momento della stesura è disponibile sui canali Insider (Dev e Beta, a partire dalle build 26220.7752 e 26300.7733) in vista del rollout su 26H2; su alcune installazioni potrebbe non essere ancora presente.

Abilitare Sysmon via PowerShell

Il modo più diretto per abilitare la feature è PowerShell, da una sessione con privilegi di amministratore:

Enable-WindowsOptionalFeature -Online -FeatureName Sysmon

In alternativa, lo stesso risultato si ottiene da prompt dei comandi con DISM:

DISM /Online /Enable-Feature /FeatureName:Sysmon

Oppure, per chi preferisce l’interfaccia grafica, da Impostazioni > App > Funzionalità facoltative > Altre funzionalità di Windows, selezionando la voce Sysmon.

Attenzione: abilitare la feature registra il componente nel sistema, ma non avvia ancora il servizio. È un dettaglio facile da perdere per chi ha familiarità con il vecchio flusso “scarica ed esegui”, e la causa più comune di “non vedo eventi nel log” dopo l’attivazione.

Inizializzare il servizio

Dopo aver abilitato la feature, va eseguito il comando di inizializzazione, sempre con privilegi elevati:

sysmon -i

Questo comando installa il driver, avvia il servizio e accetta implicitamente l’EULA (nelle versioni Sysinternals andava confermato esplicitamente con -accepteula alla prima esecuzione; vale la pena controllare che il comportamento sia identico anche nella build che si sta usando). Senza argomenti aggiuntivi, Sysmon parte con una configurazione predefinita piuttosto permissiva, che per un uso in produzione è quasi sempre da sostituire con una configurazione XML personalizzata.

Applicare una configurazione XML personalizzata

Il punto di forza di Sysmon è la possibilità di definire con precisione cosa loggare e cosa escludere, per evitare di saturare il log con rumore (ad esempio il traffico di rete di un browser) e concentrarsi sugli eventi rilevanti per la detection. La configurazione si applica con:

sysmon -c C:\Config\sysmon-config.xml

Per vedere la configurazione attualmente caricata, senza modificarla:

sysmon -c

Chi parte da zero può usare come base una configurazione pubblica ben mantenuta, come quella di SwiftOnSecurity o quella del progetto Olaf Hartong / sysmon-modular, e adattarla poi all’ambiente specifico (escludendo ad esempio i processi di antivirus/EDR già presenti, che altrimenti generano un volume enorme di eventi ridondanti).

Verificare che Sysmon stia scrivendo eventi

Il test più rapido è generare un evento e controllarlo da PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10 |
    Select-Object TimeCreated, Id, Message

Se il log restituisce eventi recenti (tipicamente Event ID 1 per la creazione di processi, Event ID 3 per le connessioni di rete), il servizio è attivo e sta applicando correttamente la configurazione. In caso contrario, verifica lo stato del servizio con:

Get-Service Sysmon*

e, se necessario, ripeti l’inizializzazione con sysmon -i.

Cosa cambia per chi gestisce molte macchine

Finché Sysmon era un download esterno, distribuirlo su larga scala significava impacchettarlo come applicazione (via Intune, SCCM/ConfigMgr o uno script di login) e gestirne separatamente gli aggiornamenti rispetto al ciclo di patch Tuesday. Con l’integrazione nativa, l’attivazione della feature può essere veicolata come una qualsiasi impostazione di sistema: una Configuration Service Provider (CSP) policy via Intune, una Group Policy che abilita la optional feature, o semplicemente uno script di provisioning eseguito in fase di imaging. La configurazione XML resta comunque da distribuire separatamente (ad esempio via Intune come file di configurazione o script di avvio), ma il componente di base segue finalmente lo stesso ciclo di vita del sistema operativo.

Per i team di detection engineering, questo riduce sensibilmente l’attrito nell’adottare Sysmon come standard di baseline su flotte Windows 11, soprattutto in ambienti dove l’installazione di software non Microsoft è soggetta a processi di approvazione più lunghi.

Conclusione

L’arrivo di Sysmon come funzionalità integrata in Windows 11 è un cambiamento più organizzativo che tecnico: la logica di logging resta quella nota da anni, ma la distribuzione diventa parte del sistema operativo stesso. Per chi già usa Sysmon in produzione, vale la pena pianificare la migrazione dalla versione Sysinternals a quella nativa non appena disponibile sui canali stabili, portandosi dietro la configurazione XML esistente. Per chi non lo ha ancora adottato, questo è probabilmente il momento più semplice per iniziare: niente più download manuali, niente più EULA da accettare a mano su ogni macchina, solo Enable-WindowsOptionalFeature e sysmon -i.

Fonte: 4sysops.com