Попытки обхода AMSI: что контролирует Windows и какие артефакты помогают защитнику

AMSI (Antimalware Scan Interface) — это API-слой в Windows, который позволяет приложениям передавать содержимое скриптов и команд на проверку антивирусному движку перед выполнением. Появившись в Windows 10, он стал обязательным элементом защиты от fileless-атак: даже если вредоносный код никогда не записывается на диск, AMSI перехватывает его в момент интерпретации.

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

Архитектура AMSI и точки интеграции​

AMSI реализован как COM-интерфейс, доступный через amsi.dll. Приложения-потребители (AMSI consumers) вызывают функции AmsiInitialize, AmsiOpenSession, AmsiScanBuffer и AmsiCloseSession, передавая буфер данных на проверку. Провайдер (AMSI provider) — антивирусный продукт, зарегистрированный в системе, — принимает буфер и возвращает вердикт.

Интегрированные потребители в Windows:

• PowerShell (начиная с версии 5.0) — сканирует каждый блок кода перед выполнением.
  
• Windows Script Host (wscript.exe, cscript.exe) — сканирует JScript и VBScript.
  
• VBA-макросы в Microsoft Office (начиная с Office 2016).
  
• User Account Control (UAC) — проверяет исполняемые файлы при повышении привилегий.
  
• .NET (начиная с .NET 4.8) — сканирует динамически загружаемые сборки.
  

Каждый из этих потребителей генерирует события, которые можно наблюдать через ETW (Event Tracing for Windows) и журналы событий.

Категории обхода и их детектируемые следы​

Патчинг amsi.dll в памяти процесса​

Наиболее распространённая техника: атакующий находит функцию AmsiScanBuffer в адресном пространстве текущего процесса и перезаписывает её первые байты, чтобы она всегда возвращала AMSI_RESULT_CLEAN или E_INVALIDARG.

Артефакты для защитника:

• ETW-провайдер Microsoft-Antimalware-Scan-Interface фиксирует инициализацию сессий. Если процесс, который обычно вызывает AMSI (powershell.exe, wscript.exe), внезапно перестаёт генерировать события сканирования при продолжении выполнения скриптов — это аномалия.
  
• Защита кода (CIG, Code Integrity Guard): если включена политика подписи кода для процесса, патчинг секции .text вызовет нарушение. Однако по умолчанию для PowerShell это не всегда активно.
  
• Memory integrity (HVCI): при включённой HyperVisor-protected Code Integrity перезапись исполняемых страниц блокируется на уровне гипервизора.
  
• Событие 1116 в журнале Microsoft-Windows-Windows Defender/Operational может фиксировать обнаружение известных паттернов патчинга, если сигнатура обновлена.
  

Обход через рефлексию и загрузку .NET-сборок​

Атакующий загружает .NET-сборку через Assembly.Load() и вызывает метод через рефлексию, минуя стандартный путь компиляции. Начиная с .NET 4.8, CLR интегрирована с AMSI, но ранние версии .NET Framework не передают содержимое на сканирование.

Артефакты:

• События ETW-провайдера Microsoft-Windows-DotNETRuntime показывают загрузку сборок из памяти (событие AssemblyLoad с флагом, указывающим на отсутствие файла на диске).
  
• Если процесс использует .NET Framework версии ниже 4.8, это само по себе индикатор: современные легитимные приложения обычно обновлены.
  
• Sysmon Event ID 1 с аргументами командной строки может показать загрузку через InstallUtil.exe, msbuild.exe или regsvcs.exe — типичные LOLBins для обхода.
  

Обход через фрагментацию и обфускацию​

AMSI сканирует буфер целиком. Если атакующий разбивает вредоносную строку на безвредные фрагменты и собирает её в рантайме (например, через конкатенацию строк в PowerShell или XOR-декодирование), сканер видит только отдельные части.

Артефакты:

• Script Block Logging (Event ID 4104) в журнале Microsoft-Windows-PowerShell/Operational записывает полный текст блока после деконструкции. Если в логе виден блок, который при сканировании был «чистым», но содержит подозрительные конструкции (Invoke-Expression, IEX, [System.Reflection.Assembly]::Load), это сигнал.
  
• Transcription (Event ID 4103) фиксирует весь ввод и вывод сессии PowerShell.
  
• Сравнение содержимого Script Block Logging с вердиктом AMSI позволяет выявить расхождения.
  

Подмена или отключение AMSI-провайдера​

AMSI-провайдер регистрируется в реестре по пути HKLM\SOFTWARE\Microsoft\AMSI\Providers\{CLSID}. Если атакующий удаляет или подменяет CLSID, все потребители теряют связь с антивирусом.

Артефакты:

• Мониторинг изменений в ключе реестра HKLM\SOFTWARE\Microsoft\AMSI\Providers через Sysmon Event ID 13 (Registry value set) или Event ID 12 (Registry object added/deleted).
  
• Если Windows Defender перестал получать запросы на сканирование, но процессы продолжают выполнять скрипты — это критическая аномалия.
  
• Tamper Protection в Microsoft Defender (доступна с Windows 10 1903) блокирует попытки изменения конфигурации защиты, включая удаление провайдеров.
  

Использование неинструментированных хостов​

AMSI покрывает не все интерпретаторы. Например, mshta.exe (HTML Application Host) исторически не был интегрирован с AMSI в ранних версиях Windows. Атакующие используют такие хосты для выполнения JScript/VBScript без сканирования.

Артефакты:

• Sysmon Event ID 1 с образом mshta.exe, rundll32.exe, regsvr32.exe в сочетании с сетевыми соединениями (Event ID 3) — классический индикатор LOLBin-атаки.
  
• AppLocker / WDAC политики могут блокировать запуск нежелательных хостов, а попытки обхода фиксируются в журнале Microsoft-Windows-AppLocker/EXE and DLL.
  

Практические источники телеметрии​

Источник	Что фиксирует	Где искать
ETW Microsoft-Antimalware-Scan-Interface	Инициализация AMSI, результаты сканирования	Трассировка через logman или EDR
PowerShell Script Block Logging (4104)	Полный код выполняемых блоков	Microsoft-Windows-PowerShell/Operational
PowerShell Transcription (4103)	Ввод/вывод сессии	Тот же журнал
Sysmon Event ID 1	Создание процессов с аргументами	Microsoft-Windows-Sysmon/Operational
Sysmon Event ID 13	Изменение значений реестра	Там же
Windows Defender Operational	Обнаружения, ошибки сканирования	Microsoft-Windows-Windows Defender/Operational
.NET ETW (Microsoft-Windows-DotNETRuntime)	Загрузка сборок из памяти	Трассировка через perfview или EDR

Настройки, которые должны быть включены​

Без правильного конфигурирования телеметрии артефакты просто не собираются. Минимальный набор:

1. Script Block Logging — включается через GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging.
   
2. PowerShell Transcription — там же, Turn on PowerShell Transcription.
   
3. Sysmon — должен быть установлен с конфигурацией, включающей Event ID 1, 3, 12, 13.
   
4. Tamper Protection — проверяется в Windows Security → Virus & threat protection → Settings.
   
5. Attack Surface Reduction rules — в частности, правило Block execution of potentially obfuscated scripts (ID: 5beb7efe-fd9a-4556-801d-275e5ffc04cc).
   

Ограничения детектирования​

• AMSI не логирует содержимое сканируемых буферов в стандартные журналы. Защитник видит факт сканирования и вердикт, но не сам код — для этого нужен Script Block Logging.
  
• Патчинг amsi.dll в процессе, запущенном с правами текущего пользователя, не требует повышения привилегий и не генерирует событие в Security-журнале по умолчанию.
  
• Если EDR не подписан на ETW-провайдер AMSI, факт отсутствия сканирования может остаться незамеченным.
  
• Обфускация, которая собирает payload после прохождения AMSI-сканирования (например, через Invoke-Expression с динамически построенной строкой), может быть не видна в момент сканирования, но видна в Script Block Logging.
  

Что проверять при расследовании​

• Процесс выполнял скриптовый код, но в ETW-трассировке AMSI нет соответствующих событий сканирования.
  
• В Script Block Logging присутствует код, который не был заблокирован, но содержит подозрительные паттерны.
  
• Реестр AMSI Providers был изменён незадолго до инцидента.
  
• Процесс-потребитель AMSI запущен с флагом --no-profile или через нетипичный родительский процесс.
  
• В памяти процесса обнаружена модификация секции .text модуля amsi.dll (проверяется через memory dump и сравнение хешей секций с эталонным файлом на диске).
  

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

Источники​

• OWASP Top Ten Web Application Security Risks | OWASP Foundation
  
• MITRE ATT&CK®