kudaes/splitПримените подход «разделяй и властвуй» для обхода EDR.
Divide and Conquer — это алгоритм, который часто применяется в программировании для решения сложной задачи путём разделения её на множество более простых подзадач. Мы можем применить этот подход к наступательной безопасности с другой целью: запутать EDR, чтобы они потеряли след нашей активности и не подняли ни одной тревоги. Это похоже на то, что в последнее время можно наблюдать почти в любой фишинговой кампании в дикой природе: длинные цепочки заражения, когда последовательно запускается множество файлов (например, .url -> .one -> .js -> .bat -> .dll) вместо непосредственного запуска финальной нагрузки. Каждый из выполняемых файлов совершает простое действие (скачивает другой файл, вносит изменения в реестр, перемещает файлы между каталогами или меняет их имена/расширения и так далее), которое само по себе сложно пометить как вредоносное, подготавливая среду для финального выполнения.
Я решил проверить эту простую идею, но применительно к другому сценарию, а именно к удалённому внедрению в процесс. Код, представленный в этом репозитории, не нов; наоборот, это, вероятно, один из самых распространённых и прямолинейных способов внедрить шеллкод в удалённый процесс: использование NtOpenProcess, NtAllocateVirtualMemory, NtWriteVirtualMemory, NtProtectVirtualMemory и NtCreateThreadEx. Единственное отличие в том, что я выполняю форк процесса через NtCreateUserProcess после каждого из этих вызовов. Поскольку форкнутый процесс продолжает выполнение с RIP + 1, а память полностью копируется от родителя, мы можем выполнить удалённое внедрение в процесс, но используя 5 разных процессов; нам лишь нужно убедиться, что все дескрипторы, необходимые для последующих вызовов API, правильно наследуются.
Таким образом, мы разбиваем процедуру внедрения шеллкода на более простые задачи и выполняем каждую из них в отдельном контексте (процессе).
Я протестировал эту PoC против трёх наиболее распространённых на сегодняшний день EDR: MDE, CrowdStrike и SentinelOne. Результаты говорят сами за себя: 2 из 3 EDR подняли тревогу о Remote Process Injection при запуске PoC без форков; напротив, ни один из них не поднял тревогу после внедрения механизма форков.
Конечно, даже с механизмом форков в сырой телеметрии можно увидеть события, соответствующие созданию процессов, созданию потоков, а также всё межпроцессное поведение, но, похоже, этого недостаточно, чтобы EDR пометили активность как вредоносную, что и доказывает идею данной PoC. Разделяя вредоносное поведение на более простые задачи и выполняя каждую из них из отдельного процесса, мы можем запутать EDR и предотвратить поднятие тревоги.
Того же результата можно достичь и другими способами; я просто использовал механизм форков, чтобы упростить свой код и уменьшить межпроцессную активность.
Если вы хотите проверить это самостоятельно, скомпилируйте код с вызовами функции fork() и без них, а затем запустите оба бинарника в среде с нужным EDR.
Поскольку мы используем плагин LITCRYPT для обфускации строковых литералов (только для кода Dinvoke_rs), перед компиляцией кода необходимо задать переменную окружения LITCRYPT_ENCRYPT_KEY:
C:\Users\User\Desktop\Split> set LITCRYPT_ENCRYPT_KEY="yoursupersecretkey"
После этого просто скомпилируйте код и запустите инструмент:
C:\Users\User\Desktop\Split> cargo build --release
C:\Users\User\Desktop\Split\target\release> split.exe -h
Сам по себе этот метод недостаточен для обхода EDR; если ваш код вообще не соответствует требованиям OPSEC, вас, скорее всего, всё равно поймают. Это не серебряная пуля, а лишь ещё один уровень обхода, который можно добавить к своим инструментам. Тем не менее код, представленный в этом репозитории, совершенно не OPSEC-safe по следующим причинам (среди прочих):
С другой стороны, я тестировал этот подход только против упомянутых EDR и не знаю, будут ли обойдены другие EDR. Можете протестировать и сообщить мне, как всё прошло ;)