Обнаружение рефлексивной DLL-инъекции

В последние несколько лет вредоносное ПО (и некоторые инструменты для проверки пера, такие как полезная нагрузка метапроцессора Metasploit) начали использовать рефлексивная инъекция DLL (PDF) загрузить DLL в память процесса. Преимущество в том, что файл никогда не записывается на диск и его трудно обнаружить. Многие примеры, которые я видел, основаны на Joachim Bauch work.

Тем не менее, в DEF CON 20 Эндрю Кинг продемонстрировал, что он смог обнаружить DLL-инъекцию с использованием рефлексивной DLL-инъекции. Его презентация называлась " Обнаружение рефлексивной инъекции". ~~К сожалению, он не выпустил исходный код (которого он, безусловно, не обязан делать).~~

UPDATE: По-видимому, я пропустил это, но Андрей сделал эту работу пару лет назад: https://github.com/aking1012/dc20

Кроме того, инструмент, называемый Antimeter, может обнаруживать двигатель измерителя при загрузке с использованием рефлексивной dll-инъекции. Опять же, закрытый источник.

Я понимаю, что инструмент Andrew King и Antimeter написаны на Python и используют pydbg/pydasm для перечисления памяти на выполнение исполняемых файлов.

Есть ли у кого-нибудь общий исходный код (в Python, C, Delphi или иначе), который они готовы поделиться, что демонстрирует, как обнаружить рефлексивную DLL-инъекцию? Существуют средства судебной экспертизы памяти, которые могут анализировать дамп памяти и находить это, но я ищу для запуска приложения на работающей системе (например, с помощью антиметра) и поиска процессов с отраженными впрысками DLL.

Если вы заинтересованы в понимании того, как работает рефлексивная DLL-инъекция, существует некоторый открытый код, написанный в Delphi, который показывает, как это сделать это.

UPDATE: Я тестировал, и я могу отражать DLL без прав администратора (и как обычный пользователь), но, конечно, как ПОЛЬЗОВАТЕЛЬ, я могу только вводить в процессы, выполняющиеся на одном уровне целостности (и в моей сессии)... но это все еще охватывает приложения, такие как Office, Internet Explorer и т.д.

Ответ 1

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

NTSYSAPI NTSTATUS NTAPI ZwProtectVirtualMemory(
    IN HANDLE ProcessHandle,
    IN PVOID *  BaseAddress,
    IN SIZE_T *     NumberOfBytesToProtect,
    IN ULONG    NewAccessProtection,
    OUT PULONG  OldAccessProtection 
);

Если вы подключаете это в самом начале вашей программы, вы можете отфильтровать подозрительные вызовы защиты (тот, который разрешает выполнение кода). Затем я сканирую PE-заголовок или такой перед запрошенными страницами, чтобы узнать, что его загружаемый модуль... note: Я думаю, что это не вызывается для обычных DLL, поскольку LoadLibrary обрабатывает это в пространстве ядра. правильно? TODO: проверьте

Обычно в заголовке PE находится 0x1000 (4096) байт или одна страница перед первым исполняемым кодом. Таким образом, ОЧЕНЬ базовый подход может быть для сканирования тега "MZ":

char* pe = ((char*)BaseAddress) - 0x1000;
if ((NewAccessProtection == PAGE_EXECUTE || ... ) & pe[0] == 'M' && pe[0] == 'Z')
{
    // do checks here
}

Если вам нужна дополнительная информация об API-подключении, просто спросите или прочитайте множество статей в сети. Другой кандидат-кандидат: FlushInstructionCache (...). Но я думаю, что только Blizzard использует это для чириканских модулей для защиты от усталости, поскольку это не значит, что архитектура x86 может вызвать это.

... просто мысль,

будет