La decrittografia dei payload dei pacchetti è efficace o efficiente dal punto di vista operativo nell'aiutare i difensori a individuare i segni di attacchi avanzati da parte di Stati nazionali o attacchi eseguiti manualmente come RansomOps in una rete?
La risposta breve è no.
- La decrittografia passiva di crittografie standard come TLS è costosa dal punto di vista operativo (con TLS 1.3, richiede l'installazione di un agente su tutti gli endpoint collegati).
- La decrittografia offre pochi vantaggi al difensore rispetto alla decrittografia attiva con firewall o proxy.
- E nessuno dei due aiuta effettivamente i difensori a rintracciare il canale C2 di un aggressore avanzato o l'esfiltrazione dei dati.
Prendiamo in considerazione il traffico ai confini della rete di un'organizzazione, dove la crittografia è prevalente, e cerchiamo segni di comando e controllo e di esfiltrazione dei dati. Quello che scopriamo è che la decrittografia offre pochissimi vantaggi, se non nessuno, ai difensori quando si tratta di rilevare attacchi avanzati da parte di Stati nazionali o attacchi criminali eseguiti manualmente come RansomOps. Ecco perché.
Gli strumenti degli aggressori degli Stati nazionali sono personalizzati
Gli attori statali tipicamente assemblano catene di strumenti da utilizzare dai propri team di attacco. Queste catene di strumenti spesso includono strumenti sviluppati internamente e strumenti più comuni. Gli strumenti comuni saranno altamente personalizzati per evitare il rilevamento tramite metodi semplici che ne ricercano la semplice presenza.
E gli attori statali più capaci aggiungeranno ulteriore entropia: configureranno gli strumenti personalizzati e standard che utilizzano in modo diverso per ogni obiettivo che perseguono e non riutilizzeranno alcuna delle infrastrutture (per C2 ed Exfil) utilizzate per sferrare attacchi contro obiettivi diversi. Pertanto, decriptare i payload per eseguire le firme non offre alcun vantaggio significativo in termini di rilevamento.
Gli strumenti degli hacker criminali (RansomOps) sono stati modificati
Gli attacchi eseguiti manualmente, come quelli utilizzati per portare a termine la maggior parte degli attacchi RansomOps, sono al servizio di un modello di business a scopo di lucro. Non ha molto senso investire molto in ricerca e sviluppo per creare strumenti da zero, poiché ciò ridurrebbe semplicemente i potenziali profitti.
Al contrario, quasi tutti gli attacchi criminali fanno ampio uso di strumenti disponibili in commercio, ma questi attori sono abbastanza esperti da non utilizzare tali strumenti con le impostazioni predefinite, che la maggior parte dei prodotti di firma sarebbe in grado di rilevare.
Al contrario, sovrascriveranno la configurazione standard fornita con gli strumenti disponibili in commercio, rendendo inutili le firme di rendering. L'infrastruttura viene riutilizzata più comunemente, ma può essere identificata tramite domini e/o IP senza decrittografia. Proprio come nel caso degli Stati nazionali, quindi, la decrittografia dei payload per eseguire le firme non offre alcun vantaggio significativo in termini di rilevamento.
Il funzionamento interno di Cobalt Strike
Vediamo cosa significa sovrascrivere le impostazioni standard di Cobalt Strike, uno dei framework di pen testing più conosciuti e disponibili in commercio. Questo esempio è illustrativo: lo stesso grado di configurabilità esiste in qualsiasi strumento di pen testing maturo, rendendo banale sovrascrivere le impostazioni predefinite per eludere le firme.
La guida utente di Cobalt Strike disponibile qui. Esaminiamo la funzionalità Malleable Command and Control inclusa in questo pacchetto. Per utilizzare la funzionalità C2 malleabile, è necessario comporre tutte le opzioni che si desidera utilizzare in un profilo.
Nel profilo, ogni elemento della richiesta e della risposta HTTPS utilizzato per la comunicazione C2 è (come suggerisce il titolo) malleabile. Ciò include il certificato utilizzato per proteggere il canale TLS che trasporta il traffico HTTP, l'URI codificato nella richiesta HTTP, l'User-Agent specificato, la presenza o l'assenza di un tag referrer e qualsiasi altra cosa l'autore dell'attacco desideri inserire nella richiesta per farla sembrare normale o incomprensibile.
Qualsiasi dato effettivo che deve essere trasferito attraverso il canale C2 può essere codificato in una varietà di formati (Base64, NetBIOS, ecc.) e può essere facilmente mascherato mediante XORing in una chiave casuale conosciuta solo dall'autore dell'attacco (consideratelo come una forma leggera ma efficace di crittografia "interna").
Sommario
Che si tratti di un attacco sferrato da uno Stato-nazione o da un RansomOps (un hacker che applica buone pratiche di sicurezza evitando di riutilizzare gli stessi tag/valori e chiavi per obiettivi diversi), violare la crittografia TLS esterna per accedere alla richiesta HTTP interna non aiuta il difensore. Non esiste un modello fisso per una firma da prendere di mira e il payload effettivo (comandi inviati, risultati dei comandi restituiti, software scaricato, ecc.) è oscurato da una crittografia leggera che utilizza la chiave generata casualmente dall'attaccante.
Pertanto, a meno che un'organizzazione non sia disposta ad adottare una politica di accesso a Internet molto restrittiva (inserendo effettivamente nella whitelist la parte di Internet di cui si fida), i canali C2 non possono essere rilevati cercando modelli di byte nei payload HTTP decrittografati. Il rilevamento dell'esfiltrazione segue più o meno la stessa logica. I payload interni crittografati sono impermeabili agli approcci DLP standard. L'unico altro mezzo di rilevamento C2 o Exfil si basa sull'analisi delle informazioni temporali dei trasferimenti di dati o sull'osservazione di semplici anomalie di volume, nessuna delle quali richiede la decrittografia del wrapper esterno.