Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Manuel Roccon : 28 Giugno 2024 07:22
In questo articolo ci occuperemo di Infection Monkey, un tool fondamentale da conoscere.
Per spiegarlo in modo semplice, in infection monkey, varie scimmiette inizieranno a rimbalzare tra un sistema all’altro sfruttando varie vulnerabilità e comunicando le varie mosse all’island, il quartier generale delle scimmiette (la nostra dashboard di controllo).
Prima di spiegare questo tool e capire come si differenzia dagli altri, facciamo un passo indietro: facciamo chiarezza su quelli più noti per la ricerca di vulnerabilità.
Vuoi diventare un Ethical Hacker?
Non perdere i nostri corsi e scrivi subito su WhatsApp al numero
375 593 1011
per richiedere informazioni dicendo che hai trovato il numero sulle pagine di Red Hot Cyber
Supporta RHC attraverso:
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
Tutti conosciamo già i sistemi di patch management che quelli di vulnerability scanner.
Le due tipologie di sistemi hanno lo stesso obiettivo ma utilizzano due approcci diversi:
I software di patch management lavorano solitamente tramite un agent e con metodo “white box” (collezionano per ogni sistema dove è installato i software installati e versioni). Questi sistemi sono in grado di capire “passivamente” quali software e sistemi operativi richiedono aggiornamenti e se sono affetti da vulnerabilità, fornendo un indice di rischio (utilizzando il CVSS) e la priorità di patching la data di pubblicazione della patch).
I sistemi di vulnerability scanner solitamente hanno un approccio differente dai precedenti. Non conoscono il sistema e lavorano con un metodo “black box”. Attraverso scansioni esterne ad IP e porte, vanno a “caccia” di vulnerabilità utilizzando tecniche di ricognizione standard utilizzate anche nel mondo offensive security, utilizzando sia appositi plugin( che sfruttano solo una prima parte dell’exploit) che i banner per capire passivamente le versioni installate. Anche questi tools infine prioritizzano le vulnerabilità dando un remediation report. Di scanner del genere ne ho parlato poco fa con quello open source di ARTEMIS in questo articolo.
L’insieme dei 2 approcci danno un quadro molto preciso delle vulnerabilità presenti e le mitigazioni da applicare.
Ma la storia non finisce qui. Ne esiste un altro molto interessate per misurare non solo il livello di aggiornamento e policy applicate, ma anche la solidità di un’infrastruttura informatica di fronte ad una minaccia per avere un riscontro oggettivo anche dai sistemi di difesa e monitoraggio: sono i software di breach and attack simulation.
Questi sistemi simulano un vero attacco tramite un malware distribuito nella rete o in un dispositivo.
Questo malware poi va a coprire tutto il ciclo di un attacco, dalla ricognizione, all’exploit dei sistemi, alla post exploiting come la collezione di hash e credenziali e privilege escalation,al movimento laterale, pivoting e per finire alla comunicazione con un C2 (Command e Control).
Sto parlando della metodologia della cyber kill chain, più precisamente della unified cyber kill chain che unisce gli step illustrati da Lockheed Martin con le tecniche, tattiche e procedure del MITRE.
Il tool poi fornirà un report su cosa è riuscito a compromettere ed uno di mitigazione.
Questi tool possono testare attivamente i sistemi di difesa nell’infrastruttura, policy applicate fino addirittura i propri sistemi di endpoint security, edr ed xdr. I SOC potranno analizzare i dati che verranno inviati e filtrati dai SIEM.
Questo tool non è nuovo e ne esistono molti commerciali, ma io come da tradizione mi occuperò di un tool open source e gratuito distribuito da Akamai.
Per prima cosa scegliamo l’ambiente dove installarlo, possiamo scegliere varie tipologie di installazione, in questo caso utilizziamo quella per linux.
https://sourceforge.net/projects/infection-monkey.mirror/files
Abbiamo preparato una macchina con ubuntu 22, per comodità in modalità desktop per utilizzare la console direttamente all’interno.
Quindi scarichiamo l’eseguibile con WGET:
wget https://master.dl.sourceforge.net/project/infection-monkey.mirror/v2.3.0/InfectionMonkey-v2.3.0.AppImage
Ora occorre solo avviarlo, però prima impostiamo i permessi di esecuzione:
chmod +x InfectionMonkey-v2.3.0.AppImage
Potrebbe ritornarci un errore di un componente mancante, quindi installiamolo.
sudo apt install libfuse2
A questo punto avviamo appimage come qui sotto
./InfectionMonkey-v2.3.0.AppImage
App farà una serie di operazioni indicando dove dobbiamo collegarci, molto importante non chiudere il terminale altrimenti il server verrà terminato:
Ora colleghiamoci al IP e porta indicato e creiamo un utente.
A questo punto rientrando saremo sulla dashboard generale:
Qui potremmo:
Per prima cosa però scarichiamo i plugin che verranno integrati negli agent.
Accedendo al menu plugin vediamo, appunto, che ci proporrà una serie di plugin, possiamo vedere che possiamo scaricare uno o più di essi che poi saranno inseriti nel finto malware.
Quasi tutti sono Safe, 2 degli altri sono usafe vuol dire che potrebbero compromettere irrimediabilmente
Quindi è molto importante sapere le conseguenze che può scatenare l’agente se eseguito in ambienti di produzione.
Scarichiamo i plugins sicuri, ma visto che nel nostro ambiente di test vogliamo fare il massimo dei danni, includiamo anche l’exploit Zerologon.
Ora ci spostiamo sulla configurazione
Nella sezione propagazione ci sono tutte le configurazioni, payloads da usare, reti consentite ecc.
Ora selezioniamo tutti gli Exploiters:
Nella sezione analisi di rete inseriamo tutte le subnet in cui è “autorizzato” ad accedere:
Possiamo configurare anche altre opzioni perchè l’agent capisca che il sistema è acceso e vada a recuperare alcuni banner.
Nella parte credenziali possiamo, appunto inserire delle credenziali che potrà usare.
Dai test che ho fatto sembrerebbe che non utilizzi nessuna sorta di dizionario durante la fase di ricognizione.
Quello che manca è la possibilità di poter caricare un file, in quanto è concesso inserirne solo una alla volta.
Oltre ai moduli di ricognizione ed exploit e collegamento con il C2, possiede un modulo per emulare un ransomware e la cifratura dei dati.
E’ necessario però indicare quale sarà la directory come nell’esempio, poi creare dei documenti di esempio (txt) in tutti i sistemi.
Credential Collector
Questa parte riguarda il recupero delle credenziali salvate da Chrome, token NTLM e credenziali SSH.
In questo punto possiamo fare in modo di impostare una firma specifica, i sistemi di rilevamento troveranno una specifica minaccia già rilevata.
Polimorfismo
Questa configurazione emulerà il polimorfismo per far in modo che tutti gli agent che si replicheranno verranno creati con firme diverse, quindi riconosciuti diversamente dai sistemi di rilevamento firme.
Avanzate
Ora è tutto pronto per salvare la configurazione, il software ci avvertirà solo che abbiamo selezionato una configurazione che potrà “rompere” i sistemi.
Nel nostro laboratorio preparato sarà composto da:
Ora passiamo alla fase di distribuzione accedendo a Run Monkey
Con l’opzione “From Island”, le nostre scimmie proveranno a muoversi nei sistemi direttamente dalla piattaforma. Questo approccio simula un dispositivo infetto che si collega alla rete aziendale.
In modalità manuale ci viene fornito un comando per lanciare attacco da un punto ben definito. Questo altro approccio invece potrebbe corrispondere ad uno script avviato aprendo un allegato da una mail di phishing oppure da un eseguibile camuffato o inserendo una chiave USB compromessa.
Avevamo già fatto già degli esempi su come camuffare e distribuire del contenuto malevolo in file word oppure eseguibili autentici “modificati”.
Ora la pagina ci chiede il sistema di partenza. Inizieremo da un client con diritti limitati (User) in un dominio Microsoft.
Una caratteristica di questo tool è che è compatibile solo con sistemi a x64 bit. Come vedremo dopo i sistemi a 32bit verranno segnati “exploitati”, ma l’agente non verrà avviato all’interno.
Ora è tutto pronto, abbiamo acceso una serie di macchine per studiare la compromissione. Alcune non sono aggiornate mentre altre utilizzano password di default.
Abbiamo anche creato in alcune macchine la cartella infection-monkey, così da verificare che l’agent una volta compromessa la macchina, esegua la cifratura dei dati.
Ci colleghiamo alla macchina, un W10 pro (CLIENT.offsec.local) non molto aggiornato: possiamo vedere che l’utente ha i privilegi minimi e niente altro.
Quindi avviamo lo script tramite IDE di powershell:
Vediamo subito che il C2 ha subito avviato e comunicato con la vittima, se notate ha un simbolo di una chiave, vuol dire che sta ancora completando la fase di ricognizione ed exploit.
Da notare le frecce e la direzione:
Possiamo vedere anche che in ogni agent ci sarà il flag verde quando il C2 sta comunicando attivamente con l’agent stesso in esecuzione.
E’ possibile che la macchina sia “attaccata” da più agent compromessi successivamente.
Man mano che aspettiamo vediamo l’evoluzione dell’attacco…
E per completare vediamo tutta la propagazione. Selezionando su ciascun agent a sinistra vediamo la timeline dell’exploit.
Possiamo vedere che dal CLIENT del sistema di partenza infettato, il malware si è spostato in 4 sistemi: tutte le macchine in dominio e linux con password debole di cui una era un un’altra rete non accessibile inizialmente alla minaccia (freccia blu).
Degli altri 2 uno è totalmente fuori dominio e completamente aggiornato ed infatti non è stato compromesso (ragione per cui utilizzare sistemi sganciati dal dominio è una buona best practice per evitare i movimenti laterali). l’ultimo con le frecce rosse da 2 sistemi, è stato compromesso ma essendo a 32 bit non è stato avviato l’agent per comunicare con il C2 (questo è solo un limite tecnico del tool).
Selezionando Monkey Events vediamo tutte le attività fatte da un agente verso una vittima, se l’attività è andata a buon fine e la tipologia di attività.
Nella tipologia è fornito anche il codice del MITRE per identificare esattamente la tecnica e tattica usata.
Ora, quando si visualizzano tutte le spunte a destra, l’attacco è concluso. Non ci resta che analizzare i risultati.
La pagina dei risultati ci fornisce 2 macro tipologie di risultati, quella legata alla sicurezza e quella legata all’attività di ransom.
Security report
In questo report iniziamo a vedere quale agente è stato manualmente installato, nel nostro caso 1, ma potrebbero essere stati di più se avessimo usato la propagazione dalla C2.
Inoltre troviamo gli utenti ed hash utili per eseguire attività di brute forcing
Proseguiamo con i suggerimenti dati per le macchine compromesse:
Per esempio buona idea è quella di alzare la complessità password, distribuire gli aggiornamenti, eseguire delle policy lato comunicazione nelle micro segmentazione di rete, ma ce ne sono molte altre selezionando i dettagli per ciascuna macchina.
Infine il report sulle porte aperte individuate, le macchine compromesse (e da chi) e le credenziali rubate (viene usato mimikatz).
Ultimo report, ma non meno importante, è quello legato all’attività di ransomware.
Qui abbiamo ancora indicazione da dove è partita la minaccia, il movimento laterale verso altri dispositivi:
E tutta la lista dei file cifrati:
Andando a verificare sugli endpoint verifichiamo effettivamente che sono stati compromessi:
Troviamo anche un simpatico README con la spiegazione, che ovviamente già sappiamo.
Se i dispositivi inviano gli eventi ad un sistema di audit o un SIEM come descritto precedentemente possiamo rilevare velocemente gli eventi di questo attacco.
Nel nostro caso abbiamo installato al volo Wazuh, un XDR dai superpoteri e oltretutto open source, e distribuito il suo agent su alcuni client prima di lanciare l’attacco per raccogliere gli eventi.
Questo strumento oltre a raccogliere dati da più fonti (es. agent, api, syslog, json file) e dispone già di default di molti decoder ed regole per adattarsi alle varie sorgenti dati, può anche costruire dashboard personalizzate con una moltitudine di widget in base a specifici eventi ed infine è anche un XDR. E’ possibile configurare e personalizzare una risposta (come isolamento tramite regole firewall o custom script) in base a specifici eventi.
Possiede anche un modulo di vulnerability detection, file integrity monitor, malware detection e altre funzionalità visibili qui sotto…
Oltretutto dispone di un agent già of the box per la maggior parte dei sistemi operativi. Una volta installato, Wazuh è già autonomo e raccoglie e cataloga i dati dai client utilizzando anche la matrice MITRE ATT&CK.
Qui per maggiori info:
https://github.com/wazuh/wazuh
Non mi dilungo molto, in quanto non è il tema di questo articolo, ma vediamo i risultati dopo aver lanciato l’attacco.
Infatti appena è stato lanciato l’attacco, tramite il modulo Threat Hunting ha iniziato a riportarci delle anomalie, riportando 207 possibili autenticazioni fallite e a categorizzare a destra i vari eventi in base al MITRE ATT&CKS.
Tra gli eventi possiamo riconoscere dei log riconducibili all’attività di Infection Monkey, come connessioni RDP, login falliti (brute forcing), autenticazione tramite pass-the-hash e creazione e modifica di account.
In questo articolo ho parlato di un’altra tipologia di tool per testare la sicurezza informatica nelle infrastrutture, utilizzando un approccio diverso dalla classica scansione di vulnerabilità o analisi di patch mancanti sui sistemi.
Ma soprattutto di un software open source gratuito.
Come sempre consiglio di prestare attenzione all’utilizzo di questi software e di avere le solite accortezze in quanto potrebbe causare danni.
Manuel Roccon
Copyright @ 2003 – 2024 RED HOT CYBER
PIVA 16821691009