kevoreilly/capev2Malware-Konfiguration und Payload-Extraktion
Eine Sandbox wird verwendet, um bösartige Dateien in einer isolierten Umgebung auszuführen, während ihr dynamisches Verhalten instrumentiert und forensische Artefakte gesammelt werden.
CAPE wurde von Cuckoo v1 abgeleitet, das die folgenden Kernfunktionen auf der Windows-Plattform bietet:
CAPE ergänzt die traditionelle Sandbox-Ausgabe von Cuckoo um mehrere wichtige Ergänzungen:
Es gibt eine kostenlose Demonstrationsinstanz online, die jeder nutzen kann:
https://capesandbox.com - Für die Kontoaktivierung wende dich an https://twitter.com/capesandbox
Cuckoo Sandbox begann als Google Summer of Code-Projekt im Jahr 2010 innerhalb des Honeynet-Projekts. Es wurde ursprünglich von Claudio Guarnieri entworfen und entwickelt; die erste Betaversion wurde 2011 veröffentlicht. Im Januar 2014 wurde Cuckoo v1.0 veröffentlicht.
2015 war ein entscheidendes Jahr mit einer bedeutenden Abspaltung in der Geschichte von Cuckoo. Die Entwicklung des ursprünglichen Monitors und der API-Hooking-Methode wurde im Hauptprojekt von Cuckoo eingestellt. Er wurde durch einen alternativen Monitor ersetzt, der ein auf restructuredText basierendes Signaturformat verwendet, das über die Linux-Toolchain kompiliert wird, erstellt von Jurriaan Bremer.
Etwa zur gleichen Zeit wurde ein Fork namens Cuckoo-modified von Brad 'Spender' Spengler erstellt, der die Entwicklung des ursprünglichen Monitors mit bedeutenden Verbesserungen fortsetzte, darunter 64-Bit-Unterstützung und vor allem die Einführung des Microsoft Visual Studio Compilers.
Im selben Jahr begann bei Context Information Security die Entwicklung eines dynamischen Kommandozeilen-Tools zur Konfigurations- und Payload-Extraktion namens CAPE durch Kevin O'Reilly. Der Name wurde als Akronym für 'Config And Payload Extraction' geprägt und die ursprüngliche Forschung konzentrierte sich auf die Verwendung von API-Hooks, die von der Detours-Bibliothek von Microsoft bereitgestellt werden, um entpackte Malware-Payloads und Konfigurationen zu erfassen. Es zeigte sich jedoch, dass API-Hooks allein nicht genügend Leistung und Präzision bieten, um Payloads oder Konfigurationen aus beliebiger Malware zu entpacken.
Aus diesem Grund begann die Forschung an einem neuartigen Debugger-Konzept, um Malware präzise steuern und instrumentieren zu können, während die Verwendung von Microsoft-Debugging-Schnittstellen vermieden wird, um so versteckt wie möglich zu sein. Dieser Debugger wurde in das proof-of-concept Detours-basierte Kommandozeilen-Tool integriert, kombiniert mit API-Hooks, was zu sehr leistungsfähigen Fähigkeiten führte.
Als erste Arbeiten zeigten, dass es möglich wäre, Microsoft Detours durch die API-Hooking-Engine von Cuckoo-modified zu ersetzen, entstand die Idee für CAPE Sandbox. Mit der Hinzunahme des Debuggers, automatisiertem Entpacken, YARA-basierter Klassifizierung und integrierter Konfigurationsextraktion wurde CAPE Sandbox im September 2016 auf der 44con erstmals öffentlich veröffentlicht: CAPE Version 1.
Im Sommer 2018 hatte das Projekt das Glück, den Beginn enormer Beiträge von Andriy 'doomedraven' Brukhovetskyy zu erleben, einem langjährigen Cuckoo-Mitwirkenden. 2019 begann er mit der Mammutaufgabe, CAPE auf Python 3 zu portieren, und im Oktober desselben Jahres wurde CAPEv2 veröffentlicht.
CAPE wurde kontinuierlich weiterentwickelt und verbessert, um mit den Fortschritten sowohl der Malware als auch der Betriebssystemfähigkeiten Schritt zu halten. 2021 wurde die Möglichkeit hinzugefügt, den Debugger von CAPE während der Detonation über dynamische YARA-Scans zu programmieren, was dynamische Umgehungen für Anti-Sandbox-Techniken ermöglicht. Windows 10 wurde zum Standard-Betriebssystem, und weitere bedeutende Ergänzungen umfassen interaktiven Desktop, AMSI (Anti-Malware Scan Interface)-Payload-Erfassung, 'Syscall-Hooking' basierend auf Microsoft Nirvana und debuggerbasierte direkte/indirekte Syscall-Gegenmaßnahmen.
Malware kann in CAPE über drei Mechanismen klassifiziert werden:
Das Parsen kann mit CAPEs eigenem Framework erfolgen, alternativ werden die folgenden Frameworks unterstützt: RATDecoders, DC3-MWCP, MalDuck oder MaCo
def extract_config(data): ist, der von cape_utils.py aufgerufen wird, und null Komplikationen.
CAPE nutzt viele Malware-Techniken oder -Verhaltensweisen aus, um die Erfassung entpackter Payloads zu ermöglichen:
Diese Verhaltensweisen führen zur Erfassung von Payloads, die injiziert, extrahiert oder dekomprimiert werden, zur weiteren Analyse. Zusätzlich erstellt CAPE automatisch einen Prozess-Dump für jeden Prozess oder, im Fall einer DLL, das DLL-Modul-Image im Speicher. Dies ist nützlich für Proben, die mit einfachen Packern gepackt wurden, bei denen der Modul-Image-Dump oft vollständig entpackt ist.
Zusätzlich zu den standardmäßigen 'passiven' Entpackungsmechanismen von CAPE ist es möglich, 'aktives' Entpacken zu aktivieren, das Breakpoints verwendet, um das Schreiben in neu zugewiesene oder geschützte Speicherbereiche zu erkennen, um entpackte Payloads so früh wie möglich vor der Ausführung zu erfassen. Dies wird über ein Kontrollkästchen bei der Web-Einreichung oder durch Angabe der Option unpacker=2 aktiviert und ist standardmäßig deaktiviert, da es die Detonationsqualität beeinträchtigen kann.
CAPE kann über YARA-Signaturen programmiert werden, um bestimmte Packer zu entpacken. Zum Beispiel sind UPX-artige Packer sehr verbreitet, und obwohl diese in CAPE dazu führen, dass entpackte Payloads passiv erfasst werden, erfolgt die Standarderfassung nachdem der entpackte Payload mit der Ausführung begonnen hat. Durch dynamische Erkennung von UPX-abgeleiteten Packern mittels benutzerdefinierter YARA-Signatur und Setzen eines Breakpoints auf die letzte Packer-Anweisung ist es möglich, den Payload an seinem ursprünglichen Einsprungspunkt (OEP) zu erfassen, bevor er mit der Ausführung beginnt.
Die Option dump-on-api erlaubt das Dumpen eines Moduls, wenn es eine bestimmte API-Funktion aufruft, die in der Weboberfläche angegeben werden kann (z.B. dump-on-api=DnsQuery_A).
Der Debugger hat es CAPE ermöglicht, sich über seine ursprünglichen Fähigkeiten hinaus weiterzuentwickeln, die nun dynamische Anti-Evasion-Umgehungen umfassen. Da moderne Malware oft versucht, der Analyse in Sandboxes zu entgehen, zum Beispiel durch Timing-Fallen zur Virtualisierung oder API-Hook-Erkennung, ermöglicht CAPE die Entwicklung dynamischer Gegenmaßnahmen, die Debugger-Aktionen in Yara-Signaturen kombinieren, um ausweichende Malware während der Detonation zu erkennen und Kontrollflussmanipulationen durchzuführen, um die Probe zur vollständigen Detonation zu zwingen oder ausweichende Aktionen zu überspringen.
Schneller Zugriff auf den Debugger wird durch die Einreichungsoptionen bp0 bis bp3 ermöglicht, die RVA- oder VA-Werte zum Setzen von Breakpoints akzeptieren, woraufhin eine kurze Anweisungs-Trace ausgegeben wird, gesteuert durch die Optionen count und depth (z.B. bp0=0x1234,depth=1,count=100).
Um einen Breakpoint am Moduleinsprungspunkt zu setzen, wird ep anstelle einer Adresse verwendet (z.B. bp0=ep). Alternativ erlaubt break-on-return einen Breakpoint auf die Rückkehradresse einer gehookten API (z.B. break-on-return=NtGetContextThread). Ein optionaler Parameter base-on-api ermöglicht es, die Image-Basis für RVA-Breakpoints durch einen API-Aufruf zu setzen (z.B. base-on-api=NtReadFile,bp0=0x2345).
Optionen action0 - action3 erlauben Aktionen, die ausgeführt werden, wenn Breakpoints getroffen werden, wie das Dumpen von Speicherbereichen (z.B. action0=dumpebx) oder das Ändern des Ausführungskontrollflusses (z.B. action1=skip). CAPE's Dokumentation enthält weitere Beispiele solcher Aktionen.
Das Repository mit dem Code für CAPE's Monitor ist getrennt.
Es gibt ein Community-Repository mit Signaturen, das mehrere hundert von der CAPE-Community entwickelte Signaturen enthält. Alle neuen Community-Funktionen sollten in dieses Repository gepusht werden. Später können sie zum Kern verschoben werden, wenn die Entwickler in der Lage und willens sind, sie zu pflegen.
Bitte trage zu diesem Projekt bei, indem du hilfst, neue Signaturen, Parser oder Umgehungen für weitere Malware-Familien zu erstellen. Derzeit sind viele in Arbeit, also behalte diesen Bereich im Auge.
Ein großes Dankeschön an @D00m3dR4v3n für die alleinige Portierung von CAPE auf Python 3.
Python3
Nur rooter sollte als root ausgeführt werden, der Rest als cape-Benutzer. Das Ausführen als root wird die Berechtigungen durcheinanderbringen.
conf-Ordner!kvm-qemu.sh und cape2.sh SOLLTEN von einer tmux-Sitzung aus ausgeführt werden, um Betriebssystemprobleme zu vermeiden, falls die ssh-Verbindung abbricht.<username> durch ein echtes Muster.<WOOT> darin ersetzen!sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.logsudo ./cape2.sh base 2>&1 | tee cape.logconf-Ordner vornimmst.systemctl restart <Dienstname>journalctl -u <Dienstname>-h für das Hilfemenü. Das Ausführen des Dienstes im Debug-Modus (-d) kann ebenfalls helfen.-h, aber bitte überprüfe die Skripte, um zu verstehen, was sie tun.git pullpython3 utils/community.py -waf siehe -h vorher, um sicherzustellen, dass du es verstehstgit 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
Wenn du CAPEv2 in deiner Arbeit verwendest, zitiere es bitte wie im GitHub-Menü 'Cite this repository' angegeben.
pefile verwenden, da jede die Version festlegt, die sie wollen.
pefile-Abhängigkeit zu entfernen, da du sie bereits installiert hast. Voilà, kein Schmerz mehr.