Fritter

Der ausweichende Cousin von Donut.

Fritter ist ein stark modifizierter Fork des Donut-Shellcode-Generators von TheWover und Odzhan. Er erzeugt positionsunabhängigen Shellcode für die In-Memory-Ausführung von VBScript, JScript, EXE, DLL und .NET-Assemblys, mit Fokus auf Evasion und Signaturresistenz. Die Codebasis ist nur für x64.

Was ist anders

Vieles. Fritter entfernt Funktionen, die selten benötigt werden, und ersetzt interne Komponenten, die im Laufe der Jahre stark signaturiert wurden. Die Krypto-, Kompressions-, Hash- und API-Auflösungsschichten wurden neben vielen anderen Bereichen überarbeitet.

Polymorphismus und Evasion sind das Designziel. Jede Ausgabe ist einzigartig, und jeder Build des Tools ist selbst einzigartig. Es gibt zwei unterschiedliche Ebenen:

Pro-Ausgabe-Randomisierung: wird jedes Mal angewendet, wenn fritter aufgerufen wird. Der Entry-Stub, der polymorphe Decoder, die Verschlüsselungsschlüssel und viele strukturelle Elemente innerhalb des generierten Shellcodes werden bei jedem PIC-Build aus neuer Entropie neu erzeugt.

Pro-Build-Randomisierung: wird jedes Mal angewendet, wenn fritter selbst kompiliert wird. Cipher- und Hash-Rotationskonstanten, Layout der API-Auflösungstabelle, Shim-seitiges String-Scrambling, PEB-Walk-Richtungen, Wipe-Muster nach der Ausführung und mehrere strukturelle Achsen innerhalb von Loader und Shim werden zur Kompilierzeit eingebacken.

Zur Laufzeit minimiert Fritter den ausführbaren Fußabdruck des Loaders. Der Loader ist in einzeln verschlüsselte Funktionen partitioniert, jede mit eigener PE-Section, eigenem XOR-Schlüssel und eigenem Dispatcher. Nur die Bytes einer Funktion sind zu einem beliebigen Zeitpunkt im Klartext. Das frühere VEH-Sliding-Window-Modell wurde zugunsten dieses Dispatch-Modells ausgemustert.

!! Aus dem Quellcode bauen wird dringend empfohlen !!

Das ist wichtig. Die vorgebauten Binaries, die in releases zum Testen verfügbar sind, teilen ihre Pro-Build-Konstanten mit allen Benutzern des Binaries.

Baut eure eigene Kopie. Die Pro-Build-Achsen werden bei jedem make-Aufruf neu randomisiert:

# Linux, static-musl ELF, no runtime libc dependency
# Requires: build-essential, mingw-w64, musl-tools
make -f Makefile.linux release

# Windows (MSVC), recommended on Windows
nmake -f Makefile.msvc

Unter Windows ist MSVC die empfohlene Toolchain. Sie legt jede Loader-Funktion in eine eigene seitenausgerichtete PE-Section, was das N>1-Pro-Funktions-Dispatch-Modell benötigt. mingw legt derzeit alles in einer einzigen .text-Section ab und führt daher einen Entry aus, der den gesamten Loader mit einem einzigen XOR-Schlüssel abdeckt (funktional identisch mit der MSVC-Ausgabe, aber nur ein Polymorphismus-Dispatcher statt vieler). Wenn ihr kein Visual Studio habt, baut unter WSL mit Makefile.linux; es cross-kompiliert den Windows-Loader über mingw-w64.

Jeder make-Lauf führt tools/gen_poly aus, um frische Pro-Build-Konstanten zu erzeugen, sowie tools/gen_api_shuffle, um die API-Auflösungstabelle zu permutieren. Das resultierende fritter-Binary ist selbst einzigartig, mit anderen Cipher-Konstanten, anderen Hash-Konstanten, einem anderen API-Tabellen-Layout, anderem Shim-seitigen String-Scrambling und so weiter. Jeder Shellcode, der von diesem Binary erzeugt wird, teilt dann diese Pro-Build-Konstanten, variiert aber auf den Pro-Ausgabe-Achsen.

Verwendung

Ein /test-Ordner mit calc.exe und inject_local64.exe ist enthalten, um Fritter zu testen. Um die Test-Hosts selbst neu zu bauen: nmake -f Makefile.msvc harness, oder make -f Makefile.linux harness unter WSL.

fritter [options] -i <EXE/DLL/VBS/JS>

  INPUT
    -i, --input  <path>       Input file to execute in-memory
    -p, --args   <args>       Parameters / command line for target
    -c, --class  <name>       Class name (required for .NET DLL)
    -m, --method <name>       Method or function for DLL
    -r, --runtime <ver>       CLR runtime version
    -w, --unicode             Pass command line as UNICODE
    -t, --thread              Run unmanaged EXE entrypoint as thread

  OUTPUT
    -o, --output <path>       Output file (default: loader.bin)
    -f, --format <1-8>        1=Bin 2=B64 3=C 4=Ruby 5=Py 6=PS 7=C# 8=Hex
    -x, --exit   <1-3>        1=Thread (default) 2=Process 3=Block
    -y, --fork   <offset>     Fork thread, continue at RVA offset

  LOADER
    -e, --entropy <1-3>       1=None 2=Random names 3=Names+Crypto (default)
    -k, --headers <1-2>       1=Overwrite (default) 2=Keep all
    -g, --chunked <0-1>       (deprecated; dispatch shim is always used)
    -d, --domain  <name>      AppDomain name for .NET
    -j, --decoy   <path>      Decoy module for Module Overloading

  STAGING
    -n, --modname <name>      Module name for HTTP staging
    -s, --server  <url>       Server URL (supports basic auth)

Beispiele

fritter -i payload.exe
fritter -i implant.dll -m RunMain -p "arg1 arg2"
fritter -i payload.exe -g 0 -k 2 -o out.bin

Architektur (viele Implementierungen sind hier nicht aufgelistet)

Ein Fritter-Shellcode-Payload ist als verschachtelte Schichten strukturiert, wobei jede Schicht die nächste entschlüsselt oder staged:

Entry-Stub. Ein randomisiertes Junk-Präfix variabler Länge, eine pro Ausgabe generierte RSP-Ausrichtungsroutine und ein generatives Trampolin. Basierend auf der Disziplin von Shikata Ga Nai.
Polymorpher XOR-Decoder. In zwei Durchgängen assembliert. Registerzuweisung per Fisher-Yates-Shuffle aus einem Pool gezogen. Schlüssellänge pro Ausgabe gewählt. Zwischen jede echte Anweisung wird Junk eingefügt. Die beweglichen Anweisungsgruppen der heißen Schleife werden innerhalb von Korrektheitsbeschränkungen neu angeordnet.
Dispatch-Shim. Ersetzt den früheren VEH-Sliding-Window-Shim. Wechselt die Loader-Region von RW auf RWX und übergibt dann die Kontrolle an den Loader-Einstieg. Bei N>1-Dispatch wird jeder Aufruf über einen Pro-Funktions-Thunk in einen Pro-Funktions-Dispatcher geleitet, der entschlüsselt, ausführt und bei der Rückkehr wischt. Das Opcode-Layout jedes Dispatchers variiert pro Build (siehe CHANGELOG v1.3).
Loader. PE-In-Memory-Mapper. Löst APIs per Hash auf, mappt das eingebettete PE über Section-APIs, wendet Imports / Relocations / TLS-Callbacks an, ruft den Entrypoint auf und wischt dann. PEB-Walk-Richtung, Wipe-Byte nach der Ausführung und strukturelle Salt-Stellen in MainProc sind alle pro Build randomisiert.
Bereinigung. Wischt Loader-Seiten mit einem Pro-Build-Byte-Muster, löscht die Instanz und beendet sich je nach -x durch Thread- oder Prozessbeendigung. Es gibt keinen VEH-Handler und keine Kontextstruktur zu säubern.

Der verbleibende Fußabdruck nach der Ausführung ist eine kleine RWX-Seite, auf der der Dispatch-Shim lief. Im Thread-Modus wird die gemappte PE-Section absichtlich intakt gelassen, damit CRT-Callbacks Fortsetzungen haben.

Danksagungen

Fritter baut auf der Arbeit von TheWover und Odzhan auf, deren ursprüngliches Donut-Projekt die Erzeugung von positionsunabhängigem Shellcode zugänglich und praktisch gemacht hat. Ihre Architektur, das Loader-Design und das PIC-Framework sind das Fundament, auf dem alles hier aufbaut. Die PE-Mapping-, .NET-Hosting- und Skriptausführungspfade sind weitgehend ihre Arbeit, beibehalten und respektiert.

Lizenz

BSD 3-Clause. Siehe LICENSE.

Fritter v1.3

Kategorien