yamato-security/enablewindowslogsettingsDocumentazione e script per abilitare correttamente i log degli eventi di Windows.
<div align="center">
<h1>
<img alt="Logo Yamato Security" src="https://assets.kitploit.com/production/public/readmes/47906/3c1a7269709550a2bd86b72a79eae8a16d904fa1acd46bc922bff0db1d103e51.png" width="80%">
</h1>
<h1>Guida di Yamato Security alla configurazione dei log eventi di Windows per DFIR e Threat Hunting</h1>
[ <b>English</b> ] | [<a href="https://github.com/yamato-security/enablewindowslogsettings/blob/main/README-Japanese.md">日本語</a>]
</div>
<p>
Questa è un'altra guida sulla corretta configurazione e sul monitoraggio dei log eventi di Windows, con particolare attenzione alla registrazione per le regole [sigma](https://github.com/SigmaHQ/sigma).
> Questo è un lavoro in corso, quindi controlla periodicamente gli aggiornamenti.
# TLDR
* Con le impostazioni di controllo predefinite di Windows è possibile utilizzare solo circa il 10~20% delle regole di rilevamento di [sigma](https://github.com/SigmaHQ/sigma).
* Anche se un log di Windows è abilitato, per impostazione predefinita la dimensione massima dei log è compresa tra 1~20 MB, quindi c'è una buona probabilità che le prove vengano rapidamente sovrascritte.
* Abilita le impostazioni di controllo appropriate con [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/main/YamatoSecurityConfigureWinEventLogs.bat) o [WELA (Windows Event Log Auditor)](https://github.com/Yamato-Security/WELA) per utilizzare fino a circa il 75% delle regole sigma e conservare i log per tutto il tempo necessario.
- **Avvertenza: assicurati di personalizzare lo script in base alle tue esigenze e di testarlo prima dell'uso in produzione!**
* Installa [sysmon](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon) per una copertura completa. (**Altamente consigliato!**)
# Progetti correlati
* [Hayabusa](https://github.com/Yamato-Security/hayabusa) - threat hunting basato su sigma e generatore di timeline forensi veloci per i log eventi di Windows.
* [Hayabusa Rules](https://github.com/Yamato-Security/hayabusa-rules) - regole di rilevamento per hayabusa.
* [Hayabusa Sample EVTXs](https://github.com/Yamato-Security/hayabusa-sample-evtx) - file evtx di esempio da utilizzare per testare le regole di rilevamento hayabusa/sigma.
* [Takajo](https://github.com/Yamato-Security/takajo) - analizzatore dei risultati di hayabusa.
* [WELA (Windows Event Log Auditor)](https://github.com/Yamato-Security/WELA) - uno strumento per controllare le impostazioni dei log eventi di Windows.
# Indice
- [TLDR](#tldr)
- [Progetti correlati](#companion-projects)
- [Indice](#table-of-contents)
- [Autore](#author)
- [Contributori](#contributors)
- [Riconoscimenti](#acknowledgements)
- [Problemi con le impostazioni predefinite dei log di Windows](#problems-with-the-default-windows-log-settings)
- [Avvertenza: apporta modifiche ai tuoi sistemi a tuo rischio!](#warning-make-changes-to-your-systems-at-your-own-risk)
- [Log eventi di Windows importanti](#important-windows-event-logs)
- [Principali fonti di log di Sigma](#sigmas-top-log-sources)
- [Principali fonti di log di sigma](#top-sigma-log-sources)
- [Principali ID evento di sicurezza](#top-security-event-ids)
- [Aumentare la dimensione massima del file](#increasing-the-maximum-file-size)
- [Opzione 1: manualmente tramite Visualizzatore eventi](#option-1-manually-through-event-viewer)
- [Opzione 2: strumento integrato di Windows](#option-2-windows-built-in-tool)
- [Opzione 3: PowerShell](#option-3-powershell)
- [Opzione 4: Criteri di gruppo](#option-4-group-policy)
- [Script di configurazione](#configuration-script)
- [Configurazione delle impostazioni dei log](#configuring-log-settings)
- [Log Sysmon (1382 regole sigma)](#sysmon-log-1382-sigma-rules)
- [Log di sicurezza (1045 regole sigma (903 regole di creazione processi + 142 altre regole))](#security-log-1045-sigma-rules-903-process-creation-rules--142-other-rules)
- [Log di PowerShell (175 regole sigma)](#powershell-logs-175-sigma-rules)
- [Registrazione dei moduli (30 regole sigma)](#module-logging-30-sigma-rules)
- [Abilitazione della registrazione dei moduli](#enabling-module-logging)
- [Opzione 1: abilitazione tramite Criteri di gruppo](#option-1-enabling-through-group-policy)
- [Opzione 2: abilitazione tramite registro di sistema](#option-2-enabling-through-the-registry)
- [Registrazione dei blocchi di script (134 regole sigma)](#script-block-logging-134-sigma-rules)
- [Abilitazione della registrazione dei blocchi di script](#enabling-script-block-logging)
- [Opzione 1: abilitazione tramite Criteri di gruppo](#option-1-enabling-through-group-policy-1)
- [Opzione 2: abilitazione tramite registro di sistema](#option-2-enabling-through-the-registry-1)
- [Registrazione della trascrizione](#transcription-logging)
- [Abilitazione della registrazione della trascrizione](#enabling-transcription-logging)
- [Opzione 1: abilitazione tramite Criteri di gruppo](#option-1-enabling-through-group-policy-2)
- [Opzione 2: abilitazione tramite registro di sistema](#option-2-enabling-through-the-registry-2)
- [Riferimenti](#references)
- [Log di sistema (55 regole sigma)](#system-log-55-sigma-rules)
- [Log applicazioni (16 regole sigma)](#application-log-16-sigma-rules)
- [Log operativo di Windows Defender (10 regole sigma)](#windows-defender-operational-log-10-sigma-rules)
- [Log operativo Bits-Client (6 regole sigma)](#bits-client-operational-log-6-sigma-rules)
- [Log del firewall (6 regole sigma)](#firewall-log-6-sigma-rules)
- [Log operativo NTLM (3 regole sigma)](#ntlm-operational-log-3-sigma-rules)
- [Log KernelMode e UserMode di Security-Mitigations (2 regole sigma)](#security-mitigations-kernelmode-and-usermode-logs--2-sigma-rules)
- [Log PrintService (2 regole sigma)](#printservice-logs-2-sigma-rules)
- [Admin (1 regola sigma)](#admin-1-sigma-rule)
- [Operativo (1 regola sigma)](#operational-1-sigma-rule)
- [Log di sicurezza SMBClient (2 regole sigma)](#smbclient-security-log-2-sigma-rules)
- [Log AppLocker (1 regola sigma)](#applocker-logs-1-sigma-rule)
- [Log operativo CodeIntegrity (1 regola sigma)](#codeintegrity-operational-log-1-sigma-rule)
- [Log operativo Diagnosis-Scripted (1 regola sigma)](#diagnosis-scripted-operational-log-1-sigma-rule)
- [Log operativo DriverFrameworks-UserMode (1 regola sigma)](#driverframeworks-usermode-operational-log--1-sigma-rule)
- [Log operativo WMI-Activity (1 regola sigma)](#wmi-activity-operational-log--1-sigma-rule)
- [Log operativo TerminalServices-LocalSessionManager (1 regola sigma)](#terminalservices-localsessionmanager-operational-log--1-sigma-rule)
- [Log operativo TaskScheduler (1 regola sigma)](#taskscheduler-operational-log--1-sigma-rule)
# Autore
Zach Mathis ([@yamatosecurity](https://twitter.com/yamatosecurity)). Man mano che svolgo ulteriori ricerche e test, intendo aggiornare periodicamente questo documento poiché c'è molto margine di miglioramento (sia nella documentazione che nella creazione di ulteriori regole di rilevamento). Le PR sono benvenute e ti aggiungerò volentieri come contributore. Se trovi errori in questa documentazione, per favore fammelo sapere e li correggerò il prima possibile.
Se trovi utile tutto questo, per favore lascia una stella su GitHub, probabilmente mi aiuterà a motivarmi a continuare ad aggiornare questo progetto.
# Contributori
* DustInDark (hitenkoku): correzioni della traduzione giapponese.
* Fukusuke Takahashi (fukusuket): traduzioni e correzioni giapponesi.
* LasseKrache: segnalazione di un bug nello script batch.
# Riconoscimenti
La maggior parte delle informazioni proviene dalle [Domande frequenti sul controllo di sicurezza avanzato](https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-auditing-faq) di Microsoft, dalle regole di [sigma](https://github.com/SigmaHQ/sigma), dalla [Guida alla registrazione degli eventi ACSC](https://www.cyber.gov.au/acsc/view-all-content/publications/windows-event-logging-and-forwarding) e dalle mie ricerche/test. Desidero ringraziare in particolare la [community sigma](https://github.com/SigmaHQ/sigma/graphs/contributors) per aver reso il rilevamento delle minacce open source e gratuito a beneficio di tutti i difensori.
# Problemi con le impostazioni predefinite dei log di Windows
Per impostazione predefinita, Windows non registra molti eventi necessari per rilevare attività dannose ed eseguire indagini forensi.
Inoltre, la dimensione massima predefinita dei file di evento è di soli 20 MB per i log eventi classici (`Security`, `System`, `Application`), 15 MB per PowerShell e appena 1 MB per quasi tutti gli altri log, quindi c'è una buona probabilità che le prove vengano sovrascritte nel tempo.
In questo repository è disponibile un semplice [script batch](https://github.com/yamato-security/enablewindowslogsettings/blob/main/YamatoSecurityConfigureWinEventLogs.bat) che consente agli amministratori di sistema di configurare facilmente i propri computer Windows, in modo da avere i log necessari quando si verifica un incidente. Per le reti di grandi dimensioni, probabilmente vorrai usare questo documento come riferimento e configurare gli endpoint con Criteri di gruppo e/o Intune.
# Avvertenza: apporta modifiche ai tuoi sistemi a tuo rischio!
Consiglio vivamente di migliorare le impostazioni predefinite di registrazione degli eventi di Windows e faccio del mio meglio per fornire le informazioni più accurate. Tuttavia, non mi assumo alcuna responsabilità per eventuali effetti negativi derivanti dall'abilitazione di una quantità eccessiva di registrazione o per l'accuratezza di qualsiasi cosa in questo repository.
È tua responsabilità comprendere e testare qualsiasi modifica apportata ai tuoi sistemi su macchine di test prima di implementarla in produzione.
Consiglio di attivare quanta più registrazione possibile su macchine di test che replicano il tuo ambiente per almeno una settimana, quindi verificare se ci sono eventi che generano troppo rumore o se ci sono eventi che desideri ma che non vengono generati.
Puoi visualizzare il numero totale e la percentuale di ID evento in un file `evtx` con il comando di metriche degli ID evento di [Hayabusa](https://github.com/Yamato-Security/hayabusa).
Esempio: `hayabusa.exe eid-metrics -f path/to/Security.evtx`
# Log eventi di Windows importanti
1. Il log eventi più importante da attivare è probabilmente `Process Creation`, che tiene traccia dei processi eseguiti su un sistema.
Attualmente, circa la metà delle regole di rilevamento di [Sigma](https://github.com/SigmaHQ/sigma) si basa su questo evento.
È possibile ottenere questo risultato installando Sysmon (Event ID `1`) o abilitando il log di sicurezza integrato Event ID `4688`.
`Sysmon 1` fornirà informazioni dettagliate come hash e metadati dell'eseguibile, quindi è l'ideale, ma nel caso in cui Sysmon non possa essere installato, è possibile utilizzare i log integrati `Security 4688`. Tuttavia, è importante che sia abilitata anche la registrazione della riga di comando, poiché molte regole di rilevamento si basano su questo. Purtroppo `Security 4688` non fornisce informazioni dettagliate come i log di creazione processi di Sysmon, quindi non tutte le regole di `Process Creation` funzionano con `Security 4688`.
2. Il secondo log eventi più importante è un log di sicurezza correttamente configurato.
3. Il terzo più importante sono probabilmente la registrazione dei moduli di PowerShell e la registrazione dei blocchi di script, poiché gli attaccanti abusano spesso di PowerShell.
4. Il quarto sono probabilmente tutti gli altri eventi Sysmon.
5. Dopo questi, ci sono molti altri log nella cartella "Registri applicazioni e servizi" che sono anch'essi molto importanti: AppLocker, Bits-Client, NTLM, PowerShell, PrintService, Security-Mitigations, Windows Defender, Windows Firewall con sicurezza avanzata, WMI-Activity, ecc...
## Principali fonti di log di Sigma
Con le impostazioni di controllo predefinite di Windows è possibile utilizzare solo circa il 10~20% delle regole sigma!
### Principali fonti di log di sigma
### Principali ID evento di sicurezza
# Aumentare la dimensione massima del file
## Opzione 1: manualmente tramite Visualizzatore eventi
Non è pratico da eseguire su larga scala, ma il modo più semplice per abilitare/disabilitare i log e controllare e/o configurare la loro dimensione massima del file è fare clic con il pulsante destro del mouse sul log nel Visualizzatore eventi e aprire `Proprietà`.
## Opzione 2: strumento integrato di Windows
È possibile utilizzare il comando integrato `wevtutil`.
Esempio: `wevtutil sl Security /ms:1073741824` per aumentare la dimensione massima del file per il log di sicurezza a 1 GB.
## Opzione 3: PowerShell
Esempio:```powershell
$sysmon = Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational
$sysmon.MaximumSizeInBytes = 2048000000 #2GB
$sysmon.SaveChanges()
```
## Opzione 4: Criteri di gruppo
È semplice aumentare la dimensione massima dei file per i log eventi classici come `Security`, `System` e `Application`, tuttavia, sfortunatamente, è necessario installare i modelli amministrativi e/o modificare direttamente il registro per cambiare la dimensione massima dei file per gli altri log. Potrebbe essere più semplice aumentare la dimensione dei file con uno script batch o PowerShell all'avvio.
# Script di configurazione
Uno script per aumentare la dimensione massima dei file e abilitare i log appropriati è fornito qui: [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/main/YamatoSecurityConfigureWinEventLogs.bat)
# Configurazione delle impostazioni dei log
## Log Sysmon (1382 regole sigma)
File: `Microsoft-Windows-Sysmon%4Operational.evtx`
Impostazioni predefinite: `Non installato`
Installare e configurare sysmon è la cosa migliore in assoluto che puoi fare per aumentare la visibilità sugli endpoint Windows, ma richiederà pianificazione, test e manutenzione.
Questo è un argomento ampio di per sé, quindi al momento esula dallo scopo di questo documento.
Consulta le seguenti risorse:
* [Guida della community Sysmon di TrustedSec](https://github.com/trustedsec/SysmonCommunityGuide)
* [Sysmon Modular](https://github.com/olafhartong/sysmon-modular)
* [Fork aggiornato di Florian Roth del file di configurazione sysmon di Swift On Security](https://github.com/Neo23x0/sysmon-config)
* [Fork aggiornato di Ion-storm del file di configurazione sysmon di Swift On Security](https://github.com/ion-storm/sysmon-config)
* [File di configurazione sysmon di Cyb3rWard0g](https://github.com/OTRF/Blacksmith/blob/master/resources/configs/sysmon/sysmon.xml)
## Log di sicurezza (1045 regole sigma (903 regole di creazione dei processi + 142 altre regole))
File: `Security.evtx`
Impostazioni predefinite: `Parzialmente abilitato`
Il log di sicurezza è il più complesso da configurare, quindi ho creato un documento separato per esso: [ConfiguringSecurityLogAuditPolicies.md](https://github.com/yamato-security/enablewindowslogsettings/blob/main/ConfiguringSecurityLogAuditPolicies.md)
## Log PowerShell (175 regole sigma)
File: `Microsoft-Windows-PowerShell%4Operational.evtx`
### Registrazione dei moduli (30 regole sigma)
L'attivazione della registrazione dei moduli abiliterà l'ID evento `4103`.
La registrazione dei moduli ha il vantaggio di poter funzionare su sistemi operativi e versioni di PowerShell meno recenti: PowerShell 3.0 (Win 7+).
Un altro vantaggio è che registra sia il comando PowerShell eseguito sia i risultati.
Lo svantaggio è che genererà un numero estremamente elevato di eventi.
Ad esempio, se un attaccante esegue Mimikatz, creerà 7 MB di log con oltre 2000 eventi!
#### Abilitazione della registrazione dei moduli
Impostazioni predefinite: `Nessun controllo`
##### Opzione 1: Abilitazione tramite Criteri di gruppo
Nell'Editor Criteri di gruppo (`gpedit.msc`), aprire `Configurazione computer > Modelli amministrativi > Componenti di Windows > Windows PowerShell` e abilitare `Attiva registrazione dei moduli`.
Nel riquadro `Opzioni`, fare clic sul pulsante `Mostra...` per configurare quali moduli registrare.
Immettere `*` nella casella di testo `Valore` per registrare tutti i moduli.
##### Opzione 2: Abilitazione tramite il registro```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames → * = *
```
### Registrazione dei blocchi di script (134 regole sigma)
Impostazioni predefinite: `On Win 10/2016+, if a PowerShell script is flagged as suspicious by AMSI, it will be logged with a level of Warning.`
Attivare la registrazione dei blocchi di script abiliterà l'ID evento `4104`. Se si abilita `Log script block invocation start / stop events`, verranno abilitati anche gli EID `4105` e `4106`, ma non è consigliato in quanto genererà solo rumore.
La registrazione dei blocchi di script è supportata per impostazione predefinita in PowerShell 5.0+ (Win 10+), ma è possibile abilitarla su sistemi operativi meno recenti (Win 7+) installando .NET 4.5 e WMF 4.0+.
Sfortunatamente, la dimensione massima di un singolo log eventi di Windows è di 32 KB, quindi qualsiasi script PowerShell di dimensioni superiori verrà frammentato in blocchi da 32 KB.
Se si dispone del file originale `PowerShell Operational.evtx`, è possibile utilizzare lo strumento [block-parser](https://github.com/matthewdunwoody/block-parser) per deframmentare questi log in un singolo file di testo facilmente leggibile.
Un aspetto positivo della registrazione dei blocchi di script è che, anche se uno script dannoso è offuscato con XOR, Base 64, ROT13, ecc..., la versione decodificata verrà registrata, rendendo l'analisi molto più semplice.
I log sono più facili da gestire rispetto alla registrazione dei moduli: se un attaccante esegue Mimikatz, verranno generati solo 5 MB e 100 eventi, contro i 7 MB e oltre 2000 eventi.
Tuttavia, l'output dei comandi non viene registrato con la registrazione dei blocchi di script.
#### Abilitazione della registrazione dei blocchi di script
#### Opzione 1: Abilitazione tramite Criteri di gruppo
Nell'editor di Criteri di gruppo, aprire `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell` e abilitare `Turn on PowerShell Script Block Logging`.
#### Opzione 2: Abilitazione tramite il registro di sistema
`HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1`
### Registrazione delle trascrizioni
Impostazioni predefinite: `No Auditing`
È possibile anche salvare i log di PowerShell in file di testo sul computer locale tramite i log di trascrizione.
Sebbene un attaccante possa di solito eliminare facilmente i log di trascrizione per contrastare l'analisi forense, possono esserci scenari in cui l'attaccante cancella tutti i log degli eventi ma non cerca i log di trascrizione da eliminare.
Pertanto, è consigliabile abilitare anche i log di trascrizione se possibile.
Per impostazione predefinita, vengono salvati nella cartella Documenti dell'utente.
Idealmente, i log di trascrizione dovrebbero essere salvati in una condivisione di rete in sola scrittura, tuttavia ciò potrebbe essere difficile da implementare nella pratica.
Un vantaggio dei log di trascrizione è che includono timestamp e metadati per ogni comando e sono molto efficienti in termini di spazio, occupando meno di 6 KB per l'esecuzione di Mimikatz.
Lo svantaggio è che i log di trascrizione registrano solo ciò che appare nel terminale di PowerShell.
#### Abilitazione della registrazione delle trascrizioni
##### Opzione 1: Abilitazione tramite Criteri di gruppo
Nell'editor di Criteri di gruppo, aprire `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell` e abilitare `Turn on PowerShell Transcription`.
Quindi, specificare la directory di output.
##### Opzione 2: Abilitazione tramite il registro di sistema```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)
```
### Riferimenti
* [Mandiant Blog: Greater Visibility Through PowerShell Logging](https://www.mandiant.com/resources/blog/greater-visibilityt)
## Log di sistema (55 regole Sigma)
File: `System.evtx`
Impostazioni predefinite: `Enabled. 20 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Il malware spesso installa servizi per la persistenza, l'escalation dei privilegi locali, ecc... che possono essere trovati in questo log.
È anche possibile rilevare qui varie vulnerabilità sfruttate.
> **Nota: Una cosa a cui prestare attenzione specifica per il log di Sistema è che i parametri nei campi a volte vengono tradotti nella lingua locale, quindi le firme che usano solo l'inglese potrebbero non rilevare su sistemi non in inglese. Ad esempio, su un sistema in inglese nei parametri per EID 7045, registrerà `Enabled` mentre in giapponese potrebbe registrare `有効`.**
> **Nota: Proprio come nel log `Application`, più provider registreranno lo stesso event ID, quindi potrebbe essere necessario filtrare anche sul nome del provider oltre che sul canale. Un esempio è l'event ID `1` che viene utilizzato da vari provider per eventi diversi.**
Event ID importanti:
| Event ID | Descrizione | Regole Sigma | Regole Hayabusa | Livello | Note |
| :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | Sospensione/Ibernazione di sistema | 0 | Non ancora. | Info | Provider: `Power-Troubleshooter` |
| 1 | Ora di sistema modificata | 0 | Non ancora. | Info | Provider: `Kernel-General` |
| 12 | Avvio del sistema operativo | 0 | Non ancora. | Info | |
| 13 | Arresto del sistema operativo | 0 | Non ancora. | Info | |
| 16 | Cronologia accessi hive del Registro cancellata | 2 | Non ancora. | High~Crit | I password dumper possono cancellare la cronologia di accesso dopo aver estratto gli hash delle password dalla chiave di registro SAM. Tuttavia, questo avviene anche normalmente, quindi è necessario filtrare i falsi positivi (FP). |
| 55 | Filesystem NTFS corrotto | 1 | No | High | Può rilevare attacchi contro le vulnerabilità NTFS. |
| 104 | Registro eventi di sistema cancellato | 1 | Sì | Med | |
| 6005 | Servizio log eventi avviato | 0 | Sì | Info | |
| 6006 | Servizio log eventi arrestato | 0 | Sì | Info | |
| 6008 | Arresto imprevisto | 0 | Sì | Info | |
| 6038 | NTLMv1 è stato utilizzato | 1 | No | Low | |
| 7031 | Servizio andato in crash | 0 | Sì | Low | |
| 7034 | Servizio andato in crash | 0 | Sì | Low | |
| 7036 | Servizio avviato/arrestato | 2 | Sì | Info~High | Può essere utilizzato per rilevare qualcuno che ferma Defender, ecc... |
| 7040 | Tipo di avvio del servizio modificato | 0 | Sì | Info | Può indicare che un attaccante ha disabilitato un servizio. |
| 7045 | Installazione del servizio | 37 | Sì | Info~Crit | Questo è l'event ID di sistema più importante poiché il malware spesso si installa come servizio o abusa dei servizi. |
| 20001 | Nuovo dispositivo PNP | 0 | Sì | Info~? | Il livello dipenderà dal fatto che i dispositivi USB siano consentiti o meno. Registra solo la prima volta che un dispositivo viene collegato. Gli eventi PNP non-USB sono molto rumorosi, quindi probabilmente dovrebbero essere filtrati. |
## Log applicazione (16 regole Sigma)
Questo log è per lo più rumore, ma potresti trovare alcune prove importanti qui.
Alcuni software antivirus di terze parti registrano qui.
Una cosa a cui prestare attenzione con il log applicazione è che diversi vendor utilizzano gli stessi event ID per eventi diversi, quindi dovresti filtrare non solo per Event ID ma anche per i nomi dei Provider.
File: `Application.evtx`
Impostazioni predefinite: `Enabled. 20 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Event ID importanti:
| Event ID | Provider | Descrizione | Regole Sigma | Regole Hayabusa | Livello | Note |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | `Audit-CVE`, `Microsoft-Windows-Audit-CVE` | Tentativo di exploit di vulnerabilità nota (CVE) | 1 | No | Critical | Rileva gli eventi generati dalle applicazioni in modalità utente quando chiamano l'API CveEventWrite quando si tenta di sfruttare una vulnerabilità nota. MS ha iniziato a usare questo log nel 2020/01 con CVE-2020-0601 (una vulnerabilità Windows CryptoAPI). Purtroppo, questo è più o meno l'unico caso di CVE scritti in questo log. |
| 325 | `ESENT` | Database ESE creato | 2 | No | Info~Crit | Rileva quando un processo crea un database ESE. Viene utilizzato da diverse cose come Exchange, AD, Servizi certificati, SRUM, ecc... Il database ESE più importante per la sicurezza è NTDS.dit, il file contenente gli hash delle password di tutti gli utenti di dominio situato sui controller di dominio. Esistono due regole sigma per rilevare il dump di NTDS.dit, tuttavia potrebbe essere un falso positivo se un amministratore usa ntdsutil per i backup o quando vengono create copie shadow. |
| 326 | `ESENT` | Database ESE associato | 1 | No | Info~Crit | Potrebbe essere in grado di rilevare l'accesso a NTDS.dit. |
| 1000, 1001 | `Application Error`, `Windows Error Reporting` | Errore dell'applicazione | 1 | No | Info~High | |
| 1034, 11724 | `MsiInstaller` | Applicazione disinstallata | 1 | No | Info~Low | |
| 1040 | `MsiInstaller` | Installazione dell'applicazione | 1 | No | Info~Med | |
| 33205 | `MSSQLSERVER` | Evento di controllo SQL | 6 | No | Info~High | Può rilevare backdoor MSSQL, SQL/command injection, ecc... |
## Log operativo di Windows Defender (10 regole Sigma)
File: `Microsoft-Windows-Windows Defender%4Operational.evtx`
Impostazioni predefinite: `Enabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Puoi rilevare non solo gli avvisi di Windows Defender (che è importante monitorare), ma anche l'aggiunta di esclusioni, la disabilitazione della protezione da manomissione (tamper protection), la cancellazione della cronologia, ecc...
## Log operativo Bits-Client (6 regole Sigma)
File: `Microsoft-Windows-Bits-Client%4Operational.evtx`
Impostazioni predefinite: `Enabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Bitsadmin.exe è un [lolbin](https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/) popolare che gli attaccanti abusano per scaricare ed eseguire malware.
Potresti trovare prove di questo in questo log, anche se ci saranno molti falsi positivi a cui prestare attenzione.
## Log del firewall (6 regole Sigma)
File: `Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx`
Impostazioni predefinite: `Enabled? 1 MB`
Impostazioni consigliate: `Enabled. 256 MB+`
Qui puoi trovare prove di regole del firewall aggiunte/modificate/eliminate.
Il malware spesso aggiunge regole del firewall per assicurarsi di poter comunicare con il proprio server C2, aggiunge regole proxy per il movimento laterale, ecc...
## Log operativo NTLM (3 regole Sigma)
File: `Microsoft-Windows-NTLM%4Operational.evtx`
Impostazioni predefinite: `Enabled but Auditing is disabled. 1 MB`
Questo log è consigliato da abilitare se vuoi disabilitare l'autenticazione NTLM.
Disabilitare NTLM molto probabilmente romperà alcune comunicazioni, quindi puoi monitorare questo log sui DC e su altri server per vedere chi sta ancora usando NTLM e disabilitare NTLM gradualmente partendo da quegli utenti prima di disabilitarlo globalmente.
È possibile rilevare l'uso di NTLM per le connessioni in entrata in eventi di accesso come il 4624, ma devi abilitare questo log se vuoi monitorare chi effettua connessioni NTLM in uscita.
Per abilitare il controllo, in Criteri di gruppo aprire `Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options` e configurare le varie impostazioni `Network security: Restrict NTLM:` appropriate.
Riferimento: [Farewell NTLM](https://www.scip.ch/en/?labs.20210909)
## Log Security-Mitigations KernelMode e UserMode (2 regole Sigma)
File: `Microsoft-Windows-Security-Mitigations%4KernelMode.evtx`, `Microsoft-Windows-Security-Mitigations%4UserMode.evtx`
Impostazioni predefinite: `Enabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Al momento ci sono solo 2 regole sigma per questi log, ma probabilmente dovresti raccogliere e monitorare tutti i log di Exploit Protection, Network Protection, Controlled Folder Access e Attack Surface Reduction (circa 40+ Event ID).
Purtroppo i log Attack Surface Reduction (precedentemente WDEG (Windows Defender Exploit Guard) ed EMET) sono distribuiti su più log e richiedono complesse query XML per essere cercati.
Dettagli: [Understand and use attack surface reduction capabilities](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction?view=o365-worldwide)
## Log PrintService (2 regole Sigma)
Si consiglia di abilitare anche il log operativo per rilevare gli attacchi a Print Spooler. (Es: PrintNightmare, ecc...)
### Admin (1 regola Sigma)
File: `Microsoft-Windows-PrintService%4Admin.evtx`
Impostazioni predefinite: `Enabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
### Operational (1 regola Sigma)
File: `Microsoft-Windows-PrintService%4Operational.evtx`
Impostazioni predefinite: `Disabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
## Log di sicurezza SMBClient (2 regole Sigma)
File: `Microsoft-Windows-SmbClient%4Security.evtx`
Impostazioni predefinite: `Enabled. 8 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Utilizzato per tentare di rilevare PrintNightmare (accesso guest SMB sospetto rifiutato da IP) e utenti che montano condivisioni nascoste.
## Log AppLocker (1 regola Sigma)
File: `Microsoft-Windows-AppLocker%4MSI and Script.evtx`, `Microsoft-Windows-AppLocker%4EXE and DLL.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx`
Impostazioni predefinite: `Enabled if AppLocker is enabled? 1 MB`
Impostazioni consigliate: `Enabled. 256 MB+`
È importante assicurarsi che sia abilitato e monitorato se stai usando AppLocker.
## Log operativo CodeIntegrity (1 regola Sigma)
File: `Microsoft-Windows-CodeIntegrity%4Operational.evtx`
Impostazioni predefinite: `Enabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Controlla questo log per rilevare eventi di caricamento dei driver bloccati dai controlli di integrità del codice di Windows, che potrebbero indicare un driver dannoso che non è riuscito a caricarsi.
## Log operativo Diagnosis-Scripted (1 regola Sigma)
File: `Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx`
Impostazioni predefinite: `Enabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Qui si possono trovare prove di pacchetti diagcab utilizzati per lo sfruttamento.
## Log operativo DriverFrameworks-UserMode (1 regola Sigma)
File: `Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx`
Impostazioni predefinite: `No Auditing. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Rileva i dispositivi USB collegati.
## Log operativo WMI-Activity (1 regola Sigma)
File: `Microsoft-Windows-WMI-Activity%4Operational.evtx`
Impostazioni predefinite: `Enabled on Win10/2016+. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Questo è importante da monitorare poiché gli attaccanti sfruttano spesso WMI per la persistenza e il movimento laterale.
## Log operativo TerminalServices-LocalSessionManager (1 regola Sigma)
File: `Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`
Impostazioni predefinite: `Enabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Rileva quando ngrok, uno strumento di reverse proxy, inoltra il traffico alla porta RDP locale per aggirare i firewall.
Link: [Bypassing Network Restrictions Through RDP Tunneling](https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling)
## Log operativo TaskScheduler (1 regola Sigma)
File: `Microsoft-Windows-TaskScheduler%4Operational.evtx`
Impostazioni predefinite: `Disabled. 1 MB`
Impostazioni consigliate: `Enabled. 128 MB+`
Gli attaccanti abusano spesso delle attività pianificate per la persistenza e il movimento laterale, quindi questo log dovrebbe essere abilitato.