Как вирусы обходят поведенческий детект и облака антивирусов

zer0coder · Вчера в 19:47

Привет Qwen!

Как вирусы обходят поведенческий детект и облака антивирусов ?

Приведи также примеры техник, которые используются в боевых вирусах.

Zer0Kernel CVE Radar · Вчера в 19:49

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

1. Что именно обходят: поведенческий детект и облако

Поведенческий детектор

Обычно анализирует события в реальном времени:

создание процессов и командные строки;
загрузку DLL/образов в память;
доступ к другим процессам и памяти;
изменения файлов, реестра, служб, планировщика;
сетевые подключения;
вызовы чувствительных API;
события AMSI, ETW, PowerShell, CLR, WMI;
действия драйверов и minifilter-фильтров.

Цель поведенческого анализа — найти не «плохой файл», а «плохую цепочку действий».

Облачная проверка антивируса

Облако может использовать:

репутацию хэша файла;
fuzzy hash / similarity hash;
репутацию сертификата подписи;
метаданные PE: секции, импорты, ресурсы, энтропию;
prevalence: насколько файл распространён в телеметрии вендора;
статический ML по признакам PE/скриптов/документов;
динамический sandbox-анализ;
репутацию URL, IP, доменов;
связи между файлами, доменами, сертификатами, инфраструктурой.

Обход облака обычно сводится к тому, чтобы образец выглядел редким, безвредным, доверенным или не проявлял вредоносного поведения во время автоматического анализа.

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

2. Типовые техники обхода облачных и статических проверок

2.1. Полиморфизм и метаморфизм

Суть:
Каждая копия вредоноса отличается байтами, структурой или кодом, но сохраняет функциональность.

Что встречается:

шифрование тела с разным ключом;
мусорные инструкции;
перестановка блоков кода;
изменение PE-секций;
генерация разных stub'ов;
перекомпиляция с другими флагами;
изменение строк, ресурсов, иконок, timestamp.

Детектирование:

высокая энтропия секций;
аномальные секции с RWX;
отсутствие полезных строк;
подозрительные импорты или скрытые импорты;
совпадение поведения у разных хэшей;
fuzzy hash и структурное сходство;
поведенческие сигнатуры после распаковки.

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

2.2. Упаковщики, протекторы, крипторы

Суть:
Полезная нагрузка распаковывается/расшифровывается в памяти во время выполнения.

Признаки:

высокий уровень энтропии;
малое число импортов;
необычные имена секций;
TLS callbacks;
точка входа в нестандартной секции;
самораспаковка;
выделение памяти с PAGE_EXECUTE_READWRITE;
последующая запись в память другого процесса.

Детектирование:

динамический анализ с контролем распаковки;
memory scanning после аллокации executable memory;
Sysmon Event ID 7 ImageLoaded;
Sysmon Event ID 8 CreateRemoteThread;
Sysmon Event ID 10 ProcessAccess;
EDR-правила на распаковку и injection;
YARA по распакованным артефактам в памяти.

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

2.3. Низкая распространённость и targeted samples

Суть:
Облачные системы часто учитывают prevalence. Если файл встречается редко, он может дольше оставаться неизвестным.

Как это используют:

уникальная сборка под кампанию;
разные дропперы для разных жертв;
персонализированные документы;
загрузка второго этапа только для целевой среды;
использование signed dropper + редкий payload.

Детектирование:

не полагаться только на репутацию;
анализировать поведение даже для неизвестных файлов;
учитывать сетевой контекст: редкий файл + сетевое подключение + persistence;
проверять цепочку: документ → скрипт → интерпретатор → сеть.

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

2.4. Злоупотребление подписями и доверенными файлами

Суть:
Используются подписанные исполняемые файлы, чтобы снизить подозрительность.

Варианты:

кража или покупка сертификатов;
использование старых подписанных бинарников;
DLL side-loading рядом с подписанным EXE;
запуск подписанных LOLBin-файлов;
supply-chain: вредоносный код внутри легитимного обновления.

Детектирование:

проверка не только подписи, но и поведения;
контроль загрузки DLL из нестандартных каталогов;
сравнение ожидаемого пути файла и фактического;
проверка репутации сертификата и цепочки;
анализ подписанных файлов, которые внезапно устанавливают persistence или подключаются к C2.

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

3. Обход песочниц и поведенческого анализа

3.1. Проверка окружения

Типовые проверки:

виртуальная машина: MAC-адреса, имена устройств, драйверы, реестр;
процессы анализа: wireshark, procmon, procexp, x32dbg, x64dbg, ida, fiddler;
малое число CPU/RAM/диска;
отсутствие истории браузера, документов, сетевых дисков;
отсутствие движения мыши;
малый uptime;
доменное имя рабочей станции против sandbox-имени;
специфичные пользователи, раскладка клавиатуры, часовой пояс;
наличие антивирусных служб и EDR.

Детектирование:

массовые запросы к WMI/реестру перед основной активностью;
чтение ключей VM/AV;
перечисление процессов и служб;
ранний выход без полезной нагрузки;
задержка перед вредоносным действием;
сетевые проверки до выполнения payload.

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

3.2. Задержки и тайм-бомбы

Суть:
Вредонос не выполняет опасные действия сразу, чтобы не попасть в короткий цикл sandbox.

Варианты:

Sleep на десятки минут;
ожидание reboot;
запуск только в определённое время;
запуск только после входа конкретного пользователя;
выполнение после открытия нескольких документов;
ожидание сетевого ответа от C2.

Детектирование:

аномальная пауза между созданием процесса и сетевой активностью;
действия после перезагрузки;
persistence + отложенное выполнение;
sandbox с увеличенным временем анализа;
симуляция пользовательской активности.

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

3.3. Разделение этапов

Суть:
Первый файл выглядит безобидно, а вредоносная логика появляется позже.

Цепочки:

документ → макрос → PowerShell/WMI/MSHTA;
LNK → PowerShell → download;
DLL → загрузка shellcode из сети;
signed EXE → side-load DLL → payload;
скрипт → расшифровка config → второй этап.

Детектирование:

анализ всей цепочки процессов;
контроль сетевых подключений интерпретаторов;
логирование загрузки DLL;
отслеживание загрузки .NET/CLR в нестандартных процессах;
детект download/cradle-паттернов в PowerShell, JScript, VBScript.

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

4. Обход user-mode hooks, AMSI и ETW

Многие EDR/AV используют user-mode hooks, ETW и AMSI. В реальных образцах встречаются попытки ослабить телеметрию.

4.1. Unhooking и direct/indirect syscalls

Суть:
Вредонос пытается вызывать системные функции в обход перехватов в ntdll.dll или других DLL.

Признаки для защиты:

syscall выполняется не из ожидаемого модуля;
call stack не содержит обычных API-переходов;
процесс использует direct syscall из собственного кода;
подозрительные шаблоны syscall/sysenter вне ntdll;
аномальные последовательности NT API.

Контрмеры:

EDR с kernel callbacks;
контроль call stacks;
HVCI/VBS;
защита EDR-агента от tampering;
анализ не только user-mode hooks, но и kernel telemetry.

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

4.2. Подавление ETW

Суть:
ETW используется для телеметрии. Вредонос может пытаться отключить или сломать запись событий.

Признаки:

внезапное исчезновение событий от провайдера;
ошибки инициализации ETW;
подозрительные изменения в памяти ETW-функций;
процесс EDR/AV сообщает о self-protection alert;
отсутствие ожидаемых событий при наличии активности.

Контрмеры:

tamper protection;
контроль целостности EDR-процессов;
kernel-based ETW providers;
проверка состояния tracing sessions;
алерты на попытки отключения телеметрии.

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

4.3. Обход AMSI

Суть:
AMSI проверяет скрипты и некоторые in-memory payload. Вредонос может пытаться обойти проверку.

Признаки:

ошибки инициализации AMSI;
подозрительные строки или паттерны в PowerShell/ScriptBlockLogging;
попытки манипулировать amsi.dll в памяти;
запуск скриптов с признаками obfuscation;
PowerShell работает с -EncodedCommand, длинными base64, IEX, DownloadString.

Контрмеры:

включить PowerShell Script Block Logging;
включить Module Logging;
включить PowerShell Transcription;
Constrained Language Mode;
WDAC/AppLocker;
AMSI для .NET и PowerShell;
EDR memory scanning.

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

5. Техники работы с памятью и процессами

5.1. Process injection

Варианты:

CreateRemoteThread;
APC injection;
process hollowing;
process doppelgänging;
thread hijacking;
module stomping;
reflective DLL loading;
atom bombing;
injection через NtWriteVirtualMemory + NtCreateThreadEx.

Зачем:

выполнить код внутри доверенного процесса;
избежать создания подозрительного процесса;
затруднить файловое детектирование;
работать memory-only.

Детектирование:

Sysmon EID 8 CreateRemoteThread;
Sysmon EID 10 ProcessAccess с подозрительными правами;
RWX-регионы в чужом процессе;
память без backing image;
загрузка DLL не через обычный loader;
несоответствие потока и модуля;
EDR memory protection alerts;
Volatility/Malfind в forensic-проверке.

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

5.2. Memory-only malware

Суть:
Вредоносный код не хранится на диске или хранится в зашифрованном виде.

Признаки:

executable memory в процессе без файла;
.NET assembly в памяти нестандартного процесса;
подозрительные вызовы CLR из non-.NET процесса;
сетевая активность из процесса с аномальной памятью;
отсутствие файла, соответствующего потоку/модулю.

Детектирование:

memory scanning;
YARA по памяти;
EDR memory telemetry;
CLR/AMSI events;
Volatility:

Bash:

vol -f mem.raw windows.pslist
vol -f mem.raw windows.malfind
vol -f mem.raw windows.dlllist --pid 1234
vol -f mem.raw windows.netscan

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

6. Fileless-техники и persistence

6.1. PowerShell, WMI, registry, scheduled tasks

Типовые механизмы:

PowerShell one-liner в scheduled task;
WMI event subscription;
registry Run/RunOnce;
службы;
startup folder;
COM hijacking;
BITS jobs;
installer abuse.

Детектирование:

Windows Event ID 4698 — scheduled task created;
Sysmon EID 12/13/14 — registry;
WMI-Activity Operational: 5857–5861;
Service Control Manager: 7045, 7040, 7036;
PowerShell 4103/4104;
AppLocker/WDAC events;
Sysmon EID 11 — file creation в startup.

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

6.2. WMI persistence

Суть:
Соз

zer0coder · Вчера в 19:50

Продолжи...

Zer0Kernel CVE Radar · Вчера в 19:52

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

Готовые обходные реализации приводить не буду. Ниже — именно модель угроз, поверхности детектирования и защита.

1. WMI persistence: продолжение

WMI-подписки позволяют выполнять код при наступлении события: запуск системы, вход пользователя, появление процесса, таймер и т.п. Это удобно для fileless-закрепления, потому что полезная нагрузка может храниться не в обычном исполняемом файле, а в WMI-репозитории.

Типовые объекты:

__EventFilter — условие срабатывания.
__EventConsumer — действие: запуск команды, скрипта, binary.
__FilterToConsumerBinding — связка фильтра и потребителя.

Проверка через PowerShell:

Код:

Get-CimInstance -Namespace root/subscription -ClassName __EventFilter
Get-CimInstance -Namespace root/subscription -ClassName __EventConsumer
Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding

Полезно также смотреть журнал WMI:

Код:

Get-WinEvent -LogName "Microsoft-Windows-WMI-Activity/Operational" -MaxEvents 200 |
    Select-Object TimeCreated, Id, Message

Ключевые события:

5857 — загрузка провайдера WMI.
5858 — ошибки WMI.
5859 — регистрация event filter.
5860 — регистрация event consumer.
5861 — регистрация filter-to-consumer binding.

Защита:

мониторить создание WMI-подписок;
ограничивать WMI через firewall и DCOM, если не требуется;
проверять WMI-репозиторий при incident response;
использовать EDR с контролем WMI-активности;
удалять подозрительные binding/filter/consumer после фиксации артефактов.

2. COM hijacking

COM-объекты могут быть перехвачены через подмену или добавление registry-ключей, например InprocServer32, LocalServer32, TreatAs, ProgID. Когда легитимное приложение загружает COM-объект, вместо ожидаемого компонента может загружаться вредоносная DLL или исполняемый файл.

Почему это удобно для обхода:

запуск происходит из доверенного процесса;
не нужно создавать новый процесс;
действие выглядит как обычная работа приложения;
можно получить persistence без явного Run-ключа.

Что мониторить:

изменения registry в разделах HKCU\Software\Classes\CLSID и HKLM\SOFTWARE\Classes\CLSID;
загрузку DLL из нестандартных путей;
запуск dllhost.exe, rundll32.exe, explorer.exe, Office-процессов с подозрительными дочерними процессами;
Sysmon Event ID 12/13/14 для registry;
Sysmon Event ID 7 для загрузки образов.

Проверка подозрительных CLSID и DLL:

Код:

Get-CimInstance Win32_ClassicCOMClassSetting |
    Select-Object ProgId, InprocServer32, Description |
    Where-Object { $_.InprocServer32 -match "Temp|AppData|Public|Downloads" }

Защита:

контроль изменений COM-реестра;
запрет загрузки DLL из пользовательских каталогов, если это возможно;
WDAC/AppLocker;
анализ подписи и пути DLL;
сравнение ожидаемого расположения компонента с фактическим.

3. Scheduled tasks и службы

Планировщик заданий и службы — один из самых частых механизмов persistence и отложенного выполнения.

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

запуск от системного контекста;
запуск по расписанию, при входе, при событии;
можно выполнять PowerShell, WMI, mshta, rundll32, regsvr32, certutil;
задание может быть создано локально или удалённо.

Что мониторить:

Windows Event ID 4698 — создана scheduled task.
Task Scheduler Operational: 106, 140, 141, 200, 201.
Event ID 7045 — установлена служба.
Event ID 7040 — изменено состояние службы.
Event ID 7036 — служба вошла в состояние.
Sysmon Event ID 1 — создание процесса с командной строкой.

Проверка задач:

Код:

Get-ScheduledTask |
    Where-Object { $_.State -ne "Disabled" } |
    Select-Object TaskName, TaskPath, State, Author

Более подробный вывод:

Код:

schtasks /query /fo LIST /v

Проверка служб:

Код:

Get-Service |
    Select-Object Name, DisplayName, Status, StartType

Код:

sc.exe query state= all

Защита:

аудит создания и изменения scheduled tasks;
контроль подозрительных команд в задачах;
запрет запуска скриптов и интерпретаторов из временных каталогов;
ограничение прав на создание служб;
EDR-правила на аномальные цепочки: svchost.exe → cmd.exe → powershell.exe → сеть.

4. Маскировка под легитимные процессы

Вредоносные образцы часто маскируются под системные файлы: svchost.exe, lsass.exe, csrss.exe, explorer.exe, winlogon.exe, services.exe.

Признаки подделки:

файл запущен не из C:\Windows\System32 или C:\Windows\SysWOW64;
неправильный родитель процесса;
отсутствие цифровой подписи Microsoft;
необычное имя с одной изменённой буквой: svch0st.exe, scvhost.exe, lsasss.exe;
процесс запущен от неожиданного пользователя;
сетевые подключения из процесса, который обычно не ходит в интернет;
процесс имеет RWX-память или загруженные модули без backing file.

Пример проверки процессов:

Код:

Get-Process |
    Select-Object Id, ProcessName, Path, Company, Product |
    Sort-Object ProcessName

Проверка подписи:

Код:

Get-AuthenticodeSignature -FilePath "C:\Path\To\file.exe"

Защита:

контроль целостности системных файлов;
AppLocker/WDAC;
EDR-правила на подозрительные имена и пути;
анализ parent-child отношений процессов;
проверка подписи и хэша.

5. Living-off-the-land binaries

LOLBin — легитимные системные утилиты, которые могут использоваться для загрузки, выполнения или маскировки вредоносного кода.

Часто встречающиеся бинарники:

powershell.exe
pwsh.exe
wscript.exe
cscript.exe
mshta.exe
rundll32.exe
regsvr32.exe
certutil.exe
bitsadmin.exe
msiexec.exe
installutil.exe
cmstp.exe
odbcconf.exe
msbuild.exe
regasm.exe
regsvcs.exe

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

файл подписан Microsoft;
облачная репутация бинарника хорошая;
поведение зависит от аргументов командной строки;
полезная нагрузка может быть в сети, registry, WMI, скрипте.

Что мониторить:

командные строки процессов;
сетевые подключения от интерпретаторов и proxy-бинарников;
загрузку DLL через rundll32.exe и regsvr32.exe;
запуск .NET-сборок через msbuild.exe, installutil.exe, regasm.exe;
загрузку скриптов и удалённого контента через mshta.exe, certutil.exe, bitsadmin.exe.

Пример поиска сетевых подключений PowerShell:

Код:

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" |
    Where-Object { $_.Id -eq 3 -and $_.Message -match "powershell" } |
    Select-Object -First 50 TimeCreated, Message

Защита:

Attack Surface Reduction rules;
Constrained Language Mode для PowerShell;
WDAC/AppLocker;
запрет сетевых загрузок через certutil, bitsadmin, mshta, если не требуется;
логирование PowerShell Script Block Logging;
контроль командных строк в Event ID 4688.

6. Обход облачных проверок через редкость и целевую доставку

Облачные антивирусы часто учитывают не только хэш, но и prevalence: насколько файл распространён, где встречался, кто его подписывал, как часто запускался.

Поэтому в целевых кампаниях используются:

уникальные сборки под одну организацию;
разные дропперы для разных жертв;
одноразовые URL и домены;
загрузка второго этапа только после проверки окружения;
использование подписанных, но редких или скомпрометированных файлов;
шифрованные архивы с паролем;
HTML-файлы, ISO/VHD/VHDX/LNK-контейнеры;
загрузка payload из легитимных облачных сервисов.

Признаки риска:

файл впервыеSeen в телеметрии;
файл находится в Temp, AppData, Downloads, Public;
файл запущен из почтового вложения или браузером;
после запуска появляется интерпретатор: PowerShell, WMI, MSHTA, CMD;
процесс обращается к редкому домену;
файл не имеет подписи или подписан неожиданным сертификатом;
после запуска создаётся persistence.

Защита:

не полагаться только на облачную репутацию;
оценивать контекст: путь, родитель, командная строка, сеть, persistence;
использовать sandbox с длительным временем анализа;
проверять архивы и контейнеры, из которых извлекается исполняемый контент;
блокировать запуск исполняемых файлов из пользовательских каталогов, если это допустимо политикой.

7. Обход sandbox и автоматического анализа

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

Типовые проверки окружения:

MAC-адреса и сетевые адаптеры;
имена устройств и драйверы виртуализации;
ключи registry, связанные с VM;
малое число CPU, RAM, диска;
малый uptime;
отсутствие документов, истории браузера, сетевых дисков;
отсутствие движения мыши;
отсутствие реального пользователя;
процессы анализа: Wireshark, Process Monitor, Process Explorer, x64dbg, x32dbg, IDA, Fiddler;
наличие антивирусов и EDR;
доменное имя компьютера;
часовой пояс, раскладка клавиатуры, язык системы.

Поведенческие признаки таких проверок:

процесс сначала долго читает registry, WMI, файлы;
перечисляет процессы и службы;
делает сетевые проверки и только потом выполняет основную логику;
завершается без действий, если среда не подходит;
ждёт пользовательской активности;
откладывает вредоносные действия на десятки минут.

Защита и улучшение sandbox:

увеличивать время анализа;
эмулировать пользовательскую активность;
использовать реалистичные имена хостов и домены;
наполнять систему артефактами реального пользователя;
анализировать не только первый запуск, но и поведение после reboot;
мониторить отложенные задачи и persistence;
сохранять memory dump и network capture.

8. Разделение этапов выполнения

Одна из главных техник против поведенческого анализа — разбить вредоносную цепочку на несколько этапов.

Пример логики без деталей реализации:

Документ или архив выглядит безобидно.
Макрос, LNK, HTML или скрипт загружает небольшой компонент.
Компент проверяет окружение.
Второй этап загружается только при выполнении условий.
Полезная нагрузка расшифровывается в памяти.
Закрепление происходит через scheduled task, WMI, COM, службу или registry.

Почему это эффективно:

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

Что нужно для обнаружения:

корреляция процессов;
анализ командных строк;
сетевые подключения интерпретаторов;
события загрузки DLL;
события создания persistence;
временные связи между событиями;
память процессов.

Пример поиска подозрительных запусков Office и дочерних процессов:

Код:

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" |
    Where-Object {
        $_.Id -eq 1 -and
        $_.Message -match "winword|excel|powerpnt|outlook" -and
        $_.Message -match "cmd|powershell|wscript|cscript|mshta|rundll32|regsvr32"
    } |
    Select-Object -First 50 TimeCreated, Message

9. Memory-only и fileless-подходы

Если вредоносный код не сохраняется на диск в открытом виде, файловому антивирусу сложнее его проверить.

Типовые варианты:

shellcode в памяти процесса;
reflective DLL;
.NET-сборка, загруженная в память;
PowerShell-скрипт, выполняемый из памяти;
WMI-подписка, выполняющая скрипт;
payload, расшифрованный в доверенном процессе;
injection в explorer.exe, svchost.exe, rundll32.exe.

Признаки:

executable memory без backing file;
RWX-регионы памяти;
поток выполняется из памяти без модуля;
.NET-код в процессе, который не является .NET-приложением;
сетевая активность из процесса с аномальной памятью;
подозрительные ProcessAccess, CreateRemoteThread, ImageLoaded.

Детектирование через Sysmon:

Event ID 8 — CreateRemoteThread.
Event ID 10 — ProcessAccess.
Event ID 7 — ImageLoaded.
Event ID 25 — process tampering, если поддерживается конфигурацией.

Forensic-проверка памяти через Volatility:

Bash:

vol -f mem.raw windows.pslist
vol -f mem.raw windows.pstree
vol -f mem.raw windows.malfind
vol -f mem.raw windows.dlllist --pid 1234
vol -f mem.raw windows.modules
vol -f mem.raw windows.netscan

Защита:

EDR memory scanning;
YARA по памяти;
AMSI для PowerShell и .NET;
Credential Guard;
HVCI/VBS;
запрет загрузки неподписанных драйверов;
контроль RWX-аллокаций и injection-паттернов.

10. Обход user-mode hooks, AMSI и ETW

EDR и антивирусы могут использовать user-mode hooks, ETW-провайдеры и AMSI. В реальных образцах встречаются попытки

zer0coder · Вчера в 19:52

Продолжи...

Zer0Kernel CVE Radar · Вчера в 19:54

Продолжаю в том же ключе: без готовых обходных реализаций, но с разбором поверхностей детектирования, телеметрии, примеров цепочек атаки и мер защиты. Это именно защитный взгляд: как понять, что образец пытается обойти поведенческий анализ и облачные проверки, и как это ловить.

10. Попытки ослабить телеметрию: hooks, AMSI, ETW

Многие EDR и антивирусы получают события через user-mode hooks, ETW, AMSI, kernel callbacks и minifilter-драйверы. В реальных кампаниях встречаются попытки уменьшить объём или качество телеметрии.

10.1. Обход user-mode hooks

Суть механизма:
EDR может перехватывать вызовы API в пользовательском режиме, например в ntdll.dll, kernel32.dll, kernelbase.dll. Вредоносный код может пытаться вызывать системные функции так, чтобы не проходить через ожидаемые перехваты.

Поверхности детектирования:

системные вызовы выполняются из неожиданного модуля;
call stack выглядит аномально;
процесс использует прямой syscall вне обычных библиотечных путей;
последовательности NT API не соответствуют стандартному поведению loader'а;
есть RWX-память, подозрительные аллокации и injection-признаки.

Защита:

использовать EDR с kernel-level телеметрией;
включать контроль call stacks, если поддерживается;
использовать HVCI/VBS;
включать tamper protection агента;
не полагаться только на user-mode hooks.

10.2. Подавление или повреждение ETW

Суть механизма:
ETW используется для сбора событий .NET, PowerShell, CLR, AMSI и других компонентов. Вредонос может пытаться сломать или отключить запись событий.

Признаки:

внезапно пропали ожидаемые события;
EDR сообщает о попытке вмешательства;
процесс антивируса или EDR перезапускается;
появляются ошибки инициализации tracing-провайдеров;
подозрительные изменения в памяти системных DLL.

Защита:

tamper protection;
контроль целостности процессов EDR/AV;
мониторинг состояния tracing sessions;
алерты на попытки отключения телеметрии;
использование защищённых kernel-based провайдеров, где это возможно.

10.3. Обход AMSI

Суть механизма:
AMSI проверяет скрипты, PowerShell, .NET-сборки и некоторые другие данные до выполнения. Вредонос может пытаться обойти проверку, чтобы скрыть полезную нагрузку.

Признаки:

PowerShell работает с длинными base64-командами;
используются -EncodedCommand, IEX, DownloadString, Net.WebClient;
script block logging показывает сильно обфусцированный код;
процесс пытается читать или менять память amsi.dll;
AMSI-события исчезают или появляются ошибки инициализации.

Защита:

включить PowerShell Script Block Logging;
включить Module Logging;
включить PowerShell Transcription;
использовать Constrained Language Mode;
использовать WDAC/AppLocker;
применять EDR memory scanning;
контролировать .NET ETW и AMSI-телеметрию.

11. Memory-only и fileless-техники

Если полезная нагрузка не хранится на диске в открытом виде, файловому антивирусу сложнее её проверить. Поэтому в реальных кампаниях часто используются memory-only подходы.

11.1. Типовые варианты

shellcode в памяти процесса;
reflective DLL;
.NET-сборка, загруженная в память;
PowerShell-скрипт, выполняемый из памяти;
WMI-подписка, выполняющая скрипт;
payload, расшифрованный внутри доверенного процесса;
injection в explorer.exe, svchost.exe, rundll32.exe, msiexec.exe.

11.2. Признаки в телеметрии

executable memory без backing file;
RWX-регионы памяти;
поток выполняется из памяти без модуля;
.NET-код в процессе, который не является .NET-приложением;
сетевая активность из процесса с аномальной памятью;
подозрительные Sysmon Event ID 7, 8, 10, 25.

11.3. Полезные события Sysmon

Event ID 7 — ImageLoaded;
Event ID 8 — CreateRemoteThread;
Event ID 10 — ProcessAccess;
Event ID 22 — DnsQuery;
Event ID 23 — FileDelete;
Event ID 25 — ProcessTampering;
Event ID 26 — FileDeleteDetected.

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

Если есть memory dump, можно использовать Volatility:

Bash:

vol -f mem.raw windows.pslist
vol -f mem.raw windows.pstree
vol -f mem.raw windows.malfind
vol -f mem.raw windows.dlllist --pid 1234
vol -f mem.raw windows.modules
vol -f mem.raw windows.netscan
vol -f mem.raw windows.cmdline

11.5. Защита

EDR memory scanning;
YARA по памяти;
AMSI для PowerShell и .NET;
Credential Guard;
HVCI/VBS;
LSA Protection;
запрет загрузки неподписанных драйверов;
контроль RWX-аллокаций и injection-паттернов.

12. Обход облачных проверок через редкость, подписи и контекст

Облачные антивирусы часто оценивают не только хэш файла, но и контекст: распространенность, подпись, путь запуска, родительский процесс, сетевые подключения, поведение в sandbox.

12.1. Низкая распространённость

Признак риска: файл впервыеSeen в телеметрии или встречается очень редко.

Как это используется:

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

Защита:

не полагаться только на репутацию;
оценивать контекст запуска;
анализировать поведение даже для неизвестных файлов;
использовать sandbox с увеличенным временем анализа;
коррелировать файл, процесс, сеть и persistence.

12.2. Подписанные файлы и DLL side-loading

Суть:
Подписанный исполняемый файл может выглядеть доверенно. Если рядом с ним положить вредоносную DLL, подписанный процесс может загрузить её.

Признаки:

подписанный EXE загружает DLL из пользовательского каталога;
DLL находится в Temp, AppData, Downloads, Public;
DLL не подписана или подписана неожиданным сертификатом;
путь DLL отличается от ожидаемого для легитимного приложения;
подписанный процесс внезапно создаёт persistence или подключается к C2.

Защита:

контроль загрузки DLL;
WDAC/AppLocker;
проверка подписи и пути;
EDR-правила на side-loading;
запрет запуска подписанных бинарников из пользовательских каталогов, если это допустимо.

12.3. Парольные архивы и контейнеры

Суть:
Облако не может проверить содержимое запароленного архива. Если пароль приходит отдельно, вредоносный файл может пройти первичную проверку как непроверяемый контейнер.

Типовые контейнеры:

ZIP/RAR/7z с паролем;
ISO/VHD/VHDX;
CAB;
WIM;
LNK внутри архива;
HTML-файлы, которые загружают payload.

Признаки:

письмо содержит архив с паролем;
после распаковки запускается скрипт или исполняемый файл;
файл извлекается в Downloads, Temp, AppData;
у файла есть Mark-of-the-Web;
после запуска появляется PowerShell, WMI, MSHTA, CMD.

Защита:

фильтрация вложений на почтовом шлюзе;
блокировка исполняемых типов файлов в архивах;
ASR-правила для Office и браузеров;
контроль извлечения архивов и запуска LNK/скриптов;
обучение пользователей не открывать архивы с паролями из неожиданных писем.

13. Обход sandbox и автоматического анализа

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

13.1. Проверки окружения

Типовые проверки:

MAC-адреса и сетевые адаптеры;
имена устройств и драйверы виртуализации;
ключи registry, связанные с VM;
малое число CPU, RAM, диска;
малый uptime;
отсутствие документов, истории браузера, сетевых дисков;
отсутствие движения мыши;
отсутствие реального пользователя;
процессы анализа: Wireshark, Process Monitor, Process Explorer, x64dbg, x32dbg, IDA, Fiddler;
наличие антивирусов и EDR;
доменное имя компьютера;
часовой пояс, раскладка клавиатуры, язык системы.

13.2. Поведенческие признаки sandbox evasion

процесс сначала долго читает registry, WMI, файлы;
перечисляет процессы и службы;
делает сетевые проверки и только потом выполняет основную логику;
завершается без действий, если среда не подходит;
ждёт пользовательской активности;
откладывает вредоносные действия на десятки минут;
выполняет payload только после reboot.

13.3. Как улучшить sandbox

увеличивать время анализа;
эмулировать пользовательскую активность;
использовать реалистичные имена хостов и домены;
наполнять систему артефактами реального пользователя;
анализировать поведение после reboot;
мониторить отложенные задачи и persistence;
сохранять memory dump и network capture;
detonate архивы и контейнеры, если это безопасно и контролируется.

14. Разделение этапов выполнения

Одна из главных техник против поведенческого анализа — разбить вредоносную цепочку на несколько этапов.

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

Документ или архив выглядит безобидно.
Макрос, LNK, HTML или скрипт загружает небольшой компонент.
Компонент проверяет окружение.
Второй этап загружается только при выполнении условий.
Полезная нагрузка расшифровывается в памяти.
Закрепление происходит через scheduled task, WMI, COM, службу или registry.

14.2. Почему это эффективно

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

14.3. Что нужно для обнаружения

корреляция процессов;
анализ командных строк;
сетевые подключения интерпретаторов;
события загрузки DLL;
события создания persistence;
временные связи между событиями;
память процессов.

15. Типовые цепочки из реальных кампаний

Ниже — не готовые вредоносы, а типовые наблюдаемые паттерны. Они встречаются в загрузчиках, бэкдорах, ransomware-цепочках и post-exploitation frameworks.

15.1. Фишинговый документ → макрос → интерпретатор

Цепочка:

пользователь открывает документ;
макрос запускает cmd.exe, powershell.exe, wscript.exe или mshta.exe;
интерпретатор загружает следующий этап;
выполняется memory payload;
создаётся persistence.

Детектирование:

Office-процесс создаёт shell или интерпретатор;
Office обращается к сети;
PowerShell загружает контент из интернета;
появляется подозрительная командная строка;
создаётся scheduled task или registry Run key.

15.2. ISO/LNK → скрипт → proxy binary

Цепочка:

пользователь получает ISO или архив;
внутри находится LNK;
LNK запускает powershell.exe, mshta.exe, rundll32.exe или regsvr32.exe;
загружается DLL или shellcode;
выполняется injection.

Детектирование:

монтирование ISO из пользовательской папки;
LNK-файл с Mark-of-the-Web;
запуск скриптового интерпретатора из Temp или AppData;
сетевое подключение от mshta, rundll32, regsvr32;
загрузка DLL из нестандартного пути.

15.3. HTML smuggling → браузер → локальный файл

Цепочка:

пользователь открывает HTML-файл;
браузер формирует локальный файл, например .iso, .lnk, .js, .hta;
файл запускается вручную или через автозапуск сценария;
выполняется загрузка payload.

Детектирование:

браузер создаёт исполняемый или скриптовый файл;
файл имеет Mark-of-the-Web;
файл запускается из Downloads;
дочерний процесс браузера — подозрительный интерпретатор;
SmartScreen/ASR блокирует или логирует запуск.

15.4. Signed binary → side-loaded DLL

Цепочка:

в пользовательский каталог помещается подписанный EXE;
рядом кладётся вредоносная DLL;
подписанный EXE загружает DLL;
DLL выполняет payload.

Детектирование:

подписанный процесс загружает неподписанную DLL;
DLL находится в Temp, AppData, Downloads;
путь DLL не соответствует обычному расположению компонента;
процесс после загрузки DLL обращается к сети или создаёт persistence.

15.5. WMI persistence → PowerShell

Цепочка:

создаётся WMI event filter;
создаётся event consumer;
binding связывает их;
при событии выполняется PowerShell-команда;
payload загружается из сети или расшифровывается из registry.

Детектирование:

Sysmon Event ID 19/20/21;
WMI-Activity Operational Event ID 5859/5860/5861;
PowerShell Script Block Logging;
подозрительная команда в consumer;
сетевое подключение от PowerShell.

15.6. Ransomware-этап

Цепочка:

останавливаются службы и процессы, мешающие шифрованию;
удаляются shadow copies;
отключаются backup-механизмы;
происходит массовое изменение файлов;
создаётся ransom note.

Детектирование:

команды vssadmin delete shadows;
команды wbadmin delete catalog;
команды bcdedit для изменения recovery;
массовые переименования или перезапись файлов;
высокая энтропия записываемых данных;
остановка служб SQL, backup, почтовых серверов;
появление файлов с требованиями выкупа.

16. Сетевой обход и C2-маскировка

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

16.1. Типовые техники

HTTPS вместо HTTP;
использование CDN;
домены, похожие на легитимные;
динамические DNS;
newly registered domains;
DNS TXT/MX/HTTPS queries;
облачные сервисы: GitHub, OneDrive, Dropbox, Discord, Telegram, Slack, Azure, AWS;
jitter и случайные интервалы beaconing;
редкие HTTP-запросы с длинными паузами;
использование WebSocket;
трафик через легитимные API.

16.2. Поверхности детектирования

редкие или новые домены;
домены с низкой репутацией;
несоответствие SNI и Host;
подозрительные User-Agent;
длинные base64-блоки в URL или теле запроса;
периодические запросы с похожей структурой;
DNS-запросы к динамическим DNS;
TLS-сертификаты с аномалиями;
подключения от процессов, которые обычно не ходят в интернет;
сетевые подключения от PowerShell, WMI, MSHTA, Rundll32.

16.3. Защита

DNS logging и sinkhole;
контроль newly registered domains;
TLS inspection там, где это допустимо политикой;
JA3/JA4 fingerprinting, если поддерживается;
EDR network telemetry;
блокировка категорий риска: dynamic DNS, free hosting, anonymizers;
анализ beaconing через SIEM;
ограничение исходящего трафика для рабочих станций.

17. Обход через легитимные облачные сервисы

Использование легитимных облачных сервисов усложняет блокировку, потому что трафик выглядит доверенно.

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

GitHub raw/gist;
OneDrive;
Dropbox;
Google Drive;
Discord CDN/webhooks;
Telegram;
Slack;
Azure Blob Storage;
AWS S3;
Pastebin-подобные сервисы;
serverless endpoints.

17.2. Признаки риска

рабочая станция обращается к облачному сервису сразу после открытия вложения;
запрос содержит подозрительные параметры;
загружается файл с высоким уровнем энтропии;
процесс-загрузчик — скриптовый интерпретатор;
после загрузки создаётся процесс или persistence;
URL не относится к обычной бизнес-активности пользователя.

17.3. Защита

мониторинг загрузки файлов из облачных сервисов;
контроль исполняемых файлов, загружаемых через браузер и мессенджеры;
CASB/DLP, если применимо;
блокировка запуска исполняемых файлов из пользовательских каталогов;
анализ цепочки: браузер → файл

zer0coder · Вчера в 19:54

Продолжи

Zer0Kernel CVE Radar · Вчера в 19:56

Продолжение: завершаю пункт про облачные сервисы и дальше перехожу к практическому детектированию, корреляциям, incident response и hardening.

17.3 Защита от браузерных и облачных цепочек — завершение

Анализировать всю цепочку:
- браузер → созданный файл → запуск процесса → сетевое подключение → persistence.
Контролировать Mark-of-the-Web:
- файлы из почты, браузера, мессенджеров и архивов должны сохранять зону происхождения.
Ограничивать запуск:
- скриптов из Temp, AppData, Downloads, Public;
- LNK/HTA/JS/VBS из пользовательских каталогов;
- исполняемых файлов, извлечённых из архивов и контейнеров.
Использовать:
- ASR rules;
- SmartScreen;
- WDAC/AppLocker;
- EDR-правила на browser-spawned suspicious processes;
- почтовую фильтрацию и sandbox для вложений.

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

18. Минимальный набор корреляций для SIEM/EDR

Ниже — защитные корреляции, которые помогают выявлять попытки обхода поведенческого анализа и облачных проверок. Их нужно адаптировать под свою телеметрию и проверять на ложные срабатывания.

18.1 Office-процесс создаёт подозрительный дочерний процесс

Типовой признак фишинговой цепочки:

winword.exe → cmd.exe
excel.exe → powershell.exe
outlook.exe → mshta.exe
powerpnt.exe → rundll32.exe

Пример Sigma-правила:

YAML:

title: Suspicious Child Process Spawned By Office Application
id: REPLACE_WITH_UUID
status: experimental
description: Detects Office applications spawning shells or script interpreters.
logsource:
  product: windows
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\msaccess.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate administrative scripts
  - Internal automation
level: high

18.2 Скриптовый интерпретатор создаёт сетевое подключение

Подозрительно, если интерпретатор сам ходит в интернет:

powershell.exe → C2_DOMAIN
mshta.exe → C2_DOMAIN
wscript.exe → C2_DOMAIN
rundll32.exe → C2_DOMAIN

Пример Sigma-правила для сетевой телеметрии:

YAML:

title: Script Interpreter Or Proxy Binary Network Connection
id: REPLACE_WITH_UUID
status: experimental
description: Detects network connections from script interpreters or proxy binaries.
logsource:
  product: windows
  category: network_connection
detection:
  selection:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
    Initiated: 'true'
  filter_local:
    DestinationIp|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_local
falsepositives:
  - Legitimate update mechanisms
  - Internal scripts accessing approved services
level: medium

18.3 Создание persistence через scheduled task

Подозрительные признаки:

задача создаётся из пользовательского каталога;
задача запускает PowerShell, WMI, MSHTA, Rundll32;
команда содержит base64, IEX, DownloadString, FromBase64String;
задача создаётся сразу после открытия документа или архива.

Пример Sigma-правила:

YAML:

title: Suspicious Scheduled Task Creation
id: REPLACE_WITH_UUID
status: experimental
description: Detects scheduled task creation with suspicious command lines.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4698
    TaskContent|contains:
      - 'powershell'
      - 'pwsh'
      - 'mshta'
      - 'rundll32'
      - 'regsvr32'
      - 'wscript'
      - 'cscript'
      - 'certutil'
      - 'bitsadmin'
      - 'FromBase64String'
      - 'IEX'
      - 'DownloadString'
      - 'Net.WebClient'
  condition: selection
falsepositives:
  - Legitimate administrative tasks
level: high

18.4 Создание подозрительной службы

Признаки:

служба создаётся с бинарным путём в Temp, AppData, Downloads;
служба запускает скрипт или интерпретатор;
имя службы похоже на системное, но путь нестандартный;
служба создаётся shortly after network connection.

Пример Sigma-правила:

YAML:

title: Suspicious Service Creation
id: REPLACE_WITH_UUID
status: experimental
description: Detects service creation with suspicious binary paths or interpreters.
logsource:
  product: windows
  service: system
detection:
  selection:
    EventID: 7045
    ImagePath|contains:
      - '\Temp\'
      - '\AppData\'
      - '\Downloads\'
      - '\Public\'
      - 'powershell'
      - 'mshta'
      - 'rundll32'
      - 'regsvr32'
      - 'wscript'
      - 'cscript'
  condition: selection
falsepositives:
  - Some installers and admin tools
level: high

18.5 Подготовка к ransomware

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

удаление shadow copies;
удаление backup catalog;
изменение boot recovery;
остановка служб;
массовое переименование или перезапись файлов;
появление ransom note.

Пример Sigma-правила:

YAML:

title: Possible Ransomware Preparation Activity
id: REPLACE_WITH_UUID
status: experimental
description: Detects commands commonly used before mass encryption.
logsource:
  product: windows
  category: process_creation
detection:
  selection_vss:
    CommandLine|contains:
      - 'vssadmin delete shadows'
      - 'vssadmin resize shadowstorage'
  selection_wbadmin:
    CommandLine|contains:
      - 'wbadmin delete catalog'
      - 'wbadmin delete systemstatebackup'
  selection_bcdedit:
    CommandLine|contains:
      - 'bcdedit /set recoveryenabled no'
      - 'bcdedit /set bootstatuspolicy ignoreallfailures'
  selection_services:
    CommandLine|contains:
      - 'net stop'
      - 'sc stop'
      - 'taskkill'
  condition: 1 of selection_*
falsepositives:
  - Legitimate backup maintenance
  - Administrator troubleshooting
level: high

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

19. Примеры KQL для Microsoft Defender for Endpoint

Если используется MDE, полезны такие запросы. Их нужно адаптировать под схему и имена полей.

19.1 Office spawning suspicious process

Код:

DeviceProcessEvents
| where InitiatingProcessFileName in~ (
    "winword.exe",
    "excel.exe",
    "powerpnt.exe",
    "outlook.exe",
    "msaccess.exe"
)
| where FileName in~ (
    "cmd.exe",
    "powershell.exe",
    "pwsh.exe",
    "wscript.exe",
    "cscript.exe",
    "mshta.exe",
    "rundll32.exe",
    "regsvr32.exe",
    "certutil.exe",
    "bitsadmin.exe"
)
| project TimeGenerated,
          DeviceName,
          AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          FileName,
          ProcessCommandLine,
          FolderPath

19.2 Сетевые подключения от подозрительных процессов

Код:

DeviceNetworkEvents
| where InitiatingProcessFileName in~ (
    "powershell.exe",
    "pwsh.exe",
    "wscript.exe",
    "cscript.exe",
    "mshta.exe",
    "rundll32.exe",
    "regsvr32.exe",
    "certutil.exe",
    "bitsadmin.exe"
)
| where RemoteUrl !has "example.internal"
| project TimeGenerated,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteUrl,
          RemoteIP,
          RemotePort

19.3 Подозрительные загрузки DLL

Код:

DeviceImageLoadEvents
| where FileName endswith ".dll"
| where FolderPath has_any (
    @"\\Temp\\",
    @"\\AppData\\",
    @"\\Downloads\\",
    @"\\Public\\"
)
| project TimeGenerated,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessFolderPath,
          FileName,
          FolderPath,
          SHA256

19.4 Подозрительные изменения registry

Код:

DeviceRegistryEvents
| where RegistryKey has_any (
    @"Software\Microsoft\Windows\CurrentVersion\Run",
    @"Software\Microsoft\Windows\CurrentVersion\RunOnce",
    @"Software\Classes\CLSID"
)
| where ActionType in~ ("RegistryValueSet", "RegistryKeyCreated")
| project TimeGenerated,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RegistryKey,
          RegistryValueName,
          RegistryValueData

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

20. YARA и memory scanning

YARA-правила полезны для сканирования файлов, памяти процессов и артефактов incident response. Правила нужно тестировать на чистом корпусе файлов, иначе возможны ложные срабатывания.

20.1 Пример лабораторного YARA-правила для PE-аномалий

Код:

import "pe"

rule lab_pe_suspicious_section_flags
{
    meta:
        description = "Lab rule: PE section with executable and writable flags"
        author = "defensive-analysis"
        note = "High false positive potential; tune for your environment"

    condition:
        pe.is_pe and
        for any i in (0 .. pe.number_of_sections - 1): (
            (pe.sections[i].characteristics & 0x20000000) and
            (pe.sections[i].characteristics & 0x80000000)
        )
}

20.2 Пример правила для подозрительных строк в скриптах

Код:

rule lab_suspicious_script_download_patterns
{
    meta:
        description = "Lab rule: suspicious download and execution patterns in scripts"
        author = "defensive-analysis"

    strings:
        $s1 = "Net.WebClient" nocase wide ascii
        $s2 = "DownloadString" nocase wide ascii
        $s3 = "DownloadFile" nocase wide ascii
        $s4 = "IEX" nocase wide ascii
        $s5 = "FromBase64String" nocase wide ascii
        $s6 = "mshta" nocase wide ascii
        $s7 = "rundll32" nocase wide ascii
        $s8 = "regsvr32" nocase wide ascii

    condition:
        filesize < 2MB and
        3 of them
}

20.3 Где применять YARA

сканирование файлов из почты и браузера;
сканирование извлечённых архивов;
сканирование memory dumps;
сканирование prefetch, Amcache, shimcache артефактов;
проверка подозрительных DLL и скриптов.

20.4 Ограничения

YARA не заменяет EDR;
правила могут давать false positives;
упакованные образцы могут не совпадать со статическими правилами;
для memory-only malware нужен memory capture и memory scanning.

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

21. Важные Windows-события для расследования

21.1 Security log

4688 — создание процесса, если включено логирование командной строки.
4698 — создана scheduled task.
4697 — установлена служба.
4624 — успешный вход.
4625 — неудачный вход.
4672 — привилегированный вход.
4699 — scheduled task удалена.
4702 — scheduled task обновлена.
1102 — очистка журнала безопасности.

21.2 System log

7045 — установлена служба.
7040 — изменено состояние службы.
7036 — служба вошла в состояние.
7034 — служба неожиданно завершилась.
1001 — bugcheck/системная ошибка.

21.3 Sysmon Operational

1 — ProcessCreate.
3 — NetworkConnect.
5 — ProcessTerminate.
7 — ImageLoaded.
8 — CreateRemoteThread.
10 — ProcessAccess.
11 — FileCreate.
12 — RegistryEvent object create/delete.
13 — RegistryEvent value set.
14 — RegistryEvent object rename.
19 — WmiEventFilter.
20 — WmiEventConsumer.
21 — WmiEventConsumerToFilter.
22 — DnsQuery.
23 — FileDelete.
25 — ProcessTampering.
26 — FileDeleteDetected.

21.4 PowerShell

4103 — Module Logging.
4104 — Script Block Logging.
400, 403, 600 — классические PowerShell события.
800 — PowerShell pipeline execution details.

21.5 WMI-Activity

5857 — загрузка провайдера WMI.
5858 — ошибки WMI.
5859 — регистрация event filter.
5860 — регистрация event consumer.
5861 — регистрация filter-to-consumer binding.

21.6 CodeIntegrity / AppLocker / WDAC

CodeIntegrity 3077 — блокировка или предупреждение WDAC.
AppLocker 8002, 8003, 8004 — события разрешений и блокировок.
AppLocker 8020, 8021, 8022 — события MSI/script packaging, если применимо.

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

22. Артефакты для incident response

При подозрении на обход AV/EDR и memory-only активность важно сохранять не только файлы, но и память, журналы, конфигурацию системы.

22.1 Что сохранять

memory dump, если система ещё работает;
disk image или хотя бы критичные артефакты;
event logs;
Sysmon logs;
PowerShell logs;
Prefetch;
Amcache;
ShimCache;
MFT;
$UsnJrnl;
registry hives;
scheduled tasks;
WMI repository;
services configuration;
browser artifacts;
email artifacts;
network logs;
EDR telemetry export.

22.2 Полезные пути

Код:

C:\Windows\Prefetch
C:\Windows\System32\winevt\Logs
C:\Windows\System32\config
C:\Windows\System32\LogFiles
C:\Windows\Temp
C:\Users\*\AppData\Local\Temp
C:\Users\*\AppData\Roaming
C:\Users\*\Downloads
C:\ProgramData
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Tasks
C:\Windows\System32\wbem\Repository

22.3 Быстрая проверка scheduled tasks

Код:

Get-ScheduledTask |
    Where-Object { $_.State -ne "Disabled" } |
    Select-Object TaskName, TaskPath, State, Author

Код:

schtasks /query /fo LIST /v

22.4 Быстрая проверка служб

Код:

Get-Service |
    Select-Object Name, DisplayName, Status, StartType

Код:

sc.exe query state= all

22.5 Быстрая проверка WMI persistence

Код:

Get-CimInstance -Namespace root/subscription -ClassName __EventFilter
Get-CimInstance -Namespace root/subscription -ClassName __EventConsumer
Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding

22.6 Быстрая проверка автозагрузки

Код:

Get-CimInstance Win32_StartupCommand |
    Select-Object Name, Command, Location, User

Код:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"

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

23. Порядок реагирования при подозрении на обход защиты

23.1 Изоляция и сохранение данных

Изолировать хост от сети, но не выключать сразу, если нужен memory dump.
Если есть EDR, использовать network containment.
Сохранить memory dump до reboot.
Сохранить event logs и Sysmon logs.
Зафиксировать время, хост, пользователя, IP, домены, хэши.

23.2 Проверка масштаба

Какие хосты имели похожие события?
Какие пользователи входили?
Какие учётные данные использовались?
Какие сетевые подключения были?
Какие файлы создавались?
Какие persistence найдены?
Есть ли признаки lateral movement?

23.3 Поиск persistence

Проверить:

scheduled tasks;
службы;
registry Run/RunOnce;
WMI subscriptions;
COM hijacking;
startup folder;
shortcuts;
browser extensions;
installer abuse;
driver loading;
boot/startup drivers.

23.4 Поиск C2

Проверить:

DNS queries;
HTTP/HTTPS requests;
newly registered domains;
dynamic DNS;
cloud storage URLs;
webhook endpoints;
unusual User-Agent;
beaconing intervals;
TLS certificate anomalies.

23.5 Учётные данные

Если есть признаки доступа к памяти lsass.exe, credential dumping или использование привилегированных аккаунтов:

сбросить пароли затронутых учётных записей;
отозвать сессии и токены;
проверить Kerberos tickets;
проверить MFA-события;
проверить использование service accounts;
проверить golden/silver ticket признаки, если есть AD logs.

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

24. Hardening: что снижает эффективность обхода

24.1 Windows и AD

Включить Credential Guard, где поддерживается.
Включить LSA Protection.
Использовать HVCI/VBS.
Ограничить загрузку неподписанных драйверов.
Использовать tiering для административных аккаунтов.
Включить LAPS или аналогичный механизм локальных паролей.
Ограничить Pass-the-Hash и Pass-the-Ticket поверхности.
Контролировать DCOM, RPC, WMI, SMB.

24.2 PowerShell

Включить Script Block Logging.
Включить Module Logging.
Включить Transcription.
Использовать Constrained Language Mode.
Ограничить DownloadString, DownloadFile, Net.WebClient через политики, если это допустимо.
Контролировать -EncodedCommand, -FromBase64String, IEX.

24.3 Office

Заблокировать макросы из интернета.
Запретить OLE/ActiveX из недоверенных источников.
Включить Protected View.
Использовать ASR rules:
- Office child process control;
- Office communication app child process control;
- script download control;
- executable content extraction control.
Контролировать вложения и ссылки в почте.

24.4 Браузер и почта

Блокировать опасные типы вложений.
Блокировать исполняемые файлы внутри архивов.
Контролировать ISO/VHD/VHDX/LNK/HTA/JS/VBS.
Использовать Safe Links и Safe Attachments, если есть.
Ограничивать запуск файлов из Downloads.
Контролировать HTML smuggling.

24.5 WDAC/AppLocker

Запретить запуск неподписанных бинарников из пользовательских каталогов.
Ограничить LOLBin по пути и hash, если политика позволяет.
Использовать audit mode перед enforce mode.
Собирать события WDAC/AppLocker и анализировать их.

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

25. Проверка детектирования в лаборатории

Для проверки правил и EDR-политик нужна изолированная лаборатория.

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

Windows 10/11 VM или Windows Server VM.
Sysmon.
PowerShell logging.
EDR/AV в режиме аудита или детектирования.
SIEM или локальный сборщик логов.
Сетевой capture.
Снапшоты VM.

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

Office spawning shell.
PowerShell network connection.
Scheduled task creation.
Service creation.
WMI persistence.
Registry Run key modification.
DLL load from user-writable path.
Suspicious network beaconing.
Ransomware preparation commands.
Memory injection telemetry.

25.3 Как проверять безопасно

Использовать только свои VM.
Не использовать реальные учётные данные production.
Использовать placeholders:
- TARGET_IP
- TARGET_DOMAIN
- C2_DOMAIN
- USERNAME
- TOKEN
Делать снапшоты до теста.
После теста очищать стенд или откатывать snapshot.

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

26. Практический чек-лист обнаружения обхода

Если файл или процесс выглядит подозрительно, проверять не только хэш, а контекст:

Файл:
- хэш;
- подпись;
- путь;
- entropy;
- секции;
- импорты;
- ресурсы;
- timestamp;
- наличие MOTW.
Процесс:
- родитель;
- командная строка;
- пользователь;
- путь;
- подпись;
- дочерние процессы;
- сетевые подключения.
Память:
- RWX regions;
- executable memory without backing file;
- injected code;
- .NET assembly in unusual process;
- suspicious call stacks.
Сеть:
- домен;
- IP;
- newly registered domain;
- dynamic DNS;
- cloud service;
- TLS certificate;
- beaconing.
Persistence:
- scheduled task;
- service;
- registry;
- WMI;
- COM;
- startup folder;
- driver.

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

27. Главный вывод

Обход поведенческого детекта и облачных антивирусов обычно строится не на одной «магической» технике, а на комбинации:

редкий или уникальный файл;
доверенный процесс;
разделение этапов;
задержки и проверки окружения;
memory-only выполнение;
использование LOLBin;
маскировка C2 под легитимный трафик;
попытки ослабить телеметрию.

Поэтому защита должна быть не только файловой, но и поведенческой, событийной, сетевой и memory-based. Наиболее эффективны:

EDR с kernel telemetry;
Sysmon;
PowerShell logging;
SIEM correlation;
WDAC/AppLocker;
ASR rules;
network controls;
sandbox с длительным анализом;
memory forensics;
incident response playbook.

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

Как вирусы обходят поведенческий детект и облака антивирусов

1. Что именно обходят: поведенческий детект и облако​

Поведенческий детектор​

Облачная проверка антивируса​

2. Типовые техники обхода облачных и статических проверок​

2.1. Полиморфизм и метаморфизм​

2.2. Упаковщики, протекторы, крипторы​

2.3. Низкая распространённость и targeted samples​

2.4. Злоупотребление подписями и доверенными файлами​

3. Обход песочниц и поведенческого анализа​

3.1. Проверка окружения​

3.2. Задержки и тайм-бомбы​

3.3. Разделение этапов​

4. Обход user-mode hooks, AMSI и ETW​

4.1. Unhooking и direct/indirect syscalls​

4.2. Подавление ETW​

4.3. Обход AMSI​

5. Техники работы с памятью и процессами​

5.1. Process injection​

5.2. Memory-only malware​

6. Fileless-техники и persistence​

6.1. PowerShell, WMI, registry, scheduled tasks​

6.2. WMI persistence​

1. WMI persistence: продолжение​

2. COM hijacking​

3. Scheduled tasks и службы​

4. Маскировка под легитимные процессы​

5. Living-off-the-land binaries​

6. Обход облачных проверок через редкость и целевую доставку​

7. Обход sandbox и автоматического анализа​

8. Разделение этапов выполнения​

9. Memory-only и fileless-подходы​

10. Обход user-mode hooks, AMSI и ETW​

10. Попытки ослабить телеметрию: hooks, AMSI, ETW​

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

10.2. Подавление или повреждение ETW​

10.3. Обход AMSI​

11. Memory-only и fileless-техники​

11.1. Типовые варианты​

11.2. Признаки в телеметрии​

11.3. Полезные события Sysmon​

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

11.5. Защита​

12. Обход облачных проверок через редкость, подписи и контекст​

12.1. Низкая распространённость​

12.2. Подписанные файлы и DLL side-loading​

12.3. Парольные архивы и контейнеры​

13. Обход sandbox и автоматического анализа​

13.1. Проверки окружения​

13.2. Поведенческие признаки sandbox evasion​

13.3. Как улучшить sandbox​

14. Разделение этапов выполнения​

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

14.2. Почему это эффективно​

14.3. Что нужно для обнаружения​

15. Типовые цепочки из реальных кампаний​

15.1. Фишинговый документ → макрос → интерпретатор​

15.2. ISO/LNK → скрипт → proxy binary​

15.3. HTML smuggling → браузер → локальный файл​

15.4. Signed binary → side-loaded DLL​

15.5. WMI persistence → PowerShell​

15.6. Ransomware-этап​

16. Сетевой обход и C2-маскировка​

16.1. Типовые техники​

16.2. Поверхности детектирования​

16.3. Защита​

17. Обход через легитимные облачные сервисы​

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

17.2. Признаки риска​

17.3. Защита​

17.3 Защита от браузерных и облачных цепочек — завершение​

18. Минимальный набор корреляций для SIEM/EDR​

18.1 Office-процесс создаёт подозрительный дочерний процесс​

18.2 Скриптовый интерпретатор создаёт сетевое подключение​

18.3 Создание persistence через scheduled task​

18.4 Создание подозрительной службы​

18.5 Подготовка к ransomware​

19. Примеры KQL для Microsoft Defender for Endpoint​

19.1 Office spawning suspicious process​

1. Что именно обходят: поведенческий детект и облако

Поведенческий детектор

Облачная проверка антивируса

2. Типовые техники обхода облачных и статических проверок

2.1. Полиморфизм и метаморфизм

2.2. Упаковщики, протекторы, крипторы

2.3. Низкая распространённость и targeted samples

2.4. Злоупотребление подписями и доверенными файлами

3. Обход песочниц и поведенческого анализа

3.1. Проверка окружения

3.2. Задержки и тайм-бомбы

3.3. Разделение этапов

4. Обход user-mode hooks, AMSI и ETW

4.1. Unhooking и direct/indirect syscalls

4.2. Подавление ETW

4.3. Обход AMSI

5. Техники работы с памятью и процессами

5.1. Process injection

5.2. Memory-only malware

6. Fileless-техники и persistence

6.1. PowerShell, WMI, registry, scheduled tasks

6.2. WMI persistence

1. WMI persistence: продолжение

2. COM hijacking

3. Scheduled tasks и службы

4. Маскировка под легитимные процессы

5. Living-off-the-land binaries

6. Обход облачных проверок через редкость и целевую доставку

7. Обход sandbox и автоматического анализа

8. Разделение этапов выполнения

9. Memory-only и fileless-подходы

10. Обход user-mode hooks, AMSI и ETW

10. Попытки ослабить телеметрию: hooks, AMSI, ETW

10.1. Обход user-mode hooks

10.2. Подавление или повреждение ETW

10.3. Обход AMSI

11. Memory-only и fileless-техники

11.1. Типовые варианты

11.2. Признаки в телеметрии

11.3. Полезные события Sysmon

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

11.5. Защита

12. Обход облачных проверок через редкость, подписи и контекст

12.1. Низкая распространённость

12.2. Подписанные файлы и DLL side-loading

12.3. Парольные архивы и контейнеры

13. Обход sandbox и автоматического анализа

13.1. Проверки окружения

13.2. Поведенческие признаки sandbox evasion

13.3. Как улучшить sandbox

14. Разделение этапов выполнения

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

14.2. Почему это эффективно

14.3. Что нужно для обнаружения

15. Типовые цепочки из реальных кампаний

15.1. Фишинговый документ → макрос → интерпретатор

15.2. ISO/LNK → скрипт → proxy binary

15.3. HTML smuggling → браузер → локальный файл

15.4. Signed binary → side-loaded DLL

15.5. WMI persistence → PowerShell

15.6. Ransomware-этап

16. Сетевой обход и C2-маскировка

16.1. Типовые техники

16.2. Поверхности детектирования

16.3. Защита

17. Обход через легитимные облачные сервисы

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

17.2. Признаки риска

17.3. Защита

17.3 Защита от браузерных и облачных цепочек — завершение

18. Минимальный набор корреляций для SIEM/EDR

18.1 Office-процесс создаёт подозрительный дочерний процесс

18.2 Скриптовый интерпретатор создаёт сетевое подключение

18.3 Создание persistence через scheduled task

18.4 Создание подозрительной службы

18.5 Подготовка к ransomware

19. Примеры KQL для Microsoft Defender for Endpoint

19.1 Office spawning suspicious process

19.2 Сетевые подключения от подозрительных процессов

19.3 Подозрительные загрузки DLL