Система и способ формирования журнала в виртуальной машине для проведения антивирусной проверки файла Российский патент 2018 года по МПК G06F21/53 G06F21/56 

Область техники

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

Уровень техники

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

Кроме того, зачастую вредоносное программное обеспечение не проявляет свою вредоносную активность сразу, вместо этого производит множество (порядка миллионов вызовов) вызовов API-функций, огромные циклы (порядка миллиардов итераций), приостанавливает свою работу на некоторое время сразу после запуска (например, на 1 час использованием функции «Sleep()»). Вычислительные устройства пользователя в настоящее время имеют высокую производительность, многоядерные процессоры (есть и многопроцессорные системы), поэтому пользователь может не увидеть или не придать значения загруженности одного из ядер. Кроме того, обычно пользователь пользуется устройством после включения более одного часа. Поэтому вредоносному программному обеспечению, если оно запустилось, нет необходимости сразу проявлять свою активность.

Для борьбы с упомянутыми подходами производителями приложений безопасности (например, антивирусных приложений) используются подходы с использованием виртуальных машин в виде изолированной среды для безопасного исполнения файлов. Зачастую такие виртуальные машины называются песочницами (от англ. sandbox). Гипервизоры, под управлением которых работают такие виртуальные машины, содержат механизмы перехвата функций, вызываемых исполняемыми в них приложениями.

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

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

Так, публикация US 8479286 B2 описывает систему и способ, в которых файл до исполнения в виртуальной машине подвергается анализу, и для исполнения файла по результатам анализа выбирается окружение, наиболее подходящее для раскрытия поведения файла. Далее файл исполняется, если по результатам исполнения принимается решение об изменении окружения, окружение изменяется, и файл исполняется повторно.

Публикация US 7779472 B1 описывает классический способ исполнения файла в виртуальной машине. В процессе исполнения происходит перехват вызовов API-функций и их параметров. Набор вызванных API-функций сравнивается с наборами вызовов, соответствующих вредоносному поведению. В случае соответствия выносится решение о вредоносности файла.

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

Настоящее изобретение позволяет влиять на процесс исполнения файла в виртуальной машине при анализе файла на вредоносность.

Сущность изобретения

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

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

Согласно другому частному варианту реализации предлагается способ, в котором событие, связанное с изменением страницы памяти, представляет собой вызов API-функции во время исполнения потока процесса.

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

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

Согласно еще одному частному варианту реализации предлагается способ, в котором выявление передачи управления измененной странице памяти осуществляется в случае, если поток, исполняющий код с измененной страницы, запущен из процесса, отличного от процесса, поток которого изменил страницу памяти.

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

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

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

Краткое описание чертежей

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

Фиг. 1 показывает пример анализа файла на вредоносность в виртуальной машине.

Фиг. 2 показывает пример реализации предлагаемой системы формирования журнала для проведения антивирусной проверки файла.

Фиг. 3 показывает пример реализации предлагаемого способа формирования журнала для проведения антивирусной проверки файла.

Фиг. 4 показывает пример компьютерной системы общего назначения, которая позволяет реализовать настоящее изобретение.

Описание вариантов осуществления изобретения

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

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

Виртуальная машина в виде среды для безопасного исполнения файла - это набор (комплекс) программно-аппаратных средств, который предоставляет ресурсы хостовой операционной системы (ГОСТ 56938-2016) для гостевой операционной системы, при этом гостевая операционная система не имеет связи с хостовой операционной системой.

Под средствами системы анализа файла на вредоносность в виртуальной машине в настоящем изобретении понимаются реальные устройства, системы, компоненты, группы компонентов, реализованные с использованием аппаратных средств, таких как интегральные микросхемы (англ. application-specific integrated circuit, ASIC) или программируемые вентильные матрицы (англ. field-programmable gate array, FPGA) или, например, в виде комбинации программных и аппаратных средств, таких как микропроцессорная система и набор программных инструкций, а также на нейроморфных чипах (англ. neurosynaptic chips) Функциональность указанных средств системы может быть реализована исключительно аппаратными средствами, а также в виде комбинации, где часть функциональности средств системы реализована программными средствами, а часть аппаратными. В некоторых вариантах реализации часть средств, или все средства, могут быть исполнены на процессоре компьютера общего назначения (например, который изображен на Фиг. 4). При этом компоненты (каждое из средств) системы могут быть реализованы в рамках как одного вычислительного устройства, так и разнесены между несколькими, связанными между собой вычислительными устройствами.

Фиг. 1 показывает пример анализа файла на вредоносность в виртуальной машине.

В общем случае для анализа на вредоносность файл 100 открывается в виртуальной машине 120 в виде изолированной среды для исполнения файлов. Средство безопасности 110 передает виртуальной машине 120 файл 100. В одном из вариантов реализации виртуальная машина 120 создается средством безопасности 110. В другом варианте реализации виртуальная машина 120 выбирается средством безопасности 110 из ранее созданных виртуальных машин.

Стоит отметить, что в рамках настоящего изобретения файлом 100 является:

- исполняемый файл;

- динамическая библиотека;

- сценарий, исполняемый каким-либо интерпретатором (например, файлы Microsoft PowerShell);

- файлы, содержащие сценарии исполнения (например, файлы форматов Microsoft Office или Adobe Acrobat);

- веб-страница;

- изображение;

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

В одном из вариантов реализации под файлом 100 понимается ссылка (например, URL).

В общем случае анализ файла 100 осуществляется после его открытия в операционной системе виртуальной машины 120. Под открытием файла 100 понимается одно из:

- исполнение файла 100, если файл 100 исполняемый;

- открытие файла 100 приложением, если файл 100 не исполняемый.

Результатом открытия файла 100 является создание и запуск на исполнение процесса (англ. process) в виртуальной машине 120. При этом создается по меньшей мере один поток (англ. thread).

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

В общем случае гипервизор 115 содержит средство перехвата 130 (средство перехвата 130 является модулем, компонентом или функциональной частью гипервизора 115). Средство перехвата 130 перехватывает вызовы API-функций потоками процесса, созданного при открытии файла 100 в виртуальной машине 120, считывает контекст процессора, на котором исполняется поток, вызывавший API-функцию. Стоит отметить, что контекст процессора содержит по меньшей мере значения регистров процессора. В одном из вариантов реализации средство 130 перехвата также считывает стек, используя ранее считанные данные, содержащиеся в регистрах процессора, соответствующих стеку (например, память по адресу из регистров ESP и ЕВР). Кроме того, средство перехвата 130 агрегирует упомянутые данные, сохраняет их (например, в базе данных или в журнале 150) и передает их средству безопасности 110 после исполнения процесса, созданного при открытии файла 100. Средство безопасности 110 в свою очередь выносит на основании данных от средства перехвата 130 вердикт о вредоносности файла 100. В общем случае вердикт выносится после анализа сохраненных данных, например, в зависимости от того, в какой последовательности и с какими параметрами производился вызов API-функций потоками процесса, созданного при открытии файла 100. В одном из вариантов реализации, если вердикт не был вынесен, данные, сохраненные средством перехвата 130, передаются средством безопасности 110 специалисту по информационной безопасности (не отображен на Фиг. 1) на анализ.

Фиг. 2 показывает пример реализации предлагаемой системы формирования журнала для проведения антивирусной проверки файла.

Настоящее изобретение отличается тем, что предлагаемая система наряду со средством перехвата 130 содержит также средство анализа 140. В одном из вариантов реализации гипервизор 115 содержит средство анализа 140. В другом варианте реализации средство анализа 140 является компонентом (модулем, функциональной частью) средства безопасности 110.

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

Событиями являются по меньшей мере:

- вызов API-функции потоком;

- возврат из API-функции;

- системный вызов или, другими словами, обращение потока к ядру операционной системы для исполнения какой-либо операции (англ. system call);

- возврат из системного вызова;

- оповещение (уведомление, нотификация) от операционной системы (например, создание потока, создание процесса, загрузка модуля).

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

- уровне ядра (англ. kernel mode),

- уровне приложений (англ. user mode).

Исполнение потока приостанавливается путем остановки исполнения инструкций потока.

Стоит отметить, что в общем случае реализации во время исполнения потоков процесса, созданного при открытии файла 100, средство перехвата 130 определяет стандарт кодирования (англ. coding convention) вызываемых потоками API-функций. Это позволяет однозначно определить использование регистров процессора для передачи параметров в вызываемые API-функции. Так, например, параметры вызовов будут находиться в регистрах ЕСХ (первый параметр), EDX (второй параметр), остальные параметры будут в стеке (регистр ESP). Кроме того, стандарт кодирования позволяет однозначно определить возвращаемые значения. Например, если API-функция возвращает значение «0», то делает это в регистре ЕАХ.

Перехваченное событие и контекст процессора средство перехвата сохраняет в журнал 150. После сохранения журнал 150 передается средством перехвата 130 средству анализа 140.

Средство анализа 140 использует набор шаблонов. В одном из вариантов реализации шаблоны хранятся в структуре данных (например, в дереве). В структуру данных шаблоны могут быть добавлены средством анализа 140 во время запуска виртуальной машины 120. В другом варианте реализации, шаблоны выбираются средством анализа 140 из базы данных.

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

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

Примерами вышеописанных правил являются:

Правило 1: «если» вызвана FileOpen(«$SytemDrive:\<случайное имя>»), «то» продолжить исполнение.

Правило 2: «если» Правило 1 и FileWrite(«$SytemDrive:\<случайное имя>», текстовая строка), «то» продолжить исполнение.

В вышеописанном примере поток процесса, созданного при открытии файла 100, обращается к случайному (требуемому) файлу в корне системного диска. Само по себе событие создания (или чтения) требуемого файла не является вредоносным, но оно зачастую является началом вредоносного функционала. Поэтому средством анализа 140 на основании правил принимается решение продолжить исполнение упомянутого потока. Далее, в требуемый файл производится запись. В зависимости от типа требуемого файла и записанной в него информации требуемый файл может иметь вредоносный функционал.

Более подробным примером работы системы и правил является следующий набор:

Правило 10: «если» файл 100 не подписан, то продолжить исполнение.

Правило 11: «если» правило 10, «и» файл 100 вызвал FileOpen(«$SytemDrive:\<случайное имя>»), «то» подменить возвращаемое значение на «Успех» «и» продолжить исполнение.

Правило 12: «если» правило 11, «и» файл 100 вызвал FileWrite(«$SytemDrive:\<случайное имя>», буфер памяти, используемый процессом, созданным при открытии файла 100), «то» признать файл 100 вредоносным «и» закончить исполнение.

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

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

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

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

Примером такого правила может являться:

Правило 21: «если» файл 100 обращается к веб-ресурсу, «и» веб-ресурсу присвоена вредоносная категория, «то» признать файл 100 вредоносным.

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

В одном из вариантов реализации правило содержит условие для глубины анализа или глубины агрегации события. Например,

Правило 31: «если» файл 100 исполняет цикл, «и» контекст событий вызова API-функций не меняется, «то» не перехватывать события возврата из API-функций.

Упомянутый пример правила позволяет ускорить исполнение файла 100 путем уменьшения количества перехватов событий и чтения контекста. Если потоком процесса, созданного при открытии файла 100, был вызван цикл длительностью порядка одного миллиарда итераций, состоящий из вызовов «CreateWindow()», «CloseWindow()», не имеет смысла перехватывать и сохранять контекст каждого события. Очевидно, что средство перехвата 130 в соответствии с вышеописанным отработает по меньшей мере четыре миллиарда раз (в цикле вызываются две API-функции, событием является вызов и возврат из API-функции), и столько же раз прочитает контекст процессора.

В одном из вариантов реализации правило содержит условие увеличения переменной цикла. Например,

Правило 41: «если» файл 100 исполняет цикл, «и» контекст событий вызова API-функций не меняется, «то» увеличивать значение переменной цикла в 5 раз спустя каждые 10 итераций.

Вышеописанный пример применим для ускорения исполнения циклов потоком процесса, созданного при открытии в виртуальной машине 120 файла 100. Средство анализа 140 определяет, что исполняемый поток циклически вызывает некоторые события. При этом ничего не происходит, что является одним из известных сценариев антиэмуляции. Чтобы поток процесса, созданного при открытии файла 100, наиболее полно проявил свой функционал, необходимо как можно быстрее завершить цикл и продолжить исполнение. Благодаря вышеописанному правилу цикл будет завершен в несколько раз быстрее.

В одном из вариантов реализации средство перехвата 130 выявляет при исполнении потока процесса, созданного при открытии файла 100, возникновение события, которое связано с изменением страницы виртуальной памяти (далее по тексту страница памяти). В общем случае событие, связанное с изменением страницы памяти, представляет собой вызов API-функции потоком. Изменение данных в странице памяти может происходить как напрямую, например, вызовом WriteProcessMemory(), так и скрыто, например посредством записи данных с использованием SetWindowLong(). При этом можно выявить, например, описатель (англ. handle) окна. Стоит отметить, что запись в память другого процесса вполне легальная операция с точки зрения операционной системы. Но вредоносные программы также очень часто используют подобные механизмы для внедрения вредоносного кода. События, связанные с изменением страниц памяти, и контекст процессора средство перехвата 130 сохраняет в журнал 150.

Средство анализа 140 определяет измененные страницы памяти. По анализу журнала 150, в котором сохранены события, связанные с изменением страниц памяти, и контекст процессора, средством анализа 140 могут быть выявлены идентификаторы (например, адреса или номера) измененных страниц памяти.

В одном из вариантов реализации средство анализа 140 передает идентификаторы измененных страниц средству перехвата 130.

Средство перехвата 130 также выявляет передачу управления на какую-либо из измененных страниц, идентификаторы которых получены от средства анализа 140. Передача управления на страницу памяти в общем случае означает, что поток выполняет код по виртуальному адресу, который содержится на этой странице памяти. В одном из вариантов реализации выявление передачи управления осуществляется в случае, если поток, исполняющий код с измененной страницы, запущен из того же процесса, что и поток, изменивший страницу памяти. В другом варианте реализации выявление передачи управления осуществляется в случае, если поток, исполняющий код с измененной страницы, запущен из процесса, отличного от процесса, поток которого изменил страницу памяти. Таким образом, если потоком процесса, созданного при открытии файла 100, была изменена страница памяти, и она принадлежит этому же (изменение своих собственных страниц памяти используется вредоносными приложениями как защита от сигнатурного анализа или противодействие статическому анализу исполняемого кода) или другому процессу (например, explorer.exe), то необходимо перехватывать события процесса, когда будет передано управление измененной странице памяти.

В общем случае после выполнения передачи управления на измененную страницу памяти средство перехвата 130 и средство анализа 140 выполняют описанные выше действия.

Примером вышеописанного является

Правило 51: «если» процесс, созданный при открытии файла 100, изменяет данные по меньшей мере в одной странице памяти, «то» перехватывать события при передаче управления по меньшей мере одной из страниц, на которой были изменены данные.

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

Таким образом, средство анализа 140 после получения журнала 150 от средства перехвата 130 анализирует произошедшие события, то есть события (текущее и предыдущие), сохраненные в журнале 150, и данные произошедших событий (например, контекст процессора, соответствующий какому-либо событию). Анализ заключается в сравнении произошедших событий с шаблоном. При этом событие сравнивается последовательно с каждым правилом, сохраненными в шаблоне (в зависимости от порядка правил в шаблоне или их приоритета). На основании сравнения средство анализа 140 принимает по меньшей мере одно из решений:

- решение о признании файла 100 вредоносным;

- решение об остановке исполнения процесса, созданного при открытии файла 100;

- решение об изменении контекста процессора;

- решение об ожидании следующего события.

Стоит отметить, что средство анализа 140 может комбинировать упомянутые выше решения. Например, если файл 100 был признан вредоносным, в одном из вариантов реализации можно остановить исполнение процесса, созданного при открытии файла 100. В другом варианте реализации можно продолжить исполнение процесса, созданного при открытии файла 100, то есть ожидать следующего события, для дальнейшего анализа поведения потоков процесса и создания журнала 150. В одном из вариантов реализации признают файл 100 вредоносным, но изменяют контекст процессора и ожидают следующего события. Такая последовательность действий нужна для более полного раскрытия функционала файла 100. Например, файл 100 был признан вредоносным после того, как в процессе анализа был создан еще один файл, содержащий вредоносный код. Однако, в некоторых случаях (например, поток пытается скачать что-то с вредоносного веб-ресурса) имеет смысл продолжить перехват событий и наполнение журнала 150 для анализа дальнейшего поведения потоков процесса, созданного при открытии файла 100. В еще одном из вариантов реализации, даже если файл 100 не был признан вредоносным (например, в процессе исполнения открылось окно, которое ожидает ввод пользователя), принимают решение об остановке исполнения процесса, созданного при открытии файла 100.

Принятые решения средство анализа 140 передает средству перехвата 130. Средство перехвата 130 исполняет действия, соответствующие принятым решениям. В случае принятия средством анализа 140 решения об ожидании следующего события возобновляется исполнение потока, которое было приостановлено средством перехвата 130.

В одном из вариантов реализации средство анализа 140 инициирует перезагрузку виртуальной машины 120. Например, если в процессе анализа файла 100 был создан новый файл, путь к которому был добавлен в автозагрузку операционной системы виртуальной машины 120, средство анализа 140 инициирует перезагрузку, чтобы проверить функционал созданного файла на вредоносность.

В общем случае после завершения анализа файла 100 в виртуальной машине 120 средство перехвата 130 передает журнал 150 средству безопасности 110. Анализ файл 100 может быть завершен как естественным путем (потоки процесса, созданного при открытии файла 100, сами закончили исполнение), так и по решению средства анализа 140 (средством анализа 140 вынесено решение об остановке процесса, созданного при открытии файла 100).

Таким образом, упомянутая система позволяет выявить вредоносность файла 100 на основании решений от средства анализа 140, а именно на основании того, было ли вынесено решение о признании файла 100 вредоносным.

Фиг. 3 показывает пример реализации предлагаемого способа формирования журнала для проведения антивирусной проверки файла.

В общем случае формирования журнала для проведения антивирусной проверки файла средство безопасности 110 передает файл 100 виртуальной машине 120.

В общем случае анализ файла 100 осуществляется после его открытия в операционной системе виртуальной машины 120. Под открытием файла 100 понимается одно из:

- исполнение файла, если файл исполняемый;

- открытие файла приложением, если файл не исполняемый.

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

На этапе 320 определяют с помощью средства анализа 140 по меньшей мере одну измененную страницу памяти путем анализа сохраненных в журнале 150 данных. В одном из вариантов реализации при определении измененных страниц памяти выявляют идентификаторы измененных страниц. Идентификаторы измененных страниц средство анализа 140 передает средству перехвата 130.

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

На этапе 340 с помощью средства анализа 140 формируют журнал 150, в который сохраняют:

- события, возникающие во время исполнения потока процесса, созданного при открытии упомянутого файла, в измененной странице памяти;

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

В одном из вариантов реализации на этапе 350 после формирования журнала 150 на этапе 340 производят его анализ с помощью средства анализа 140 для определения вредоносности файла, открываемого в виртуальной машине.

Фиг. 4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п.Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 4. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

Изобретение относится к решениям для выявления вредоносных файлов. Техническим результатом является повышение безопасности компьютерной системы, которое достигается путем принятия решения о признании вредоносным файла, открываемого в виртуальной машине. Раскрыт способ принятия решения о признании вредоносным файла, открываемого в виртуальной машине в виде среды для безопасного исполнения файлов, при этом способ содержит этапы, на которых: а) выявляют во время исполнения потока процесса, созданного при открытии упомянутого файла, возникновение события, которое связано с изменением по меньшей мере одной страницы виртуальной памяти; б) выявляют во время исполнения потока процесса, созданного при открытии упомянутого файла, передачу управления по меньшей мере в одну измененную страницу виртуальной памяти; в) формируют журнал, в который сохраняют: события, возникающие во время исполнения потока процесса, созданного при открытии упомянутого файла, в измененной странице памяти, и считываемый при возникновении сохраняемого в журнал события контекст процессора, на котором исполняется поток процесса, созданного при открытии упомянутого файла; г) сравнивают сохраненные в сформированном журнале события и контекст процессора с по меньшей мере одним шаблоном; д) принимают решение о признании файла вредоносным на основании результатов сравнения. 7 з.п. ф-лы, 4 ил.

1. Способ принятия решения о признании вредоносным файла, открываемого в виртуальной машине в виде среды для безопасного исполнения файлов, при этом способ содержит этапы, на которых:

а) выявляют во время исполнения потока процесса, созданного при открытии упомянутого файла, возникновение события, которое связано с изменением по меньшей мере одной страницы виртуальной памяти;

б) выявляют во время исполнения потока процесса, созданного при открытии упомянутого файла, передачу управления по меньшей мере в одну измененную страницу виртуальной памяти;

в) формируют журнал, в который сохраняют:

- события, возникающие во время исполнения потока процесса, созданного при открытии упомянутого файла, в измененной странице памяти, и

- считываемый при возникновении сохраняемого в журнал события контекст процессора, на котором исполняется поток процесса, созданного при открытии упомянутого файла;

г) сравнивают сохраненные в сформированном журнале события и контекст процессора с по меньшей мере одним шаблоном;

д) принимают решение о признании файла вредоносным на основании результатов сравнения.

2. Способ по п. 1, в котором событие, связанное с изменением страницы памяти, представляет собой вызов API-функции во время исполнения потока процесса.

3. Способ по п. 1, в котором при определении измененной страницы памяти выявляют идентификатор измененной страницы.

4. Способ по п. 1, в котором выявление передачи управления измененной странице памяти осуществляется в случае, если поток, исполняющий код с измененной страницы, запущен из того же процесса, что и поток, изменивший страницу памяти.

5. Способ по п. 1, в котором выявление передачи управления измененной странице памяти осуществляется в случае, если поток, исполняющий код с измененной страницы, запущен из процесса, отличного от процесса, поток которого изменил страницу памяти.

6. Способ по п. 1, в котором шаблон содержит по меньшей мере одно правило.

7. Способ по п. 6, в котором правило содержит по меньшей мере одно событие.

8. Способ по п. 6, в котором правило содержит по меньшей мере один контекст процессора.