Altre source utili per DNS e Domain logging

Questo post finale tratta altre source utili per DNS e Domain logging che non sono stati trattati nei post precedenti. Questo post termina quindi con una nota di sfide da anticipare e idee per i passaggi successivi oltre la registrazione.

Per una maggior comprensione dei contenuti, è consigliato aver letto i precedenti post di questa serie:

  1. Log Collection tramite Domain Tools: I vantaggi in una visione “Bird’s Eye”
  2. Come la Log Collection mirata rafforza le difese
  3. Massimizzare le difese con la log collection DNS in Windows
  4. Aumentare la visibilità dei server DNS Linux con la Log Collection

 

Altre source di log rilevanti
Sono disponibili aggiuntive source di event log, che contengono metadati preziosi. Tool IDS/IPS, log del firewall, mail log, utilizzano tutti metadati per estrarre indirizzi IP, hostname e altri metadati per informare ulteriormente il lavoro di IR e di threat hunting. Gli indirizzi IP possono essere utilizzati per risalire e indagare sull’infrastruttura, oppure utilizzare i dati per condurre una reverse IP dell’hostname per orientarsi verso i domini associati e trovare il Threat Profile e il Risk Score. La prima metà di questa sezione copre brevemente altre fonti e fornisce esempi approfonditi nella metà finale.

Managed DNS Provider
Amazon Route 53 DNS Query Logging e CloudWatch
Configurare Amazon Route 53 per raccogliere i log delle informazioni sulle query DNS pubbliche ricevute da Route 53 (consultare la Guida per gli sviluppatori). I metadati disponibili sono simili ad altre fonti di registrazione delle query DNS: dominio o sottodominio richiesto, data e timestamp, tipo di record DNS, codice di risposta DNS e edge location di Route 53 che ha risposto alla query DNS. Se si utilizza Amazon CloudWatch Logs per monitorare, archiviare e accedere ai file di log delle query DNS, è possibile anche trasmettere questi log alla propria istanza LM e SIEM.

Google Cloud DNS
Google Cloud DNS Logging, tiene traccia delle query che i server dei nomi risolvono per le reti VPC (Virtual Private Cloud). Sono disponibili altri Managed DNS Provider, controllare la loro documentazione per vedere come impostare query e response logging.

Proxy Server Log
I Proxy Server Log sono una fonte comune di informazioni per i metadati del dominio. Questi log contengono le richieste effettuate all’interno della rete sia dagli utenti che dalle applicazioni.

DNS Packet Log
Oltre ad acquisire e ascoltare i pacchetti su strumenti di analisi di rete, è anche possibile impostare il logging dei pacchetti e configurarlo per raccogliere solo i log dei pacchetti di determinati protocolli come i pacchetti DNS. Tuttavia, l’acquisizione e la registrazione dei pacchetti fornisce solo i metadati relativi al DNS. Non è possibile, ad esempio, ottenere maggiori dettagli sull’host da cui questo evento ha avuto origine o quale utente specifico o azione dell’utente ha attivato quell’evento.

Log generati da tool IDS/IPS
I log generati da tool IDS/IPS, come regole e avvisi, possono essere raccolti e inoltrati al proprio LM/SIEM. Alcuni esempi sono:

  • Zeek (formerly Bro) DNS Query and Response logging per raccogliere e ottenere query e risposte DNS. Utilizzato anche in combinazione con Domain Hotlist.
  • Snort DNS – Regole che ispezionano le risposte alle query DNS e agiscono in base alla risposta.
  • Suricata DNS – Regoel per registrare e raccogliere eventi correlati, creare azioni basate su eventi come abbinare query DNS a una blocklist (ad esempio, Domain Hotlist) o scrivere eventi di log per raccogliere query DNS e registrazione delle risposte.

Mail Exchange Server Events
Esistono alcuni casi d’uso per sfruttare i log generati dal proprio server di posta:

  • Rileva l’infrastruttura di posta elettronica di phishing/spam nota.
    • Inviato da infrastruttura di phishing nota o malevola.
    • Esempio: “Chiamami al numero 1-888-382-1222 per configurare la tua VPN – Matthew (dal supporto tecnico).”
  • Rileva collegamenti di phishing/spam noti nel corpo dell’e-mail.
    • Contiene collegamenti di phishing, ma è stata eseguita un’azione dell’utente in base agli event log successivi (ad esempio, l’utente fa clic sul collegamento, il dominio su cui viene eseguita la query viene visualizzato nei log).
    • Esempio: “Fare clic qui per scaricare il certificato VPN – Matthew (dal supporto tecnico).”
  • Analizza ulteriormente le indicazioni di phishing ancora sconosciute.

 

Event Source per i Log di Exchange:

  • MSExchange Management channel on EventLog (called “MSExchange Management”)
  • Message Tracking Logs, dove la posizione predefinita è %ExchangeInstallPath%TransportRoles\Logs\MessageTracking

L’MSExchange Message tracking log contiene campi popolati con metadati per la ricerca delle minacce e le indagini DomainTools. Loro includono:

  • client-ip: l’IP del server/client di messaggistica che ha inviato il messaggio.
  • client-hostname: l’hostname/FQDN del server/client di messaggistica che ha inviato il messaggio.
  • server-ip: l’IP del server di origine o di destinazione.
  • server-hostname: l’hostname/FQDN del server di destinazione.
  • Un source value field include DNS come origine nota.

L’IP del client e il nome host del client rispondono alle domande “quale infrastruttura ha inviato questo messaggio”, che l’analista utilizza per cercare ulteriori informazioni sull’infrastruttura.

L’IP del server e l’hostname del server è l’indirizzo di destinazione. Questo risponde alla domanda “a chi era rivolto questo messaggio”.

Proactive Defense Note: Utilizzare DomainTools API o la piattaforma di indagine Iris per esaminare ulteriormente le acquisizioni di metadati in questi campi. Un esempio di lavoro con Iris:

  • Gli hostname vengono estratti dal campo client-hostname dai log di MSExchange.
  • I domini vengono estratti con il successivo elenco di domini quindi importati in Iris.
  • Il Domain Risk Score associato a ciascun dominio indica il livello di rischio per quel dominio.
  • Ulteriori decisioni:
    • Correlazione tra il client.hostname e l’IP del server.
    • Isolare l’IP del server di destinazione o persino impostare più logging per trovare altri IOC (EventID e altri eventi che potrebbero essere generati per indicare ulteriori compromessi o movimenti laterali).
  • Aggiunta ad una blocklist, oltre a utilizzare Domain Hotlist

 

Windows Firewall Logging
Altre fonti di log che contengono dati IP preziosi includono i log del firewall dal Windows Firewall EventLog Channel.

Proactive Defense Note: utilizzare la Domain Hotlist come blocklist sul firewall della rete.

Finding Advanced Attacks and Malware With Only 6 Windows  EventID’s” di Michael Gough (aka Malware Archaeologist) fornisce ulteriori informazioni sul ciclo di vita di questi EventID che segnalano un attacco. L’Event ID 5156 viene generato quando la Windows Filtering Platform consente a un programma di connettersi a un altro processo (sullo stesso computer o su un computer remoto) su una porta TCP o UDP. I preziosi metadati di questo Event Source indicano il comando e il controllo o l’origine dell’attacco e quale applicazione è stata utilizzata per comunicare con l’indirizzo IP esterno o interno.

Proactive Defense Note: Utilizzare DomainTools Iris Investigate API, Classic Tools API o la piattaforma di indagine Iris per indagare ulteriormente su questo IP. I risultati includono: ricerca di informazioni sull’infrastruttura IP, rivelazione dell’infrastruttura connessa, ricerca di connessioni di questo indirizzo IP, reverse lookup dell’indirizzo IP.

 

Windows IIS Server Logging

<13>Sep 9 17:38:25 IIS-SERVER 2020-09-09 17:38:25 MALICIOUS_CLIENT_IP_HERE GET /welcome.png - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:69.0)+Gecko/20100101+Firefox/69.0 http://localhost/ 200 0 0 11

L’esempio precedente presenta un evento di registro in formato Syslog generato da un server IIS ospitato localmente (test).

Ad esempio, se esiste un numero insolito di richieste da un IP client (indicato da MALICIOUS_CLIENT_IP_HERE), un analista potrebbe voler verificare se l’IP associato è dannoso.

Proactive Defense Note: eseguire un reverse DNS check (ovvero eseguire un controllo per trovare il nome host associato a un IP client). Dal reverse DNS check (per trovare il nome host), controllare l’infrastruttura o il punteggio di rischio o il profilo di minaccia associati su Iris o con l’API.

 

Sfida
Aumento dei requisiti e dei costi di archiviazione SIEM e LM
Relative ai problemi di infrastruttura sono le sfide di archiviazione e licenza poiché potrebbe essere necessario aumentare la capacità a causa dei requisiti di logging aggiuntivi. Tuttavia, esistono soluzioni per risolverli. Includono il logging mirato (raccolta selettiva solo di determinati EventID o logging channels), la deduplicazione dei log, l’eliminazione dei campi metadati non necessari di un evento di log, batch compression logging e altro ancora.

Altri costi correlati che possono anche aumentare includono:

  1. Costo dell’abbonamento. Questi sono casi in cui l’agente di log o LM/SIEM incorporano costi di abbonamento incentrati sull’inserimento dei dati. Potrebbero esserci utenti o clienti che utilizzano Community Edition o agenti gratuiti con limitazioni di importazione di eventi.
  2. Costo del personale. Gli amministratori o altro personale specializzato potrebbero dover eseguire la distribuzione su istanze o scenari di distribuzione che richiedono la registrazione basata su agenti. Alcuni endpoint richiedono anche lavoro aggiuntivo, ad esempio un endpoint che richiede la configurazione di impostazioni aggiuntive per distribuire la registrazione.

 

Problemi di infrastruttura relativi alla registrazione
È problematico registrare query e/o richieste a causa di problemi quali il degrado delle prestazioni del server (con il lavoro di elaborazione aggiuntivo richiesto), problemi di archiviazione e altro. In termini di problemi relativi all’elaborazione, ogni volta che si verifica una query o un evento di risposta, il server DNS non solo interpreterà l’evento di telemetria come un’origine del log da raccogliere, ma dovrà anche scrivere gli eventi in un file formato specificato) e quindi inviare a una destinazione esterna. Sono inoltre necessarie analisi aggiuntive o altri arricchimenti che possono fornire maggiori imposizioni relative alle prestazioni sulla risorsa.

 

I registri devono essere strutturati e normalizzati
I log degli eventi devono essere importati dalla suite SIEM, che ha i propri campi e schemi SIEM. Potrebbero essere necessari moduli e componenti aggiuntivi specialistici aggiuntivi (oltre a quanto offerto dall’agente di raccolta dei registri) per importare e arricchire adeguatamente i registri. Ad esempio, il campo Messaggio nel registro eventi di Windows potrebbe contenere informazioni preziose sull’evento stesso, che deve essere estratto. I log DNS di Linux possono essere scritti in diversi formati, che devono anche essere normalizzati per l’importazione in un SIEM. Questo processo di normalizzazione può aggiungere un ulteriore carico sulle prestazioni.

 

Il prossimo passo…
…è costruire le configurazioni per raccogliere, analizzare e arricchire gli eventi da queste fonti.

Sebbene sia fuori dallo scopo di questo post coprire il labirinto di impostazioni e configurazioni degli event source per la miriade di piattaforme disponibili, vale la pena ribadire alcuni modi per sfruttarle.

 

Craft Sigma e altre regole di rilevamento
Sono disponibili regole Sigma che sono già state predisposte per scenari come il rilevamento di server C2 o il rilevamento di un numero elevato di query su un singolo dominio. Le regole Sigma guidano la coerenza nei rilevamenti delle minacce, dopo che una regola Sigma è stata creata, viene quindi condivisa (o convertita) in modo che qualsiasi endpoint che deve utilizzare la regola, come una particolare piattaforma SIEM, possa farlo.

Sono disponibili anche altre risorse per le regole di rilevamento. Esistono altre regole di rilevamento create e condivise online, quindi di seguito è riportato un piccolo elenco:

 

Sviluppare con i prodotti API DomainTools
Una copertura efficace degli event source significherà che gli investigatori saranno in grado di trarre il massimo vantaggio da ciò che le integrazioni di DomainTools hanno da offrire. Ad esempio, non limitandosi a fare affidamento sui log proxy quando è possibile anche estrarre un dominio prezioso e altri metadati in altre origini di eventi. Inoltre, i prodotti DomainTools API possono essere utilizzati per sviluppare le proprie integrazioni. Inizia con la documentazione API qui, comprese le query di esempio gratuite.

Usare le integrazioni DomainTools con il proprio SIEM
Oltre alle API, è possibile utilizzare le integrazioni DomainTools per trovare informazioni sulle minacce nei metadati del tuo dominio.

Foto di Green Pass digitali e stampati fornite dai venditori ai loro acquirenti.

PUBBLICATO DA:<br>Domenico Panetta
PUBBLICATO DA:
Domenico Panetta
Presales Technical Engineer

ARTICOLI CORRELATI

Netwrix acquisisce PolicyPak, sicurezza ai desktop

Netwrix acquisisce PolicyPak, sicurezza ai desktop

I Clienti PolicyPak avranno accesso al portafoglio Netwrix di soluzioni di sicurezza e conformità, per identificare e mitigare i rischi per la sicurezza dei dati Netwrix acquisisce PolicyPak, produttore di software che aiuta le organizzazioni di tutte le dimensioni a...