med0x2e/sigflipSigFlip ist ein Tool zum Patchen von mit Authenticode signierten PE-Dateien (exe, dll, sys, usw.), ohne die bestehende Signatur zu ungültig zu machen oder zu beschädigen.
SigFlip ist ein Tool zum Patchen von mit Authenticode signierten PE-Dateien (exe, dll, sys usw.), ohne die vorhandene Authenticode-Signatur zu beeinträchtigen oder zu brechen. Mit anderen Worten: Sie können die Prüfsumme/den Hash einer PE-Datei ändern, indem Sie Daten (z. B. Shellcode) einbetten, ohne die Dateisignatur, Integritätsprüfungen oder die Funktionalität der PE-Datei zu beeinträchtigen.
SigInject verschlüsselt Shellcode und injiziert ihn in die [WIN_CERTIFICATE]-Zertifikatstabelle einer PE-Datei. Der Verschlüsselungsschlüssel wird zur Verwendung mit einem einfachen BOF/C/C#-Loader (SigLoader) ausgegeben. SigInject speichert die Änderungen in einer modifizierten PE-Datei und bewahrt ihre Signatur und Zertifikatsgültigkeit.
SigLoader ist ein einfacher Loader, der als Parameter den Pfad einer modifizierten PE-Datei (erstellt von SigInject) und den Entschlüsselungsschlüssel nimmt, dann den eingebetteten Shellcode extrahiert und entschlüsselt, um ihn mit einer beliebigen Shellcode-Injection zu verwenden.
SigFlip prüft, ob der PE-Hash erfolgreich geändert wurde, und beendet sich bei Endpunkten, die gegen solche häufigen Fehlkonfigurationen gehärtet sind, ordnungsgemäß (siehe Abschnitt „Details“).
Kurzer Hinweis: SigFlip, SigInject und SigLoader sind als BOF-Skripte und .NET-Assemblys verfügbar. Der einzige Unterschied besteht darin, dass die SigInject-Funktionalität als Teil von SigFlip (-i) implementiert ist, falls Sie sich für .NET-Artefakte anstelle von BOFs entscheiden.
Es kann hauptsächlich für Persistenz, laterale Bewegung oder Code-/Befehlsausführung verwendet werden und kann helfen bei:
Vorkompilierte BOFs werden in diesem Projekt nicht bereitgestellt. Sie können mit Mingw-w64 kompiliert werden. Für .NET verwenden Sie VS oder csc.exe zum Kompilieren der .NET-Projekte (SigFlip, SigLoader). Für BOF führen Sie die folgenden Schritte aus:
➜ i686-w64-mingw32-gcc -c sigflip.c -o sigflip.x86.o➜ x86_64-w64-mingw32-gcc -c sigflip.c -o sigflip.x64.o➜ x86_64-w64-mingw32-gcc -c SigLoader/sigloader.c -o sigloader.x64.o➜ i686-w64-mingw32-gcc -c SigLoader/sigloader.c -o sigloader.x86.oStellen Sie sicher, dass sich alle Objektdateien im selben Verzeichnis wie sigflip.cna befinden, und laden Sie dann das Skript sigflip.cna in Cobalt Strike.
Kurzer Hinweis: Vorkompilierte BOFs wurden getestet und sind kompatibel mit mingw-64 v8.0.0_3. Die Verwendung von mingw-64 >= v9 könnte funktionieren, aber aktive Beacons könnten abstürzen. Weitere Details finden Sie unter https://github.com/med0x2e/SigFlip/issues/2.
Execute-Assembly
execute-assembly SigFlip.exe -hexecute-assembly SigLoader -hBOF
SigFlip: Ändert den Hash einer PE-Datei (DLL, EXE, SYS, OCX usw.), ohne die Signatur oder die Gültigkeit des Zertifikats zu brechen:
SigFlip "<PE\_FILE\_PATH>" "<OUTPUT\_PE\_FILE\_PATH (mit Erweiterung)>"SigInject: Verschlüsselt Shellcode und injiziert ihn in die [WIN_CERTIFICATE]-Zertifikatstabelle einer PE-Datei. Der Verschlüsselungsschlüssel wird zur Verwendung mit einem einfachen C/C#-Loader ausgegeben. Signatur und Zertifikatsgültigkeit bleiben erhalten:
SigInject "<PE\_FILE\_PATH> <OUTPUT\_PE\_FILE\_PATH (mit Erweiterung)>" "<SHELLCODE\_FILE>"SigLoader: Lädt verschlüsselten Shellcode aus von SigInject erstellten PE-Dateien und verwendet dann Early Bird QueueUserAPC, um Shellcode in einen Opferprozess zu injizieren. Die Shellcode-Injektionslogik kann angepasst oder durch eine beliebige andere Code-Injektionstechnik ersetzt werden:
SigLoader <PE_FILE_PATH_WITH_SH> <DECRYPTION_KEY> <SPAWNTO_PROCESS_PATH> <PARENT_PROCESS_ID>Beispiele
BOF:
SigFlip "C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" "C:\lolbins\modified-msbuild.exe"SigInject "C:\Windows\System32\kernel32.dll" "C:\random\modified-kernel32.dll" "C:\shellcode\cobaltstrike_or_msf_shellcode.bin"Sigloader "C:\random\modified-kernel32.dll" "DECRYPTION_KEY" "C:\Windows\System32\werfault.exe" 6300Execute-Assembly:
execute-assembly SigFlip.exe -b C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe -o C:\Temp\MSBuild.exeexecute-assembly SigFlip.exe -i C:\Windows\System32\kernel32.dll -s C:\Temp\x86shellcode.bin -o C:\Temp\kernel32.dll -e TestSecretKeyexecute-assembly SigLoader.exe -f C:\Temp\modified-kernel32.dll -e TestSecretKey -pid 2354Dies ist eine bekannte Technik, die von APT#10 in mehreren Kampagnen oder Angriffssets verwendet wird.
Authenticode ist eine Microsoft-Technologie zur Code-Signierung, die den Herausgeber von mit Authenticode signierter Software identifiziert. Authenticode überprüft auch, ob die Software seit ihrer Signierung und Veröffentlichung nicht manipuliert wurde.
Microsoft verlässt sich hauptsächlich auf das Authenticode-Signierungsformat zur Überprüfung der Integrität und Herkunft von PE-Binärdateien. Gemäß der Authenticode-Portable-Executable-Formatspezifikation können die Authenticode-Signaturen in einer Windows-PE-Datei „eingebettet“ werden, und zwar an einer Stelle, die durch den Eintrag der Zertifikatstabelle in den Optional-Header-Datenverzeichnissen angegeben wird. Wenn Authenticode zum Signieren einer Windows-PE-Datei verwendet wird, schließt der Algorithmus, der den Authenticode-Hashwert der Datei berechnet, bestimmte PE-Felder aus. Wenn die Signatur in die Datei eingebettet wird, kann der Signierungsprozess diese Felder ändern, ohne den Hashwert der Datei zu beeinflussen. Diese Felder sind: **die Prüfsumme, die RVA der Zertifikatstabelle, die Größe der Zertifikatstabelle und die Attributzertifikatstabelle. Die Attributzertifikatstabelle enthält eine PKCS#7-SignedData-Struktur mit dem Hashwert der PE-Datei, einer Signatur, die mit dem privaten Schlüssel des Softwareherausgebers erstellt wurde, und den X.509 v3-Zertifikaten, die den Signaturschlüssel des Herausgebers an eine juristische Person binden.
Einfach ausgedrückt: Wir können Daten in Felder ändern oder einbetten, die von der Authenticode-Hashberechnung ausgeschlossen sind, ohne uns Gedanken über das Brechen der Authenticode-Signatur und der Dateiintegritätsprüfungen machen zu müssen.
Weitere Details zu diesen ausgeschlossenen Feldern:
RVA und Größe der Zertifikatstabelle: Die optionale Header-Struktur einer signierten PE-Datei enthält ein Array von Datenverzeichnissen, einschließlich des Sicherheitsverzeichniseintrags IMAGE_DIRECTORY_ENTRY_SECURITY, der zwei Felder hat: RVA und Größe.
Attributzertifikatstabelle: eine Datenstruktur WIN_CERTIFICATE, die die Signatur und Zertifikate kapselt und die folgenden Felder hat:
dwLength: Größe der Zertifikatstabelle.wRevision: die „Revision“ des WIN_CERTIFICATE.wCertificateType: die Art der gekapselten Zertifikatsdaten.bCertificate: die eigentlichen Zertifikatsdaten. Für WIN_CERT_TYPE_PKCS_SIGNED_DATA ist dies die oben erwähnte PKCS#7-SignedData-Struktur (die den PE-Hashwert, die Signatur und das X.509-Zertifikat enthält). Genau hier bettet SigFlip zufällige Daten oder Shellcode ein.Vor diesem Hintergrund führt SifFlip nun Folgendes aus:
Der erste Schritt ist entscheidend, um zu bestätigen, ob das System so fehlkonfiguriert ist, dass das Auffüllen und Injizieren von Shellcode in mit Authenticode signierte PE-Dateien möglich ist. Daher werden die folgenden Integritätsprüfungen durchgeführt:
X86:
X64:
Der Windows-Lader lädt Zertifikatsdaten nicht in den Prozessadressraum. Daher benötigen Sie einen benutzerdefinierten Lader, um Daten wie Shellcode zu extrahieren und zu verwenden (z. B. SigLoader). Dies erklärt auch, warum der RVA des Datenverzeichniseintrags IMAGE_DIRECTORY_ENTRY_SECURITY ein Datei-Offset und kein typischer Speicher-Offset ist.