nvisosecurity/pycobalthoundpyCobaltHound è un'estensione di script Aggressor per Cobalt Strike che mira a fornire una profonda integrazione tra Cobalt Strike e Bloodhound.
pyCobaltHound è un'estensione per script Aggressor per Cobalt Strike che mira a fornire una profonda integrazione tra Cobalt Strike e BloodHound.
pyCobaltHound si impegna ad assistere gli operatori red team:
BloodHound per scoprire percorsi di escalation aperti da credenziali appena raccolte.Per fare ciò, pyCobaltHound utilizza un insieme di query integrate. Gli operatori possono anche aggiungere/rimuovere le proprie query per ottimizzare le capacità di monitoraggio di pyCobaltHound. Questo offre la flessibilità di adattare al volo durante gli impegni per tenere conto di obiettivi specifici dell'impegno (utenti, host, ecc.).
pyCobaltHoundPer installare pyCobaltHound clona questo repository. Non dimenticare di clonare anche il sottomodulo incluso!
Puoi usare il seguente comando:
git clone https://github.com/NVISOsecurity/pyCobaltHound.git --recurse-submodulesAssicurati che le seguenti dipendenze siano installate correttamente:
PyCobalt è un'API Python per Cobalt Strike. Espone molte funzioni di Aggressor da utilizzare direttamente da Python.
Assicurati di avere Python3+ installato. Mentre PyCobalt potrebbe funzionare anche su macOS e Windows, lo abbiamo testato principalmente su Linux.
Ci sono due modi per usare la libreria Python PyCobalt:
pyCobaltHound adotta questo approccio, impostando il percorso di ricerca all'interno del programma Python usando la variabile sys.path.PyCobalt. Per farlo, esegui python3 setup.py install. Dovrai modificare pycobalthound.py per assicurarti che usi la libreria installata invece di quella nel repository incluso.PyCobalt venga mantenuto in futuro. In effetti, l'ultimo aggiornamento al progetto è stato per incorporare le modifiche apportate in Cobalt Strike 4.2. Tuttavia, poiché pyCobaltHound utilizza solo funzioni base di Aggressor per interfacciarsi con Cobalt Strike e il suo operatore, questo non è un grosso problema per pyCobaltHound.PyCobalt usato in questo progetto è un fork realizzato da noi. Tuttavia non controlliamo il repository PyCobalt.PyCobalt include alcuni comandi della Script Console per gestire gli script Python in esecuzione. Quando ricarichi il tuo script Aggressor dovresti prima fermare esplicitamente gli script Python. Altrimenti rimarranno in esecuzione per sempre senza fare nulla. Durante lo sviluppo di pyCobaltHound abbiamo notato che questo può anche portare a comportamenti indefiniti.
Il ricaricamento di pyCobaltHound può essere fatto come segue:
aggressor> python-stop-all`
[pycobalt] Asking script to stop: /root/pycobalthound/pycobalthound.py
[pycobalt] Script process exited: /root/pycobalthound/pycobalthound.py
aggressor> reload example.cna`
[pycobalt] Executing script /root/pycobalthound/pycobalthound.py
Per un corretto funzionamento di PyCobalt, puoi chiamare PyCobalt solo in uno script Aggressor. Tienilo a mente se vuoi usare pyCobaltHound insieme ad altri script Aggressor che usano PyCobalt. Il nostro approccio è avere uno script Aggressor con chiamate a python() e include() per ogni strumento basato su PyCobalt.
notify2 è – o era – un pacchetto per mostrare notifiche desktop su Linux. Come vedremo più avanti, pyCobaltHound supporta alcuni modi per notificare l'operatore. notify2 viene usato su Linux per inviare notifiche al demone di notifica tramite D-Bus.
Per abilitarlo, notify2 deve essere installato usando:
pip install notify2
Usare pyCobaltHound in Cobalt Strike è semplice come importare lo script Aggressor pycobalthound.cna nel tuo client. Una volta fatto, dovresti vedere un menu pyCobaltHound apparire nella barra dei menu di Cobalt Strike.
L'obiettivo iniziale di pyCobaltHound era monitorare la cache delle credenziali di Cobalt Strike (View > Credentials) per nuove voci. Lo fa reagendo all'evento on_credentials che Cobalt Strike attiva quando vengono apportate modifiche al credential store.
Quando questo evento viene attivato, pyCobaltHound:
Cobalt StrikeBloodHoundBloodHound per ogni nuova entità utilizzando sia query integrate sia personalizzate.Poiché tutto ciò avviene in modo asincrono rispetto al client principale di Cobalt Strike, questo processo non dovrebbe bloccare la tua interfaccia utente, permettendoti di continuare a lavorare mentre pyCobaltHound indaga in background.
pyCobaltHound utilizza cache separate per ogni teamserver per prevenire problemi quando si usano più teamserver.
A volte ci sono situazioni in cui vorresti investigare nuovamente utenti specifici (o l'intero credential store). Potrebbe essere il caso quando hai caricato nuovi dati nel database di BloodHound.
Poiché pyCobaltHound dovrebbe aver già investigato (e quindi messo in cache) tutte le entità nel tuo credential store, non le valuterà rispetto a questi nuovi dati senza un intervento dell'operatore.
Sono disponibili due metodi per controllare quali entità sono in cache.
Nei casi in cui desideri rimuovere una o più entità specifiche dalla cache, puoi farlo nel visualizzatore delle credenziali (View > Credentials). Basta selezionare i target e cliccare sull'opzione remove from cache sotto la voce di menu pyCobaltHound.
Nei casi in cui desideri rimuovere tutte le entità dalla cache, puoi farlo nel menu principale di pyCobaltHound (Cobalt Strike > pyCobaltHound > Wipe cache). Questo è molto utile quando vuoi rivalutare l'intero credential store.
Dopo aver rimosso i target dalla cache, puoi richiedere manualmente a pyCobaltHound di reinvestigare il contenuto del credential store. Questo segue esattamente lo stesso processo di cui sopra.
pyCobaltHound contiene funzionalità per interagire con sessioni beacon esistenti. Si trovano nel menu contestuale del beacon. Nota che questi comandi possono essere eseguiti su un singolo beacon o su una selezione di beacon.
Questa funzionalità è particolarmente utile quando si ha a che fare con utenti e computer le cui credenziali non sono state ancora compromise, ma che sono effettivamente sotto il nostro controllo (ad esempio perché abbiamo un beacon in esecuzione con il loro token di sessione).
La funzionalità Mark as owned (pyCobaltHound > Mark as owned) può essere utilizzata per contrassegnare come owned un beacon (o una selezione di beacon) nel database di BloodHound.
Questa finestra di dialogo chiederà all'operatore le seguenti informazioni:
pyCobaltHound contrassegnerà i computer come owned solo se la sessione beacon è in esecuzione come amministratore locale, SYSTEM o una sessione ad alta integrità come un altro utente.La funzionalità Investigate (pyCobaltHound > Investigate) può essere utilizzata per investigare gli utenti e gli host associati a un beacon (o a una selezione di beacon).
Questa finestra di dialogo chiederà all'operatore le seguenti informazioni:
pyCobaltHound investigherà i computer solo se la sessione beacon è in esecuzione come amministratore locale, SYSTEM o una sessione ad alta integrità come un altro utente.pyCobaltHound investigherà tutte le entità senza controllare i livelli di integrità.pyCobaltHound contiene funzionalità per investigare liberamente le entità. Si trovano nel menu principale (Cobalt Strike > pyCobaltHound > Investigate).
Questa funzionalità è particolarmente utile quando si ha a che fare con utenti e computer le cui credenziali non sono state compromesse e non sono sotto il nostro controllo.
Questa finestra di dialogo chiederà all'operatore le seguenti informazioni:
Il menu delle impostazioni di pyCobaltHound si trova in Cobalt Strike > pyCobaltHound > Settings.
pyCobaltHound salverà le tue impostazioni su disco. Ogni volta che pyCobaltHound viene ricaricato, controllerà l'esistenza di un file di impostazioni e caricherà le impostazioni salvate se ne trova uno.
pyCobaltHound salva un file di impostazioni per ogni teamserver, quindi è possibile avere impostazioni diverse su teamserver diversi.
Per autenticarsi al database di BloodHound, pyCobaltHound avrà bisogno delle seguenti informazioni:
Nota: se scegli di salvare in modo persistente le tue impostazioni (per preservarle tra riavvii del client/host), pyCobaltHound deserializzerà e memorizzerà queste credenziali su disco.
Come discusso in precedenza, pyCobaltHound utilizza la cache per assicurarsi di non eseguire lavoro non necessario. Questa cache può essere disabilitata nelle impostazioni. È utile principalmente quando si sviluppano nuove query per non dover gestire/pulire costantemente la cache.
pyCobaltHound supporta alcuni metodi diversi per notificare l'operatore una volta identificata un'entità di interesse. È possibile disabilitare queste notifiche.
Per impostazione predefinita, pyCobaltHound notificherà l'operatore utilizzando la messagebox predefinita di Aggressor. Questa opzione può influenzare il flusso di lavoro dell'operatore. È comunque il metodo predefinito poiché è supportato su ogni piattaforma in cui puoi eseguire un client Cobalt Strike.
pyCobaltHound supporta anche la visualizzazione di notifiche desktop su Linux. Questa è la nostra opzione preferita poiché non interrompe il flusso di lavoro dell'operatore.
Durante alcuni dei suoi flussi di lavoro, pyCobaltHound genererà un report HTML. Questa scelta progettuale è stata fatta per evitare di inondare l'operatore con notifiche enormi nel caso in cui vengano investigate molte entità. Questi report verranno generati nella cartella reports. È possibile disabilitare la generazione dei report.
Per impostazione predefinita, pyCobaltHound sincronizzerà le query tra i teamserver utilizzando un file centrale per tutte le impostazioni relative alle query. Ciò significa che le query abilitate, aggiunte o eliminate su un teamserver verranno anche abilitate, aggiunte o eliminate per le query effettuate da altri teamserver. Questa è principalmente un'opzione di comodità e può essere disabilitata, il che è utile nei casi in cui stai eseguendo query specifiche per un impegno che non si applicano a tutti i teamserver a cui sei connesso.
Quando la sincronizzazione delle query è disabilitata, pyCobaltHound controllerà l'esistenza di file di query unici. Se esistono, li caricherà e utilizzerà queste query durante i suoi flussi di lavoro. Se i file non esistono, li creerà e caricherà. Questa impostazione persisterà attraverso i ricaricamenti.
Quando la sincronizzazione delle query è abilitata, pyCobaltHound controllerà l'esistenza di file di query unici. Se esistono, all'operatore verrà chiesto di scegliere.
L'operatore ha le seguenti scelte:
pyCobaltHound rimuoverà semplicemente i file di query unici. Tutte le query personalizzate andranno perse.pyCobaltHound tenterà di unire i file di query unici nei file di query generali. Prima di unire una query, controllerà se non esiste già una query con lo stesso nome o la stessa istruzione Cypher nel file generale. Se si verificano conflitti di merge, all'operatore verrà chiesto se desidera mantenere le query non unite. Verranno salvate in un file separato. I file di query unici verranno quindi rimossi.pyCobaltHound lascerà semplicemente i file di query unici. Tutte le query personalizzate verranno preservate e i file verranno caricati di nuovo se la sincronizzazione delle query viene disabilitata di nuovo.pyCobaltHound attualmente supporta le seguenti query integrate:
La gestione delle varie query utilizzate da pyCobaltHound può essere effettuata tramite il menu principale (Cobalt Strike > pyCobaltHound > Queries).
La finestra di dialogo Update queries consente agli operatori di abilitare/disabilitare query specifiche. Quando si utilizza questa finestra, all'operatore verrà prima chiesto quale tipo di query desidera aggiornare. Questo viene fatto per rendere/caricare dinamicamente le query corrette durante questo flusso di lavoro.
Dopo aver risposto alla prima finestra di dialogo, all'operatore verrà presentato un elenco di tutte le query disponibili di quel tipo. Qui potrà scegliere quali query abilitare/disabilitare.
L'opzione del tipo di query è una soluzione poco elegante per passare il tipo di query alla funzione successiva nel flusso di lavoro e non è di competenza dell'operatore.
La funzionalità Add query consente agli operatori di aggiungere/rimuovere le proprie query per ottimizzare le capacità di investigazione di pyCobaltHound. Questo offre la flessibilità di adattare pyCobaltHound al volo durante gli impegni per tenere conto di obiettivi specifici dell'impegno (utenti, host, ecc.).
Questa finestra di dialogo chiederà all'operatore le seguenti informazioni:
pyCobaltHound.pyCobaltHound deve eseguire. Gli operatori sono abbastanza liberi di definire le loro query. Gli unici requisiti sono i seguenti:
pyCobaltHound genera dinamicamente la seguente stringa Cypher basata sui nomi delle entità che sta investigando:
WITH [nomi account qui] AS samAccountNames UNWIND samAccountNames AS names.MATCH (x) WHERE x.name STARTS WITH names(x:User)) a seconda del tipo di query che stai aggiungendo.pyCobaltHound si aspetta che la query restituisca un insieme distinto di nomi utente.
RETURN DISTINCT (x.name)pyCobaltHound usa per la query personalizzata. Verrà utilizzato nelle notifiche e nei report durante i flussi di lavoro di pyCobaltHound.
pyCobaltHound sostituirà con la quantità di risultati per questa query.La finestra di dialogo Delete query consente agli operatori di rimuovere query personalizzate specifiche da pyCobaltHound. Quando si utilizza questa finestra, all'operatore verrà prima chiesto quale tipo di query desidera rimuovere. Questo viene fatto per rendere/caricare dinamicamente le query corrette durante questo flusso di lavoro.
Dopo aver risposto alla prima finestra di dialogo, all'operatore verrà presentato un elenco di tutte le query disponibili di quel tipo. Qui potrà scegliere quali query rimuovere.
L'opzione del tipo di query è una soluzione poco elegante per passare il tipo di query alla funzione successiva nel flusso di lavoro e non è di competenza dell'operatore.
pyCobaltHound utilizza/si ispira a quanto segue: