Как антивирусы и EDR обнаруживают вредоносный код: сигнатуры, поведение и анализ памяти

zer0coder · 13.08.2026

А можешь рассказать как обходят детект в памяти ?

Qwen · 13.08.2026

Коротко

Обход детекта в памяти — это не одна техника, а уменьшение количества артефактов, по которым AV/EDR строит обнаружение:

байтовые сигнатуры в исполняемой памяти;
подозрительные права страниц, например RWX;
PE-заголовки, секции, импорты в private memory;
потоки, стартующие из «unbacked» памяти;
подозрительные цепочки API: VirtualAllocEx → WriteProcessMemory → VirtualProtectEx → CreateRemoteThread / QueueUserAPC;
хуки, ETW, AMSI, CLR, PowerShell telemetry;
аномальные стеки вызовов и источники системных вызовов.

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

────────────────────

Что AV/EDR обычно смотрит в памяти

1. Статические признаки в памяти

Сканер памяти может искать:

MZ / PE заголовки в private memory;
известные shellcode-паттерны;
строки: cmd.exe, powershell, mimikatz, lsass, URL, ключи, токены;
импорты API: VirtualAlloc, WriteProcessMemory, CreateRemoteThread, NtCreateThreadEx, QueueUserAPC, SetThreadContext;
хеши строк, подозрительные константы;
высокую энтропию в исполняемых страницах;
фрагменты известных PE, DLL, shellcode, .NET-сборок.

2. Свойства регионов памяти

EDR и memory scanners обращают внимание на:

PAGE_EXECUTE_READWRITE;
private executable memory, не привязанную к образу;
регионы, созданные через VirtualAlloc / VirtualAllocEx;
регионы, куда писали данные, затем сделали исполняемыми;
исполняемую память внутри процесса, но вне загруженных модулей;
страницы с высоким уровнем энтропии;
RW-страницы, которые позже становятся RX.

3. Поведенческие цепочки

Типичная инъекция выглядит как последовательность:

Код:

OpenProcess / NtOpenProcess
VirtualAllocEx
WriteProcessMemory
VirtualProtectEx
CreateRemoteThread / NtCreateThreadEx / QueueUserAPC / SetThreadContext

Даже если каждая операция легитимна по отдельности, цепочка и контекст процесса часто являются индикатором.

4. Потоки и стеки

EDR может проверять:

StartAddress потока;
находится ли адрес старта внутри загруженного модуля;
есть ли у потока backing image;
стек вызовов;
соответствует ли стек ожидаемому модулю;
не выполняется ли код из стека или кучи;
не был ли поток создан удалённо;
не использовался ли APC к существующему потоку.

5. User-mode hooks и телеметрия

Многие EDR ставят user-mode hooks в:

ntdll.dll;
kernel32.dll;
kernelbase.dll;
CLR / .NET;
AMSI;
PowerShell;
ETW providers.

Через них видны:

вызовы WinAPI;
параметры аллокации памяти;
загрузку DLL;
создание потоков;
доступ к процессам;
сетевые подключения;
скриптовый код;
.NET assembly loads.

6. Kernel-mode telemetry

На уровне ядра могут использоваться:

PsSetCreateProcessNotifyRoutine;
PsSetCreateThreadNotifyRoutine;
PsSetLoadImageNotifyRoutine;
object callbacks;
minifilters;
ETW kernel providers;
WFP для сети;
kernel callbacks для контроля памяти и потоков.

────────────────────

Основные классы обхода детекта в памяти

1. Шифрование и кодирование payload

Идея: полезная нагрузка не хранится в памяти в открытом виде.

Типовые подходы:

XOR, RC4, AES, ChaCha20;
encoding: base64, custom encoders;
multi-stage decryption;
расшифровка только перед выполнением;
повторное шифрование во время сна;
хранение ключа отдельно от данных;
получение ключа из окружения, времени, хеша файла, реестра, сети.

Что это даёт атакующему:

нет статических строк;
нет явных сигнатур;
высокая энтропия вместо читаемого кода;
сложнее сканировать память по YARA.

Что остаётся видимым:

высокая энтропия в исполняемых регионах;
вызовы крипто-API;
паттерны decrypt stub;
последовательность write → protect → execute;
короткоживущие расшифрованные участки;
изменения энтропии региона между сканами;
подозрительные таймеры и периодическая расшифровка.

Детект:

мониторинг VirtualProtect после записи;
анализ энтропии executable pages;
сканирование памяти в момент выполнения, а не только в покое;
ETW telemetry по crypto API;
поведенческие правила: decrypt → execute → network.

────────────────────

2. Отказ от `PAGE_EXECUTE_READWRITE`

Классический красный флаг для EDR — долгоживущая память с правами RWX.

Поэтому в лабораторных образцах часто делают:

Код:

allocate RW
write payload
change to RX
execute

или:

Код:

allocate RW
decrypt
change to RX
execute
re-encrypt / free

Что это даёт:

нет постоянного RWX;
память выглядит менее подозрительно.

Что остаётся:

VirtualProtect меняет страницу на executable после записи;
регион private, не привязан к образу;
поток стартует из private memory;
в момент выполнения код всё равно может быть просканирован;
цепочка операций остаётся в телеметрии.

Детект:

логировать VirtualAlloc + VirtualProtect + thread creation;
отслеживать private executable memory;
проверять, был ли регион записан перед получением execute-прав;
анализировать время жизни RX-страниц.

────────────────────

3. Удаление PE-заголовков и manual mapping

Если в памяти находится полноценный PE, его легко найти по:

MZ;
PE\0\0;
section headers;
import table;
relocations;
строкам;
именам секций.

Поэтому payload может:

стирать DOS header;
стирать NT headers;
не хранить import table;
резолвить API по хешам;
выполнять код как position-independent shellcode;
использовать manual mapping без полного PE.

Что это даёт:

memory scanner не видит классический PE;
меньше строк и структур;
сложнее восстановить модуль из дампа.

Что остаётся:

unbacked executable memory;
поток с адресом старта вне известного модуля;
стек, не соответствующий нормальному image;
вызовы API через косвенные механизмы;
подозрительные memory regions;
отсутствие легитимного VAD image.

Детект:

проверять thread StartAddress;
искать executable memory без backing file/image;
анализировать VAD tree;
сравнивать память с загруженными модулями;
использовать Volatility / WinDbg для forensic-проверки.

────────────────────

4. Использование легитимных модулей

Вместо создания собственной private memory payload может пытаться выполняться внутри легитимных модулей.

Примеры направлений:

module stomping;
перезапись .text загруженной DLL;
использование JIT-памяти;
выполнение через CLR / .NET;
выполнение через JavaScript / VBScript / PowerShell engines;
использование signed binary как proxy.

Что это даёт:

память принадлежит подписанному модулю;
поток стартует внутри известного image;
меньше unbacked memory.

Что остаётся:

содержимое модуля может не совпадать с хешем на диске;
code integrity может видеть модификации;
EDR может сравнивать in-memory bytes с file bytes;
поведение модуля может быть аномальным;
вызовы из .text могут идти на неожиданные адреса;
могут появляться modified code pages.

Детект:

сверка хешей загруженных DLL;
проверка подписи и пути;
обнаружение модифицированных executable pages внутри image;
анализ VAD и module list;
контроль аномальных child process / network / API chains.

────────────────────

5. Обход user-mode hooks

EDR часто hook'ает ntdll.dll, чтобы видеть API-вызовы. Поэтому исследуются способы обойти такие hooks.

Типовые направления:

чтение чистого ntdll.dll с диска и восстановление syscall stubs;
direct syscalls;
indirect syscalls через gadget в ntdll;
использование syscall-номеров, характерных для текущей версии Windows;
обход hooks в kernel32 / kernelbase;
patching ETW event write;
patching AMSI scan buffer;
использование native API без WinAPI wrappers.

Что это даёт:

user-mode EDR hook может не увидеть вызов;
часть телеметрии теряется;
AMSI может не получить скрипт или .NET assembly;
ETW может не отправить событие.

Что остаётся:

kernel callbacks всё ещё могут видеть процессы, потоки, образы;
ETW Threat Intelligence может давать более низкоуровневые события;
syscall source может быть не из ожидаемого модуля;
syscall number может не соответствовать обычному call path;
stack trace может быть подозрительным;
tamper protection может заметить patching;
HVCI / CET / CFG могут ломать часть техник;
EDR может проверять целостность собственных hooks и DLL.

Детект:

контролировать целостность ntdll.dll, EDR DLL, AMSI DLL;
использовать kernel-level telemetry;
анализировать call stacks;
проверять источник syscall;
включать Tamper Protection;
использовать Protected Process Light для EDR;
мониторить попытки patching ETW/AMSI.

────────────────────

6. ETW и AMSI bypass

ETW и AMSI дают защитным решениям много данных, поэтому их часто пытаются ослабить.

Типовые поверхности:

EtwEventWrite;
EtwEventWriteFull;
AmsiScanBuffer;
AmsiScanString;
CLR ETW providers;
PowerShell ScriptBlock Logging;
.NET assembly load telemetry.

Что пытаются сделать в лабораторных исследованиях:

патчить функции, чтобы они возвращали успех без отправки события;
подменять буферы;
отключать providers;
ломать инициализацию AMSI;
использовать constrained language mode bypasses;
загружать .NET сборки так, чтобы обойти assembly load logging.

Что остаётся:

изменения в памяти системных DLL;
неожиданные return instructions в начале функций;
отсутствие ожидаемых событий при подозрительном поведении;
alerts от Tamper Protection;
kernel ETW может продолжать работать;
EDR может детектить отсутствие собственной телеметрии как аномалию.

Детект:

проверять целостность AMSI/ETW functions;
мониторить patching системных DLL;
сравнивать ожидаемый поток событий с фактическим;
включать PowerShell logging, .NET ETW, ScriptBlock Logging;
использовать Defender Tamper Protection.

────────────────────

7. Скрытое создание потоков

Классический CreateRemoteThread хорошо детектится. Поэтому используются альтернативы:

QueueUserAPC;
NtQueueApcThread;
SetThreadContext;
NtCreateThreadEx;
создание потока внутри собственного процесса;
hijacking существующего потока;
использование legitimate thread pool mechanisms;
выполнение через callback-структуры.

Что это даёт:

меньше очевидных remote thread events;
поток может выглядеть как часть легитимной активности.

Что остаётся:

kernel thread notify routines;
EDR может видеть APC queueing;
thread context changes;
необычный start address;
подозрительный stack;
поток может стартовать из unbacked memory;
поведение целевого процесса меняется.

Детект:

Sysmon Event ID 8: CreateRemoteThread;
Sysmon Event ID 10: ProcessAccess;
EDR telemetry по APC и thread context;
kernel thread callbacks;
анализ start address и stack.

────────────────────

8. Sleep obfuscation

Если payload долго находится в памяти, его могут сканировать. Поэтому в лабораторных образцах иногда делают:

шифрование payload перед сном;
расшифровку перед действием;
смену прав страниц;
очистку или перезапись памяти;
использование таймеров;
повторное шифрование после выполнения.

Что это даёт:

в момент простоя память не содержит явного кода;
периодические memory scans могут не находить payload.

Что остаётся:

регулярные VirtualProtect / VirtualAlloc / VirtualFree;
изменения энтропии;
подозрительные таймеры;
короткие моменты executable memory;
поведенческие цепочки после пробуждения;
stack anomalies, если поток продолжает работать с подменённым стеком.

Детект:

отслеживать частые protect/free/allocate cycles;
сканировать память в разные моменты времени;
анализировать entropy changes;
коррелировать sleep patterns с последующей сетевой или credential activity.

────────────────────

9. Stack spoofing

Современные EDR могут анализировать call stack при системных вызовах. Если стек выглядит неправильно, это повышает score события.

Поэтому исследуются техники:

подмена user stack;
использование ROP-like chains;
вызовы через legitimate frames;
indirect syscalls;
возврат через expected module code;
spoofing thread context.

Что это даёт:

call stack выглядит более легитимным;
сложнее отличить direct syscall от обычного API call.

Что остаётся:

несоответствие stack pointers;
отсутствие expected return addresses;
CET / shadow stack может выявлять подмену;
kernel-side stack validation;
аномальные transition pages;
несоответствие между syscall source и stack.

Детек

zer0coder · 13.08.2026

Продолжи...

Qwen · 13.08.2026

Продолжение. Ниже — дальнейший разбор техник, которые обычно рассматривают при исследовании обхода детекта в памяти, и, что важнее, как это обнаруживать и проверять в локальной лаборатории / авторизованном аудите.

Детект stack spoofing

Для подмены стека защитные решения могут проверять не только сам факт системного вызова, но и целостность call stack.

Признаки, которые могут вызывать подозрение:

RIP указывает на ntdll, но стек начинается из private memory, heap или unbacked region.
RSP или return addresses не соответствуют ожидаемым фреймам.
В стеке отсутствуют нормальные frames из kernelbase.dll, kernel32.dll, CLR или другого ожидаемого модуля.
Системный вызов выполняется через direct syscall, но user-mode stack выглядит как подделанный.
Return address указывает на страницу с правами RW, RX без backing image или на адрес вне модуля.
Поток использует нестандартный stack base / stack limit.
Обнаруживаются признаки ручной сборки ROP/JOP-цепочек.

Методы защиты и проверки:

Проверка call stack в момент критических событий: process access, thread creation, memory allocation, image load.
Сравнение return addresses с загруженными модулями.
Контроль целостности стека через CET / Shadow Stack, если доступно.
Анализ StartAddress, StackBase, StackLimit потока.
Корреляция событий: если поток создан из unbacked memory и затем делает sensitive API call, это повышает риск.
Использование kernel-level telemetry, а не только user-mode hooks.

────────────────────

Direct syscalls и indirect syscalls

Один из известных классов обхода user-mode hooks — выполнение системных вызовов напрямую, минуя hooked функции в ntdll.dll.

Что пытаются обойти

EDR часто ставит hooks в:

ntdll.dll
kernel32.dll
kernelbase.dll
CLR / AMSI / ETW write paths

Если hook стоит в NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThreadEx, NtQueueApcThread, то direct syscall может попытаться выполнить syscall instruction без прохода через hooked prologue.

Что остаётся видимым

Даже при direct syscall защитное решение может увидеть:

сам факт системного вызова через kernel callbacks;
несоответствие источника вызова: syscall пришёл не из ожидаемого диапазона ntdll.dll;
подозрительный syscall number;
странный call stack;
отсутствие ожидаемых user-mode API events;
аномальную последовательность операций;
обращение к чувствительным процессам или памяти.

Детект

Анализ источника syscall: user-mode address, module, VAD.
Сравнение syscall instruction address с ожидаемым диапазоном ntdll.dll.
ETW Threat Intelligence / kernel audit providers.
Контроль целостности ntdll.dll и EDR hooks.
Поведенческая корреляция: allocation + write + protect + thread execution.
Обнаружение попыток читать syscall numbers из ntdll или использовать hardcoded syscall tables.

────────────────────

Hardware breakpoints и debug-механизмы

Иногда для скрытия выполнения или перехвата потока используются debug registers, vectored exception handling, SetThreadContext, hardware breakpoints.

Что может использоваться

SetThreadContext
GetThreadContext
DebugActiveProcess
WaitForDebugEvent
ContinueDebugEvent
Vectored Exception Handler
Hardware breakpoints через debug registers
Изменение RIP, RSP, RFLAGS в контексте потока

Почему это подозрительно

Такие механизмы позволяют:

перенаправить выполнение;
скрыть реальный entry point;
изменить поток без создания нового;
обойти часть hooks;
выполнить код через exception handling.

Детект

Мониторинг SetThreadContext с изменением instruction pointer.
Контроль DebugActiveProcess против критичных процессов.
Анализ неожиданных vectored exceptions.
Проверка изменений CONTEXT потока.
Обнаружение hardware breakpoints в debug registers.
Корреляция debug events с последующим выполнением кода из private memory.

Защитные меры:

Ограничение SeDebugPrivilege.
Контроль использования debug API в не-отладочных процессах.
LSA Protection / PPL для критичных процессов.
Аудит доступа к lsass.exe, winlogon.exe, csrss.exe, services.exe.

────────────────────

Reflective DLL loading

Reflective loading позволяет загрузить DLL в память без стандартного LoadLibrary.

Признаки

DLL присутствует в памяти, но отсутствует в обычном module list.
Нет соответствующего VAD image.
PE-структура находится в private memory.
Поток или callback стартует из региона, не привязанного к модулю.
В памяти есть PE header, но модуль не виден через EnumProcessModules.
IAT/EAT может быть восстановлена вручную.

Что ищет EDR / memory scanner

MZ / PE в private executable memory.
Подозрительные секции .text, .data, .rdata вне легитимного image.
Unbacked executable memory.
Thread start address вне известных модулей.
Несоответствие между VAD и module list.
Подозрительные строки, импорты, экспорты.

Детект

Сравнение списка загруженных модулей с VAD tree.
Поиск executable regions без backing file.
Проверка PE headers в private memory.
Анализ thread start addresses.
Memory forensics через Volatility / WinDbg.
Контроль аномальных VirtualAlloc + VirtualProtect + execution chains.

────────────────────

Module stomping

Module stomping — это техника, при которой payload размещается внутри уже загруженного легитимного модуля, часто с перезаписью его executable memory.

Почему это сложнее для детекта

Память принадлежит подписанному модулю.
VAD указывает на легитимный файл.
Поток может стартовать внутри известного image.
Нет obvious unbacked memory.

Что всё равно можно обнаружить

Содержимое памяти модуля не совпадает с файлом на диске.
Хеш in-memory .text отличается от expected hash.
Изменены executable pages внутри signed DLL.
Модуль ведёт себя нетипично: сеть, доступ к lsass, создание процесса, injection.
Вызовы из модуля идут на unexpected addresses.
Появляются modified code pages после загрузки.

Детект

Сверка хешей загруженных DLL с дисковыми файлами.
Проверка подписи, пути, версии.
Обнаружение изменений в executable sections.
Контроль image integrity через kernel callbacks или EDR driver.
Поведенческий анализ: signed module + suspicious behavior.
Использование HVCI / Code Integrity, где возможно.

────────────────────

Process hollowing, doppelgänging, ghosting и похожие техники

Эти техники связаны с подменой или манипуляцией процессом на этапе создания или загрузки образа.

Общие признаки

Процесс создан легитимно, но его memory image не соответствует ожидаемому.
Original image был unmapped или заменён.
Thread starts from unexpected address.
VAD tree содержит аномалии.
Process path и фактический memory content не совпадают.
Процесс запускается из suspicious parent или с suspicious command line.

Что можно детектить

Несоответствие между process image path и memory layout.
Отсутствие ожидаемого PE header.
Изменённый entry point.
Подозрительные section objects.
Аномальные transaction / file mapping operations.
Создание процесса в suspended state с последующим thread resume.
Доступ к процессу с правами PROCESS_VM_WRITE, PROCESS_VM_OPERATION, PROCESS_CREATE_THREAD.

Защитные сигналы

Sysmon Event ID 1: Process Creation.
Sysmon Event ID 8: CreateRemoteThread.
Sysmon Event ID 10: ProcessAccess.
EDR process creation telemetry.
Kernel process notify callbacks.
VAD analysis.
Memory forensics.

────────────────────

Shared memory и section objects

Иногда payload передаётся через shared memory, section objects, mapped views.

Почему это используется

Можно передать данные между процессами без классического WriteProcessMemory.
Можно создать executable section и mapping в целевом процессе.
Меньше obvious injection API calls.

Признаки

Создание section object с execute rights.
Mapping view в чужой процесс.
Подозрительные права: SECTION_MAP_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE.
Cross-process mapping в чувствительный процесс.
Исполнение кода из mapped view.
Отсутствие ожидаемого backing file или suspicious file path.

Детект

Мониторинг создания section objects.
Контроль cross-process memory mapping.
Анализ VAD на executable shared memory.
Проверка backing file.
Поведенческая корреляция: shared memory + thread execution + network / credential access.

────────────────────

.NET, CLR, PowerShell и in-memory assemblies

Многие современные атаки выполняются не как классический native shellcode, а через managed runtime.

Что может выполняться в памяти

.NET assembly через Assembly.Load(byte[])
Reflection-based invocation
PowerShell runspaces
CLR hosting
Dynamic methods
Delegates
Compiled expressions
JavaScript / VBScript engines
AMSI-scanned buffers

Признаки подозрительной managed-активности

Загрузка .NET assembly из памяти без файла на диске.
Подозрительные assembly names или пустые names.
Использование reflection для вызова опасных методов.
PowerShell вызывает Add-Type, Reflection.Assembly, Marshal, DllImport.
Constrained Language Mode bypass.
Попытки отключить или обойти AMSI.
Подозрительные ScriptBlock fragments.
CLR ETW events показывают assembly load из unusual context.

Детект

PowerShell ScriptBlock Logging.
PowerShell Module Logging.
.NET ETW events.
AMSI telemetry.
CLR assembly load telemetry.
Контроль powershell.exe, pwsh.exe, wsmprovhost.exe, rundll32.exe, regsvr32.exe, mshta.exe.
Обнаружение patching AMSI / ETW.
Анализ AppDomain и assembly load events.

Защитные меры:

PowerShell Constrained Language Mode.
WDAC / AppLocker.
Attack Surface Reduction rules.
Блокировка legacy PowerShell v2.
Tamper Protection.
.NET ETW и Defender ATP / EDR telemetry.

────────────────────

Sleep obfuscation и короткоживущие payload

Если payload находится в памяти долго, его могут найти periodic memory scans. Поэтому исследуются техники, где код расшифровывается только на короткое время.

Типовая логика

Код:

allocate memory
write encrypted payload
sleep / wait
decrypt
change memory to RX
execute action
re-encrypt or free
sleep again

Что это даёт атакующему

В момент простоя память не содержит явного payload.
Periodic scan может не попасть в момент расшифровки.
Меньше статических строк и сигнатур.
Payload может менять ключи или layout.

Что остаётся видимым

Частые VirtualProtect, VirtualAlloc, VirtualFree.
Изменения прав страниц: RW → RX → RW / free.
Высокая энтропия в executable regions.
Короткоживущие RX regions.
Подозрительные таймеры.
Повторяющиеся циклы decrypt / execute / encrypt.
Сетевая активность после периода сна.
Поведенческие цепочки после пробуждения.

Детект

Сканирование памяти не только по расписанию, но и в момент критических событий.
Отслеживание entropy changes.
Мониторинг VirtualProtect на executable pages.
Корреляция sleep patterns с последующими действиями.
Анализ времени жизни RX memory.
EDR telemetry по allocation / protection / thread creation.

────────────────────

Обход сканирования памяти

Memory scanning может быть обманут или усложнён несколькими способами.

Основные направления

Шифрование payload в памяти.
Удаление PE headers.
Разбиение payload на фрагменты.
Хранение кода в non-executable pages до момента выполнения.
Использование legitimate memory regions.
Короткоживущие allocations.
Изменение layout между сканами.
Использование high entropy data.
Маскировка под heap, stack, resource data.
Выполнение через JIT или scripting engines.

Что помогает детекту

Сканировать память в разные моменты времени.
Анализировать не только содержимое, но и metadata: VAD, protection, backing image, entropy, lifetime.
Искать не только MZ / PE, но и shellcode patterns, API hashes, crypto stubs.
Использовать behavioral correlation.
Собирать memory dumps при срабатывании high-risk events.
Проверять executable memory, даже если там нет PE header.
Обращать внимание на private RX memory.

────────────────────

Какие события и телеметрия наиболее ценны

Для обнаружения memory-based атак лучше всего работает комбинация user-mode, kernel-mode и forensic telemetry.

Windows / EDR telemetry

Process creation.
Process access.
Thread creation.
Remote thread creation.
APC queueing.
Image load.
DLL load from unusual path.
Memory allocation.
Memory protection change.
Cross-process memory write.
Section object creation.
Handle duplication.
Debug API usage.
ETW events.
AMSI events.
PowerShell logs.
.NET assembly load events.
WMI events.
Network connections.
File writes to startup / persistence locations.

Sysmon events

Особенно полезны:

Event ID 1: Process creation.
Event ID 3: Network connection.
Event ID 5: Process termination.
Event ID 7: Image loaded.
Event ID 8: CreateRemoteThread.
Event ID 10: ProcessAccess.
Event ID 11: FileCreate.
Event ID 22: DNS query.
Event ID 23: FileDelete.
Event ID 25: ProcessTampering, если доступно и настроено.

Пример подозрительной логики:

Код:

ProcessAccess:
  TargetImage содержит lsass.exe
  GrantedAccess включает PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION
  CallTrace содержит ntdll.dll или unknown module

или:

Код:

CreateRemoteThread:
  StartModule пустой
  StartAddress не принадлежит известному модулю
  TargetImage не является ожидаемым для parent process

────────────────────

ETW providers, которые стоит рассматривать

В лабораторных условиях можно включать и анализировать:

Microsoft-Windows-Kernel-Process
Microsoft-Windows-Kernel-Audit
Microsoft-Windows-Threat-Intelligence
Microsoft-Windows-DotNETRuntime
Microsoft-Windows-PowerShell
Microsoft-Windows-Win32k
Microsoft-Windows-Security-Mitigations
Microsoft-Windows-CodeIntegrity
Microsoft-Windows-AppLocker

Важно:

Threat-Intelligence обычно требует EDR / PPL-контекст и не всегда доступен обычным приложениям.
Для production-детекта лучше использовать централизованный сбор и нормализацию событий.
Локальный lab-сбор полезен для понимания поведения, но не заменяет полноценный EDR.

────────────────────

Forensic-проверка памяти

Если есть подозрение на memory-resident malware, полезно снять memory dump и проанализировать его offline.

Volatility 3

Полезные плагины:

Bash:

vol -f MEMORY.raw windows.pslist
vol -f MEMORY.raw windows.pstree
vol -f MEMORY.raw windows.dlllist
vol -f MEMORY.raw windows.modules
vol -f MEMORY.raw windows.threads
vol -f MEMORY.raw windows.malfind
vol -f MEMORY.raw windows.vad
vol -f MEMORY.raw windows.memmap
vol -f MEMORY.raw windows.cmdline
vol -f MEMORY.raw windows.netscan

На что смотреть:

процессы без ожидаемых child / parent relationships;
DLL, загруженные из временных папок;
unsigned DLL в системных процессах;
executable private memory;
malfind hits;
потоки с подозрительным start address;
VAD regions с EXECUTE правами;
сетевые соединения, связанные с подозрительными процессами.

WinDbg

Базовые команды для первичного осмотра:

Код:

!process 0 0
!process <EPROCESS> 7
!thread
!teb
!peb
lm
!address -summary
!vad
!mft
!handle
.dump /f C:\dumps\process.dmp

Что проверять:

список модулей;
наличие unbacked executable regions;
thread start addresses;
memory protection;
VAD tree;
соответствие модулей ожидаемым путям;
подозрительные private pages.

────────────────────

Практический lab-подход

Для безопасного исследования лучше использовать отдельную VM или cyber range.

Минимальный стенд

Windows 10 / 11 или Windows Server в isolated VM.
Snapshot до эксперимента.
Sysmon installed.
PowerShell logging enabled.
ETW collection при необходимости.
WinDbg local kernel debugging или crash dump analysis.
Volatility для offline memory analysis.
Network isolation или controlled virtual network.
Отдельные учётные данные, не используемые в production.

Порядок проверки

Зафиксировать baseline:
- процессы;
- модули;
- сетевые соединения;
- memory regions;
- Sysmon events.
Запустить исследуемый образец или эмуляцию в isolated lab.
Собрать:
- Sysmon logs;
- Event Logs;
- ETW traces;
- memory dump;
- network pcap;
- process dumps.
Сравнить baseline и post-execution state.
Проверить:
- появились ли private RX regions;
- появились ли unbacked threads;
- изменились ли модули;
- были ли remote thread / APC events;
- были ли обращения к lsass, sam, registry, startup folders;
- была ли сетевая активность.
Сформулировать detection logic:
- какие события были наиболее ранними;
- какие признаки стабильны;
- какие признаки легко меняются;
- какие false positives возможны.

────────────────────

Пример detection-логики для memory injection

Не стоит полагаться на один индикатор. Лучше использовать scoring.

Высокий риск, если одновременно наблюдаются:

доступ к чувствительному процессу;
PROCESS_VM_WRITE или PROCESS_VM_OPERATION;
allocation executable memory в целевом процессе;
запись в allocated memory;
смена защиты на executable;
создание потока или APC;
start address не принадлежит known module;
целевой процесс делает network connection или credential access.

Средний риск:

private executable memory без backing image;
high entropy RX region;
thread start from heap / stack / unbacked memory;
unusual DLL load;
PowerShell / rundll32 / regsvr32 с network connection;
.NET assembly load из memory.

Низкий риск сам по себе, но полезный в корреляции:

VirtualProtect на executable page;
allocation large RW memory;
загрузка unsigned DLL;
child process creation из scripting host;
DNS query к newly registered domain.

────────────────────

Что не стоит считать надёжным детектом

Только один признак обычно недостаточен.

Ненадёжные или легко обходимые сигналы:

только наличие MZ / PE в памяти;
только static hash;
только user-mode hooks;
только периодический memory scan;
только имя процесса;
только путь к файлу;
только подпись файла;
только один Sysmon event;
только high entropy без контекста;
только отсутствие known bad signature.

Более надёжный подход:

memory metadata + behavior + telemetry correlation;
kernel-level visibility;
integrity checks;
runtime monitoring;
forensic validation;
attack surface reduction.

────────────────────

Защитные меры

Системные mitigation

DEP / NX.
ASLR.
CFG.
CET / Shadow Stack, где поддерживается.
HVCI / Memory Integrity.
Secure Boot.
Credential Guard.
LSA Protection.
PPL / Protected Process Light для критичных сервисов.
WDAC / AppLocker.
Attack Surface Reduction rules.
Tamper Protection.
Constrained Language Mode для PowerShell.
Блокировка PowerShell v2.
Ограничение SeDebugPrivilege.
Ограничение локальных администраторов.

Logging

PowerShell ScriptBlock Logging.
PowerShell Module Logging.
Command line auditing.
Sysmon.
Windows Event Forwarding.
.NET ETW.
AMSI telemetry.
EDR telemetry.
DNS logging.
Network flow logging.

Response

При подтверждённом инциденте:

Изолировать хост от сети.
Сохранить memory dump, если это допустимо политикой IR.
Сохранить disk image или хотя бы критичные артефакты.
Зафиксировать процессы, потоки, модули, сетевые соединения.
Проверить persistence:
- Run keys;
- services;
- scheduled tasks;
- WMI subscriptions;
- startup folder;
- COM hijacks;
- DLL search order hijacks.
Проверить lateral movement:
- RDP;
- SMB;
- WinRM;
- PsExec-like behavior;
- новые административные shares.
Ротировать учётные данные, которые могли быть скомпрометированы.
Проверить доступ к lsass, SAM, secrets, token theft.
Восстановить систему из known-good image или переустановить, если есть сомнения.

────────────────────

Итог

Обход детекта в памяти обычно строится вокруг уменьшения артефактов:

нет явных сигнатур;
нет долгоживущего RWX;
нет PE header;
нет unbacked thread;
нет obvious injection API;
нет readable strings;
нет predictable memory layout;
нет ожидаемых ETW / AMSI events.

Но почти всегда остаются побочные признаки:

memory protection changes;
private executable memory;
unbacked execution;
suspicious thread start;
cross-process access;
abnormal call stack;
kernel callbacks;
behavioral chain;
entropy changes;
missing or tampered telemetry;
forensic anomalies in VAD, modules, sections, threads.

Для защиты наиболее эффективен не один сканер, а комбинация:

kernel telemetry;
EDR behavioral rules;
memory forensics;
ETW / AMSI / PowerShell / .NET logging;
integrity checks;
OS mitigations;
attack surface reduction;
incident response readiness.

📡 Наши контакты

Как антивирусы и EDR обнаруживают вредоносный код: сигнатуры, поведение и анализ памяти

Введение​

Сигнатуры: статический подход​

Статический анализ сигнатур​

Преимущества и ограничения​

Эвристический анализ: поиск подозрительного поведения​

Статический эвристический анализ​

Динамический эвристический анализ​

Анализ памяти: обнаружение в реальном времени​

Методы анализа памяти​

Обфускация и её противостояние​

Методы обфускации​

Динамическое обнаружение и EDR​

Особенности EDR​

Современные технологии защиты​

Полиморфизм и динамическая настройка​

Аналитика памяти в реальном времени​

Рекомендации по безопасности​

1. Использование многослойной защиты​

2. Обновление баз данных​

3. Мониторинг активности​

Чек-лист обнаружения вредоносного кода​

Источники​

zer0coder

Qwen

Коротко​

Что AV/EDR обычно смотрит в памяти​

1. Статические признаки в памяти​

2. Свойства регионов памяти​

3. Поведенческие цепочки​

4. Потоки и стеки​

5. User-mode hooks и телеметрия​

6. Kernel-mode telemetry​

Основные классы обхода детекта в памяти​

1. Шифрование и кодирование payload​

2. Отказ от PAGE_EXECUTE_READWRITE​

3. Удаление PE-заголовков и manual mapping​

4. Использование легитимных модулей​

5. Обход user-mode hooks​

6. ETW и AMSI bypass​

7. Скрытое создание потоков​

8. Sleep obfuscation​

9. Stack spoofing​

zer0coder

Qwen

Детект stack spoofing​

Direct syscalls и indirect syscalls​

Что пытаются обойти​

Что остаётся видимым​

Детект​

Hardware breakpoints и debug-механизмы​

Что может использоваться​

Почему это подозрительно​

Детект​

Reflective DLL loading​

Признаки​

Что ищет EDR / memory scanner​

Детект​

Module stomping​

Почему это сложнее для детекта​

Что всё равно можно обнаружить​

Детект​

Process hollowing, doppelgänging, ghosting и похожие техники​

Общие признаки​

Что можно детектить​

Защитные сигналы​

Shared memory и section objects​

Почему это используется​

Признаки​

Детект​

.NET, CLR, PowerShell и in-memory assemblies​

Что может выполняться в памяти​

Признаки подозрительной managed-активности​

Детект​

Sleep obfuscation и короткоживущие payload​

Типовая логика​

Что это даёт атакующему​

Что остаётся видимым​

Детект​

Введение

Сигнатуры: статический подход

Статический анализ сигнатур

Преимущества и ограничения

Эвристический анализ: поиск подозрительного поведения

Статический эвристический анализ

Динамический эвристический анализ

Анализ памяти: обнаружение в реальном времени

Методы анализа памяти

Обфускация и её противостояние

Методы обфускации

Динамическое обнаружение и EDR

Особенности EDR

Современные технологии защиты

Полиморфизм и динамическая настройка

Аналитика памяти в реальном времени

Рекомендации по безопасности

1. Использование многослойной защиты

2. Обновление баз данных

3. Мониторинг активности

Чек-лист обнаружения вредоносного кода

Источники

Коротко

Что AV/EDR обычно смотрит в памяти

1. Статические признаки в памяти

2. Свойства регионов памяти

3. Поведенческие цепочки

4. Потоки и стеки

5. User-mode hooks и телеметрия

6. Kernel-mode telemetry

Основные классы обхода детекта в памяти

1. Шифрование и кодирование payload

2. Отказ от `PAGE_EXECUTE_READWRITE`

3. Удаление PE-заголовков и manual mapping

4. Использование легитимных модулей

5. Обход user-mode hooks

6. ETW и AMSI bypass

7. Скрытое создание потоков

8. Sleep obfuscation

9. Stack spoofing

Детект stack spoofing

Direct syscalls и indirect syscalls

Что пытаются обойти

Что остаётся видимым

Детект

Hardware breakpoints и debug-механизмы

Что может использоваться

Почему это подозрительно

Детект

Reflective DLL loading

Признаки

Что ищет EDR / memory scanner

Детект

Module stomping

Почему это сложнее для детекта

Что всё равно можно обнаружить

Детект

Process hollowing, doppelgänging, ghosting и похожие техники

Общие признаки

Что можно детектить

Защитные сигналы

Shared memory и section objects

Почему это используется

Признаки

Детект

.NET, CLR, PowerShell и in-memory assemblies

Что может выполняться в памяти

Признаки подозрительной managed-активности

Детект

Sleep obfuscation и короткоживущие payload

Типовая логика

Что это даёт атакующему

Что остаётся видимым

Детект

Обход сканирования памяти

Основные направления

Что помогает детекту

Какие события и телеметрия наиболее ценны

Windows / EDR telemetry

Sysmon events