Massimizzare le difese con la log collection DNS in Windows

Massimizzare le difese tramite DNS Logging
Lo scopo di questo post, terzo della serie, è di introdurre alla raccolta dei log sulla piattaforma Microsoft Windows. Inizieremo con un’illustrazione di una distribuzione di log solo origine Windows, seguita da una raccolta di campi scelti da esempi di log e una breve descrizione di queste origini. L’ultima parte riguarderà l’audit logging, poiché svolge un ruolo importante nel garantire la difesa dell’infrastruttura.

Prima di continuare, raccomandiamo la lettura del primo e del secondo post di questa serie.

Windows Log Deployment Scenario
Per iniziare le indagini trattate nella seconda parte di questo post, gli analisti e i soccorritori devono essere armati con i relativi log DNS e di dominio, dando loro così visibilità sugli eventi rilevanti che si verificano sulla rete. L’organizzazione potrebbe già implementare una forma di registrazione centralizzata su una scala simile a quella mostrata di seguito. In caso contrario, c’è sempre spazio per miglioramenti!

 

Dalla sorgente al SIEM

Sul lato sinistro sono indicati possibili fonti di log, è stata definita una piccola parte di una distribuzione di log di esempio, anche se il numero effettivo di endpoint di origine log univoci è molto più di quanto illustrato qui. Quindi, mentre ci spostiamo a destra del diagramma, vediamo come i log possono essere inoltrati a un server di gestione dei log o a un data lake, quindi a un SIEM per ulteriori azioni.

 

Da questi Event Source…

Il lato del diagramma “Source” a sinistra, illustra alcune potenziali sorgenti di eventi. Un computer client viene mostrato per rappresentare che ci sono eventi che si verificano client-side che devono essere raccolti ed è stata aggiunta l’etichetta per mostrare alcuni esempi dei tipi di eventi da raccogliere, come gli eventi generati da Windows Sysinternals System Monitor (Sysmon), eventuali subscription a EventID di alto valore e canali. Esistono anche altre log source che non utilizzano la telemetria del Windows Event Log, come il loggin file-based e altre log source che sono raggruppate nell’area “other predefined collection processes” come (rappresentati nelle icone) Windows firewall, Powershell logging, ingress logging.

Ci sono tre server che sono stati definiti in questo esempio:

• Un server di posta in sede, il server Exchange: È impostato per raccogliere gli Exchange Message Tracking Logs che, nei metadati, contengono informazioni su IP e nome host.
• Il server DNS di Windows: La raccolta dei log è impostata sul canale DNSServer Windows EventLog Analytic, così come l’audit logging. La raccolta può anche essere abilitata e configurata manualmente per raccogliere gli eventi del registro DNS debug.
• Il server Active Directory: Questo server è un obiettivo di alto valore per molti motivi. La raccolta dei log è configurata per raccogliere i log GPO o Group Policy Object, nonché gli Audit log.

Esistono molte altre origini di log che forniscono informazioni preziose per le indagini e le integrazioni di DomainTools, come i log provenienti da eventi del firewall, Windows IIS server log, i tentativi di autenticazione in ingresso e altro ancora. È anche possibile distribuire una baseline di raccolta e un’opzione per abilitare la raccolta baseline sospetta che comporterebbe una raccolta più dettagliata di una macchina di destinazione sospetta.

 

…al SIEM per integrazioni, automazione e analisi

Le Windows subscriptions possono essere distribuite per estrarre solo eventi di Windows EventLog (tramite WEF, Windows Event Forwarding). Da queste origini client/server, tali eventi vengono inoltrati a un Windows Event Collector.

Un altro collector, fornito dal SIEM o da una terza parte, verrà inoltre distribuito per raccogliere più eventi, espandere la visibilità e garantire che altri tipi di log non vengano lasciati indietro, come i log file-based.

Questi eventi possono essere eventualmente inoltrati a un data lake o a un server di gestione dei log. Tutti i log non arrivano a un SIEM per motivi quali i costi di archiviazione, infrastruttura e licenza, e anche perchè non tutti gli eventi potrebbero avere un caso d’uso supportato da SIEM.

Il processo di normalizzazione dei log è importante, poiché le voci non sono scritte in un formato standard. Oltre a normalizzare i log, vengono applicati l’analisi e l’arricchimento di questi eventi. Questi processi vengono eseguiti durante il transito dal collector e/o sul disco della sorgente stessa o sul server di gestione dei log.

Una volta che i log raggiungono il SIEM, vengono utilizzati per integrazioni aggiuntive, per fornire qualsiasi altra azione da eseguire (triaging), arricchire l’analisi, attivare avvisi e così via.

Windows Event Log
Finora abbiamo coperto un esempio di distribuzione dei log. Di seguito sono riportati i campi di esempio dei log di Windows DNS selezionati per dare un’idea dei tipi di informazioni fornite. Da notare che questi sono già arricchiti/scritti in un altro formato e sono solo frammenti e non il log completo.

Windows DNS Client Sources
Gli event source specifici di Windows DNS Client per gli eventi DNS includono:

• Windows Event Log channels (DNS Client Events – Operational)
• Sysmon Event ID 22 DNSQuery
• Event Tracing for Windows (Microsoft-Windows-DNS-Client ETW Provider)

 

Esempio di DNSQuery con Sysmon Event ID

“Hostname”: “sld.tld.”
“Severity”: “INFO”
“EventID”: 22
“Source”: “Microsoft-Windows-Sysmon”
“ProviderGuid”: “{5770385F-C22A-43E0-BF4C-06F5698FFBD9}”
“Channel”: “Microsoft-Windows-Sysmon/Operational”
“Domain”: “NTAUTHORITY”
“AccountName”: “SYSTEM”
“UserID”: “S-1-5-18”
“AccountType”: “User”

Nell’esempio sopra, possiamo vedere che questo evento proviene da un’istanza chiamata “sld.tld”. Poiché conosciamo l’origine di questo evento, è quindi utile per trovare la fonte nel caso in cui venga eseguita un’indagine per IR. Anche i campi per Domain, Account Name e security identifier (SID) (o UserID S-1-5-18) possono essere utili.

“Message”:
Dns query:
RuleName:
UtcTime: 2020-10-29 11:32:43.274
ProcessGuid: {b3c285a4-5f1e-5db8-0000-0010c24d1d00}
ProcessId: 5696
QueryName: example.com
QueryStatus: 0
QueryResults: ::ffff:93.184.216.34;
Image: C:\\Windows\\System32\\PING.EXE

Incluso negli eventi di Windows c’è il campo Message. Dal campo Message (che era stato analizzato qui), possiamo vedere che l’evento Sysmon Event ID 22 DNSQuery è stato emesso a causa del comando ping utilizzato con example.com.

Che cos’è un’applicazione di esempio del Sysmon Event ID 22 loggin?
Supponiamo che example.com sia un link di grande interesse. Una delle funzionalità dell’app è arricchire i risultati con un Risk Score, e in questo caso, example.com ha ottenuto un Risk Score elevato di 90. Con i log raccolti, è possibile risalire a data, ora, nome host, account, il programma di utilità e così via. Ulteriori azioni di risposta agli incidenti, come la ricerca della fonte di origine, possono aiutare con le misure di isolamento/contenimento di un’istanza, oltre a fornire un caso d’uso per iniziare una registrazione più ampia come macchina mirata. Supponendo che vengano raccolti 600 milioni di eventi al giorno, isolare tali incidenti in un intervallo di tempo specifico può anche aiutare a ridurre MTTD/MTTR per ottenere e trovare altri EventID IOC.

Ulteriore lettura:
Sono disponibili ricerche interessanti su Evading Sysmon DNS Monitoring e Using Sysmon and ETW For So much more on Binary Defense, che contiene una sezione sullo sfruttamento degli eventi DNS e Sysmon.

Windows DNS Server Source

Le origini degli eventi del server DNS sono:

• Event Tracing for Windows (Microsoft-Windows-DNS-Server-Service, Microsoft-Windows-DNSServer ETW Providers)
• DNS Debug log file
• Windows Event Log channels

ETW/Windows DNS Service Provider Source
Quello che segue è uno snippet dal canale Microsoft-Windows-DNSServer/Analytical channel for Event ID 260. È solo una parte di un esempio di traccia degli eventi in key-value pairs.

“Source”: “Microsoft-Windows-DNSServer”
“ProviderGuid”: “{EB79061A-A566-4698-9119-3ED2807060E7}”
“EventId”: 260
“Severity”: “INFO”
“Domain”: “NT AUTHORITY”
“AccountName”: “SYSTEM”
“UserID”: “S-1-5-18”
“AccountType”: “User”
“TCP”:”0″
“Destination”: “destination.IP”
“InterfaceIP”: “interface.IP”
“RD”: “0”
“QNAME”: “subdomain.sld.tld”
“QTYPE”: “28”
“XID”: “17271”
“Port”: “0”
“Flags”: “0”
“RecursionScope”: “.”
“CacheScope”: “Default”
“PolicyName”: “NULL”
“BufferSize”: “76”
“PacketData”: “0x437700000001000000000001096C6F63616C686F73740975732D656173742D320D6563322D7574696C697469657309616D617A6F6E61777303636F6D00001C00010000290FA0000080000000”

• QTYPE significa che era un record A, un indirizzo IP.
• QNAME: proviene dalla nostra istanza.
• AAAA: 28 indica un record di indirizzo IPv6 a 128 bit. Più comunemente utilizzato per mappare i nomi host a un indirizzo IP dell’host.

Se si effettua un confronto tra l’EventID 260 e il WireShark DNS request packet per lo stesso evento, si noterà che gli stessi campi vengono acquisiti nel payload DNS rispetto al testo completo dell’evento (es. PacketData, QNAME, DestinationIP, etc.).

Esistono anche altre fonti per ETW per registrare altri eventi rilevanti. Da F-Secure Consulting nei loro laboratori si nota un altro provider ETW, Microsoft-Windows-WebIO, che fornisce agli analisti la visibilità delle richieste Web effettuate da alcuni processi di sistema.

Informazioni sul ETW/Windows DNS Service Provider
In breve, ETW ha quattro componenti principali che sono:

• Provider: un fornitore di informazioni per la traccia degli eventi per le sessioni di Windows.
• Sessione: una raccolta di buffer in memoria che accettano eventi tramite l’API del provider ETW di Windows.
• Controller: avvia e arresta le sessioni ETW.
• Consumatore: riceve gli eventi dalla sessione ETW da un file di registro.

ETW contiene una preziosa fonte di telemetria di Windows. Non rientra nell’ambito di questo post, ma è possibile saperne di più su Windows DNS ETW nel portale della documentazione.

Windows DNS Server Debug
Di seguito è riportato un esempio di frammento di prova dal Windows DNS Debug Log File. Questo tipo di logging dovrebbe essere eseguito solo in un lasso di tempo temporaneo, a causa della sua natura dettagliata che influisce sulle prestazioni del server, tra gli altri potenziali problemi. I log devono essere analizzati per estrarre i metadati rilevanti (come l’indirizzo IP o il protocollo) come parte della raccolta dei log. Questo esempio è stato aggiunto per mostrare come i registri grezzi da soli non siano sicuramente pronti per l’uso e richiedono un ulteriore arricchimento per essere utilizzabili.

10/30/2020 8:16:54 PM 0FC0 PACKET 000001E1A286DE90 UDP Rcv 172.31.21.66 16df Q [0001 D NOERROR] NS (0)
10/30/2020 8:16:54 PM 0FC0 PACKET 000001E1A34544B0 UDP Rcv 199.7.83.42 de78 R Q [0084 A NOERROR] NS (0)

DNS Server Shutdown Event Snippet in XML
Di seguito è riportato un frammento del Windows DNS Shutdown Event in XML View dal Windows Event Viewer. Sebbene si tratti di dati strutturati, è possibile vedere come si discosta da un formato di dati che può essere utilizzato in un altro sistema, come un SIEM. È necessario un connettore event source come un connettore diretto, un modulo di input o un log agent per normalizzare l’XML.

<Provider Name=”Microsoft-Windows-DNS-Server-Service” Guid=”{71a551f5-c893-4849-886b-b5ec8502641e}” />
<TimeCreated SystemTime=”2020-09-23T21:33:21.512036500Z” />
<Channel>DNS Server</Channel>
<Computer>ec2-xx-xxx-xxx-xx.us-east-2.compute.amazonaws.com</Computer>
<Security UserID=”S-1-5-18″ />
</System>
<EventData Name=”DNS_EVENT_SHUTDOWN” />
</Event>

Window Auditing Logs
La discussione sulla raccolta di log che coinvolge DNS non è completa finché non includiamo anche la registrazione di controllo sull’infrastruttura DNS. La registrazione dell’audit non solo aiuta a soddisfare gli obiettivi di verifica e conformità, ma fornisce anche i dati degli eventi ai difensori per aiutare i soccorritori a ottenere maggiori informazioni su un attacco all’infrastruttura DNS. La registrazione del server, serve anche per qualsiasi altro problema operativo e di risoluzione dei problemi che coinvolge l’infrastruttura.

Queste fonti di eventi includono:

• Windows Enhanced DNS server auditing events (Windows-DNSServer/Audit channel – Windows DNS Logging and Diagnostics – Audits events)
• Windows DNS server analytic events (vedi la pagina Windows DNS Logging and Diagnostics – Analytic events)
• Microsoft Active Directory (vedi AD Events to Monitor resource and Microsoft Audit Policy recommendations)
• Microsoft DNS Windows Group Policy logging (vedi DNS Windows Group Policy settings associated with the DNS Client service)

 

Opzioni di Windows DNS Event Logging migliorate
L’origine di questi eventi include il canale Microsoft-Windows-DNSServer/Audit EventLog e l’Event Tracing Windows provider. I tipi di eventi trattati nella registrazione di controllo sul server DNS includono:

• Cache operations—Purging a cache.
• DNSSEC operations—Key rollover events, export/import DNSSEC, trust point related events.
• Policy operations—Events for the client subnet record, zone level policy, forwarding policy, client subnet record were created, deleted, or updated.
• Server operations—Restarting server, clearing of debug logs, clearing of statistics, changes to listen events.
• Resource record updates—Resource Record (RR) creation events such as deletion or that a record was modified.
• Zone operations—The zone was deleted or updated, a zone scope was deleted or updated.

 

Domande finali
Nota: un elemento che si potrebeb notare dal diagramma “Source to SIEM” è che sono stati inclusi sorgenti di log che non sono trattate in questo post, ad esempio i log di Exchange così come i log di altri processi di raccolta. Ne parleremo un po’ più in dettaglio nel post finale di questa serie.

Con questo post, ci siamo introdotti in una distribuzione di Windows log collection di esempio, i tipi di eventi che possono essere raccolti su Windows DNS Server e clint e sui tipi di log. Si consiglia tornare all’inizio e verificare se la propria distribuzione ha coperto quanto segue:

1. Quali informazioni di monitoraggio su DNS e attività del dominio possono essere ottenute dalle fonti esistenti?
2. Quali aree devono essere ampliate per migliorare la visibilità dei log, in particolare per i metadati contenenti log di dominio e DNS?
3. Quali altre opportunità ci sono per aumentare l’ambito complessivo della raccolta dei registri?
4. Quale di queste fonti porta a una migliore intelligence per i propri casi d’uso?
5. L’attuale log deployment, soddisfa le esigenze della fase finale in termini di informazioni per la ricerca delle minacce, risposta all’incidenza, orchestrazione, automazione, ecc.

Sebbene non sia possibile approfondire i dettagli della distribuzione effettiva (come esempi di configurazione o istruzioni su come abilitare la registrazione di controllo), è possibile controllare la documentazione Microsoft, nonché il proprio agente di registro e la documentazione SIEM per vedere quali configurazioni devono essere applicati e quali opzioni sono disponibili.

Utilizzate le integrazioni e le API di DomainTools per arricchire ulteriormente gli eventi rilevanti con DNS e domain intelligence (Domain Risk Score), oltre a utilizzare gli IOC di dominio con la piattaforma Iris. Usare DomainTools come parte della propria difesa proattiva e reattiva, oltre alla registrazione mirata.