GraphStrike

Blog di rilascio: GraphStrike: Utilizzare Microsoft Graph API per far scomparire il traffico Beacon
Blog dello sviluppatore: GraphStrike: Anatomia dello sviluppo di strumenti offensivi

Introduzione

GraphStrike è una suite di strumenti che consente all'HTTPS Beacon di Cobalt Strike di utilizzare Microsoft Graph API per le comunicazioni C2. Tutto il traffico Beacon verrà trasmesso tramite due file creati nel sito SharePoint dell'attaccante, e tutte le comunicazioni dal Beacon instraderanno verso https://graph.microsoft.com:

GraphStrike include un provisioner per creare le risorse Azure necessarie per Cobalt Strike HTTPS tramite Graph API:

GraphStrike non crea asset a pagamento in Azure, quindi l'utilizzo di GraphStrike o del suo provisioner non comporta costi aggiuntivi.

Perché?

Sono state rilasciate informazioni di threat intelligence riguardanti diversi APT che sfruttano Microsoft Graph API e altri servizi Microsoft per campagne offensive:

1. BLUELIGHT - APT37/InkySquid/ScarCruft
2. Graphite - APT28/Fancy Bear
3. Graphican - APT15/Nickel/The Flea
4. SiestaGraph - UNKNOWN

Gli attori delle minacce continuano a utilizzare servizi legittimi per scopi illegittimi. Utilizzare un dominio di alta reputazione come graph.microsoft.com per le comunicazioni C2 è estremamente efficace e desiderabile, ma spesso complicato e proibitivo dal punto di vista del tempo e dello sforzo. La maggior parte dei framework C2 non supporta metodi per recuperare o ruotare i token di accesso, il che li rende incapaci di utilizzare Graph API. Questo può rendere difficile per i red team replicare queste tecniche e priva i difensori dell'opportunità di osservare e sviluppare firme per questo tipo di attività. GraphStrike cerca di alleviare questo onere e fornire un processo affidabile e ripetibile per sfruttare Microsoft Graph API, mantenendo al contempo la familiarità e l'affidabilità dell'esperienza utente di Cobalt Strike.

È un External C2?

Tecnicamente no. Avendo già costruito in precedenza un vero External C2 utilizzando Graph API (che inviava il traffico Beacon come messaggi di Microsoft Teams), l'onere di dover sviluppare, mantenere e integrare un implant personalizzato che soddisfi le specifiche di External C2 e faccia il lavoro è fin troppo familiare. GraphStrike invece sfrutta un User Defined Reflective Loader (UDRL) open source chiamato AceLdr di Kyle Avery (adattato come 'GraphLdr' in questo progetto) per agganciare le chiamate alla libreria WinINet che Beacon normalmente effettua e manipolarle secondo necessità per utilizzare Graph API. Non c'è un implant personalizzato o un processo aggiuntivo di cui parlare, solo il processo Beacon con un paio di API Windows agganciate. Sul lato server c'è un programma Python3 che traduce il traffico del Cobalt Strike Team Server in traffico Graph API e viceversa.

Caratteristiche

GraphStrike supporta quasi tutte le normali attività di Cobalt Strike, tra cui:

1. Uso di Proxychains tramite un proxy SOCKS di Cobalt Strike (anche se è molto lento...)
2. Caricamento/Scaricamento di file di grandi dimensioni
3. BOFs, execute-assembly, ecc.

Questo include anche l'integrazione in GraphStrike dei comandi sleep, exit e remove per far corrispondere i tempi di sleep del server GraphStrike con Beacon e cancellare i file in SharePoint quando un Beacon viene chiuso o rimosso.

GraphStrike incorpora inoltre tutte le funzionalità e caratteristiche dell'AceLdr originale, con alcune API aggiuntive create per utilizzare anche lo spoofing dello stack di chiamate.

Requisiti

GraphStrike richiede quanto segue prima di iniziare:

1. Un tenant di Microsoft Azure con licenza SharePoint/O365 assegnata e sito creato. Il sito predefinito va bene.
2. Un account Azure con permessi di Amministratore Globale in quel tenant.
3. Python 3.8-3.11^{Nota #4} (e dipendenze aggiuntive che verranno installate durante il processo di installazione)

Regole del firewall

1. Assicurarsi che ogni macchina su cui gira il client Cobalt Strike sia in grado di connettersi alla macchina del team server di Cobalt Strike sulle porte 443 e 5000.

Configurazione

Prendere nota di quanto segue prima di procedere con il processo di configurazione:

1. Alcuni componenti utilizzano percorsi relativi per localizzare altre risorse. Si prega di cambiare directory come indicato di seguito.
2. Il profilo di Cobalt Strike può essere modificato SOLO PRIMA del passaggio 5 nel processo di configurazione seguente^{Nota #1}.

Sulla macchina che eseguirà il team server di Cobalt Strike:

1. Clonare il repository.
2. Dalla directory del repository, eseguire sudo setup/install_dependencies.sh per installare le dipendenze di sistema richieste.
3. Eseguire python3 -m venv virtual e poi source virtual/bin/activate per creare e quindi entrare nell'ambiente virtuale.
4. Spostarsi nella directory setup ed eseguire pip3 install -r requirements.txt.
5. Eseguire ./provisioner.py new e completare il processo di configurazione.
6. Avviare il team server di Cobalt Strike utilizzando graphstrike.profile come profilo C2 malleabile.
7. Avviare un'istanza del client Cobalt Strike (può essere fatto su una macchina client, o sulla macchina TS e terminarlo dopo) e creare un listener HTTPS di Cobalt Strike sulla porta 443 con graph.microsoft.com come campi HTTPS Hosts e HTTPS Host(Stager).
8. Tornare alla directory principale del repository ed eseguire il server GraphStrike usando ./GraphStrike.py.

Su TUTTE le macchine che eseguiranno il client Cobalt Strike:

9. Copiare la directory GraphStrike/client dalla macchina TS alla macchina client. Questo deve essere fatto solo DOPO aver completato il provisioning!
10. Importare GraphStrike.cna in Cobalt Strike utilizzando il Gestore Script (Script Manager).
11. Creare payload di Cobalt Strike, che siano raw shellcode o artefatti compilati usando Artifact Kit o un framework alternativo di generazione payload. Gli utenti di Artifact Kit vedano sotto!
12. Profitto.

Utenti di Artifact Kit

A causa delle dimensioni di GraphLdr, gli utenti di Artifact Kit dovranno ricompilarlo con opzioni specifiche affinché GraphStrike sia compatibile con i payload generati da Artifact Kit. Nello specifico, i campi 'Stage Size' e 'RDLL Size' devono essere specificati per utilizzare la dimensione RDLL di 100K. Di seguito vengono forniti due esempi di sintassi funzionante:

./build.sh pipe VirtualAlloc 505029 100 false false none /opt/cobaltstrike/artifacts
./build.sh peek HeapAlloc 492376 100 false true indirect /opt/cobaltstrike/artifacts

Pulizia

Sulla macchina che esegue il TS + GraphStrike Server:

1. Fermare il server GraphStrike
2. Tornare alla directory setup ed eseguire ./provisioner.py delete per rimuovere le risorse Azure create.

Note

In nessun ordine particolare, ecco alcuni suggerimenti e osservazioni per aiutare a utilizzare GraphStrike al massimo del suo potenziale.

1. Il profilo incluso con GraphStrike è molto minimalista; questo è voluto. Modificare uno qualsiasi dei campi ESISTENTI nel profilo potrebbe/spezzera GraphStrike! Dovresti essere in grado di aggiungere ulteriore linguaggio/comportamento del profilo in altre sezioni non già definite (ad esempio personalizzare il nome della pipe, il comportamento di injection, ecc.). Qualsiasi modifica al profilo DEVE essere effettuata prima di eseguire il provisioner!
2. L'applicazione Azure utilizzata per le comunicazioni C2 sia da Beacon che dal server GraphStrike ha un limite di 1200 richieste/min. Il server GraphStrike utilizza 120/min come base per funzionare. Minore è il tempo di sleep di Beacon, maggiori sono le richieste che effettuerà; inoltre, ogni Beacon creato utilizzando GraphStrike consumerà parte di quel limite di 1200/min. Interagire in modo interattivo con un Beacon è fattibile, ma probabilmente non con più di un Beacon. Se incontri problemi di limitazione delle richieste, considera di aumentare il tempo di sleep dei tuoi beacon, diminuire il numero di beacon in esecuzione, o entrambi.
3. Sebbene il tempo di sleep del server GraphStrike cambi per ogni Beacon in base ai comandi sleep emessi, ciò significa in realtà che il server GraphStrike dormirà per il tempo specificato prima di effettuare il check-in con il TS per ottenere le task. NON significa che Beacon riceverà ed elaborerà immediatamente le task non appena vengono recuperate dal TS dal server GraphStrike. Beacon dormirà per il tempo specificato prima di contattare SharePoint per recuperare le task del TS, ma a causa della natura asincrona del C2, questo non sarà sincronizzato con il momento in cui il server GraphStrike le carica.
4. Se un Beacon muore senza essere uscito correttamente (AV, crash, ecc.), il Beacon apparirà ancora in contatto con il TS, e il fatto che sia morto diventerà evidente solo quando gli viene impartito un comando. Ciò che sta effettivamente connettendo al TS / facendo sembrare che il Beacon stia ancora chiamando è il server GraphStrike, quindi questo non riflette realmente lo stato di salute di un Beacon. Tale è la natura del C2 asincrono.
5. GraphStrike funziona su un modello 1:1:1; 1 sito SharePoint è associato a 1 server GraphStrike che è associato a 1 TS. Avrai problemi se provi a connettere due server TS/GraphStrike a un singolo sito SharePoint. Puoi ovviamente connettere più client Cobalt Strike a un singolo server TS / GraphStrike, ogni client necessita solo di una copia della cartella 'client' prodotta dal processo di provisioning.
6. Esiste un problema noto riguardante la compatibilità dell'utilità az utilizzata da GraphStrike con Python 3.12.
7. Ti consiglio di rivedere la documentazione di AceLdr, poiché tutte le note di quel progetto valgono anche qui.

Limitazioni

Le seguenti limitazioni esistono in GraphStrike:

1. Solo beacon x64 sono supportati.
2. Beacon staged non sono supportati.
3. GraphStrike è compatibile solo con la libreria WinINet; la nuova opzione della libreria WinHTTP per i Beacon non è supportata.
4. Nessun supporto per l'emissione di un comando sleep tramite il menu contestuale di Beacon. Utilizzare invece l'opzione da riga di comando per far dormire i beacon.
5. GraphStrike è supportato solo su istanze Linux di Cobalt Strike. Il supporto Windows è certamente implementabile, e si tratta solo di modificare alcuni percorsi all'interno dei file Python e dello script Aggressor.

Crediti

GraphStrike non sarebbe possibile senza i contributi delle seguenti persone:

1. Kyle Avery per AceLdr
2. Didier Stevens per cs-decrypt-metadata.py
3. Mike Saunders, Corey Overstreet, Chris Truncer e Justin Palk del team Red Siege che hanno gentilmente testato in beta GraphStrike e identificato diversi problemi che sono stati risolti prima del rilascio.