med0x2e/sigflipSigFlip — это инструмент для модификации (патчинга) PE-файлов (exe, dll, sys и т.д.), подписанных Authenticode, без аннулирования или нарушения существующей подписи.
SigFlip — это инструмент для модификации PE-файлов (exe, dll, sys и т.д.) с аутентикодной подписью таким образом, чтобы это не затрагивало и не нарушало существующую аутентикодную подпись. Другими словами, вы можете изменить контрольную сумму/хэш PE-файла, внедряя данные (например, шелл-код), не нарушая при этом подпись файла, проверки целостности или функциональность PE-файла.
SigInject шифрует и внедряет шелл-код в таблицу сертификатов [WIN_CERTIFICATE] PE-файла. Ключ шифрования выводится для использования с базовым загрузчиком BOF/C/C# (SigLoader). SigInject сохраняет изменения в изменённый PE-файл, сохраняя его подпись и действительность сертификата нетронутыми.
SigLoader — это базовый загрузчик, который принимает путь к изменённому PE-файлу, созданному SigInject, и ключ дешифрования в качестве параметров, затем извлекает и дешифрует встроенный шелл-код для использования с выбранным методом инжекции шелл-кода.
SigFlip проверяет, был ли успешно изменён хэш PE, а также корректно завершает работу в случае, если конечные точки защищены от подобной распространённой неверной конфигурации (см. раздел «Детали»).
Краткое примечание: SigFlip, SigInject и SigLoader доступны в виде BOF-скриптов и .NET-сборок. Единственное отличие в том, что функциональность SigInject реализована как часть SigFlip (-i), если вы решите использовать .NET-артефакты вместо BOF.
Он может использоваться в основном для постоянства, горизонтального перемещения или выполнения кода/команд и может помочь с:
Предварительно скомпилированные 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.
Execute-Assembly
execute-assembly SigFlip.exe -hexecute-assembly SigLoader -hBOF
SigFlip: Изменить хэш PE-файла (DLL, EXE, SYS, OCX и т.д.) без нарушения подписи или действительности сертификата:
SigFlip "<ПУТЬ\_К\_PE\_ФАЙЛУ>" "<ПУТЬ\_К\_ВЫХОДНОМУ\_PE\_ФАЙЛУ (с расширением)>"SigInject: Шифрует и внедряет шелл-код в таблицу сертификатов [WIN_CERTIFICATE] PE-файла. Ключ шифрования выводится для использования с базовым загрузчиком C/C#, подпись и действительность сертификата сохраняются:
SigInject "<ПУТЬ\_К\_PE\_ФАЙЛУ> <ПУТЬ\_К\_ВЫХОДНОМУ\_PE\_ФАЙЛУ (с расширением)>" "<ПУТЬ\_К\_ФАЙЛУ\_ШЕЛЛ-КОДА>"SigLoader: Загружает зашифрованный шелл-код из PE-файлов, созданных SigInject, затем использует Early Bird queueuserapc для внедрения/запуска шелл-кода в жертвенный процесс. Логику инжекции шелл-кода можно настроить или заменить любой другой техникой внедрения кода:
SigLoader <ПУТЬ\_К\_PE\_ФАЙЛУ\_С\_ШЕЛЛ-КОДОМ> <КЛЮЧ\_ДЕШИФРОВАНИЯ> <ПУТЬ\_К\_ПРОЦЕССУ\_SPAWNTO> <ИДЕНТИФИКАТОР\_РОДИТЕЛЬСКОГО\_ПРОЦЕССА>Примеры
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" "КЛЮЧ\_ДЕШИФРОВАНИЯ" "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 2354Это известная техника, используемая APT#10 в множестве кампаний и наборов вторжений.
Authenticode — это технология подписания кода от Microsoft, которая идентифицирует издателя программного обеспечения, подписанного с помощью Authenticode. Authenticode также проверяет, что программное обеспечение не было изменено после его подписания и публикации.
Microsoft в основном полагается на формат подписи Authenticode для проверки целостности и происхождения PE-бинарных файлов. Согласно спецификации формата Authenticode для Portable Executable, подписи Authenticode могут быть «встроены» в PE-файл Windows в место, указанное записью «Таблица сертификатов» в каталогах данных необязательного заголовка. Когда Authenticode используется для подписи PE-файла Windows, алгоритм, вычисляющий хэш-значение файла Authenticode, исключает определённые поля PE. При встраивании подписи в файл процесс подписания может изменять эти поля, не влияя на хэш-значение файла. Эти поля следующие: контрольная сумма, RVA таблицы сертификатов, размер таблицы сертификатов и таблица атрибутов сертификатов. Таблица атрибутов сертификатов содержит структуру PKCS #7 SignedData, содержащую хэш-значение PE-файла, подпись, созданную закрытым ключом издателя программного обеспечения, и сертификаты X.509 v3, которые связывают ключ подписи издателя с юридическим лицом.
Простыми словами, мы можем изменять или встраивать данные в поля, исключённые из расчёта хэша Authenticode, не беспокоясь о нарушении аутентикодной подписи и проверок целостности файла.
Подробнее об этих исключённых полях:
RVA и размер таблицы сертификатов: Структура необязательного заголовка подписанного PE-файла содержит массив каталогов данных, включая запись каталога безопасности IMAGE_DIRECTORY_ENTRY_SECURITY, которая имеет два поля: RVA и Size.
Таблица атрибутов сертификатов: структура данных WIN_CERTIFICATE, которая инкапсулирует подпись и сертификаты и имеет следующие поля:
dwLength: размер таблицы сертификатов.wRevision: «ревизия» WIN_CERTIFICATE.wCertificateType: тип инкапсулированных данных сертификата.bCertificate: фактические данные сертификата. Для WIN_CERT_TYPE_PKCS_SIGNED_DATA это упомянутая выше структура PKCS#7 SignedData (которая содержит хэш-значение PE, подпись и сертификат x.509). Именно сюда SigFlip встраивает случайные данные или шелл-код.Исходя из этого, SifFlip делает следующее:
Первый шаг необходим для подтверждения того, что система неправильно настроена таким образом, чтобы допускать дополнение и внедрение шелл-кода в подписанные аутентикодом PE-файлы. Поэтому выполняются следующие проверки:
X86:
X64:
Загрузчик Windows не загружает данные сертификата в адресное пространство процесса, поэтому вам нужен пользовательский загрузчик для извлечения таких данных, как шелл-код, и их использования (например, SigLoader). Это также объясняет, почему RVA записи каталога данных IMAGE_DIRECTORY_ENTRY_SECURITY является смещением в файле, а не типичным смещением в памяти.