Как вредоносные программы используют «reflected DLL injection» — и как это заметить

Как вредоносные программы используют «reflected DLL injection» — и как это заметить

Если ты работаешь с инцидентами кибербезопасности, то наверняка сталкивался с ситуацией: процесс выглядит абсолютно легитимным — запущен от имени системы, не вызывает подозрений в диспетчере задач, но при этом ведёт себя странно: отправляет данные, подключается к подозрительным IP, создает неизвестные файлы. При этом антивирус молчит. В таких случаях один из самых коварных методов, который может быть за этим — reflected DLL injection. Это не просто «внедрение DLL», а умная, почти невидимая техника, которую используют продвинутые вредоносные программы, чтобы обойти даже современные системы защиты.

Суть проста: вредоносная программа не загружает DLL напрямую. Она копирует её содержимое в память целевого процесса, а затем заставляет этот же процесс сам «восстановить» и запустить свою же DLL — как будто она изначально была частью его кода. Никаких вызовов LoadLibrary, никаких следов на диске, никаких аномалий в логах загрузки модулей. И это делает метод практически неуловимым для стандартных сканеров.

Почему именно reflected DLL injection?

Традиционные методы внедрения DLL — например, через CreateRemoteThread + LoadLibrary — давно известны. Антивирусы и EDR-системы отслеживают вызовы этих функций. Если ты видишь, что explorer.exe вызывает LoadLibrary с путём к DLL из %TEMP% — это красный флаг. Но reflected DLL injection работает иначе.

Вот как это происходит на практике:

1. Вредоносная программа (например, загруженный через фишинг скрипт) читает DLL-файл с диска или из памяти в буфер.
2. Она выделяет память в целевом процессе (например, в svchost.exe или lsass.exe) с помощью VirtualAllocEx.
3. Копирует туда содержимое DLL — но не как обычный файл, а как набор байтов, без метаданных.
4. Находит в DLL адрес точки входа (обычно это _DllMainCRTStartup), и записывает его в память целевого процесса.
5. Создаёт удалённую нить (CreateRemoteThread), но вместо того, чтобы передать ей адрес LoadLibrary, передаёт адрес точки входа DLL, скопированной в память.
6. Когда нить запускается, она сама начинает выполнять код DLL — но в контексте легитимного процесса. DLL не загружается как модуль, она просто выполняется как код в памяти.

Результат? DLL не появляется в списке загруженных модулей процесса (как в Process Explorer или VMMap). Антивирус не видит её как DLL — потому что она не загружена через стандартный механизм. EDR-системы, которые следят только за вызовами LoadLibrary, остаются слепы.

Как выглядит это на реальном примере?

Представь, что злоумышленник получил доступ к машине через фишинговый документ. Он хочет украсть учетные данные из lsass.exe — процесса, который хранит пароли в памяти. Вместо того, чтобы загружать mimikatz.dll напрямую, он делает так:

• Копирует бинарник mimikatz.dll в память как массив байт.
• Находит в нём смещение точки входа (это не DllMain, а внутренняя функция, которая вызывается при инициализации).
• Выделяет память в lsass.exe и записывает туда эти байты.
• Запускает удалённую нить с адресом точки входа — и код начинает работать как будто он всегда был частью lsass.exe.
• Он извлекает хэши паролей, удаляет следы, и уходит.

В диспетчере задач — всё чисто. В Process Explorer — нет новых DLL в списке модулей. В логах EDR — нет подозрительных вызовов LoadLibrary. Только если ты смотришь на поведение процесса — например, неожиданные сетевые соединения или чтение памяти других процессов — ты поймёшь, что что-то не так.

Чем reflected DLL injection отличается от других методов?

Вот таблица, которая показывает, как этот метод сравнивается с другими техниками внедрения:

Как видишь, reflected DLL injection — это «золотая середина» для злоумышленника: он получает полный контроль в легитимном процессе, без следов на диске и без типичных триггеров в системах защиты. Это не «хакерская фича» — это стандартный инструмент в арсенале APT-групп и коммерческих RAT-ов вроде Cobalt Strike, Metasploit и других.

Как это обнаружить?

Ты не можешь найти DLL, если её нет в списке модулей. Но ты можешь найти поведение.

Вот что смотреть:

1. Неожиданные вызовы CreateRemoteThread в легитимных процессах. Особенно если источник — cmd.exe, powershell.exe, или wscript.exe, а цель — svchost.exe, lsass.exe, winlogon.exe.
2. Выделение памяти с флагом PAGE_EXECUTE_READWRITE в процессах, где это не нужно. Например, в explorer.exe — это почти всегда подозрительно.
3. Наличие байтового кода в памяти, который не соответствует образу процесса. В Process Explorer можно открыть вкладку «View» → «Lower Pane» → «DLLs», а затем в правой части — «Memory» → «View Memory». Если ты видишь куски кода, которые не принадлежат ни одному из загруженных модулей — это тревожный знак.
4. Поведенческие аномалии: процесс, который внезапно начинает делать сетевые запросы к IP-адресам в странах, где у компании нет офисов; или читает память других процессов (например, lsass.exe из svchost.exe).

Самый надёжный способ — использовать EDR с поведенческим анализом. Например, CrowdStrike, SentinelOne или Microsoft Defender for Endpoint. Они не ищут DLL — они смотрят на действия: «Процесс A внезапно начал выполнять код, скопированный в память из процесса B, без загрузки DLL». Это именно то, что нужно.

Частые ошибки при анализе

Даже опытные аналитики делают одни и те же ошибки:

• Смотрят только на список DLL. Если DLL нет — значит, всё чисто. Нет. Reflected DLL injection не оставляет следов в этом списке.
• Доверяют только сигнатурам антивируса. Если антивирус не ругается — значит, вируса нет. Но reflected DLL injection часто использует «чистые» DLL, которые не известны как вредоносные. Их код — это просто набор байтов, без вредоносных сигнатур.
• Игнорируют вызовы VirtualAllocEx и WriteProcessMemory. Эти вызовы — основа всего. Если ты их не отслеживаешь, ты слеп.
• Проверяют только пользовательские процессы. Атаки чаще всего направлены на системные процессы: svchost.exe, lsass.exe, spoolsv.exe. Они тише, и их меньше проверяют.
• Ожидают, что вредонос будет писать на диск. Reflected DLL injection работает исключительно в памяти. Никаких файлов — только байты в RAM.

Как лучше делать: практические рекомендации

Если ты — ИТ-специалист, администратор или аналитик безопасности — вот что делать:

1. Включи поведенческую детекцию в EDR. Не полагайся только на сигнатуры. Убедись, что твоя система отслеживает: создание исполняемой памяти в легитимных процессах, вызовы CreateRemoteThread с нестандартными параметрами, и копирование кода между процессами.
2. Настрой алерты на вызовы VirtualAllocEx + WriteProcessMemory в системных процессах. Особенно если источник — PowerShell, cmd, или любой скриптовый интерпретатор.
3. Используй Process Explorer или Process Hacker для ручного анализа. Открой подозрительный процесс → перейди в «Memory» → включи «Show memory regions». Ищи регионы с флагом EXECUTE_READWRITE, которые не принадлежат ни одному из загруженных модулей.
4. Сравнивай хэши памяти процесса с эталонными. Если у тебя есть «чистый» образ процесса (например, после перезагрузки), можешь сравнить его с текущим. Любые неожиданные блоки кода — повод для глубокого анализа.
5. Ограничь выполнение скриптов. 90% таких атак начинаются с PowerShell или VBScript. Используй AppLocker или WDAC, чтобы запретить запуск скриптов из %TEMP% или %USERPROFILE%.

Что выбрать в зависимости от ситуации?

Если ты не знаешь, с чего начать — вот сценарии:

• Ситуация: у тебя есть EDR, но он не ловит ничего → Включи режим «Behaviour Monitoring» и настрой алерты на CreateRemoteThread + VirtualAllocEx в системных процессах.
• Ситуация: у тебя нет EDR, только антивирус → Обнови антивирус, но не рассчитывай на него. Начни с ограничения прав пользователя (не запускай Excel/Word от имени админа) и отключения PowerShell в офисе, если он не нужен.
• Ситуация: ты подозреваешь компрометацию, но не можешь найти вредонос → Загрузи Process Hacker → найди svchost.exe с высоким CPU или сетевой активностью → открой его память → ищи неизвестные исполняемые регионы. Если есть — сделай дамп памяти и проанализируй его в IDA Pro или Ghidra.
• Ситуация: ты разрабатываешь защиту для компании → Внедри WDAC (Windows Defender Application Control) + EDR с поведенческим анализом. Это единственный способ остановить reflected DLL injection на уровне предотвращения.

Итог: что делать прямо сейчас

Если ты читаешь это — значит, ты либо столкнулся с подозрительной активностью, либо хочешь быть готовым. Вот что делать:

1. Проверь, есть ли у тебя EDR с поведенческим анализом. Если нет — это твоя главная уязвимость.
2. Включи логирование вызовов VirtualAllocEx, WriteProcessMemory и CreateRemoteThread в системе. Даже если ты не знаешь, как их анализировать — собери их. Потом с ними можно работать.
3. Не доверяй «чистым» процессам. Если svchost.exe внезапно начал делать сетевые запросы — это не «нормально». Это признак заражения.
4. Обучи свою команду: «Если DLL нет в списке — это не значит, что её нет». Reflected DLL injection — это не редкость. Это стандарт.

Этот метод не «суперсложный». Он прост, элегантен и работает. Потому что он использует саму систему против неё. Ты не можешь его устранить — но можешь его обнаружить. И если ты знаешь, на что смотреть, ты уже на шаг впереди злоумышленника.

Информация в этой статье предназначена для ознакомления и не заменяет профессиональную кибербезопасностную диагностику. При подозрении на компрометацию системы рекомендуется обратиться к специалисту по инцидент-реагированию.