La decriptazione dei payload dei pacchetti è efficace o efficiente dal punto di vista operativo per aiutare gli analisti ad individuare i segnali di attacchi avanzati nation state o di attacchi eseguiti manualmente come RansomOps in una rete?
La risposta breve è no.
- La decodifica passiva della crittografia standard come TLS è operativamente costosa (con TLS 1.3, richiede l'installazione di un agente su tutti gli endpoint connessi).
- La decodifica non offre al difensore molti vantaggi che non siano già offerti dalla decodifica attiva con firewall o proxy.
- E nessuno dei due aiuta effettivamente i difensori a rintracciare il canale C2 di un attaccante avanzato o l'esfiltrazione dei dati.
Consideriamo 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. Scopriamo che la decrittografia offre pochissimi vantaggi ai difensori, se non addirittura nessuno, quando si tratta di rilevare attacchi avanzati da parte dello Stato nazionale o attacchi criminali eseguiti manualmente come RansomOps. Ecco perché.
Gli strumenti di attacco dello Stato nazionale sono personalizzati
Gli attori degli Stati-nazione di solito assemblano catene di strumenti da utilizzare per le loro squadre di attacco. Queste catene di strumenti spesso includono strumenti sviluppati internamente e strumenti più semplici. Gli strumenti non disponibili saranno altamente personalizzati per evitare di essere rilevati con metodi semplici che ne rilevano la semplice presenza.
Inoltre, gli attori più capaci degli Stati nazionali aggiungeranno ulteriore entropia: configureranno gli strumenti personalizzati e quelli off-the-shelf che utilizzano in modo diverso per ogni obiettivo che perseguono e non riutilizzeranno nessuna delle infrastrutture (per il C2 e l'Exfil) utilizzate per condurre attacchi su obiettivi diversi. Pertanto, la decrittazione dei payload per eseguire le firme non ha alcun vantaggio significativo per il rilevamento.
Gli strumenti di attacco criminale (RansomOps) vengono modificati
Gli attacchi eseguiti manualmente, come quelli utilizzati per la maggior parte degli attacchi RansomOps, sono al servizio di un modello commerciale a scopo di lucro. Non ha molto senso spendere molte risorse in ricerca e sviluppo per costruire strumenti da zero, poiché ciò riduce semplicemente i potenziali profitti.
Al contrario, quasi tutti gli attacchi criminali fanno un uso massiccio di strumenti disponibili sul mercato, ma questi attori sanno abbastanza da non utilizzare questi strumenti con le impostazioni predefinite fornite, che la maggior parte dei prodotti di firma rileverebbe.
Invece, sovrascriveranno la configurazione standard con cui vengono forniti gli strumenti standard, rendendo inutili le firme. L'infrastruttura è più comunemente riutilizzata, ma può essere identificata tramite domini e/o IP senza decrittografia. Proprio come nel caso degli Stati nazionali, quindi, la decodifica dei payload per eseguire le firme non ha alcun vantaggio significativo per il rilevamento.
Il funzionamento interno di Cobalt Strike
Vediamo cosa significa sovrascrivere le impostazioni standard di Cobalt Strike, uno dei framework di pen-test più noti. L'esempio è illustrativo: lo stesso grado di configurabilità esiste in qualsiasi strumento di pen testing maturo, che rende banale sovrascrivere le impostazioni predefinite per eludere le firme.
Il manuale d'uso di Cobalt Strike è disponibile qui. Esaminiamo la capacità di Command and Control malleabile che fa parte di questo pacchetto. Per utilizzare la funzione C2 malleabile, si compongono 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'aggressore voglia inserire nella richiesta per farla sembrare normale o incomprensibile.
I dati effettivi che devono essere trasferiti attraverso il canale C2 possono essere codificati in una varietà di formati (Base64, NetBIOS, ecc.) e possono essere facilmente mascherati inserendo una chiave casuale nota solo all'attaccante (si pensi a questa forma leggera ma efficace di crittografia "interna").
Sintesi
Sia che ci si trovi di fronte a uno Stato nazionale o a un attaccante RansomOps (che applica una buona igiene di sicurezza evitando di riutilizzare gli stessi tag/valori e chiavi per obiettivi diversi), la violazione della crittografia TLS esterna per ottenere l'accesso alla richiesta HTTP interna non aiuta il difensore. Non esiste uno schema fisso per una firma da colpire 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.
Quindi, a meno che un'organizzazione non sia disposta ad adottare una politica di accesso a Internet molto restrittiva (in pratica, una whitelist della parte di Internet di cui si fida), i canali C2 non possono essere individuati cercando modelli di byte nei payload HTTP decriptati. 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 di C2 o Exfil si basa sull'analisi delle informazioni sulle serie temporali dei trasferimenti di dati o sull'osservazione di semplici anomalie di volume, che non richiedono la decodifica dell'involucro esterno.