Come la Log Collection rafforza le difese con DomainTools

In questo secondo post della serie “Log Collection”, ci concentreremo sulla relazione e il ruolo della log collection dei metadati con sicurezza difensiva (squadra blu/viola) tramite DomainTools, aiutando a considerare il lavoro di ricerca condotto in precedenza.

Nel primo post della serie, abbiamo menzionato diverse guide alla log collection, inclusa l’NSA, queste configurazioni e pubblicazioni nascono solitamente dalla ricerca sulla difesa, completando il ciclo di vita dalla ricerca offensiva, alla difesa, per poi tornare agli implementatori dei sistemi SIEM e di telemetria; l’NSA ha pubblicato il rapporto Spotting the Adversary, ad esempio, e JPCERT (Coordination Center) in Giappone ha analizzato quali log di eventi erano dovuti a strumenti malware noti, come Windows EventID 5156, che indica un nuovo evento di connessione di rete, e abbiamo anche coperto un esempio di log deployment, ma analizzando solo i numeri, per darci un’idea della scala della raccolta di telemetria in un ambiente aziendale.

Log Source e MITRE ATT&CK
La mancanza di un approccio mirato ai log di sicurezza, può portare a problemi di prestazioni da parte degli agenti di log, eccessivi costi di licenza SIEM e agent e costi di sottoscrizione, eccessivi requisiti di infrastruttura, rumore di fondo e alert, insufficiente log colelction e altro. OWASP ha anche consigliato di non raccogliere troppi log (così come troppo pochi) come best practice per l’implementazione del log di sicurezza. Oltre a seguire la guida e le risorse del post inaugurale di questa serie, un’altra squadra blu e pratica difensiva è quella di mappare le fonti di log con framework come MITRE ATT&CK per garantire che i dati di log elevino la caccia alle minacce, e le operazioni di sicurezza possano configurare migliori avvisi e regole di triage.

Come la Log Collection mirata rafforza le difese

Cos’è il Framework MITRE ATT&CK
MITRE ATT&CK® è una base di conoscenza accessibile a livello globale di tattiche e tecniche avversarie basate su osservazioni del mondo reale. Sopra c’è uno screenshot della matrice MITRE ATT&CK Navigator v4.0 for Enterprise, disponibile anche su Github.

Specifiche tattiche MITRE ATT&CK
Le seguenti sono fonti di log che si riferiscono a una tattica MITRE ATT&CK. Questi log sono specifici per i casi d’uso che DomainTools copre per Iris, PhishEye e API come:

  • Trovare IOC di dominio tramite Risk Score, Threat Profile o investigation sulla piattaforma web Iris.
  • Trovare metadati preziosi, come indirizzi e-mail o termini chiave per le indagini sulla piattaforma web Iris.
  • Utilizzo delle API, come la Reverse IP API, per trovare i domini associati a un indirizzo IP.

Quali fonti devono aggiungere i difensori nell’ambito della log collection?
Tattica: Command&Control (C2)

Tattica: Exfiltration (Exfiltration over C2, Over Alternative Protocol)

  • Le richieste DNS mostrano tentativi di risolvere domini dannosi noti o tentativi di contattare domini con una cattiva reputazione.
  • I log del perimetro di rete mostrano l’esfiltrazione verso un indirizzo IP esterno.

Fonti di log correlate: Linux DNS query logs, Windows Sysmon DNSQuery logs, DNS protocol packet capture logs, Windows Firewall logs, etc.

Tattica: Defense Evasion

Tecnica “Impairment of Defence”

  • Server DNS utilizzato in modo dannoso (generazione di nomi di dominio falsi, squatting, attacchi alle infrastrutture).
  • Il server è stato modificato, ad esempio la modifica delle autorizzazioni al flusso di output di Syslog o al file di output per non consentire il logging o la modifica della configurazione del server DNS stesso per disabilitare il logging.
  • Manomissione del sistema per disabilitare il logging di PowerShell (nel senso di disabilitare il meccanismo di traccia degli eventi Powershell in Windows).

Fonti di log correlate: Group Policy Modification (Windows GPO) logs, Windows PowerShell logs to find suspicious PowerShell commands (disable of PowerShell event trace), Linux auditing logs (configuration file changes).

Tattica: Persistence Mechanism

  • Configurazione della persistenza su un server DNS per attività backdoor malware in un secondo momento, come la connessione successiva a un server C&C.

Fonti di log correlate: Le sorgenti di log sono simili a Exfiltration e alle tattiche C2.

Credential Access (T1171)

  • Successo e insuccesso delle autenticazioni in ingresso, inclusi i tentativi di accesso di una minaccia interna nota nell’azienda.

Log correlati: autenticazioni in ingresso e tentativi di accesso al perimetro della rete.

Caccia post-sfruttamento con i log: Mimikatz, uno strumento per il furto di credenziali
I seguenti sono tipi di esempi di sorgenti di log* per rilevare un attacco Mimikatz, ma sono più correlati ai log che mostrano i metadati relativi a DNS, IP e dominio:

  • Windows Sysmon Logs
    • Sysmon è uno strumento di utilità che offre una capacità di log collection robusta ed estesa. Ad esempio, è possibile configurare Sysmon per aiutare il logging del trail degli strumenti di utilità che gli aggressori utilizzano con il Sysmon process logging.
    • È inoltre possibile utilizzare Sysmon per raccogliere eventi DNSQuery, eventi FileDelete, eventi correlati a WMI (Strumentazione gestione Windows) e altro ancora.
  • Windows PowerShell Event Log a Logging via
    • PowerShell è uno strumento di utilità comune utilizzato per automatizzare le attività in un ambiente Windows. La stessa origine eventi di PowerShell può essere presa di mira, ad esempio gli aggressori che disabilitano la traccia Windows PowerShell ETW Event Provider.
    • È possibile non solo il logging degli eventi di Windows di PowerShell (tramite Windows Event Log o Event Tracing per Windows), ma anche il logging di PowerShell, che può essere abilitato tramite le impostazioni GPO.
    • Lo script Invoke-Mimikatz viene loggato tramite canale Microsoft-Windows-PowerShell/Operational (da JPCERT CC), nonché il Destination IP address/Hostname/Port number in caso di successo.
  • Windows DNS Analytical Logging
    • Fonte molto dettagliata dei log DNS, che contiene dati molto dettagliati delle informazioni DNS inviate e ricevute dal server DNS. Disponibile da Windows Server DNS (2012R2 in poi con questo hotfix).
  • Windows DNS Analytical Logging
    • Tipo di eventi “Informational” disponibile da Windows Server DNS (2012R2 in poi con questo hotfix). I tipi di eventi includono eventi RESPONSE_SUCCESS che contengono l’indirizzo IP di destinazione, QNAME (o il Query Name like example.com).

*Questi esempi provengono dalla ricerca “Hunting for Post-Exploitation Stage Attacks with Elastic Stack and the MITRE ATT&CK Framework“. DomainTools possiede l’integrazione Elastic App per fornire una migliore comprensione delle minacce nella rete utilizzando i log raccolti dai proxy.

Trovare gli aghi (metadati) nel pagliaio
Anche dopo la raccolta della sorgente di log, c’è ancora la sfida di elaborare (strutturare, estrarre, arricchire) i preziosi metadati all’interno di questi log. L’analisi dei metadati avvantaggia le operazioni di sicurezza perché porta a regole più mirate (per dashboard, search index o per filtrare le indagini), alert o per utilizzare i dati per ulteriori analisi su come indagare sugli IOC di dominio all’interno del proprio SIEM/SOAR.

Quali sorgenti di log rivelano l’esfiltrazione di IP/Hostname?
Diamo un’occhiata a un paio di fonti di log menzionate in precedenza nella sezione MITRE ATT&CK Tactics. In questo caso, esaminiamo la tattica Exfiltration MITRE e vediamo quali fonti di log sono rilevanti per le indagini IOC relative a dominio/hostname/IP.

Detection: Raccogliere i log di PowerShell da Windows PowerShell ETW Provider
Questi log contengono i metadati dei comandi che gli aggressori usano su PowerShell. Le nuove connessioni di rete effettuate o tentate verranno loggate e includeranno l’IP (interno o esterno) come destinazione. Questi sono segni di esfiltrazione (caricamento e invio di dati a un endpoint dannoso).

Anche se il payload fosse costituito da comandi o dati offuscati in base64, rendendo così difficile l’analisi e la creazione di regole, poiché le regole dipendono da determinati modelli, la raccolta di tali log può comunque aiutare a trovare eventuali valori anomali. Esistono strumenti di analisi aggiuntivi come lo strumento ee-outlier tool by NVISO-BE per questi tipi di attività.

Detection: Ricerca del tunneling DNS tramite logging e monitoraggio o DNS Query e Responses
Il tunneling DNS (un metodo di  Exfiltration Over Alternative Protocol) è dove “gli avversari possono rubare i dati esfiltrandoli su un protocollo diverso da quello del canale di comando e controllo esistente”. Gli aggressori possono utilizzare il campo del sottodominio DNS per esfiltrare i dati, oltre ad altri modi per abusare del protocollo DNS per gli attacchi.

Il tunneling DNS a un server di Command e Control utilizza il protocollo DNS come un modo per offuscare gli attacchi. Uno dei motivi di questa tecnica è che i difensori hanno un tempo minore per monitorare le cattive attività sugli endpoint più comuni come RDP, il tunneling DNS abusa del protocollo DNS per intrufolarsi in comandi e dati come l’esfiltrazione. La ricerca di attacchi di tunneling DNS implica il logging di query e risposte DNS.

Nota: se sei interessato a saperne di più su questi tipi di log e metadati, le prossime parti di questa serie si concentreranno maggiormente sul deployment dei log e sugli esempi di log.

Conclusione
In questa parte della serie, leggiamo ulteriormente il valore della sicurezza ottenuto dalla log collection mirata, che deve essere consapevole del fatto che non tutte le origini di log sono le stesse in termini di affidabilità e qualità degli eventi di log. Garantire che queste fonti di log facciano parte della tua esposizione aiuta a fornire agli IOC un percorso di indagine su Iris o indagini tramite l’API o l’integrazione di DomainTools.

Ogni tanto riceviamo richieste di (possibile) aiuto post-sfruttamento e di immergerci nei dati di dominio per trovare indizi post-sfruttamento. Sebbene la serie non approfondisca le parti operative della ricerca delle minacce, è importante che le distribuzioni vedano il valore dell’aumento dell’esposizione dei log, nonostante le sfide della gestione delle origini dei log (e dei loro tipi di log, metadati, campi mancanti e così via). Nella prossima serie, entreremo nelle specifiche di questi, coprendo le opportunità e le sfide rispettivamente nelle piattaforme Windows e Linux.

Per sapere come identificare e tenere traccia delle operazioni avversarie in DomainTools Iris, visita la nostra pagina del prodotto.

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...