Публичный релиз DropSpawn несколько отличается от непубличного. В непубличном релизе используется проприетарный генератор полезной нагрузки, что делает работу оператора гораздо более удобной. Публичный релиз был немного изменён с учётом того, что пользователи будут использовать свои собственные способы генерации совместимых с перехватом DLL полезных нагрузок. Включены скрипт на Python3, а также исходный код демонстрационной DLL, чтобы помочь пользователям интегрировать и использовать DropSpawn в своих целях.

Как использовать

1.

Определите целевые исполняемые файлы, которые пытаются загрузить DLL без указания их абсолютных путей. Это можно сделать, скопировав exe в доступный для записи пользователю каталог и запустив его, отслеживая процесс с помощью Procmon. В этом примере мы будем использовать WerFault.exe, который обычно находится в C:\Windows\System32\WerFault.exe

В приведённом выше примере cryptsp.dll, wer.dll, dbghelp.dll и bcrypt.dll являются подходящими кандидатами, поскольку их абсолютные пути не были указаны внутри WerFault; в результате WerFault сначала попытается загрузить их из своего каталога приложения, прежде чем перейти к остальной части порядка поиска DLL. Обратите внимание, что обычно это не проблема, поскольку каталог приложения WerFault — это и есть System32.

2.

Скачайте одну из перехватываемых DLL с целевой системы.

Это необходимо, чтобы мы могли извлечь её экспортируемые функции и включить их в нашу DLL-полезную нагрузку. Важно скачать перехватываемую DLL с той же машины, на которой вы планируете использовать DropSpawn, поскольку DLL меняются между версиями Windows. Кроме того, если вы используете x86 beacon и хотите запустить x64 beacon с помощью DropSpawn, убедитесь, что вы скачали x64 версию настоящей DLL, указав 'C:\windows\sysnative...' вместо 'C:\windows\system32...'.

3.

Запустите generate_dll.py, передав скачанную DLL и желаемую архитектуру полезной нагрузки. Generate_dll.py — это модифицированная версия этого скрипта. Он анализирует предоставленную DLL, создаёт .def файл, содержащий экспортируемые функции DLL, и вызывает MingW для компиляции нашей демонстрационной DLL-полезной нагрузки. Когда порождённый процесс попытается вызвать реальную функцию внутри подменённой DLL, наша DLL-полезная нагрузка перенаправит вызов к настоящей DLL, находящейся в System32, чтобы основной процесс не завершился с ошибкой.

4.

Вызовите dropspawn, используя сгенерированную DLL-полезную нагрузку.

dropspawn <payload DLL> <x86|x64> <program to spawn> [writable target folder] [parent]

payload DLL — полный путь к сгенерированной DLL-полезной нагрузке.
architecture — архитектура процесса, который вы хотите запустить
program to spawn — имя/путь процесса, который вы хотите запустить. Если этот процесс находится в System32 (или syswow64), вы можете указать только имя. В противном случае укажите полный путь. Вы также можете передать аргументы командной строки процессу. Если в пути есть пробелы/если вы используете аргументы, заключите всё в кавычки.
writable target folder — Необязательно. Если оставить пустым, dropspawn попытается использовать текущий каталог Beacon'а. Используйте кавычки, если в пути есть пробелы.
parent — Необязательно. Имя процесса, который будет использоваться для подмены PPID у нового порождённого процесса. Если указан процесс, имеющий несколько запущенных экземпляров с разными уровнями привилегий (например, svchost.exe), dropspawn попытается определить тот, который можно использовать для подмены PPID.

Пример: dropspawn /root/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe

Это поместит DLL-полезную нагрузку 'dbgcore.dll' на диск по пути 'c:\users\user\appdata\local\temp\dbgcore.dll' и запустит x64 процесс WerFault.exe с аргументами командной строки '-u -p 4352 -s 160' и explorer.exe в качестве родительского процесса.

5.

Очистка проста. Благодаря включению функции Self-Deletion в DLL-полезную нагрузку, которая сохраняется на диск, она будет удалена, как только наш новый процесс запустится и загрузит её. Это меняет правила игры, поскольку обычно DLL остаётся заблокированной на диске, пока продолжает работать процесс, который её загрузил. Если техника Self-Deletion по какой-то причине не сработает (или процесс не сможет запуститься), DropSpawn попытается удалить DLL-полезную нагрузку с диска и в любом случае сообщит пользователю о результате операции.

Обнаружение

Внедрение в процессы обычно следует цепочке «открыть удалённый процесс -> выделить удалённую память -> записать в удалённую память -> выполнить в удалённой памяти», с возможностью запуска нового процесса в начале вместо использования существующего. DropSpawn только создаёт новый процесс; вновь порождённый процесс отвечает за выделение, запись и выполнение шеллкода, поэтому мы можем избежать многих IOC, обычно связанных с внедрением в удалённые процессы.

Эта техника, конечно, зависит от того, насколько хороши ваши DLL-полезные нагрузки. Но мы можем посмотреть, что видит Windows (в этом разделе используется приватная версия DropSpawn и запуск Beacon'ов).

Что касается Event Viewer, всё выглядит нормально:

В MDE почти ничего не видно.

Запуск dropspawn:

Журналы MDE:

С подменой PPID:

Без подмены PPID:

В обоих случаях мы видим, как наш исходный процесс beacon'а (также werfault) сохраняет dbgcore.dll на диск, создаёт новый процесс WerFault.exe, вновь порождённый процесс загружает dbgcore.dll, а затем переименовывает (удаляет) её. Важно отметить, что нет дополнительного внимания к dbgcore.dll, которое часто сопровождает перехват DLL, потому что мы не записываем её в часто перехватываемые места, и WerFault.exe (или любой другой выбранный вами процесс) не ассоциируется с перехватом DLL так, как, например, WmiPrvSE.exe.

Интересно, что эта операция почти более заметна с подменой PPID, чем без неё. Однако это может варьироваться в зависимости от продукта безопасности.

Ограничения

Как уже упоминалось, крайне важно, чтобы пользователи скачивали настоящие DLL с целевой машины, на которой они планируют использовать DropSpawn. Использование неправильной версии DLL может привести к сбою порождённого процесса, если он попытается вызвать функцию, которая не существует.

DropSpawn можно использовать с исполняемыми файлами за пределами System32; однако предупреждаем, что могут возникнуть проблемы, если процесс попытается загрузить дополнительные DLL из настоящего каталога приложения процесса. Поскольку мы подменили каталог приложения в другом месте, если настоящий каталог приложения также не доступен через порядок поиска DLL иным образом, процесс завершится с ошибкой или не сможет запуститься, потому что не сможет найти важные DLL. Всегда тестируйте потенциальные перехваты на разработочных машинах перед использованием в производственной среде!

Благодарности

Это исследование началось, когда я изучал, как процессы формируют свой окончательный порядок поиска DLL (поскольку он должен определяться во время выполнения из-за исполняемых файлов, находящихся в разных каталогах, текущего каталога как части пути поиска и т.д.). Мои исследования привели меня к этому сообщению на форуме, которое послужило источником двух критически важных недокументированных API, лежащих в основе этой техники.

На них уже были ссылки выше, но эта статья об избежании блокировки загрузчика, этот скрипт для генерации .def файла для проксирования DLL и это исследование о включении самоудаления запущенных исполняемых файлов необходимы для создания эффективных, боевых DLL-полезных нагрузок, подходящих для DropSpawn.

Когда я впервые опубликовал эту технику в Twitter, несколько других специалистов присоединились к обсуждению и создали POC. SecurityAndStuff создал этот, а у Snovvcrash есть свой здесь