jymcheong/autottpTattiche, tecniche e procedure automatizzate
Tattiche, Tecniche e Procedure automatizzate. Rieseguire manualmente sequenze complesse per test di regressione, valutazioni di prodotto, generare dati per ricercatori e così via può essere noioso. Ho giocato con l'idea di rendere più facile scrivere script per Empire (o qualsiasi framework/prodotto/toolkit che fornisca API come Metasploit (RPC), Cobalt-Strike e così via) usando un IDE come Visual Studio Code (o equivalente). Così ho iniziato a progettare AutoTTP. È ancora un lavoro in corso. Testato con Empire 2.2.
Youtube - Panoramica e Approfondimento Tecniche Selezionate
Nel mio caso, le tattiche sono organizzate secondo il mio modello di ciclo di vita dell'attacco. Esistono altri modelli come il Kill-Chain di Lockheed Martin, il Ciclo di vita dell'attacco di Mandiant e ATT&CK di Mitre. Qualunque sia il modello, una "Tattica" raggruppa essenzialmente tecniche insieme, ad esempio l'esecuzione di codice/il caricamento di payload può essere ottenuto in molti modi:
Uso "Stage" per raggruppare "Tattiche" rilevanti insieme. Se guardi nell'albero delle sorgenti, la struttura delle cartelle riflette la colonna delle Tattiche della matrice. La matrice menziona anche i controlli corrispondenti per ogni tattica offensiva. Come sono nati questi stadi?
Il diagramma di Venn al centro del ciclo rosso proviene dal "Three Tenets for Secure Cyber-Physical System Design and Assessment" del Dartmouth College. Definisce le condizioni necessarie e sufficienti, o semplicemente i requisiti di qualsiasi attacco fisico/logico di successo. Ho aggiunto l'anello rosso (stadi) attorno al diagramma di Venn per illustrare i flussi offensivi tipici che portano infine all'impatto sulla Riservatezza, Integrità e Disponibilità delle Informazioni o sulla Sicurezza se riguarda il Cyber-Physical (pensa alle Infrastrutture Critiche di Informazione).
Un attaccante può iniziare dallo Stadio 1 e passare direttamente allo Stadio 4, ad esempio credenziali di amministratore predefinite su una pagina admin esposta pubblicamente. Non deve essere lineare (stadio 1->2->3->4). Dopo l'infiltrazione iniziale, potrebbe aver svolto prima un po' di raccolta di informazioni interne (recon) prima di elevare i privilegi sulla prima macchina e poi lanciare un comando remoto verso un'altra macchina bersaglio nella stessa rete. Per la successiva macchina vittima, si tratta di uno Stadio 2; consegna ed esecuzione riuscita del payload che permette all'attaccante di ottenere comando e controllo su un'altra macchina.
Il file a sinistra è uno script di procedura, quello a destra è uno script di tecnica. Nota che la scrittura di procedure non è piena di troppi dettagli specifici di Empire, molti dettagli sono incapsulati nello script di tecnica. La scrittura di procedure dovrebbe concentrarsi sulla sequenza di tecniche usando le informazioni degli asset, ad esempio hostname/ip, quale email inviare il payload, quale tecnica di payload e così via.
L'esempio di "is user admin?" consiste in realtà di alcuni passaggi poiché ci sono almeno 3 possibilità come descritto nei commenti dello script. Possiamo ovviamente creare "macro" personalizzate in Empire, Metasploit e quant'altro, ma diventa strettamente integrato all'interno di un particolare framework/prodotto. Vogliamo sfruttare gli strumenti disponibili e organizzare tecniche riutilizzabili in moduli in modo da mescolarle e abbinarle a livello Procedurale (cioè l'automazione).
Ho sfruttato i moduli ben strutturati in Empire per creare una classe python di auto-completamento. Invece di digitare il nome completo del modulo (ad esempio powershell/situational_awareness....), basta usare le capacità di autocompletamento dell'IDE.
Per ogni modulo, ci sono opzioni (per la maggior parte, se non tutti, dei framework). Il problema con Empire è che una volta eseguito in modalità rest/headless (ne parleremo più avanti), NON c'è una console per vedere le opzioni del modulo. Nella classe helper di autocompletamento, ogni modulo ha una sottoclasse options. Le opzioni obbligatorie sono prefissate come mostrato sopra, quindi possiamo popolare quelle opzioni con valori prima di chiamare un modulo.
La descrizione di ogni modulo è inclusa anche come parte della documentazione della classe python e verrà visualizzata al passaggio del mouse sulla classe. Poiché ci sono 276 moduli (a partire da Empire 2.1), questa classe helper necessiterà di un po' di scripting per essere creata! Fonte: https://gist.github.com/jymcheong/22c2eede978c8eb694945e3347c20c6b
Con IDE come Visual Studio Code (o equivalenti), si può sfruttare il debug per osservare le variabili, eseguire passo passo lo script o persino modificarlo durante il debug/step dopo aver conosciuto la struttura dei valori restituiti. La documentazione delle API REST è disponibile per Empire, ma a volte non conosciamo esattamente i valori restituiti finché non eseguiamo il modulo. Per questo motivo, si passa al prossimo argomento.
Per quanto vogliamo fare tutto nell'IDE, avrai bisogno di una console. L'autore di DeathStar lo sapeva già mentre sviluppava quello script che automatizza l'0wning del Domain Admin usando Empire. Ho preso in prestito la sua idea ma ho adattato il suo approccio al threading per Empire 2.1 poiché il suo approccio non funzionava con la funzione start restful api rifattorizzata. Fonte: https://gist.github.com/jymcheong/6a7668ecf73c29dd1d234d1c76ef438c
NON c'è bisogno di modificare lo script di Empire poiché Empire 2.2 ha il gestore del ciclo dei comandi mentre è in esecuzione in modalità REST. Tuttavia NON interagire con l'agente mentre si utilizza l'API per ottenere il risultato dell'agente.
Un ringraziamento a @radioboyQ per il suo EmpireAPIWrapper, @allfro e @Mikaayenson per pymetasploit, e a @byt3bl33d3r, MTFBWU.
