jconwell/secret_handshakeUn prototipo di canale C2 per malware che utilizza certificati x509 su mTLS
Prima di tutto, perché dovrei renderlo open source?
MITRE ATT&CK parla solo di certificati rubati o autofirmati, e gli NDR (per quanto ne so) prestano pochissima attenzione al contenuto dei certificati x509 al di fuori di chi è la CA emittente. In generale, i certificati x509 sono considerati affidabili e possono attraversare i nostri firewall senza problemi. Ma in sostanza sono solo file che possono facilmente contenere payload dannosi come qualsiasi altro. Ci fidiamo e li ignoriamo perché sono un componente fondamentale di un processo di cifratura che diamo per scontato. L'obiettivo principale di questo progetto è aumentare la consapevolezza verso una classe di indicatori di sicurezza di cui ci fidiamo, ed evidenziare metodi che possono essere usati per rilevarne gli usi malevoli.
Mi sono sempre chiesto se gli attaccanti abbiano mai usato certificati x509 come parte della loro comunicazione C2, non per cifrare il traffico di rete, ma per incorporare effettivamente la comunicazione C2 nel certificato x509. Dopo aver cercato qualcosa del genere "in the wild" per 5 anni, ho finalmente deciso di codificarlo da solo per vedere se è possibile... lo è.
Ogni singolo messaggio cifrato inviato su HTTPS/TLS è reso possibile dal trasferimento di un certificato x509. Quando si stabilisce un handshake TLS (figura sotto), durante il quarto passaggio il server invia il suo certificato x509 al client. Il client verifica il certificato, confronta gli algoritmi di cifratura supportati dal server e sceglie quale algoritmo usare per tutta la comunicazione successiva.
Come mostra questo diagramma, si tratta solo di un trasferimento unidirezionale del certificato x509 dal server al client. Questo non si presta bene alla comunicazione C2 perché non c'è modo per il client di rispondere al server. Al massimo, potrebbe essere usato come meccanismo di trasferimento dati unidirezionale (vedi sezione "Prior Art" sotto).
Ma esiste un altro tipo di sessione TLS chiamata Mutua Autenticazione TLS (mTLS), in cui sia il client che il server si scambiano certificati x509 come metodo per autenticarsi a vicenda.
Come mostra la figura sopra, durante l'autenticazione reciproca il certificato x509 del server viene inviato al client per l'autenticazione, e poi il certificato x509 del client viene inviato al server per l'autenticazione. Questo scambio di artefatti rappresenta un'opportunità per creare un canale di comunicazione bidirezionale per i server C2.
Poiché i certificati del server e del client vengono scambiati dalla libreria SSL sottostante, non c'è l'opportunità per il client di estrarre il messaggio dal certificato del server, eseguire il comando, e generare un certificato di risposta tutto all'interno di una singola connessione mTLS. Questo significa che il canale C2 deve essere progettato in modo tale che lo scambio richiesta-risposta avvenga su due diverse connessioni TLS mutuali, un po' come una modalità di trasmissione pseudo half-duplex.
Il processo di richiesta/risposta segue i seguenti passaggi:
Dopo averlo fatto funzionare, ero piuttosto orgoglioso di me stesso per essere stato tutto creativo e quant'altro.
Poi mi sono imbattuto in questo intervento al BSides del 2018 di Jason Reaves che ha scritto un dropper di malware usando certificati x509 su TLS. Un anno dopo Jason pubblicò questo articolo che descrive un canale di comunicazione bidirezionale completo usando mTLS.
mTLS richiede che sia il certificato del client che quello del server siano firmati dalla stessa CA, quindi il primo passaggio è generare la propria coppia chiave privata / certificato della CA
Crea la chiave privata della CA root:
openssl genrsa -des3 -out hmCA.key 2048
nota: La passphrase impedirà a chiunque entri in possesso della tua chiave privata di generare un proprio certificato root.
Crea il certificato della CA root
openssl req -x509 -new -nodes -key hmCA.key -sha256 -days 1825 -out hmCA.pem
Copia i file di chiave e certificato generati nella cartella certs/ca_certs. Il progetto include una coppia
chiave/certificato demo, quindi puoi saltare questo passaggio se vuoi.
Avvia il client:
python client.py
Avvia il server:
python server.py
Non voglio mai rilasciare qualcosa di potenzialmente malevolo senza anche spiegare come rilevarlo nei log di rete.
Penseresti che rilevare questo tipo di pattern TLS sia facile, ma non è così semplice. Uno dei principali indizi di questo canale C2 è il suo stile di comunicazione half-duplex; servono due flussi di autenticazione reciproca per completare una richiesta/risposta completa tra server e client. Questo poi si ripete più volte mentre il server invia diversi comandi al client.
Questo significa che dovresti cercare:
Sembra un insieme di regole di rilevamento infallibile, ma come ho detto prima non è così facile. A quanto pare esiste una serie di servizi enterprise che hanno anche loro un pattern di traffico mTLS simile, tra cui:
Molti di questi sembrano essere servizi di gestione di asset/dispositivi, quindi in teoria dovrebbero inviare lo stesso set di certificati ogni volta che eseguono la scansione di tutti i loro dispositivi. Potresti verificare se ci sono set di più sessioni mTLS che si ripetono ogni N ore, e poi controllare se gli hash dei certificati tra due set diversi di sessioni mTLS corrispondono, o corrispondono in gran parte. Inoltre, potenzialmente cerca certificati client diversi per ogni sessione mTLS, ma lo stesso certificato server su tutte le sessioni.
L'SSL inspection è un modo per bloccare potenzialmente questo tipo di canale di comunicazione C2, poiché il server di SSL inspection non avrebbe il certificato CA malevolo necessario per autenticare il certificato del client.
