Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Введение в интерфейс проверки антивредоносных программ 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.
Что еще хуже в обоих из этих примеров заключается в том, что антивирусная подсистема проверяет файлы, открытые пользователем. Если вредоносное содержимое живет только в памяти, то атака может не обнаружиться.
В этом разделе показаны ограничения обнаружения с помощью традиционных подписей. Но, хотя вредоносный скрипт может пройти несколько этапов снятия обфускации, в конечном итоге он должен предоставить обработчику скриптов обычный, необфусцированный код. И на этом этапе, как описано в первом разделе выше, встроенные узлы сценариев Windows вызывают API AMSI, чтобы запросить сканирование этого незащищенного содержимого. И ваше приложение может сделать то же самое.