
Объединяет инъекцию AppDomain Manager с внедрением shellcode в подписанные бинарные файлы для обхода обнаружения EDR/AV для полезных нагрузок red team.
За последние несколько дней я экспериментировал с техникой внедрения менеджера AppDomain и добился неплохих результатов в своих предыдущих операциях Red Team против некоторых EDR. Хотя это действительно хороший вектор для первоначального доступа, я хотел выпустить PoC, который поможет скрыть ваш шеллкод в другом месте. Больше никаких DLL-файлов с внедренным шеллкодом!
Хотя это отличная техника при самостоятельном использовании, в сочетании с методом доставки, например, отправкой C# ClickOnce внутри ISO/ZIP/VHD/VHDX файла, возникает реальная проблема: в 1 из 10 случаев DLL для appdomain обнаруживалась AI/ML эвристиками антивируса/EDR. Это связано с тем, что DLL-файл необходимо сбросить на диск перед инициализацией appdomain. Не принимая во внимание удаленные загрузки DLL (UNC-пути в .config), DLL для appdomain содержала бы шеллкод, и я сильно чувствовал, что это является причиной вероятного статического обнаружения, потому что остальной код (вызовы WINAPI) можно динамически разрешать и довольно хорошо обфусцировать.
Я хотел улучшить эту технику, минимизировав то, что изначально содержит DLL. Я начал с того, что помещал зашифрованный шеллкод в отдельный файл на диске вместе с DLL-инжектором, но затем наткнулся на эту замечательную статью от Checkpoint о кампании Zloader
Краткая версия: мы можем встраивать произвольные данные в некоторые поля PE таким образом, чтобы не нарушить подпись файла. Таким образом, наши данные будут внедрены, а исполняемый файл останется цифровой подписью.
Подробнее об этом - https://www.blackhat.com/docs/us-16/materials/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf
Итак, идея заключается в том, чтобы встроить зашифрованный шеллкод-стаб в известный подписанный исполняемый файл и при этом сохранить его подпись, как это делал вредонос Zloader. Таким образом, DLL менеджера AppDomain больше не будет содержать шеллкод внутри себя, а будет содержать только логику для извлечения шеллкода из PE-бинарного файла, который его загружает, для расшифровки и выполнения в отдельном потоке. Это может снизить уровень статического обнаружения DLL, в то время как ваш шеллкод будет аккуратно размещен внутри подписанного бинарного файла.
Я пытался добиться этого, вручную изменяя образцы Zloader, полученные с VirusTotal, но позже нашел проект, который уже довольно хорошо реализовал все эти техники - Sigflip. В этом PoC я использовал код загрузчика Sigflip для создания DLL для AppDomain и инжектор SigFlip для встраивания зашифрованного шеллкода в наш C# exe.
Большие блоки шеллкода, такие как Stageless шеллкод Cobalt Strike, больше не будут находиться в неподписанной DLL на диске, независимо от используемых методов обфускации/кодирования. DLL становится чище, меньше и незаметнее с минимальным кодом, что снижает вероятность обнаружения.
SigFlip.exe -i "Z:\ZLoader\CasPol.exe" "Z:\ZLoader\x64-stageless.bin" "Z:\ZLoader\update.exe" "S3cretK3y"update.exe, который будет представлять собой цифровую подпись PE с встроенным зашифрованным шеллкодом.csc /target:library /out:test.dll test.csЭтот PoC — всего лишь идея, которая пришла мне в голову, объединить две совершенно разные техники обороны, которые помогут мне и другим участникам Red Team в создании лучших начальных полезных нагрузок для выполнения для своих операций. Этот проект использует инъекцию менеджера AppDomain в качестве примера, но эта идея применима и к другим техникам инъекции, таким как DLL SideLoading, DLL Hijacking и т.д.
Полная благодарность med0x2e, этот PoC построен на основе его проекта SigFlip