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) помогает защититься от вредоносных программ

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

Например, предположим, что приложение является скриптовым: оно принимает произвольный скрипт и выполняет его с помощью обработчика сценариев. На момент, когда скрипт готов к отправке в обработчик сценариев, приложение может вызвать API-интерфейсы AMSI Windows, чтобы запросить сканирование содержимого. Таким образом, вы можете безопасно определить, является ли скрипт вредоносным, прежде чем принять решение о его выполнении и выполнении.

Это верно, даже если скрипт был создан во время выполнения. Скрипт (вредоносный или иным способом) может пройти через несколько проходов отмены маскировки. Но в конечном итоге необходимо предоставить обработчик скриптов с простым незамеченным кодом. И это точка, в которой вы вызываете API AMSI.

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

Открытый интерфейс AMSI Windows. Это означает, что любое приложение может вызвать его; и любой зарегистрированный модуль защиты от вредоносных программ может обрабатывать содержимое, отправленное в него.

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

AMSI в действии

Давайте рассмотрим AMSI в действии. В этом примере Защитник Windows — это приложение, которое вызывает API AMSI. Но вы можете вызывать те же API из собственного приложения.

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

Чтобы сделать все более интересными, мы можем ввести этот скрипт вручную в командной строке, чтобы не было фактического файла для отслеживания. Это отражает то, что называется «без файловой угрозой». Это не так просто, как сканирование файлов на диске. Угроза может быть backdoor, который живет только в памяти компьютера.

Ниже приведен результат выполнения скрипта в Windows PowerShell. Вы увидите, что Защитник Windows может обнаружить пример теста AMSI в этом сложном сценарии, просто используя стандартную сигнатуру тестов AMSI.

Интеграция AMSI с JavaScript/VBA

Приведенный ниже рабочий процесс описывает комплексный поток другого примера, в котором демонстрируется интеграция AMSI с выполнением макросов в Microsoft Office.

• Пользователь получает документ, содержащий (вредоносный) макрос, который уклоняется от сканирования статического антивирусного программного обеспечения, используя такие методы, как скрытие, защищенные паролем файлы или другие.
• Затем пользователь открывает документ, содержащий (вредоносный) макрос. Если документ откроется в защищенном представлении, пользователь нажимает кнопку «Включить редактирование «, чтобы выйти из защищенного представления.
• Пользователь нажимает кнопку «Включить макросы» , чтобы разрешить выполнение макросов.
• При выполнении макроса среда выполнения VBA использует циклический буфер для записи данных и параметров, связанных с вызовами API Win32, COM и VBA.
• При наблюдении определенных API Win32 или COM, которые считаются высоким риском (также известные как триггеры) [2], выполнение макроса останавливается, а содержимое циклического буфера передается в AMSI.
• Зарегистрированный поставщик службы защиты от вредоносных программ AMSI отвечает вердиктом, чтобы указать, является ли макрокоманда вредоносным.
• Если поведение не является вредоносным, выполнение макроса продолжается.
• В противном случае, если поведение является вредоносным, Microsoft Office закрывает сеанс в ответ на оповещение [3], а av может поместить файл в карантин.

Что это означает для вас?

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

Для вас в качестве разработчика приложений рассмотрите возможность вызова приложения Windows интерфейса AMSI, если вы хотите воспользоваться дополнительными (и защитить клиентов) дополнительным сканированием и анализом потенциально вредоносного содержимого.

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

Дополнительные сведения об угрозах без файлов

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

Мы будем использовать PowerShell в качестве примера. Но вы можете использовать те же методы и процессы, которые мы продемонстрируем с любым динамическим языком: VBScript, Perl, Python, Ruby и т. д.

Ниже приведен пример вредоносного скрипта PowerShell.

Хотя этот скрипт просто записывает сообщение на экран, вредоносная программа обычно является более гнусной. Но вы можете легко написать подпись для обнаружения этого. Например, подпись может искать строку «Write-Host «pwnd!» в любом файле, который открывается пользователем. Отлично: мы обнаружили наши первые вредоносные программы!

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

В этом сценарии авторы вредоносных программ создают строку, представляющую скрипт PowerShell для запуска. Но они используют простой метод объединения строк, чтобы разорвать нашу более раннюю сигнатуру. Если вы когда-либо просматриваете источник веб-страницы ad-laden, вы увидите множество экземпляров этого метода, чтобы избежать блокировки рекламы программного обеспечения.

Наконец, автор вредоносных программ передает эту объединенную строку Invoke-Expression в командлет — механизм PowerShell для оценки скриптов, созданных или созданных во время выполнения.

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

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

Будучи ресурсным, большинство обработчиков антивредоносных программ также реализуют эмуляцию декодирования Base64. Поэтому, так как мы также реализуем эмуляцию декодирования Base64, мы надолго.

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

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

Но что делать, если маскатор настолько тривиальный, что выглядит как многие хорошо себя скрипты? Подпись для нее приведет к недопустимому числу ложных срабатываний. Ниже приведен пример сценария промежуточного сценария , который слишком неопасен для обнаружения самостоятельно.

В этом примере мы скачиваем веб-страницу и вызываем содержимое из него. Ниже приведен эквивалент в скрипте Visual Basic.

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

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

F#ck AMSI! Как обходят Anti-Malware Scan Interface при заражении Windows

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

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

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

Ког­да поль­зователь запус­кает скрипт или ини­циали­зиру­ет про­цесс 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( ) .

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

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

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

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