Способ формирования антивирусной записи при обнаружении вредоносного кода в оперативной памяти

Способ формирования антивирусной записи при обнаружении вредоносного кода в оперативной памяти

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

Так, в публикации US 8612995 B1 описан подход, основанный на вычислении «рейтинга вредоносности» (англ. score) инструкций из кода (рейтинга, отражающего, насколько использование инструкции характерно вредоносным программам), записанного в адресное пространство процесса другим процессом. Каждой инструкции в таком коде ставится в соответствие числовое значение. Совокупность таких числовых значений оценивается с целью определения, насколько код, записанный в упомянутое адресное пространство, похож на вредоносный код.

В публикации US 20140325650 A1 предложено анализировать данные, записанные одним процессом в адресное пространство другого процесса в особых ситуациях: например, если данные были записаны в адресное пространство процесса, который был запущен из исполняемого файла приложения, содержащего уязвимости, или же процесс, к адресному пространству которого производился доступ, запущен из популярного приложения.

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

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

Фиг. 1 иллюстрирует структурную схему обнаружения вредоносного кода в оперативной памяти в рамках работы способа.

Фиг. 2А показывает примерную схему работы одного из вариантов реализации изобретения.

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

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

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

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

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

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

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

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

Контекст вызова функции - информация о вызове функции, включающая в себя по меньшей мере следующие признаки вызова: наименование функции, значения операндов функции (в случае, если операнд - это адрес в памяти, контекст вызова может включать и блок данных в памяти, например, размером 100 байт, на который ссылается соответствующий операнд функции), адрес вызова функции (может быть вычислен исходя из адреса возврата функции), идентификатор потока, осуществляющего вызов функции (англ. Thread ID), описатель потока, осуществляющего вызов функции (англ. Thread Handle), описатель процесса, в рамках которого осуществляется вызов функции (англ. Process Handle).

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

Недоверенное приложение - приложение, которое не является доверенным, но также не признано вредоносным, например, при помощи приложения безопасности.

Недоверенный процесс - процесс, который был запущен из недоверенного приложения. 4

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

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

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

Функция межпроцессного взаимодействия - системная функция (например, Windows API-функция), используемая для исполнения кода в адресном пространстве (иногда употребляется «из адресного пространства») другого процесса (не того, из которого данная функция вызывается), например, CreateRemoteThread, SetThreadContext, NTQueueApcThread или ResumeRemoteThread, а также функция, используемая для внедрения кода, который будет исполняться другим процессом (например, WriteProcessMemory). Под целью вызова функции межпроцессного взаимодействия будем понимать процесс (процесс-цель), при этом контекст вызова функции межпроцессного взаимодействия содержит такие значения аргументов, что запись данных (осуществляемая, например, при помощи функции WriteProcessMemory) производится в адресное пространство процесса-цели, или осуществляется передача управления на исполняемый код, находящийся в адресном пространстве процесса, являющегося целью вызова функции межпроцессного взаимодействия.

Функционал кода - совокупность системных вызовов, которые могут быть осуществлены во время исполнения кода.

На Фиг. 1 проиллюстрирована структурная схема обнаружения вредоносного кода в оперативной памяти в рамках работы способа. Схематично изображенное на Фиг. 1 вычислительное устройство 100, детальная схема которого будет приведена на Фиг. 3, может представлять собой персональный компьютер (для простоты, «компьютер»), мобильное вычислительное устройство (например, смартфон или ноутбук), а также распределенную вычислительную сеть, состоящую из упомянутых устройств. На вычислительном устройстве находится (установлено) по меньшей мере одно приложение 110 (программа, программное обеспечение - ПО), которое пользователь вычислительного устройства 100 использует, например, для просмотра веб-страниц, прослушивания аудиозаписей, общения посредством сети Интернет. В дополнение к вышеописанным приложениям 110 на вычислительном устройстве 100 присутствует приложение безопасности 120 (например, антивирусное приложение), предназначенное для защиты вычислительного устройства 100 и его пользователя от вредоносных приложений. Для выполнения задач по защите вычислительного устройства 100 приложение безопасности 120 может включать в себя множество модулей, например модуль сигнатурного анализа, модуль эвристического анализа, модуль журналирования. Модуль журналирования предназначен для перехвата системных вызовов - вызовов системных функций (например, WinAPI-функций), которые осуществляются различными процессами на вычислительном устройстве 100, а также для сохранения контекста вызовов этих функций. В частном случае реализации при использовании операционной системы семейства Windows модуль журналирования осуществляет перехват вызовов функций путем установки драйвера-фильтра (драйвера, внедренного в стек драйверов для взаимодействия с устройством). Для реализации такого подхода используется диспетчер фильтров (англ. Filter Manager), в который загружается драйвер, реализующий логику работы модуля журналирования. В частном случае реализации изобретения на вычислительном устройстве 100 также присутствует модуль контроля приложений 130. Модуль контроля приложений 130 предназначен для контроля запуска и выполнения приложений 110. В частном случае реализации модуль контроля приложений 130 оперирует правилами («правило контроля приложения» или «правило контроля»), регулирующими его поведение в различных ситуациях (например, контроль действий упомянутого программного обеспечения). В частном случае такие правила определяют работу модуля 130 при запуске и выполнении различных приложений 110, а также приложений из различных групп. В качестве групп могут выступать: доверенное программное обеспечение, вредоносное программное обеспечение, недоверенное программное обеспечение. В частном случае реализации правила контроля могут иметь вид:

- предотвращать запуск вредоносного программного обеспечения;

- разрешать запуск только доверенного программного обеспечения (правило запрета по умолчанию, от англ. default deny);

- разрешать запуск программного обеспечения не из группы вредоносного программного обеспечения.

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

Процесс 1 140 - процесс, созданный из недоверенного приложения. Приложение безопасности 120 при помощи модуля журналирования перехватывает вызываемые в рамках процесса 1 140 функции, в том числе и функции межпроцессного взаимодействия. Стоит отметить, что приложение безопасности 120 способно перехватывать вызовы функций всех приложений 110 (не только недоверенных). Для перехваченных вызовов функций (в том числе и функций межпроцессного взаимодействия) приложение безопасности 120 способно определить контекст вызова функции.

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

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

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

- наименование процесса-цели (может быть определено с использованием идентификатора процесса-цели, как аргумента вызова функции);

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

- наличие заголовка исполняемого файла (например, РЕ-заголовка для ОС семейства Windows, ELF-заголовок для ОС семейства Unix или DEX-заголовок для ОС Android) в блоке памяти (внедряемом блоке данных), записываемом в адресное пространство процесса-цели (например, для ОС семейства Windows может быть определено путем поиска в блоке памяти структуры РЕ-заголовка - сигнатуры MZ, DOS-заголовка и т.п.);

- является ли процесс-цель доверенным процессом;

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

Процесс 2 150 - это процесс-цель для вызовов функций межпроцессного взаимодействия, вызываемых из адресного пространства процесса 1 140. На Фиг. 1 отображено примерное представление адресного пространства процесса 2 150. Как видно из Фиг. 1, упомянутое адресное пространство содержит данные, принадлежащие процессу 2 150, например исполняемый код; область памяти, зарезервированная под кучу (англ. heap); исполняемый код используемых библиотек и т.п. Эти данные отображены, как «данные процесса 2». В то же самое время адресное пространство процесса 2 150 может содержать и «внедренные данные» - это данные, которые записаны процессом 1 140 в адресное пространство процесса 2 150 при помощи функций межпроцессного взаимодействия.

На Фиг. 2А-2В изображена примерная схема алгоритма работы одного из вариантов реализации. На этапе 201 приложение безопасности 120 осуществляет обнаружение недоверенного процесса (процесс 1 140), запущенного из одного из приложений 110. На этапе 202 приложение безопасности 120 осуществляет сбор данных о приложении 110 (которое является недоверенным), из которого был запущен процесс 1 140. Затем, на этапе 203, приложение безопасности 120 при помощи модуля журналирования перехватывает вызов по меньшей мере одной функции межпроцессного взаимодействия из адресного пространства процесса 1 140, при этом целью перехваченного вызова функции является процесс 2 150. На этапе 204 приложение безопасности 120 определяет признаки по меньшей мере одного вызова функции межпроцессного взаимодействия, перехваченного на этапе ранее. Вызов функций межпроцессного взаимодействия свидетельствует о том, что процесс 1 140 либо пытается вызвать исполнение некоторого кода из адресного пространства процесса 2 150, либо внедряет (записывает) этот исполняемый код в адресное пространство процесса 2 150. На этапе 205 приложение безопасности определяет необходимость анализа кода в адресном пространстве процесса-цели вызова функции межпроцессного взаимодействия. В частном случае реализации под кодом в упомянутой области памяти понимается исполняемый код. В еще одном частном случае реализации под кодом в упомянутой области памяти понимаются любые двоичные данные в памяти.

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

1) если в процесс-цель записывается блок данных, содержащий РЕ-заголовок, то необходим анализ кода;

2) если процесс, запущенный из каталога «Application Data» (в ОС Windows полный путь данного каталога содержится в переменной окружения «APPDATA»), внедряет данные в доверенный процесс-цель, то необходим анализ кода;

3) если процесс, запущенный из каталога «Temp» (в ОС Windows полный путь данного каталога содержится в переменной окружения «ТЕМР»), внедряет данные в доверенный процесс-цель, то необходим анализ кода;

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

5) если процесс внедряет данные в доверенный системный процесс (например, с именами «svchost», «csrss», «winlogon», «rundll» или «iexplorer»), то необходим анализ кода;

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

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

Следует отметить, что правила 2, 3, 4 можно объединить в одно правило вида «если процесс, запущенный из ранее определенного каталога, внедряет данные в доверенный процесс-цель, то необходим анализ кода». При этом факт, что процесс, в который внедряются данные, является доверенным, следует из того, что приложение 110, из которого он был запущен, является доверенным.

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

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

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

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

В еще одном частном случае реализации изобретения после обнаружения вредоносного кода на этапе 206 приложение безопасности 120 определяет по меньшей мере один унифицированный идентификатор ресурса (англ. URI - uniform resource identifier), который используется вредоносным кодом. Обнаружение (определение) URI осуществляется путем анализа адресного пространства процесса, содержащего вредоносный код. В частном случае реализации приложение безопасности 120 определяет URI путем поиска возможных строковых представлений URI, например, адреса удаленного ресурса "http://******.com/****" или ресурса в рамках файловой системы "file://****". В еще одном частном случае реализации приложение безопасности 120 определяет адреса в реестре операционной системы (например, для операционных систем Windows) как URI. В частном случае реализации поиск соответствующих URI производится приложением безопасности 120 в адресном пространстве процесса-цели. В еще одном частном случае реализации поиск производится в части адресного пространства, удаленной от начала вредоносного кода не более чем на определенную величину байт, например не более 1000 байт. В еще одном частном случае реализации поиск производится в окрестностях (например, размером 100 байт) адресов, которые используются в качестве аргументов инструкций, входящих в состав вредоносного кода. Стоит отметить, что под ресурсами в рамках настоящего изобретения понимают объекты, на которые можно ссылаться при помощи URI. В частном случае реализации упомянутыми ресурсами являются: файл, сайт, параметр реестра и т.п.

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

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

Фиг. 3 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 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). Могут использоваться другие устройства ввода (не отображ