这是什么？

SigFlip 是一款用于修补已进行 Authenticode 签名的 PE 文件（exe、dll、sys 等）的工具，其修补方式不会影响或破坏已有的 Authenticode 签名。换句话说，你可以在不破坏文件签名、完整性检查或 PE 文件功能的前提下，通过嵌入数据（例如 shellcode）来改变 PE 文件的校验和/哈希值。

SigInject 会将 shellcode 加密并注入到 PE 文件的 [WIN_CERTIFICATE] 证书表中，加密密钥会打印出来，供基本的 BOF/C/C# 加载器（SigLoader）使用。SigInject 会将修改后的 PE 文件保存，并保持其签名和证书有效性不变。

SigLoader 是一个基本的加载器，它将 SigInject 创建的修改后 PE 文件路径和解密密钥作为参数，然后提取并解密嵌入的 shellcode，以供所选的 shellcode 注入技术使用。

SigFlip 将检查 PE 哈希是否已成功更改，并且在端点针对此类常见错误配置进行了加固时，会优雅地退出并给出提示。（请参阅“详细信息”部分）。

快速说明： SigFlip、SigInject 和 SigLoader 均以 BOF 脚本和 .NET 程序集的形式提供。唯一的区别在于，如果你选择使用 .NET 工件而不是 BOF，则 SigInject 的功能作为 SigFlip 的一部分（-i）实现。

为什么需要这个？

它主要用于持久化、横向移动或代码/命令执行，并有助于：

绕过应用程序白名单，在不破坏签名的情况下更改 PE 文件哈希（例如 msbuild.exe）。
绕过那些依赖特定 LOLBIN 哈希来检测恶意代码/命令执行的 EDR。
使用不同的哈希加载已签名的驱动程序，可能有助于规避那些使用预定义哈希列表监视常见易受攻击的已签名驱动程序的 EDR。
将加密的 shellcode 嵌入到已签名的 PE 文件中，并使用你偏好的加载器（sigloader）来解析、解密、加载和执行它。
端点安全厂商通常将已签名的 PE 文件视为良性文件，将你的未签名代码（shellcode 等）嵌入到已签名的 PE 文件中会使其更难被检测/标记。
绕过主要依赖默认 WinVerifyTrust 进行签名验证的端点安全厂商。
改进 OPSEC，挑战那些仅依赖典型签名验证工具（如 signtool、sigcheck、Get-AuthenticodeSignature 等）来验证 PE 文件 Authenticode 签名的防御者。

使用方法与示例：

编译/构建：

本项目不提供预编译的 BOF，可以使用 Mingw-w64 进行编译。对于 .NET，请使用 VS 或 csc.exe 来编译 .NET 项目（SigFlip、SigLoader）。对于 BOF，请参考以下步骤：

➜ 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

确保所有目标文件与 sigflip.cna 位于同一目录下，然后加载 sigflip.cna 脚本到 Cobalt Strike。

快速说明： 预编译的 BOF 已经过测试，兼容 mingw-64 v8.0.0_3。使用 mingw-64 >= v9 可能可以工作，但可能导致活跃的 beacon 崩溃，更多详情请查看 https://github.com/med0x2e/SigFlip/issues/2。

Cobalt Strike：

Execute-Assembly
- execute-assembly SigFlip.exe -h
- execute-assembly SigLoader -h
BOF
- 用于 Cobalt Strike 时，加载 SigFlip.cna 脚本后，将注册两个新命令：SigFlip 和 SigInject，然后按如下方式使用；
  - SigFlip：更改 PE 文件（DLL、EXE、SYS、OCX 等）的哈希，且不破坏签名或证书有效性：
    - SigFlip "<PE\_FILE\_PATH>" "<OUTPUT\_PE\_FILE\_PATH (with extension)>"
  - SigInject：将 shellcode 加密并注入到 PE 文件的 [WIN_CERTIFICATE] 证书表中，加密密钥会打印出来，供基本的 C/C# 加载器使用，并保持签名和证书有效性不变：
    - SigInject "<PE\_FILE\_PATH> <OUTPUT\_PE\_FILE\_PATH (with extension)>" "<SHELLCODE\_FILE>"
  - SigLoader：从 SigInject 创建的 PE 文件中加载加密的 shellcode，然后使用 Early Bird QueueUserAPC 将 shellcode 生成/注入到牺牲进程中，shellcode 注入逻辑可以自定义或替换为任何其他代码注入技术：
    - SigLoader <PE_FILE_PATH_WITH_SH> <DECRYPTION_KEY> <SPAWNTO_PROCESS_PATH> <PARENT_PROCESS_ID>
示例
- BOF：
  - 向 msbuild.exe 注入随机数据（即对 msbuild.exe 进行位翻转）：
    - SigFlip "C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" "C:\lolbins\modified-msbuild.exe"
  - 向 kernel32.dll 注入 shellcode（参数顺序不同，请确保记下解密密钥）：
    - 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：
  - 向 msbuild.exe 注入随机数据：
    - execute-assembly SigFlip.exe -b C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe -o C:\Temp\MSBuild.exe
  - 向 kernel32.dll 注入 shellcode（参数顺序不同，请确保记下解密密钥）：
    - 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

详细信息：

这是一种已知的技术，被 APT#10 在多个活动或入侵集中使用。

Authenticode 数字签名？

Authenticode 是一种微软代码签名技术，用于标识经过 Authenticode 签名的软件的发布者。Authenticode 还验证软件在签名和发布后未被篡改。

它是如何工作的？

微软主要依赖 Authenticode 签名格式来验证 PE 二进制文件的完整性和来源。根据 Authenticode 可移植可执行文件格式规范，Authenticode 签名可以“嵌入”到 Windows PE 文件中，位置由可选头部数据目录中的证书表条目指定。当使用 Authenticode 对 Windows PE 文件进行签名时，计算文件 Authenticode 哈希值的算法会排除某些 PE 字段。当签名嵌入文件时，签名过程可以修改这些字段而不影响文件的哈希值。这些字段如下：校验和、证书表 RVA、证书表大小以及属性证书表。属性证书表包含一个 PKCS #7 SignedData 结构，其中包含 PE 文件的哈希值、由软件发布者私钥创建的签名，以及将软件发布者签名密钥绑定到法律实体的 X.509 v3 证书。

通俗地说，我们可以修改或嵌入数据到这些从 Authenticode 哈希计算中排除的字段中，而无需担心破坏 Authenticode 签名和文件完整性检查。

关于此类排除字段的更多细节：

证书表 RVA 和大小：已签名 PE 文件的可选头部结构包含一个数据目录数组，其中包括安全目录 IMAGE_DIRECTORY_ENTRY_SECURITY 条目，该条目有两个字段：RVA 和 Size。
- RVA：属性证书表的文件偏移量（不是内存偏移量）。
- Size：属性证书表的大小。
属性证书表：一个名为 WIN_CERTIFICATE 的数据结构，它封装了签名和证书，并包含以下字段：
- dwLength：证书表大小。
- wRevision：WIN_CERTIFICATE 的“修订版本”。
- wCertificateType：封装的证书数据类型。
- bCertificate：实际的证书数据。对于 WIN_CERT_TYPE_PKCS_SIGNED_DATA，这就是上面提到的 PKCS#7 SignedData 结构（包含 PE 哈希值、签名和 x.509 证书），这正是 SigFlip 嵌入随机数据或 shellcode 的地方。

基于以上理解，SigFlip 执行以下操作：

检查系统配置
加载 PE 文件并验证 PE 文件签名，计算 SHA1 哈希
获取 "e_lfanew" 偏移量（指向 PE 文件头部 -> IMAGE_NT_HEADERS）
从 IMAGE_NT_HEADERS 中获取 IMAGE_OPTIONAL_HEADER
从 IMAGE_OPTIONAL_HEADER 中获取 IMAGE_DATA_DIRECTORY
获取 IMAGE_DIRECTORY_ENTRY_SECURITY 字段，并检索属性证书表（WIN_CERTIFICATE）的 RVA 和 SIZE
通过向证书表填充额外的字节（随机数据/shellcode）来修补 PE 文件 blob
更新可选头部 -> IMAGE_DIRECTORY_ENTRY_SECURITY 数据目录的 Size
更新 WIN_CERTIFICATE（证书表）的 dwLength
生成新的 PE 校验和并进行更新。（可选头部校验和）
保存最终的新尺寸 PE 文件
验证修改后的 PE 文件签名

第一步对于确认系统是否以允许填充并注入 shellcode 到 Authenticode 签名的 PE 文件的方式配置错误至关重要，因此会执行以下健全性检查：

检查 MS13-098 修复补丁是否未安装（KB2893294）。请注意，该补丁可能已安装，但注册表键未正确设置，导致补丁失效。
检查注册表键
1. X86：
  - 检查注册表键 "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" 是否不存在
    - -> 如果存在，则检查 "EnableCertPaddingCheck" 注册表值是否不存在
2. X64：
  - 检查注册表键 "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" 是否不存在
    - -> 如果存在，则检查 "EnableCertPaddingCheck" 注册表值是否不存在

为什么当修改后的 PE 作为模块加载到其自身地址空间或其他进程的地址空间时，无法读取注入的数据？

Windows 加载器不会将证书数据加载到进程地址空间中，这就是为什么你需要一个自定义加载器来提取数据（例如 shellcode）并使用它（例如 SigLoader）。这也解释了为什么 IMAGE_DIRECTORY_ENTRY_SECURITY 数据目录条目的 RVA 是文件偏移量，而不是典型的内存偏移量。

检测/预防：

https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720?redirectedfrom=MSDN
安装补丁并正确设置注册表键后，无需重启系统，只需重启 Cryptographic Services 服务。Applocker 服务也会因依赖于加密服务而重启。（@p0w3rsh3ll）
Adrien 提供的 Yara 规则：https://twitter.com/Int2e_/status/1330975808941330432

SigFlip

最受欢迎