Как интерфейс проверки антивредоносных программ (AMSI) помогает защитить от вредоносных программ

Общие сведения об интерфейсе проверки антивредоносных программ Windows (AMSI) см. в разделе "Интерфейс проверки антивредоносных программ" (AMSI).

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

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

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

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

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

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

AMSI в действии

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

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

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

Ниже приведен результат выполнения скрипта в 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, автоматически проверяется на гораздо более глубоком уровне, чем когда-либо раньше, обеспечивая дополнительные уровни защиты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связанные ресурсы

• Угрозы без файлов
• Office VBA + AMSI: часть завесы на вредоносных макросах
• Вне зрения, но невидимо: поражение файловых вредоносных программ с мониторингом поведения, AMSI и next-gen AV