Rilevamento del traffico C2 su DNS?

4

Supponiamo di avere una grande rete aziendale (migliaia di nodi) e da qualche parte su quella rete ci sono malware che comunicano tramite DNS per C2. Supponiamo che le richieste siano progettate in modo tale che il traffico sia legittimo DNS e non contenga comandi ovvi o altre stringhe che possono essere rilevate banalmente. (Forse usa i record A o AAAA per codificare i dati.)

È possibile provare a rilevare il traffico utilizzando diverse tecniche:

  1. Cerca traffico DNS a tempo regolarmente. (ad es., esattamente ogni ora)
  2. Cerca i domini richiesti raramente - su una rete così grande, le richieste di malware dovrebbero essere i valori anomali. (Ma forse c'è anche altro traffico che è un outlier.)
  3. Cerca i risultati DNS che continuano a cambiare (ma forse è il bilanciamento del carico DNS)

Ci sono altre tecniche che non ho considerato?

    
posta David 17.01.2018 - 06:12
fonte

2 risposte

4
  1. La maggior parte del malware che abusa dei canali (dalla mia esperienza) include una qualche forma di randomizzazione nei tempi di connessione. Anche qualcosa di semplice come 60 minutes + rand(-5,5) può sconfiggere i profiler del tempo. Scoprirai anche che le persone hanno alcuni schemi scandalosamente regolari nelle loro abitudini di navigazione.
  2. Dall'esperienza, l'analisi della frequenza produrrà molti falsi positivi in una grande azienda. Ognuno è nella propria cosa e gli interessi cambiano. Invece, analizza i domini per "infanzia". Cerca quando il dominio è stato registrato e cerca domini a meno di 3 mesi. Quindi cerca domini non di proprietà di * Inc. o * Ltd. o che hanno uno "scudo di privacy del dominio" sul posto. Bolla quelli per ulteriori indagini.

Una cosa che non hai menzionato è il confronto del dominio con le blacklist da un servizio di blacklist. Presumo che tu ci abbia pensato, ma volevo parlarne.

Ricorda che è banale che gli autori di malware si adattino a qualsiasi metodo di rilevamento che puoi escogitare (come l'analisi del tempo). I processi di rilevamento più robusti richiedono analisi statistiche complesse sia sulla destinazione che sul nodo richiedente rispetto ai peer del nodo e alle tendenze generali nell'ambiente locale (tempi, frequenza, contenuto, larghezza di banda, profili peer non corrispondenti) (un non-peer si comporta come un pari)). E anche allora, richiederà ulteriori analisi per determinare i veri positivi.

Ho sviluppato algoritmi UEBA per questo tipo di cose, e una volta che inizi, ti troverai un po 'una tana di coniglio ("forse posso modificarlo in questo modo e ottenere una migliore efficienza!"). Per l'efficacia dell'80%, concentrati sull'analisi "infantile" che ho menzionato sopra.

    
risposta data 17.01.2018 - 10:36
fonte
2

Altre due opzioni:

1) Controlla la lunghezza delle query DNS. È probabile che il traffico C2, in particolare se si esegue l'estrazione di dati, abbia query più grandi. Se tracciato nel tempo, potrebbe mostrare un possibile tunnel

2) Conteggio FQDN di dominio di secondo livello .

Some of the specific payload analysis rules could be bypassed by a knowledgeable attacker. They could shorten the labels used and reduce the number of labels in an FQDN. However, they will always need to create a large number of unique FQDNs which are normally from a specific root domain.

Si tratta di un documento SANS sull'individuazione di tunnel DNS che dà anche molti altri possibili indicatori e copre in modo specifico questo secondo punto in modo molto dettagliato.

    
risposta data 17.01.2018 - 10:52
fonte

Leggi altre domande sui tag