Amsi защита касперский что это

Amsi защита касперский что это

Компонент AMSI-защита предназначен для поддержки интерфейса Antimalware Scan Interface от Microsoft. Интерфейс Antimalware Scan Interface (AMSI) позволяет сторонним приложениям с поддержкой AMSI отправлять объекты (например, скрипты PowerShell) в Kaspersky Endpoint Security для дополнительной проверки и получать результаты проверки этих объектов. Сторонними приложениями могут быть, например, программы Microsoft Office (см. рис. ниже). Подробнее об интерфейсе AMSI см. в документации Microsoft.

AMSI-защита может только обнаруживать угрозу и уведомлять стороннее приложение об обнаруженной угрозе. Стороннее приложение после получения уведомления об угрозе не дает выполнить вредоносные действия (например, завершает работу).

Пример работы AMSI

Компонент AMSI-защита может отклонить запрос от стороннего приложения, например, если это приложение превысило максимальное количество запросов за промежуток времени. Kaspersky Endpoint Security отправляет информацию об отклонении запроса от стороннего приложения на Сервер администрирования. Компонент AMSI-защита не отклоняет запросы от тех сторонних приложений, для которых установлен флажок Не блокировать взаимодействие с AMSI-защитой .

AMSI-защита доступна для следующих операционных систем рабочих станций и серверов:

Как хакеры обходят проверку AMSI защиты

В последней статье посвященной антивирусам, я рассказал как обойти антивирус с помощью Chimera. В этой статье я покажу, как хакеры обходят проверку AMSI защиты.

Если вы пользователь Windows, тогда вам знакомо сообщение «Данный сце­нарий содер­жит вре­донос­ное содержимое и был заблокирован антивирусом» Это блокирующий механизма защиты Windows. Давайте разберемся, как его обходят хакеры.

AMSI (Anti-Malware Scan Interface) — это тех­нология Microsoft, которую раз­работа­ли для защиты компьютера от вирусов и другой малвари. Впер­вые была внед­рена в Windows 10. AMSI умеет в реаль­ном вре­мени перех­ватыва­ть и анализировать скрип­ты JavaScript, VBScript, VBA и коман­ды PowerShell.

Как это работает AMSI

При запуске скрипта или ини­циали­зации про­цесса PowerShell (или PowerShell_ISE), в про­цесс авто­мати­чес­ки заг­ружа­ется биб­лиоте­ка AMSI.DLL. Она пре­дос­тавля­ет нужный API для вза­имо­дей­ствия с анти­вирусом. Перед выполнением скрипта или коман­ды с помощью RPC подключается Microsoft Defender, он, в свою оче­редь, изучает получен­ные данные и отсы­лает ответ обратно AMSI.DLL. Если была обна­руже­на извес­тная вредоносная сиг­натура, выпол­нение останавливается и появ­ляет­ся сооб­щение о блокировке анти­вирус­ом.

Схема работы AMSI

На схеме выше обоз­начены две фун­кции — AmsiScanString ( ) и AmsiScanBuffer ( ) , они, в целом, глав­ные в цепоч­ке AmsiInitialize , AmsiOpenSession , AmsiScanString , AmsiScanBuffer и AmsiCloseSession . Если посмотреть Exports для amsi.dll, то можно увидеть это:

Экспорты amsi.dll библиотеки

Но большая часть данного спис­ка нам сегод­ня не понадобиться.

Итак, после запуска PowerShell. До того как ввести какие‑нибудь коман­ды, будет заг­ружена AMSI.DLL и про­изой­дет вызов AmsiInitialize ( ) .

Здесь исполь­зуют­ся 2 аргу­мен­та: имя при­ложе­ния и ука­затель на струк­туру CONTEXT. Параметр amsiContext будет исполь­зовать­ся в каж­дом пос­леду­ющем вызове AMSI API.

Пос­ле ввода коман­ды и попытки выпол­нить скрипт, про­исхо­дит вызов AmsiOpenSession ( ) :

В этот момент переда­ются 2 аргу­мен­та: amsiContext , получен­ный на шаге AmsiInitialize ( ) , и ука­затель на струк­туру SESSION. Параметр amsiSession будет исполь­зовать­ся в каж­дом пос­леду­ющем вызове AMSI API внут­ри данной сес­сии.

После чего в дело всту­пают AmsiScanString ( ) и AmsiScanBuffer ( ) . Вы можете понять по названию, какие именно парамет­ры они переда­ют.

Defender про­веря­ет буфер или стро­ку и воз­вра­щает резуль­тат. Если ответ от Defender — 32768, то вредонос обна­руже­н, еди­нич­ка сиг­нализи­рует, что все чис­то.

alt=»Вредонос обна­руже­н AMSI Windows» width=»750″ height=»312″ /> Вредонос обна­руже­н alt=»Вредонос не обна­ружен AMSI Windows» width=»750″ height=»312″ /> Вредонос не обна­ружен

Ну и пос­ле всех выше перечис­ленных про­верок текущая сес­сия зак­рыва­ется с исполь­зуя AmsiCloseSession .

Как обойти AMSI защиту

Ме­ханизм AMSI исполь­зует сиг­натур­ное (rule-based) детек­тирова­ние угроз. Зная этот факт, мож­но при­думы­вать раз­ные так­тики и тех­ники. Некото­рые извес­тные спо­собы уже не сра­бота­ют, но, исполь­зуя модифи­кацию кода, обфуска­цию и крип­тование, мож­но добить­ся инте­рес­ных резуль­татов.

PowerShell downgrade

Пер­вый спо­соб, который иног­да сра­баты­вает, три­виален. PowerShell 2.0 уста­рел, но Microsoft не спе­шит уда­лять его из опе­раци­онной сис­темы. У ста­рой вер­сии PowerShell нет таких защит­ных механиз­мов, как AMSI, поэто­му для обхо­да детек­та иног­да дос­таточ­но исполь­зовать коман­ду powershell — version 2 .

amsiInitFailed

Вто­рой спо­соб пре­дот­вра­тить ска­ниро­вание — это попытать­ся выс­тавить флаг amsiInitFailed для дан­ного про­цес­са. Дела­ется это сле­дующей коман­дой:

Од­нако тут не все так прос­то: что­бы выпол­нить эту коман­ду, при­дет­ся пот­рудить­ся, при­думы­вая спо­собы обфуска­ции PowerShell, так как на нее тоже сра­баты­вает детект.

Увы, на нашу команду сработал детект

Нап­ример, обфусци­ровать эту коман­ду мож­но так:

При­мер обфусци­рован­ной коман­ды для amsiInitFailed

Во вре­мя обфуска­ции мож­но про­явить фан­тазию. Нап­ример, так:

Хукинг

Function hooking — метод, поз­воля­ющий нам получить управле­ние над фун­кци­ей до ее вызова. В дан­ном слу­чае полез­но будет переза­писать аргу­мен­ты, которые фун­кция AmsiScanBuffer ( ) (или AmsiScanString ( ) ) будет переда­вать на про­вер­ку.

Тут все прос­то: инжектим DLL, которая пой­мает AmsiScanBuffer ( ) и передаст на про­вер­ку что‑нибудь безобид­ное. Исполь­зовать мож­но, нап­ример, AmsiHook.dll, инжектор мож­но взять там же.

Ре­зуль­тат инжекта AmsiHook.dll

Патчинг памяти

Ис­поль­зующих дан­ный метод инс­тру­мен­тов мно­го, мож­но выб­рать любой рабочий. Прин­цип оди­наков: про­пат­чить AmsiScanBuffer ( ) , что­бы всег­да воз­вра­щалось зна­чение «Про­вер­ка прой­дена успешно». Вот нес­коль­ко таких средств:

Для при­мера поп­робу­ем выпол­нить Memory Patching с помощью my — am — bypass . ps1 .

Ис­поль­зуем my-am-bypass.ps1

Вызов ошибки

Вспо­миная опи­сание прин­ципа работы AMSI, мож­но заметить, что во всех фун­кци­ях при­сутс­тву­ет струк­тура amsiContext . Идея спо­соба — выз­вать ошиб­ку в этой струк­туре и сло­мать весь цикл про­вер­ки. Слож­ности добав­ляет тот факт, что Microsoft никак не докумен­тиру­ет эту струк­туру, да и в целом мало и неохот­но пишет докумен­тацию для AMSI.

Рас­смот­рим этот спо­соб, исполь­зуя Frida (что­бы най­ти адрес) и дебаг­гер (что­бы пос­мотреть, что там про­исхо­дит).

Ис­сле­дуем amsiContext

Вве­дем что‑нибудь и пос­мотрим на вывод «Фри­ды».

Вы­вод «Фри­ды»

Те­перь откро­ем про­цесс PowerShell в дебаг­гере и пос­мотрим, что же находит­ся по это­му адре­су. Раз­мера этой струк­туры мы не зна­ем, но пер­вые 4 бай­та — это AMSI.

Прос­мотр про­цесса PowerShell в отладчи­ке

Ис­сле­дуя про­исхо­дящее даль­ше, замеча­ем, что регистр rcx (в котором дол­жен лежать пер­вый аргу­мент фун­кции) срав­нива­ется с нашими четырь­мя бай­тами и, если эти зна­чения не рав­ны, выпол­няет­ся переход на amsi ! AmsiOpenSession + 0x4c .

Мы видим, что фун­кция вер­нет нам то, что лежит в регис­тре eax . А в докумен­тации ука­зано, что воз­вра­щает­ся зна­чение с типом HRESULT .

На сай­те Microsoft мы находим нуж­ную информа­цию:

Ес­ли пер­вые четыре бай­та струк­туры кон­тек­ста не сов­падут с AMSI, AmsiOpenSession вер­нет ошиб­ку. Глав­ный воп­рос — к чему при­ведет эта ошиб­ка и что слу­чит­ся, если бай­ты все‑таки не сов­падут.

Единс­твен­ный спо­соб про­верить это — выз­вать ошиб­ку и пос­мотреть, что будет. Для это­го пос­тавим точ­ку оста­нова (breakpoint) на AmsiOpenSession, а затем поменя­ем 4 бай­та на зна­чение 0000 . Убе­дим­ся, что в регис­тре rcx находит­ся зна­чение 49534d41 ( dc rcx L1 ) , изме­ним его на 0 ( ed rcx 0 ) , про­верим, что выпол­нение прош­ло успешно и в регис­тре rcx сей­час 00000000 (еще раз dc rcx L1 ).

Пат­чим AmsiOpenSession

Те­перь, если заг­лянуть в frida-trace, мы уви­дим завет­ное AmsiScanBuffer ( ) Exit . При­вела ли эта ошиб­ка к наруше­нию цик­ла про­вер­ки AMSI? Про­верим эту теорию, выпол­нив что‑то «злов­редное».

Обход AMSI

Дан­ный метод с исполь­зовани­ем дебаг­гера был рас­смот­рен в качес­тве теории, в живом кей­се, разуме­ется, дебаг­гером ник­то не поль­зует­ся, а реали­зует­ся дан­ный метод в нес­коль­ко стро­чек в том же PowerShell.

Выводы

Как вид­но из при­меров, обой­ти защиту AMSI не так уж и слож­но. Зна­ние извес­тных методик может облегчить фазу пос­тэкс­плу­ата­ции (или даже фазу экс­плу­ата­ции).

AMSI может сыг­рать важ­ную роль в защите сис­тем Windows 10 и Windows Server от ком­про­мета­ции. Но AMSI не панацея. И хотя Microsoft Windows Defender обес­печива­ет некото­рую защиту от обхо­да AMSI, зло­умыш­ленни­ки пос­тоян­но находят спо­собы скрыть вре­донос­ный кон­тент от обна­руже­ния.

Amsi защита касперский что это

Antimalware Scan Interface (AMSI) позволяет стороннему приложению с поддержкой AMSI отправлять объекты в приложение Kaspersky Free для дополнительной проверки (например, скрипты PowerShell) и получать результаты проверки этих объектов. Сторонними приложениями могут быть, например, приложения Microsoft Office. Подробнее об интерфейсе AMSI см. в документации Microsoft.

С помощью Antimalware Scan Interface можно только обнаруживать угрозу и уведомлять стороннее приложение об обнаруженной угрозе. Стороннее приложение после уведомления об угрозе не дает выполнить вредоносные действия (например, завершает работу).

Приложение Kaspersky Free может отклонить запрос от стороннего приложения, например, если это приложение превысило максимальное количество запросов за промежуток времени. В этом случае приложение Kaspersky Free показывает уведомление о том, что запрос был отклонен. При получении такого уведомления вам не требуется выполнять никаких действий.

Защита с помощью Antimalware Scan Interface доступна на операционных системах Windows 10 Home / Pro / Education / Enterprise и Windows 11 Home / Pro / Enterprise.

BypassAV, бесфайловая атака и AMSI (теория)

Разработчики вредоносных программ постоянно ищут способ избежать обнаружения своих действий средствами защиты. Один из способов — обойти сканеры, используя обфускацию, шифрование, стеганографию и другие методы, чтобы антивирусному программному обеспечению было сложнее определить назначение «полезной нагрузки» или его загрузчика. Другой способ заключается в том, чтобы полностью избежать проверки кода вредоносного ПО или инструкций в памяти.

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

Современные антивирусные средства (механизмы)

В настоящее время типовые средства обеспечения информационной безопасности имеют множество функций, которые поддерживают серьезный уровень контроля и фильтрации трафика. Базовым средством защиты на каждом рабочем месте в организациях остается средство антивирусной защиты (САВЗ или АВЗ). Современные САВЗ являются сложной системой, подробности их работы не раскрываются, однако общие механизмы, лежащие в основе функционирования этих средств, известны.

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

К механизмам анализа условно относят

1. Статический (aka Сигнатурный) анализ

Первый рубеж. Антивирусный «вендор» выявляет так называемую сигнатуру. Сигнатура вируса — это признак вредоносной программы (часть кода), по которому её можно «узнать» и однозначно определить. Такие сигнатуры вносятся в базу и с помощью сравнения исследуемого кода с элементами базы осуществляется поиск плохиша. Основная проблема в том, что обойти этот механизм очень просто: от небольшого изменения исходного кода и обфускации при компиляции, до шифрования уже готового исполняемого файла.

Анализ осуществляется с файлами, лежащими на диске до их исполнения в виртуальной памяти.

2. Динамический анализ

Sandbox или же песочница. Запуск исполняемых файлов в эмулируемой среде, имитирующей окружение целевой ОС. Это позволяет выявить все действия файла после потенциального запуска пользователем. Например, расшифрование криптоконтейнера с вредоносным кодом в теле программы или подключение к удаленному серверу. Данный вид анализа обойти сложнее, однако злоумышленники исследователи в области ИБ находят методы обнаружения запуска в песочнице и не дают вредоносному участку кода выявить себя. Вот интересная статья от Positive Technologies.

Анализ осуществляется с файлами, лежащими на диске до их исполнения в виртуальной памяти или во время запуска пользователем.

3. Механизм распаковки

Является вспомогательным инструментом для динамического анализа. Злоумышленники часто упаковывают свой вредоносный код в контейнер путем различных преобразований для обхода статического и динамического обнаружения. Контейнеры с вредоносным кодом создаются вручную или с помощью различных упаковщиков или архиваторов. Сотрудники антивирусных компаний собирают все известные методы упаковки в единый механизм распаковки, который и позволяет выявить вредоносный код до запуска в песочнице. Метод экономит ресурсы и позволяет обнаружить большую часть опубликованных (с инструментами автоматизации) методов сокрытия. Данный механизм уязвим, так как его обход заключается в создании метода упаковки на основе небольшого видоизменения любого из публичных методов.

Анализ осуществляется при попадании файла на диск до его исполнения в виртуальной памяти или во время запуска пользователем.

4. Поведенческий (aka эвристический) анализ

Иногда еще называют методом статистического оценивания потенциально вредоносного поведения, что говорит само за себя. Файлу и созданному им процессу выдается «порог подозрительного поведения». После запуска, если первые два механизма не обнаружили ничего вредоносного, антивирусное средство оценивает поведение кода в виртуальной памяти системы. Например, вызов нетипичных системных функций, подключение сторонних библиотек, самокопирование, внедрение в память других процессов, инициация удаленного подключения и т.д. Если количество подозрительных действий процесса больше порога, то принимается решение о том, что это вредоносная программа. Данный механизм является одним из самых перспективных с точки зрения систем защиты и сложных со стороны обхода обнаружения.

Анализ осуществляется с запущенным в виртуальной памяти машины кодом исследуемого процесса.

Почему же не использовать глубокий анализ для всех входящих файлов сразу? Ограничены ресурсы! Антивирусное средство не может себе позволить забрать большую часть ресурсов пользователя, что вынуждает осуществлять градацию по степеням доверия кода, поступившего на вход системы.

Типы угроз (файловые и бесфайловые)

В данной статье разделим все угрозы на две категории: файловые и бесфайловые.
Файловые нам хорошо известны. Они попадают в систему через почту в половине случаев или через другой сетевой трафик (веб-интерфейс, любые другие протоколы передачи файлов). Их в свою очередь можно разделить на исполняемые .exe, .dll (бинарные) или неисполняемые, текстовые файлы, скрипты и т.д. К неисполняемым нагрузкам в последнее время повышенный интерес, ведь они являются основой для бесфайловых атак.

Бестелесное или бесфайловое вредоносное ПО — это такое ПО, которое не сохраняется на жестком диске в виде исполняемого файла, а загружается напрямую в виртуальную память. Такие зловреды опасны тем, что практически не оставляют следов в зараженной системе, поэтому их довольно сложно обнаружить. Так можно осуществить запуск Powershell кода сразу в процессе интерпретатора в лице системной службы powershell.exe удаленно или из другого процесса. Они находятся в оперативной памяти системы, реестре и других непостоянных областях хранения, что затрудняет их обнаружение с помощью обычного антивирусного программного обеспечения. Главное условие — код не должен попасть на жесткий диск, чтобы избежать динамического анализа.

Почему мы рассматриваем бесфайловые угрозы? Потому что злоумышленники все чаще используют их для атаки. На примере тех же powershell-нагрузок в виде файлов-скриптов или бесфайловой one-liner команды вредоносный код не подвергается динамическому анализу и распаковке. Проверка осуществляется только статическим и поведенческим анализом. И для достижения их цели они разрабатывают методы обхода только этих механизмов. Ниже продемонстрирован порядок создания необнаруживаемого ВПО и методы обхода соответствующих механизмов анализа.

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

Методы обхода публикуются, но сразу же теряют актуальность. Для нагрузок Powershell часто используется стратегия «оживления» известных методов обхода и их реализация при реальной атаке. Коды публичных методов обхода защиты в кратчайший срок вносятся в базы антивирусных средств. Ведь само решение обойти защиту — это вредоносное действие.

Bypass AMSI

Существует большое количество статей с описанием метода обхода защиты от файловых нагрузок. Но как мы говорили раньше, неисполняемые файлы подвергаются меньшему анализу, что привлекает злоумышленников. На примере Powershell-загрузчиков рассмотрим механизм защиты в операционных системах семейства Windows.
Интерфейс Microsoft Antimalware Scan. AMSI, представленный в 2015 году, предоставляет программному обеспечению свое внутреннее API для взаимодействия со средствами защиты, запрашивая сканирование файлов, памяти или потоков на наличие вредоносных полезных нагрузок методами сигнатурного и поведенческого анализа независимо от разработчика САВЗ. Если стороннее антивирусное средство не установлено, то по умолчанию библиотека amsi.dll взаимодействует с Windows Defender.

AMSI является «мостом» между антивирусным средством и процессом Powershell. Средство АВЗ осуществляет анализ скрипта функцией Amsiscanstring(), если он лежит на диске или после запуска пользователем, но до его передачи на исполнение процессу Powershell. А поведенческий анализ выявляет вредоносную активность после его запуска функцией Amsiscanbuffer().

Со дня появления AMSI злоумышленники (и исследователи безопасности) создавали инструменты для обхода или отключения AMSI. Корпорация Майкрософт и поставщики антивирусных средств предпринимают шаги по блокированию некоторых подходов, используемых для обхода AMSI, но злоумышленники продолжают приспосабливаться. Наиболее эффективными методами обхода являются различные варианты патчинга функций библиотеки AMSI.dll в памяти для недопущения проверки входящих скриптов антивирусным средством. Сам код таких обходов детектируется механизмами статического анализа, однако путем глубокой обфускации и многочисленных тестирований злоумышленники достигают своих целей и разрушают «мост», не давая антивирусному средству дойти до их основной нагрузки, передаваемой на уже полностью незащищенный процесс powershell.

Исследователи в области ИБ находят новые методы и публикуют их. Несомненно, данный код уже внесен в базы антивирусных средств, однако после глубокой обфускации и других преобразований над ними они встают на вооружение у злоумышленников.

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

Инструменты обфускации

Самые популярные инструменты автоматизации обфускации:

Однако их преобразования имеют паттерн, который хорошо известен разработчикам антивирусных средств. Часто их неправильное использование приводит к потере работоспособности исходного скрипта. Злоумышленники и исследователи берут их за основу. Также создаются и комбинируются собственные средства преобразования загрузчика, полезной нагрузки или кода отключения AMSI.

Но даже при использовании открытых инструментов напрямую получают обфусцированный код powershell загрузчика любой C2 системы, который пройдет механизм сигнатурного и поведенческого анализа ДО передачи основной нагрузки. А если вместе с ним был осуществлен патчинг amsi, то дальнейший анализ для данного процесса будет невозможен 🙂

Выводы

Итак, мы рассмотрели принципы работы современных САВЗ, упомянули методы их обхода и остановились подробнее на одном актуальным векторе атаки. Он заключается в применении powershell-загрузчиков Command and Control систем, обработанных путем глубокой обфускации и добавления кодов отключения механизмов защиты, например AMSI. Необходимо учитывать данные подходы при построении системы защиты от сетевого периметра до конкретного рабочего места в организации. Необходимо быть на шаг впереди, ведь злоумышленники продолжают разрабатывать новые инструменты для реализации известных векторов атак.