introduzione

In questo articolo approfondirò il rilevamento del contrabbando di HTML, seguendo il processo di ingegneria del rilevamento che ho descritto nei miei ultimi due post. Questo processo include ricerca, test e sviluppo di nuovi concetti di rilevamento. A differenza dei miei post precedenti, tuttavia, questa volta osserveremo, creeremo profili e rileveremo il vero malware QakBot in laboratorio. Con questo pezzo spero di mostrare come gli attuali e aspiranti ingegneri del rilevamento possono andare oltre le sfide simulate in stile CTF per studiare e rilevare le tecniche degli aggressori del mondo reale, segnalandole per il nostro SOC e consentendo ai nostri colleghi di risposta agli incidenti di neutralizzare la minaccia.

Il nostro itinerario

Dopo un po' di background e definendo l'obiettivo, dimostrerò come possiamo eseguire il malware QakBot HTML Smuggling in laboratorio, monitorando il suo comportamento in Splunk. Quindi, sequenzierò gli eventi osservabili di questo attacco e identificherò utili punti di rilevamento (che considero come "mattoni" o collegamenti della catena di attacco). Introdurrò anche la correlazione (in particolare le regole della catena), uno strumento cruciale nella cassetta degli attrezzi per il rilevamento delle minacce. Per illustrare come appare, discuterò e dimostrerò una capacità di Sigma non ancora rilasciata, chiamata Sigma Correlations. Concluderò testando una nuova regola della catena su 10 campioni aggiuntivi di malware QakBot HTML Smuggling per vedere come si comporta.

Iniziamo!

Sfondo

All'inizio del mio viaggio nella sicurezza informatica, John Strand di Black Hills Information Security ha detto qualcosa che mi è rimasto impresso: "Non esiste un registro 'SEI STATO HACKERATO'". I registri degli eventi possono essere confusi e difficili da leggere anche in una buona giornata. Ricavare informazioni utili e fruibili dai log è complicato! La sfida a volte richiede un'analisi approfondita e tecniche specializzate per avere successo.

Ho avuto quella lezione nella parte posteriore della mia mente durante tutta la mia carriera nella sicurezza, ed è stato con questo in mente che alcuni mesi fa ho iniziato a vedere tonnellate di post come questo da @ pr0xylife :

Mi piace il modo in cui pr0xylife e i loro colleghi riassumono questi attacchi in modo così succinto, e mi sono ritrovato a ripetere la sequenza dei tipi di file ad alta voce, quasi come una strana forma di poesia!

Volevo saperne di più, ma non sapevo come iniziare. Avevo esaminato alcune eccellenti ricerche su QakBot da parte del team di Trellix, quindi conoscevo un po' le loro tecniche. (Se non hai mai sentito parlare di QakBot, leggi il rapporto Trellix!) Quando ho iniziato a seguire l'attività di QakBot e a scavare più a fondo, mi sono reso conto che pr0xylife e altri stavano descrivendo le sottili combinazioni e variazioni nel modo in cui QakBot poteva ingannare le sue vittime ed eludere il nostro difese. Qualche esempio:

• Utilizza HTML Smuggling , in cui un file HTML dannoso contenente JavaScript codificato viene eseguito dal browser della vittima, scaricando la fase successiva del payload.
• Utilizza file zip protetti da password per bloccare l'analisi sandboxing.
• Utilizza un formato immagine disco chiamato file .iso per eludere la protezione Mark-of-the-Web, come spiega molto bene Red Canary .
• File LNK camuffati per indurre gli utenti a eseguire file .CMD e .DLL nascosti.
• E ancora e ancora con trucchi sempre più ingannevoli!

L'obiettivo

Ci sono alcuni rilevamenti là fuori per il contrabbando di HTML e altre tecniche connesse a QakBot. Questi si basano principalmente sulla corrispondenza di eventi di log sospetti, come questo da Elastic security:

Volevo vedere se potevo costruire i miei rilevamenti, utilizzando la correlazione (al contrario della semplice corrispondenza) per renderli resistenti a sottili cambiamenti nel comportamento di attacco.

TBH, ero anche stufo degli stupidi imbrogli di QakBot e volevo un modo affidabile per metterlo esattamente sotto i nostri occhi.

Osservazione iniziale e analisi del malware QakBot

Per raggiungere il mio obiettivo, ho dovuto andare oltre i rapporti di intelligence sulle minacce dei fornitori di sicurezza e i test dell'Atomic Red Team; Avevo bisogno dei miei dati creati da veri campioni di malware. Mi sono rivolto a un vecchio preferito: malware-traffic-analysis.net di Brad Duncan (@malware_traffic). Questo sito è tra le risorse educative più utili in cui mi sono imbattuto in materia di sicurezza. Oltre ai tutorial di Wireshark e agli esercizi pratici sul traffico di rete, il sito offre un'analisi qualitativa di campioni di malware del mondo reale, inclusi i file di contrabbando HTML di QakBot.

Dopo aver creato istantanee delle macchine virtuali del mio laboratorio, ho avviato il mio laboratorio di rilevamento virtuale e ho visitato una voce recente. Fai attenzione, i file ospitati su questo sito non sono sicuri!

Ho scaricato il file zip degli artefatti e l'ho estratto nella cartella dei download utilizzando l'utilità WinRAR integrata nel mio laboratorio di rilevamento:

Le note del CIO sono state estremamente utili per dare un contesto ai file inclusi. Tra le note c'erano le seguenti, che mi hanno fatto sapere che la catena di infezione è iniziata con il file HTML, chiamato SCAN_DT6281.html.

2022-12-09 (FRIDAY) - HTML SMUGGLING FOR QAKBOT (QBOT) DISTRIBUTION TAG: AZD

DISTRIBUTION:

- Unknown source, possibly email --> HTML file --> password-protected zip archive --> extracted ISO image with .img file extension

…certo, apriamo il file zip, perché no?

Il file zip era protetto da password ma poteva essere aperto utilizzando la password visualizzata nella pagina HTML. Il file zip conteneva un singolo file .img, che so essere un altro formato di file immagine disco montabile. Facendo doppio clic su questo, il file è stato montato come unità D sul mio sistema:

Ho anche notato una directory nascosta chiamata IncomingPay, che conteneva un file .lnk, due file di testo che contenevano (non scherzo) estratti dalla pagina di Wikipedia sulla psicologia, un file .cmd e un file .lc .

In qualità di professionista della sicurezza e rispettoso osservatore della formazione sulla consapevolezza della sicurezza aziendale, tutti i miei erano in piedi e salutavano la brezza. Ma questo è per la scienza, quindi abbocco e faccio doppio clic sul file LNK, proprio come l'attaccante vuole che faccia la vittima. Una finestra della riga di comando appare per alcuni secondi, poi scompare:

La proprietà di destinazione del file LNK è interessante:

C:\Windows\System32\cmd.exe /c IncomingPay\Issues.cmd A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9

Come faccio a sapere quali ricerche eseguire? Non lo so davvero, ma attraverso la mia esperienza come analista e ricercatore so che ci sono alcuni tipi di prove che possono apparire nei miei registri: esecuzioni di processi, creazioni di file, connessioni di rete e simili. È qui che torna utile l'esperienza sul posto di lavoro come analista della sicurezza o una buona dose di corsi di formazione in stile CTF (come quelli disponibili presso CyberDefenders o LetsDefend ).

Dopo aver aggiornato alcune volte le mie ricerche e chiedendomi se avessi fatto qualcosa di sbagliato, ho notato un segno preciso e incontrovertibile di un'intrusione: un'esplosione di attività di ricognizione sul mio host vittima:

Mentre guardavo questi comandi, ho notato il periodo di tempo in cui si sono verificati, il tutto nell'arco di pochi secondi! Inoltre, i processi sono stati tutti generati da un genitore insolito: wermgr.exe (Windows Error Reporting Manager). Una buona opportunità di rilevamento, forse? Anche l'amministratore più confuso o il software [legittimo] sovradimensionato non eseguirà tutti questi comandi di ricognizione sospetti in un lasso di tempo così breve e mai come figli di un wermgr.exe. Passando alle mie connessioni di rete, ho notato che wermgr.exe era improvvisamente diventato estremamente loquace con indirizzi IP esterni:

A seguito di questa valutazione iniziale dei miei dati, ho stabilito che:

• Il campione di malware conteneva un vettore di accesso iniziale dannoso (duh, la galleria dei ladri dei file .html, .zip, .img, .lnk, .cmd e .lc).
• Il malware scaricherà il file zip dopo aver aperto la pagina HTML in un browser e il file zip conteneva un file .img montabile.
• L'unità montata conteneva un collegamento dannoso che avrebbe comportato l'esecuzione di comandi aggiuntivi.
• Un processo wermgr.exe iniettato ha generato un'esplosione automatica di attività di ricognizione e quindi si è connesso a indirizzi IP esterni sospetti, presumibilmente per inviare all'aggressore informazioni sul nostro sistema e sulla nostra rete.

Scomporre l'attacco in elementi costitutivi di rilevamento

Dopo aver eseguito un'esecuzione iniziale della tecnica di contrabbando HTML di QakBot in laboratorio ed essere tornati alle mie istantanee VM, era giunto il momento di scavare ulteriormente nei registri per vedere cosa stava succedendo.

Mentre esaminavo i vari tipi di eventi generati dall'attacco, ho iniziato a sviluppare una comprensione narrativa in un linguaggio semplice di ciò che stava accadendo:

“Un utente malintenzionato invia a una vittima un file HTML che pretende di contenere un rapporto, una fattura o un altro documento di suo interesse. Fondamentalmente, un'esca di phishing. Quando la vittima apre il file nel proprio browser, viene eseguito il codice JavaScript incorporato, che scarica o crea un file zip protetto da password sul sistema della vittima. Quando la vittima decomprime l'archivio , l'estrazione crea un file immagine disco montabile. Dopo aver montato l'unità , l'utente vede un collegamento che ritiene lo porterà alla risorsa che sta cercando di trovare. Ma il collegamento chiama in realtà un comando o un interprete di script che esegue altri file dannosiche sono nascosti sull'unità disco, portando alla compromissione dell'accesso iniziale.

È un pezzo prolisso di prosa proprio lì, ma ha senso nella mia testa. Se devo rilevare qualcosa, devo prima capirlo! Nota il testo in grassetto: ho usato la mia narrazione per evidenziare eventi che avrei potuto usare per rilevare la catena di attacco. Sulla base di questa recensione, ho analizzato i log dell'attacco, cercando di isolare i seguenti eventi:

1. E-mail di phishing inviata alla vittima contenente un allegato HTML.
2. Creazione di un file HTML in posizioni sospette.
3. Apertura di un file HTML autonomo in un'applicazione browser.
4. Download/creazione di un file zip dall'applicazione browser.
5. Apertura/estrazione di un file zip protetto da password.
6. Creazione di un formato di file di unità disco montabile (.iso, .img, ecc.).
7. Montaggio di un'unità.
8. Esecuzione del processo su un'unità esterna (da un eseguibile su quell'unità o da un eseguibile di sistema che tocca i file su quell'unità).

Le buone notizie

La buona notizia è che ci sono modi per rilevare quasi tutti gli eventi sopra elencati! Ciò significa che ho avuto numerose idee su come interrogare e filtrare i registri disponibili per estrarre gli eventi significativi (elementi costitutivi) per rilevamenti futuri.

Le cattive notizie

La cattiva notizia era che nessuno di questi numerosi eventi è, di per sé, dannoso. Ancora una volta, non esiste un registro YOU ​​HAVE BEEN HACKED: ciascuno di questi eventi potrebbe verificarsi nel corso delle normali attività ed essere completamente sicuro e benigno. La soluzione sarebbe correlare questi eventi, in una sequenza ordinata o non ordinata, raggruppandoli in base a un attributo comune come il nome host e attivando un avviso quando tutti questi eventi si verificano entro una finestra temporale, ad esempio un'ora. Il problema è, dalla mia analisi e test (ne parleremo tra poco), il concatenamento o la correlazione di molti eventi risulterebbe in un rilevamento fragile.

Fragile contro resiliente

La "fragilità" descrive il grado in cui un'idea di rilevamento fallisce di fronte a sottili modifiche alle tecniche dell'attaccante, variazioni nelle azioni eseguite dalla vittima, problemi con la registrazione o altri fattori al di fuori del nostro controllo. I rilevamenti fragili contrastano con i rilevamenti "resilienti", che sono flessibili e possono resistere a questi sottili cambiamenti.

Non è così semplice come dire "Fragile = cattivo e resistente = buono". Un rilevamento fragile potrebbe essere altamente mirato, con una "apertura" ristretta. Il vantaggio potrebbe essere che, se viene attivata una regola di rilevamento fragile, esiste un'altissima probabilità che si tratti di un vero positivo. I rilevamenti resilienti possono avere un'apertura più ampia e possono corrispondere a più potenziali attività dannose. Tuttavia, questo potrebbe portare a falsi positivi e a un SOC frustrato se non vengono sviluppati con cura.

Con questo in mente, sono tornato al mio elenco di eventi dall'alto.

Determinazione degli elementi costitutivi da testare

Nel contesto, mi sono reso conto che gli elementi da uno a tre nell'elenco precedente potrebbero non essere buoni componenti del mio rilevamento del contrabbando HTML. La mancanza di visibilità e un elevato volume di comportamenti innocenti ostacolerebbero l'elemento 1. Ho colpito l'elemento due perché avevo una capacità limitata di testare questo evento e l'elemento tre si è rivelato inaffidabile a seconda del browser che ho utilizzato. Inoltre, pur non essendo tecnicamente contrabbando HTML, molte attività di QakBot utilizzano URL, anziché file HTML autonomi, per fornire il payload iniziale.

L'elemento cinque (estrazione di un file zip protetto da password) ha molte potenzialità e può essere rilevato utilizzando questa regola scritta da Florian Roth e ispirata dalla ricerca di @SBousseaden . Tuttavia, l'ho lasciato fuori dal mio ambito perché 1) quell'evento non si registrava nel mio laboratorio e 2) alcuni documenti indicano che è applicabile solo a determinati sistemi operativi.

Dopo aver esplorato i miei dati, enumerando i possibili elementi costitutivi del rilevamento per la mia correlazione e vagliando l'elenco sulla base di ulteriori analisi, ho ottenuto i seguenti elementi costitutivi:

1. Il browser Web crea (download) file di archivio zip (rappresenta l'apertura del file HTML dannoso in un browser).
2. File ISO, VHD, LNK o IMG estratto da Zip (estrazione del file immagine del disco dannoso).
3. Disk Image Mount (montaggio dell'immagine - questa l'ho estratta direttamente da Sigma).
4. Esecuzione di un processo sospetto avviato dall'utente su un'unità esterna (facendo clic sul file .lnk che esegue o fa riferimento a file sull'unità esterna).

Correlazioni Sigma

La correlazione ci consente di tenere traccia degli eventi di registro nel tempo. Anziché attivare un avviso per ciascuno dei quattro eventi sopra elencati, una correlazione di regole a catena ci consente di avvisare solo quando tutti e quattro gli eventi si verificano in ordine sullo stesso host dallo stesso utente, il che è molto più sospetto. Molti prodotti SIEM e i corrispondenti linguaggi di query supportano questo tipo di concatenamento (sebbene alcuni non lo facciano).

Per supportare questa funzionalità, Sigma ha in corso uno standard di correlazione che ci consentirà di scrivere regole di correlazione personalizzate in un formato comune, quindi convertirle in qualsiasi prodotto SIEM supporti questa logica. La bozza dello standard può essere rivista qui:

Come potrebbe essere? È una bozza di standard e soggetta a modifiche , ma un semplice esempio di regola della catena di forza bruta potrebbe essere simile a questo:

action: correlation
type: temporal
rule:
    - many_failed_logins
    - successful_login
group-by:
    - User
timespan: 1h
ordered: true

La mia bozza di regola per le correlazioni si presenta così:

title: HTML Smuggling Activity - Chain Rule
id: 0952f2fa-e29b-4eb5-831c-ce21520c56e3
status: experimental
description: Detects HTML smuggling-style compromise (such as HTML > ZIP > ISO/IMG/VHD > CMD/BAT/VBS > DLL). Includes rules to detect zipfile dropped by browser, ISO/IMG/VHD/LNK file extraction, disk image mount, followed by user-initiated process creation on an external drive.
references:
    - https://blog.talosintelligence.com/html-smugglers-turn-to-svg-images/#:~:text=HTML%20smuggling%20is%20a%20technique,directly%20on%20the%20victim's%20device.
    - https://www.malwarebytes.com/blog/news/2021/11/evasive-maneuvers-html-smuggling-explained
    - Original research and analysis performed off of QakBot intelligence gathered at https://github.com/pr0xylife/Qakbot, https://www.malware-traffic-analysis.net/, and https://github.com/executemalware/Malware-IOCs
author: Micah Babinski
date: 2022/12/27
tags:
    - attack.s0650
    - attack.s0483
    - attack.initial_access
    - attack.defense_evasion
    - attack.execution
    - attack.t1564
    - attack.t1566.001
    - attack.t1566
    - attack.t1027
    - attack.t1027.006
    - attack.t1059
    - attack.t1204
    - attack.t1204.002
action: correlation
type: temporal
rule:
    - 1_win_zipfile_drop.yml
    - 2_win_susp_file_extraction.yml
    - 3_win_security_iso_mount.yml
    - 4_win_process_creation_ext_drive.yml
group-by:
    - ComputerName
    - User
timespan: 1h
ordered: true
falsepositives:
    - Unknown
level: high

Ancora una volta, la specifica Sigma Correlations è in fase di sviluppo ed è soggetta a modifiche. Tuttavia, questa sarà un'espansione molto utile delle capacità di Sigma, quindi volevo mostrarvela in anteprima ora!

Testare la correlazione

Con questo concetto di rilevamento che prendeva forma e un'ipotesi sviluppata sotto forma della mia regola di correlazione, era giunto il momento di testare il rilevamento con una dimensione del campione più ampia. Mi sono affidato al repository MalwareBazaar di Abuse.ch, che fornisce un'utile libreria di campioni di malware con tag. Ho scaricato 10 campioni HTML di QakBot, per lo più segnalati da pr0xylife, con una data compresa tra l'11 luglio e il 22 dicembre 2022. Ho preparato i campioni sulla VM del mio laboratorio e ho assegnato a ciascuno un nome in base alla data della prima visualizzazione e al suo "humanhash" proprietà (una sequenza casuale e univoca di parole leggibili dall'uomo, come ("dakota-earth-mockingbird-march"):

Per tenere traccia dei miei risultati, ho creato una semplice tabella in Fogli Google:

Ho creato un'istantanea pulita e pre-test del mio host VM vittima a cui tornare dopo ogni test e ho iniziato il test. Dopo aver testato sette dei dieci campioni, la mia sequenza di quattro elementi costitutivi aveva una copertura perfetta! Quando ho raggiunto l'ottavo campione, tuttavia, la quarta regola nella catena non si è attivata, perché il file .lnk ha chiamato RunDLL32.exe direttamente, invece di cmd.exe o wscript.exe. Andava bene: ho semplicemente apportato modifiche alle condizioni della mia regola Sigma, ho ripetuto il test e ho ottenuto corrispondenze perfette! Sono rimasto molto soddisfatto dei risultati ed entusiasta di condividere il caso d'uso del rilevamento con la community.

Giro bonus!

Molti attacchi di phishing QakBot non utilizzano allegati .html, ma utilizzano invece file .pdf dannosi con collegamenti incorporati o solo buoni collegamenti di phishing vecchio stile che puntano a file zip ospitati su un sito Web compromesso. Per verificare se il mio rilevamento fosse abbastanza flessibile da rilevare anche queste istanze, le ho testate su un paio di esempi recenti dal repository IOC gestito da @ExecuteMalware e ho scoperto che anche questi attacchi driveby basati su URL sono stati rilevati dal rilevamento. Quello documentato qui includeva anche un file .wsf (Windows Script File), un tipo di file con cui non avevo familiarità ma che è stato comunque catturato dal mio rilevamento.

Evviva la resilienza!

Conclusione

Congratulazioni! Sei arrivato alla fine di un lungo post su alcuni argomenti densi e complicati. Puoi trovare tutte le regole a cui si fa riferimento qui . Grazie per aver letto e spero che ti siano piaciute le mie divagazioni su QakBot, HTML Smuggling, Sigma e correlazioni. Sono davvero entusiasta del lancio di Sigma Correlations. Sarà una grande vittoria per la comunità degli ingegneri di rilevamento e ci consentirà di condividere casi d'uso di rilevamento più sofisticati.

Sono stato davvero contento di come sono andati i miei test, in particolare quando è emerso che uno degli elementi costitutivi della mia regola della catena aveva fallito e necessitava di aggiustamenti! Dopotutto, perché testare se pensi che il tuo lavoro sia già perfetto? Infine, questa esperienza mi ha portato a casa ciò che avevo già iniziato a credere: che non possiamo rilevare ciò che non capiamo. Non c'è alcun sostituto per l'esperienza diretta con il vero malware dal vivo se stai cercando di vedere cosa fa.

Grazie al progetto Detection Lab di cui mi sono entusiasmato nei post precedenti, questa esperienza di vita reale è alla portata di più persone che mai. Infine, grazie a pr0xylife, Brad (malware_traffic) ed executemalware per averci fornito repository incontaminati di campioni di malware QakBot ben documentati a cui accedere, analizzare e comprendere. Questi sono davvero un tesoro educativo!

Non esitate a inviarmi idee, commenti o suggerimenti su come posso migliorare. Sono ancora nuovo in questo e accolgo con favore feedback e critiche rispettosi in qualsiasi forma.

Come sempre, buona analisi!