kevoreilly/capev2Configurazione del Malware ed Estrazione del Payload
Una sandbox viene utilizzata per eseguire file malevoli in un ambiente isolato, monitorando il loro comportamento dinamico e raccogliendo reperti forensi.
CAPE deriva da Cuckoo v1, che offre le seguenti capacità fondamentali sulla piattaforma Windows:
CAPE completa l'output tradizionale della sandbox di Cuckoo con diverse aggiunte chiave:
Esiste un'istanza dimostrativa gratuita online che chiunque può utilizzare:
https://capesandbox.com - Per l'attivazione dell'account contatta https://twitter.com/capesandbox
Cuckoo Sandbox è nato come progetto Google Summer of Code nel 2010 all'interno di The Honeynet Project. È stato originariamente progettato e sviluppato da Claudio Guarnieri, la prima beta è stata pubblicata nel 2011. Nel gennaio 2014 è stata rilasciata Cuckoo v1.0.
Il 2015 è stato un anno cruciale, con un fork significativo nella storia di Cuckoo. Lo sviluppo del monitoraggio originale e del metodo di API hooking è stato interrotto nel progetto principale di Cuckoo. È stato sostituito da un monitor alternativo che utilizza un formato di firma basato su restructuredText compilato tramite toolchain Linux, creato da Jurriaan Bremer.
Nello stesso periodo, un fork chiamato Cuckoo-modified è stato creato da Brad 'Spender' Spengler, continuando lo sviluppo del monitor originale con miglioramenti significativi, incluso il supporto a 64 bit e, cosa importante, l'introduzione del compilatore Microsoft Visual Studio.
Nello stesso anno è iniziato lo sviluppo di uno strumento dinamico da riga di comando per l'estrazione di configurazioni e payload chiamato CAPE presso Context Information Security da Kevin O'Reilly. Il nome è stato coniato come acronimo di 'Config And Payload Extraction' e la ricerca originale si è concentrata sull'uso degli API hook forniti dalla libreria Detours di Microsoft per catturare payload e configurazioni di malware decompressi. Tuttavia, è diventato evidente che i soli API hook non forniscono potenza e precisione sufficienti per consentire l'unpacking di payload o configurazioni da malware arbitrario.
Per questo motivo è iniziata la ricerca su un innovativo concetto di debugger per consentire al malware di essere controllato e strumentato con precisione, evitando l'uso delle interfacce di debug di Microsoft, per essere il più furtivo possibile. Questo debugger è stato integrato nello strumento proof-of-concept basato su Detours, combinato con API hook, ottenendo capacità molto potenti.
Quando il lavoro iniziale ha mostrato che sarebbe stato possibile sostituire Microsoft Detours con il motore di API hooking di Cuckoo-modified, è nata l'idea di CAPE Sandbox. Con l'aggiunta del debugger, dell'unpacking automatico, della classificazione basata su YARA e dell'estrazione integrata della configurazione, nel settembre 2016 al 44con, CAPE Sandbox è stata rilasciata pubblicamente per la prima volta: CAPE versione 1.
Nell'estate del 2018 il progetto ha avuto la fortuna di vedere l'inizio di enormi contributi da parte di Andriy 'doomedraven' Brukhovetskyy, un contributore di lunga data di Cuckoo. Nel 2019 ha iniziato l'immane compito di portare CAPE su Python 3 e nell'ottobre di quell'anno è stato rilasciato CAPEv2.
CAPE è stato continuamente sviluppato e migliorato per tenere il passo con i progressi sia del malware che delle capacità del sistema operativo. Nel 2021 è stata aggiunta la possibilità di programmare il debugger di CAPE durante la detonazione tramite scansioni YARA dinamiche, consentendo di creare bypass dinamici per le tecniche anti-sandbox. Windows 10 è diventato il sistema operativo predefinito, e altre aggiunte significative includono desktop interattivo, cattura di payload AMSI (Anti-Malware Scan Interface), 'syscall hooking' basato su Microsoft Nirvana e contromisure per syscall dirette/indirette basate sul debugger.
Il malware può essere classificato in CAPE tramite tre meccanismi:
L'analisi può essere effettuata utilizzando il framework di CAPE stesso, oppure sono supportati i seguenti framework: RATDecoders, DC3-MWCP, MalDuck, o MaCo
def extract_config(data): che verrà chiamato da cape_utils.py e 0 complicazioni.
CAPE sfrutta molte tecniche o comportamenti del malware per consentire la cattura del payload decompresso:
Questi comportamenti porteranno alla cattura dei payload iniettati, estratti o decompressi per ulteriori analisi. Inoltre CAPE crea automaticamente un dump del processo per ogni processo, o, nel caso di una DLL, l'immagine del modulo DLL in memoria. Questo è utile per campioni impacchettati con packer semplici, dove spesso il dump dell'immagine del modulo è completamente decompresso.
Oltre ai meccanismi di unpacking 'passivo' predefiniti di CAPE, è possibile abilitare l'unpacking 'attivo' che utilizza breakpoint per rilevare la scrittura in regioni di memoria appena allocate o protette, al fine di catturare i payload decompressi il prima possibile prima dell'esecuzione. Questa opzione è abilitata tramite una casella di spunta nell'invio web o specificando l'opzione unpacker=2 ed è disattivata per impostazione predefinita poiché potrebbe influire sulla qualità della detonazione.
CAPE può essere programmato tramite firma YARA per decomprimere packer specifici. Ad esempio, i packer di tipo UPX sono molto comuni e, sebbene in CAPE ciò porti alla cattura passiva dei payload decompressi, la cattura predefinita viene effettuata dopo che il payload decompresso ha iniziato l'esecuzione. Pertanto, rilevando dinamicamente i packer derivati da UPX tramite una firma YARA personalizzata e impostando un breakpoint sull'ultima istruzione del packer, è possibile catturare il payload al suo punto di ingresso originale (OEP) prima che inizi l'esecuzione.
L'opzione dump-on-api consente di scaricare un modulo quando chiama una specifica funzione API che può essere specificata nell'interfaccia web (ad esempio dump-on-api=DnsQuery_A).
Il debugger ha permesso a CAPE di continuare ad evolversi oltre le sue capacità originali, che ora includono bypass anti-evasione dinamici. Poiché il malware moderno cerca comunemente di eludere l'analisi all'interno delle sandbox, ad esempio utilizzando trappole temporali per la virtualizzazione o il rilevamento di API hook, CAPE consente di sviluppare contromisure dinamiche combinando azioni del debugger all'interno delle firme Yara per rilevare il malware evasivo mentre detona e manipolare il flusso di controllo per forzare il campione a detonare completamente o saltare azioni elusive.
L'accesso rapido al debugger è reso possibile con le opzioni di invio bp0 fino a bp3 che accettano valori RVA o VA per impostare breakpoint, dopodiché verrà emessa una breve traccia di istruzioni, governata dalle opzioni count e depth (ad esempio bp0=0x1234,depth=1,count=100).
Per impostare un breakpoint al punto di ingresso del modulo, si usa ep invece di un indirizzo (ad esempio bp0=ep). In alternativa, break-on-return permette di impostare un breakpoint sull'indirizzo di ritorno di un API hook (ad esempio break-on-return=NtGetContextThread). Un parametro opzionale base-on-api consente di impostare la base immagine per i breakpoint RVA tramite chiamata API (ad esempio base-on-api=NtReadFile,bp0=0x2345).
Le opzioni action0 - action3 consentono di eseguire azioni quando vengono raggiunti i breakpoint, come scaricare regioni di memoria (ad esempio action0=dumpebx) o cambiare il flusso di controllo dell'esecuzione (ad esempio action1=skip). La documentazione di CAPE contiene ulteriori esempi di tali azioni.
Il repository che contiene il codice per il monitor di CAPE è separato.
Esiste un repository comunitario di firme contenente diverse centinaia di firme sviluppate dalla comunità di CAPE. Tutte le nuove funzionalità della comunità dovrebbero essere inviate a quel repository. In seguito possono essere spostate nel core se gli sviluppatori sono in grado e disposti a mantenerle.
Si prega di contribuire a questo progetto aiutando a creare nuove firme, parser o bypass per ulteriori famiglie di malware. Ce ne sono molti in lavorazione attualmente, quindi tenete d'occhio questo spazio.
Un enorme ringraziamento a @D00m3dR4v3n per aver portato CAPE su Python 3 da solo.
Python3
Solo rooter dovrebbe essere eseguito come root, il resto come utente cape. Eseguire come root causerà problemi con i permessi.
conf!kvm-qemu.sh e cape2.sh DOVREBBERO ESSERE eseguiti da una sessione tmux per prevenire problemi al sistema operativo se la connessione ssh si interrompe.<username> con un pattern reale.<WOOT> all'interno!sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.logsudo ./cape2.sh base 2>&1 | tee cape.logconf.systemctl restart <nome_servizio>journalctl -u <nome_servizio>-h per il menu di aiuto. Eseguire il servizio in modalità debug (-d) può aiutare.-h, ma per favore controlla gli script per capire cosa fanno.git pullpython3 utils/community.py -waf vedi -h prima per assicurarti di capiregit add --all
git commit -m '[STASH]'
git pull --rebase origin master
# fix conflict (rebase) if needed
git reset HEAD~1
# make sure kevoreilly repo has been added as a remote (only needs to be done once)
git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git
# make sure all your changes are commited on the branch which you will be merging
git commit -a -m '<your commit message goes here>'
# fetch changes from kevoreilly repo
git fetch kevoreilly
# merge kevoreilly master branch into your current branch
git merge kevoreilly/master
# fix merge conflicts if needed
# push to your repo if desired
git push
Se usi CAPEv2 nel tuo lavoro, per favore citarlo come specificato nel menu GitHub 'Cite this repository'.
pefile poiché ognuno blocca la versione che vuole.
pefile poiché la hai già installata. Voilà, niente più dolore.