CC BY
71
УДК 004.49, 004.622, 004.048
А. А. Переберина1'2, А. В. Костюшко1'2
1 Московский физико-технический институт (государственный университет)
2 ООО «Акронис»
Проектирование программно-аппаратного комплекса для запуска вредоносного программного обеспечения
Рассматривается создание автоматизированного программно-аппаратного комплекса (Sandbox) для запуска вредоносного программного обеспечения в целях сбора данных о поведении вредоносной программы для последующего анализа. Была разработана архитектура системы, схема развёртывания (deployment) и управления системой. Основное внимание было уделено производительности и безопасности Sandbox, а также её интеграции с системами автоматизации. На данном этапе работы был запущен прототип Sandbox, состоящий из семи тестовых серверов и управляющего сервера, расположенных в ЦОД. Был подготовлен и запущен в Sandbox тестовый набор образцов вредоносного ПО, состоящий из шифровальщиков-вымогателей (crypto-ransomware). Получаемые в Sandbox данные проходят предобработку и фильтрацию, а затем подаются на вход модели машинного обучения. В данный момент Sandbox используется также для автоматического тестирования ПО на способность детектировать вредоносное программное обеспечение и нейтрализовать его воздействие на операционную систему.
Ключевые слова: Вредоносное программное обеспечение, автоматический анализ вредоносного ПО, автоматическое развёртывание тестового окружения, программы-вымогатели, шифровальщики-вымогатели, песочница.
12
1
2
Hardware and software system design for malware execution (Sandbox)
This paper discusses an automated hardware and software system (Sandbox) for malware execution that gathers data for behaviour analysis. The system architecture, the deployment and management process are considered. We focus on Sandbox security and performance as well as integration with automation systems. Currently, Sandbox is in the prototype stage and consists of seven test servers and one managing server, which placed at the data center. We pick and verify a test pack of ransomware samples. Collected data is processed, filtered and then transferred as input to the machine learning model. Sandbox is also used to automatically test software for the ability to detect malware and neutralize its impact on the operating system.
Key words: Malware, automatic malware analysis, automatic deployment, ransomware, crypto-ransomware, sandbox.
@ Переберина А. А., Костюшко А. В., 2018
(с) Федеральное государственное автономное образовательное учреждение высшего образования «Московский физико-технический институт (государственный университет)», 2018
1. Введение
В данной работе рассматривается проектирование автоматизированного программно-аппаратного комплекса (Sandbox) для запуска вредоносного программного обеспечения, ориентированного на операционные системы семейства Microsoft Windows, в целях сбора данных о поведении вредоносной программы (таком как операции по работе с файлами, системным реестром, стек вызовов) для последующего анализа. Главным образом мы сосредоточены на шифровальщиках-вымогателях (ransomware, или, более точно, crypto-ransomware), которые в настоящее время являются одним из ключевых типов компьютерных угроз [1]. Полученные данные будут подаваться на вход модели машинного обучения, осуществляющей классификацию программ на потенциально представляющие угрозу (suspicious) и не представляющие угрозы (clean). Второе важное применение Sandbox — автоматическое тестирование программного обеспечения (в том числе обученной модели) на способность детектировать вредоносную программу и нейтрализовать её воздействие на операционную систему (например, остановить соответствующий процесс и расшифровать файлы).
Из-за большого количества вредоносного ПО традиционный подход к защите — проверка сигнатур — перестает работать [2]. Современные антивирусы используют эвристики и эмуляторы и ведут активный мониторинг того, что происходит в операционной системе. Также существует так называемый «next-gen» подход, при котором применяется поведенческий анализ вредоносного ПО и машинное обучение. Возможности искусственного интеллекта для анализа вредоносного программного обеспечения использовались многими исследователями [3, 4]. Распространённые подходы включают в себя классификацию образцов на вредоносные и невредоносные, а также кластеризацию вредоносного ПО.
При проектировании комплекса для запуска вредоносного программного обеспечения самыми важными являются вопросы безопасности системы: тестовые серверы, на которых будет исполняться вредоносное ПО, должны находиться под контролем управляющих серверов и, таким образом, иметь соответствующий канал коммуникации, но при этом управляющие серверы системы не должны подвергнуться воздействию вредоносных программ. На данном этапе исследования основное внимание было уделено безопасности Sandbox и автоматизации цикла работы (подготовки окружения, запуска образцов вредоносного ПО и сбора интересующих нас данных). В работе рассмотрены ключевые решения относительно сетевой инфраструктуры и развёртывания системы, обеспечивающие безопасность Sandbox.
Другими значимыми вопросами являются вопросы производительности системы: необходимо минимизировать время исследования одного образца вредоносного программного обеспечения, так как количество «вирусов» в существующих базах данных велико и каждый день появляются новые угрозы. Так, немецкая лаборатория AV-TEST регистрирует более 250 000 новых вредоносных программ в день [5]. Кроме того, для обучения классифицирующей модели нужно большое количество данных, при этом данные должны постоянно обновляться с появлением новых образцов вредоносного ПО, то есть должно происходить непрерывное до-обучение модели. Sandbox в этом сценарии выступает как изолированная площадка для поставки информации о вредоносном ПО в лабораторию машинного обучения.
В работе также приводится краткий обзор существующих аналогов Sandbox, многие из которых используют виртуальные машины для запуска вредоносного программного обеспечения. Несмотря на тренд виртуализации и возможность создания чисто программных комплексов виртуальных машин для запуска вредоносных программ, для наших целей необходимы данные, полученные на реальном аппаратном обеспечении. Это обусловлено тем, что запуск вредоносной программы в виртуальной машине может быть небезопасен — например, если речь идет о сетевом черве, распространяющемся, используя уязвимости в сетевых протоколах [6]. Кроме того, некоторые вредоносные программы могут
детектировать окружение, в котором исполняются [7], и в виртуальной машине вести себя не так, как на реальном оборудовании (например, просто прекращать свою работу). Также существует компьютерная атака, называемая прорывом окружения виртуальной машины (virtual machine escape), которая эксплуатирует уязвимости в имплементации гипервизора [8, 9]. Тем не менее тесты на виртуальных машинах выигрывают по производительности благодаря скорости восстановления системы из снимка состояния (снепшота), поэтому для увеличения пропускной способности комплекса на части тестовых серверов Sandbox планируется развернуть виртуальные машины.
В данный момент Sandbox находится на стадии прототипа. Для тестирования системы был подготовлен и запущен набор шифровальщиков-вымогателей, были собраны и переданы для анализа в лабораторию машинного обучения первые данные.
2. Терминология
Для описания архитектуры системы введём следующую терминологию:
1) Тестовый сервер — сервер, предназначенный для запуска вредоносного программного обеспечения.
2) Управляющий сервер — сервер, предназначенный для управления Sandbox, обеспечивающий цикл развёртывания и запуск различных сценариев на тестовых серверах.
3) Тестовая операционная система — операционная система, работающая на тестовых серверах и предназначенная для запуска вредоносного ПО.
4) Управляющая операционная система — операционная система, работающая на тестовых серверах и предназначенная для осуществления действий, необходимых для поддержки развёртывания Sandbox (установка тестовой ОС, создание резервной копии тестовой ОС, восстановление тестовой ОС из резервной копии).
5) Агент — программное обеспечение, установленное на тестовой операционной системе, осуществляющее анализ состояния системы и создающее логи для последующего анализа.
6) Логи — выходные данные, поставляемые агентом.
7) Набор образцов вредоносного ПО — список экземпляров вредоносного ПО, которые будут автоматически по очереди (после отката тестовой среды) запущены на тестовом сервере в рамках одного задания.
8) Лаборатория машинного обучения — команда исследователей, занимающаяся разработкой и обучением модели, осуществляющей классификацию программ на потенциально представляющие угрозу (suspicious) и не представляющие угрозы (clean). Данная часть работы не является фокусом текущей статьи.
3. Обзор существующих решений
Нами был произведён обзор существующих решений по автоматическому анализу вредоносного программного обеспечения. Общие подходы, предложенные нами, такие как использование Linux в качестве управляющей системы при исследовании вредоносного ПО, ориентированного на Windows-системы, и цикл исследования образца вредоносного ПО, характерны для большинства работ, посвященных аналогам Sandbox. Основное внимание в большинстве статей уделяется программному обеспечению для динамического анализа образцов, а не инфраструктурным решениям и вопросам развёртывания системы.
Однако проектирование архитектуры закладывает фундамент для выбора аналитических инструментов.
В статье [7] описываются различные подходы к анализу вредоносного программного обеспечения и обозреваются существующие решения. В статье [10] подробно описывается решение, использующее виртуальные машины для запуска вредоносного ПО. Cuckoo Sandbox также использует виртуальные машины [11]. Мы остановились на запуске вредоносного ПО на реальном аппаратном обеспечении. Вредоносное ПО может детектировать виртуальное окружение и прекращать свою работу [7], маскируя вредоносную активность в ситуациях потенциального исследования аналитическими инструментами. Предложенная нами архитектура оставляет возможность в дальнейшем запускать вредоносное ПО, не чувствительное к виртуальному окружению, в виртуальных машинах на части тестовых серверов (для увеличения производительности и пропускной способности системы). При этом аналитические инструменты на уровне эмулятора или монитора виртуальных машин, призванные скрыть присутствие анализирующего ПО даже в случае наличия у вредоносного программного обеспечения компонент режима ядра (kernel-mode), нами применяться не будут. Мы ограничимся средствами анализа, исполняющимися на том же уровне привилегий, что и анализируемая программа, т. к. количество вредоносного ПО, использующего драйверные компоненты, довольно мало (благодаря механизму защиты Windows-драйверов электронной цифровой подписью), даже без учёта нашей нацеленности на анализ шифровальщиков.
В существующих решениях интернет-соединение эмулируется или фильтруется [7], чтобы не допустить рассылку спам-сообщений или участие в DDOS-атаке. В статье [12] можно увидеть краткое описание инфраструктурного решения от SANS Institute, в котором также используется эмуляция Интернета. Мы же, в силу специфики работы программ-вымогателей, решили предоставить тестовым серверам полный доступ в Интернет. В дальнейшем, при расширении фокуса до других типов вредоносного программного обеспечения, будет применяться фильтрация интернет-доступа.
4. Архитектура Sandbox
4.1. Общий обзор архитектуры
Аппаратное обеспечение Sandbox состоит из управляющего сервера, тестовых серверов, сетевого коммутатора и другого сетевого оборудования, обеспечивающего 1 GigE.
На управляющем сервере расположены три виртуальных сервера (см. табл. 1): РХЕ-сервер (используется для загрузки тестовых серверов), MAN-сервер (используется для запуска управляющих скриптов на тестовом сервере), Jenkins-сервер (используется для запуска заданий из графического WтEB-интepфeйca). Тестовые серверы, предназначенные для запуска вредоносного программного обеспечения, сконфигурированы для сетевой загрузки через РХЕ-сервер. В качестве управляющей операционной системы используется Linux. Для запуска агентов и экземпляров шифровальщиков-вымогателей используются операционные системы семейства Windows.
4.2. Сетевая архитектура
Одним из ключевых вопросов запуска вредоносного программного обеспечения на тестовых серверах была безопасность управляющих серверов и компьютеров корпоративной сети, с которых осуществляется удалённое управление Sandbox. Чтобы не допустить заражения через каналы коммуникации, мы должны были решить следующие задачи:
1) задача защиты управляющих серверов от вредоносной активности на тестовых серверах;
2) задача защиты тестовых серверов от вредоносной активности на других тестовых серверах.
Таблица 1
Управляющие серверы Sandbox
Сервер Программное обеспечение Задачи
РХЕ-сервер РХЕ server NFS server DHCP server Сетевая загрузка тестовых серверов Присвоение IP-адресов
MAN-сервер SSH server Python environment Jenkins slave agents Управление циклом работы тестовых серверов (включение и выключение питания через IP-KVM, запуск скриптов на управляющей и тестовой операционных системах)
Jenkins-сервер Jenkins HTTP server SSH server Запуск управляющих скриптов на MAN-сервере с помощью Jenkins WтEB-интepфeйca
Для решения поставленных задач была предложена следующая архитектура (см. рис. 1). Внутренняя сетевая конфигурация Sandbox состоит из двух логических локальных компьютерные сетей (VLAN) — доверенная сеть (GoodNet) и недоверенная сеть (DarkNet). Доверенная сеть предназначена для взаимодействия управляющих виртуальных серверов. Тестовые серверы получают IP-адреса из недоверенного диапазона от DHCP-сервера. Все запросы проходят через межсетевой экран (firewall) на управляющем сервере. Тестовые серверы имеют доступ в Интернет, а запросы к управляющим серверам блокируются. Также на этом уровне происходит изоляция тестовых серверов друг от друга.
Внешний доступ к управляющему серверу разрешён только с IP-адресов корпоративной сети.
Возможен также доступ по RDP к тестовым серверам, происходящий через SSH-туннель на MAN-сервере. RDP является сложным протоколом, работа с которым представляет потенциальную опасность — например, при подключении пользователь может случайно предоставить целевой системе доступ к локальным дискам машины, с которой производится подключение, тем самым подвергнув их риску шифрования. Поэтому такой способ подключения рассматривается нами как небезопасный и для его осуществления используются специальные машины во внешней изолированной подсети.
4.3. Развёртывание
Ещё одной важной задачей, стоявшей перед нами, была задача автоматизации цикла работы Sandbox и сбора данных. Цикл развёртывания Sandbox начинается с загрузки по сети (с использованием РХЕ-сервера) образа Linux в RAM (см. рис. 2). В качестве тестовых операционных систем используются образы Windows 7x64, Windows 8.1x64, Windows 10x64. Образы были специальным образом подготовлены для тихой (unattended) установки и содержат предустановленный SSH-сервер. Резервные копии (бэкапы) тестовых систем размещаются на отдельном диске или разделе, файловая система на котором не распознаётся тестовой операционной системой. Таким образом, при расширении списка тестовых систем (например, добавлении Linux-систем в качестве тестовых) в управляющей системе потребуется поддержка одной из малораспространённых файловых систем. Тем не
менее перед запуском процесса восстановления происходит проверка целостности бэкапа, и в случае повреждения он загружается с МАК-еервера.
Рис. 1. Сотовая конфигурация (^^дтогк corlfigш'atiorl)
Цикл развертывания и тестирования происходит следующим образом:
1) Одноразовая подготовка образа тестовой ОС с предустановленным программным обеспечением (таким как БЯН-сервер) и его загрузка на МАК-сервер.
2) Одноразовая установка тестовой ОС и создание ее бэкапа на отдельном диске либо разделе.
3) Для каждого экземпляра вредоносного ПО из тестового набора:
• перезагрузка тестового сервера с использованием 1Р-КУМ;
• загрузка управляющей операционной системы;
• восстановление тестовой операционной системы из бэкапа;
• переча! [>у ;ка тестового сервера с использованием 1Р-КУМ;
• загрузка тестовой операционной системы;
• установка агента;
• запуск вредоносного ПО, ожидание сигнала от агента либо тайм-аута;
• сбор логов и другой выходной информации.
Рис. 2. Развёртывание (Вор1оутог11)
Перезагрузка и восстановление тестовой системы из бэкапа на каждой итерации цикла тестирования гарантирует нам «чистоту» системы после запуска вредоносного программного обеспечения. Таким образом происходит откат тестовой среды к начальному состоянию. Переключение между загрузкой тестовой операционной системы
с локального диска (localboot) и загрузкой управляющей операционной системы (netboot) обеспечивается конфигурацией РХЕ-сервера.
Каждый этап развёртывания Sandbox может быть запущен с помощью соответствующей задачи в WEB-интерфейсе Jenkins. После завершения задачи фреймворком Allure генерируется WEB-отчет, а логи и другая выходная информация попадает в специальное хранилище (Artifactorv).
4.4. Агенты
В данный момент в Sandbox запускаются различные агенты. Агенты делятся на два типа:
1) Занимающиеся только мониторингом и сбором доступной им информации о том, что происходит в системе.
2) Антивирусного типа, занимающиеся также защитой системы и ориентированные на детектирование вредоносного программного обеспечения.
Process Monitor
В качестве примера мы здесь рассмотрим агент Process Monitor (Procmon). Данная утилита, разработанная Sysinternals, осуществляет мониторинг файловой системы, системного реестра, сетевой активности и процессов. Эта информация записывается в лог в формате .pml. На рис. 3 можно видеть образец лога, полученный с системы, заражённой шифровальщиком-вымогателем WannaCrv (MD5-xeni исследуемого образца 4287el5af6191f5cablc92ff7be8dcc3). Приведённый фрагмент лога содержит файловую активность порождённого WannaCrv процесса tasksche.exe, в котором происходит шифрование файлов. Таким образом, на выходе получается большое количество данных (размер лога за 5 минут работы может достигать 1 Gb). Полученные логи проходят несколько фильтраций и переводятся в формат .xml, удобный для синтаксического анализа и обработки данных, и в сжатом виде передаются на управляющий сервер.
5. Набор образцов вредоносного ПО
На начальном этапе в Sandbox запускалось программное обеспечение, симулирующее работу программы-шифровальщика, выполняющее исключающее ИЛИ (XOR) с некоторым заданным ключом для файлов в указанной директории.
На следующем этапе работы для запуска в Sandbox был подготовлен набор образцов шифровальщиков-вымогателей, для формирования которого была использована база вредоносных программ службы VirusTotal [13] и данные компании F-Secure о шифровальщиках, появившихся в 2010-2016 гг. (на рис. 4 представлен фрагмент с 2013 года, оригинал можно найти в [14]). Также были рассмотрены некоторые образцы, появившиеся в 2017 году (такие как WannaCrv [15], ExPetr [16], и др.). Тестовый набор составил 317 образцов. Данный набор был запущен с агентом 2-го типа, при этом происходило тройное тестирование, включающее в себя:
1) Тестирование агента 2-го типа на способность детектировать активность шифровальщика и восстановить зашифрованные файлы. По результатам было выявлено несколько техник, позволяющих скрыть вредоносную активность от тестируемого агента.
2) Верификацию тестового набора. По результатам тестирования было выявлено, что около трети найденных нами образцов не являются действующими шифровальщиками (например, серверы, к которым они обращаются, более недоступны).
3) Отладку процесса запуска вредоносного программного обеспечения. По результатам тестирования были выявлены проблемы окружения и защиты логов, о которых подробнее рассказывается в следующих разделах.
После этого образцы, прошедшие верификацию, были запущены с агентом 1-го типа для сбора данных об их вредоносной активности.
В дальнейшем планируется создание новых наборов crypto-ransomware и пополнение их новыми образцами.
Рис. 3. Логи Process Monitor с системы, заражённой вредоносным ПО WarmaCry
Рис. 4. Из отчёта F-Socuro [14]: шифровальщики-вымогатели, появившиеся в 2013 2016 годах
6. Проблема окружения
Образы Windows, предназначенные для установки на тестовых серверах, содержат SSH-сервер, который используется для подключения к тестовым серверам и запуска на них управляющих скриптов, агентов и вредоноежнх) ирограммнемч) обеспечения. Однако такой способ запуска программ отличается от стандартно!^ запуска пользователем ПК и приводил к проблеме окружения. Под окружением здесь понимается совокупность следующих факторов: неременные окружения (environment variables), сессия пользователя (terminal session), профиль пользователя (user profile), конфигурация в системном реестре (HKEY_CURRENT_USER), идентификатор нользовательско!'о сеанса (logon session, LUID), идентификатор безопасности (SID). Некоторые экземпляры crvpto-ransomware не могли осуществить необходимую им активность в системе в нестандартном окружении
.либо отказывались запускаться, поэтому потребовалось вспомогательное программное обеспечение для запуска шифровальщиков-вымогателей (Environment Helper).
а)
б)
Рис. 5. Запуск notepad.охо на тестовом сервере через SSH: а) Сведения о процессе в Task Manager; б) Дерево процессов в Process Explorer
а)
б)
Рис. 6. Корректный запуск notepad.охо на тестовом сервере с помощью Environment Helper: а) Сведения о процессе в Task Manager; б) Дерево процессов в Process Explorer
Проиллюстрируем проблему окружения на примере запуска стандартной программы Блокнот (notepad.exe). На рис. 5 представлены снимки экрана (скриншоты) при подключении по RDP к тестовому серверу, на котором по SSH был запущен notepad.exe. На рис. 5а видно, что идентификатор сессии (Session Id), в которой запущен notepad.exe, равен 0 это неинтерактивная сессия, в которой нет графической оболочки пользователя (Windows shell), поэтому графическое окно не отображается. Также при помощи еще одной
утилиты Syslnternals — Process Explorer — можно видеть, что родительский процесс (parent process) для notepad.exe — bash.exe (консоль SSH-сервера), а не explorer.exe, как у Task Manager и Process Explorer, запущенных при подключении по RDP (см. рис. 56).
Нашей задачей был запуск вредоносного программного обеспечения таким образом, чтобы эмулировать стандартный сценарий запуска пользователем интерактивной сессии. На скриншотах на рис. 6 notepad.exe запущен с корректно настроенным окружением, которое обеспечивается вспомогательным ПО. В данном случае идентификатор сессии notepad.exe равен 1 (см. рис. 6а), а его родительский процесс — explorer.exe (см. рис. 66). Такое окружение не отличается от стандартного и не должно помешать корректной работе crypto-ransomware.
Архитектурно Environment Helper состоит из сервиса, который запускает программу, имя которой сообщается ему клиентом, в нужной сессии (получив необходимые привилегии, которыми не обладает SSH-сервер). Сервис в Windows не может осуществить интерактивный вход в систему. (До Windows 8 существовал обходной путь через использование G IN А [17], однако, начиная с Windows 8, где больше нет данного компонента, эта задача становится недокументированной и сложной.) Поэтому в нашем решении сервис открывает уже существующую сессию пользователя, а система настроена так, что происходит автоматический интерактивный вход созданного нами пользователя, при котором загружаются стандартные параметры окружения. При необходимости в дальнейшем пользователь получит MS аккаунт, электронную почту и так далее. Клиент передаёт серверу запрос на запуск вспомогательной утилиты, которая использует СОМ-интерфейс для взаимодействия с графической оболочкой, чтобы запустить шифровальщик-вымогатель. При этом происходит эмуляция интерактивного запуска ransomware самим пользователем.
7. Проблема защиты логов
Другой важной проблемой стала проблема хранения данных в системе, в которой запущено вредоносное ПО, шифрующее данные. Опасности подвергались как выходная информация, которую мы хотим получить с системы (логи), так и необходимые для теста программы и утилиты. Чтобы защитить необходимые для работы агентов файлы, мы написали драйвер мини-фильтр файловой системы [18], который контролирует доступ к рабочим директориям. Для этого он обрабатывает события открытия файловых дескрипторов, регистрируя Preoperation and Postoperation Callback Routines. Доступ разрешён Sandbox-программам и некоторому белому списку доверенных процессов.
8. Производительность
В данный момент Sandbox состоит из 7 тестовых серверов и 1 управляющего сервера, расположенных в ЦОД. Возможности текущей версии прототипа Sandbox описаны в табл. 2.
Таблица 2
Производительность Sandbox
Образцов с Образцов с
Развёртывание Агент 1-го Агент 2-го агентом 1-го агентом 2-го
системы типа типа типа за 24 типа за 24
часа часа
10 минут 2-6 минут 1 12 минут 630-840 458-916
9. Машинное обучение
Процесс машинного обучения не является фокусом данной работы, поэтому подробно описываться не будет. Получение входных данных является важным этаном машинного обучения: необходимо не только собрать большой объем данных, но и должным образом нод!х)товить их произвести предварительную обработку.
Происходит обучение модели Random Forest, которая представляет собой классификатор программ на подозрительные (suspicious) и не вызывающие подозрения (clean). Концептуально роль Sandbox в этом процессе заключается в поставке сырых данных, возможно, с переходом на следующий этан, где происходит их предобработка (см. рис. 7).
Сейчас для обучения модели используются отфильтрованные логи Procmon. При этом в Sandbox собираются данные только о вредоносных образцах, данные о поведении не вредоносного ПО поступают из других источников. В рамках нод!х)товки данных мы проводим фильтрацию событий но классам и процессам. Процесс подготовки данных происходит итеративно: получая обратную связь о работе обученной модели, мы уменьшаем объем поставляемых данных, оставляя только существенную для классификации информацию.
Рис. 7. Машинное обучение и Sandbox
10. Заключение
В данной работе рассматриваются сетевая архитектура и архитектура развертывания программного-аппаратного комплекса Sandbox, включающая решения но обеспечению безопасности и автоматизации запуска вредоносного программного обеспечения. По результатам исследования был спроектирован и запущен прототип Sandbox, состоящий из семи тестовых серверов и оджнх) управляющих) сервера, расположенных в ЦОД. Исследование было сфокусировано на шифровалыциках-вымогателях (crypto-ransomware), ориентированных на операционные системы семейства Windows. Для тестирования работы системы был подготовлен набор ransomware, состоящий из 317 образцов. В настоящее время мы уже начали работу но добавлению Linux в качестве тестовой операционной системы и формированию тестового набора программ-вымогателей, ориентированных на операционные системы Linux.
На текущий момент существуют автоматические сценарии работы для агентов двух типов: (1) осуществляющих сбор данных о происходящем в операционной системе, (2) обеспечивающих антивирусную защиту. В первом сценарии нас интересуют такие события, как файловая, реестровая активность, стек вызовов. Нами были собраны и переданы для анализа первые данные, полученные с помощью утилиты Procmon.
В дальнейшем планируется автоматизация обмена данными с лабораторией машинного обучения и непрерывное обучение модели на поставляемых Sandbox данных. Для получения новых данных набор образцов вредоносного программного обеспечения будет расширяться.
Также была рассмотрена пропускная способность текущего прототипа. На следующем этапе будет произведено масштабирование Sandbox, в рамках которого планируется увеличение количества тестовых серверов, а также использование виртуальных машин на части серверов, что позволит повысить производительность системы.
Следующий важный этап развития Sandbox — разработка собственных инструментов динамического анализа вредоносного программного обеспечения. Например, осуществляющих эмуляцию ускоренного течения времени или инжекцию во вредоносные программы для получения более полной информации об алгоритмах их работы.
Работа выполнена при поддержке ООО «Акронис» (www.acronis.com). Литература
1. 2017 state of malware report // Malwarebvtes LABS, 2017.
URL: https://www.malwarebvtes.com/pdf/white-papers/stateofmalware.pdf (дата обращения: 15.05.2018).
2. Antivirus software // Wikipedia. Дата обновления: 05.05.2018.
URL: https://en.wikipedia.org/wiki/Antivirus_software (дата обращения: 15.05.2018).
3. Ucci D., Aniello L., Baldoni R. Survey on the Usage of Machine Learning Techniques for Malware Analysis // ACM Transactions on the Web, 2017. V. 1, N 1, Article 1.
URL: https://arxiv.org/pdf/1710.08189.pdf (дата обращения: 15.05.2018).
4. Pfeffera A., Ruttenberga В., Kellogga L., Howarda M., С alia C., O'Connora A., Takataa G., Reillya S., Pattena Т., Taylora J., Halla R., Lakhotiab A., Milesb C., Scofieldc D., Frankc J. Artificial Intelligence Based Malware Analysis // arxiv.org, 2017. Дата обновления: 27.04.2017.
URL: https://arxiv.org/pdf/1704.08716.pdf (дата обращения: 15.05.2018).
5. Malware // AV-TEST. Дата обновления: 08.05.2018.
URL: https://www.av-test.org/en/statistics/malware/ (дата обращения: 15.05.2018).
6. Wannacrv ransomware campaign exploiting smb vulnerability // C.E.R. Team-EU, 2017. Дата обновления: 22.05.2017.
URL: https://cert.europa.eu/static/SecurityAdvisories/2017/CERT-EU-SA2017-012.pdf, 2017 (дата обращения: 15.05.2018).
7. Egele M., Scholte Th., Kirda E., Kruegel C. A survey on automated dynamic malware analysis techniques and tools // ACM Computing Surveys, 2012. V. 44, N 2, Article 6. URL: https://www.cs.ucsb.edu/%7Echris/research/doc/acmsurveyl2_dvnamic.pdf (дата обращения: 15.05.2018).
8. Carpenter M., Listen Т., Skoudis E. Hiding virtualization from attackers and malware // Security Privacy, IEEE 5 (3) (2007) 62-65. doi:10.1109/MSP.2007.63.
9. Virtual machine escape // WTikipedia. Дата обновления: 11.03.2018.
URL: https://en.wikipedia.org/wiki/Virtual_machine_escape (дата обращения: 15.05.2018).
10. Wojner Ch. Mass Malware Analysis: A Do-It-Yourself Kit 11 CERT.at, 2009.
URL: http://cert.at/static/downloads/papers/cert.at-mass_malware_analvsis_LO.pdf (дата обращения: 15.05.2018).
11. WThat is Cuckoo? // Cuckoo Sandbox.
URL: https://cuckoo.sh/docs/introduction/what.html (дата обращения: 15.05.2018).
12. Building an Automated Behavioral Malware Analysis Environment using Open Source Software // SANS Institute, 2009.
URL: https://www.sans.org/reading-room/whitepapers/tools/buildingautomated-
behavioral-malware-analysis-environment-open-source-software-33129 (дата обращения: 15.05.2018).
13. VirusTotal.
URL: https://www.virustotal.com/ (дата обращения: 15.05.2018).
14. 2017 state of cyber report // F-Secure, 2017. P. 41.
URL: https://www.f-secure.com/documents/996508/1030743/cyber-securitv-report-2017 (дата обращения: 15.05.2018).
15. WannaCrv ransomware used in widespread attacks all over the world // Kasperskv LAB, 2017. Дата обновления: 12.05.2017.
URL: https://securelist.com/wannacry-ransomware-used-in-widespread-attacks-all-over-theworld/78351/ (дата обращения: 15.05.2018).
16. New Petva/NotPetva/ExPetr ransomware outbreak // Kasperskv LAB, 2017. Дата обновления: 28.06.2017.
URL: https://www.kasperskv.com/blog/new-ransomware-epidemics/17314/ (дата обращения: 15.05.2018).
17. Winlogon and GIN A // Microsoft.
URL: https://msdn.microsoft.com/ruru/librarv/windows/desktop/aa380543(v=vs.85).aspx (дата обращения: 15.05.2018).
18. Filter Manager Concepts // Microsoft, 2017. Дата обновления: 20.04.2017.
URL: https://docs.microsoft.com / en-us / windows-hardware/drivers/ifs/filter-manager-concepts (дата обращения: 15.05.2018).
References
1. 2017 state of malware report. Malwarebvtes LABS, 2017.
URL: https://www.malwarebvtes.com/pdf/white-papers/stateofmalware.pdf.
2. Antivirus software. Wikipedia. URL: https://en.wikipedia.org/wiki/Antivirus_software.
3. Ucci D., Aniello L., Baldoni R. Survey on the Usage of Machine Learning Techniques for Malware Analysis. ACM Transactions on the Web, 2017. V. 1, N 1, Article 1.
URL: https://arxiv.org/pdf/1710.08189.pdf.
4. Pfeffera A., Ruttenberga B., Kellogga L., Howarda M., Calla C., O'Connora A., Takataa G., Reillya S., Pattena T., Taylora J., Halla R., Lakhotiab A., Milesb C., Scofieldc D., Frankc J. Artificial Intelligence Based Malware Analysis, arxiv.org, 2017.
URL: https://arxiv.org/pdf/1704.08716.pdf.
5. Malware. AV-TEST. URL: https://www.av-test.org/en/statistics/malware/.
6. Wannacrv ransomware campaign exploiting smb vulnerability. C.E.R. Team-EU, 2017. URL: https://cert.europa.eu/static/SecurityAdvisories/2017/CERT-EU-SA2017-012.pdf, 2017.
7. Egele M., Scholte Th., Kirda E., Kruegel C. A survey on automated dynamic malware analysis techniques and tools. ACM Computing Surveys, 2012. V. 44, N 2, Article 6. URL: https://www.cs.ucsb.edu/%7Echris/research/doc/acmsurvev 12_dvnamic.pdf.
8. Carpenter M., Liston T., Skoudis E. Hiding virtualization from attackers and malware. Security Privacy, IEEE 5 (3) (2007) 62-65.
doi:10.1109/MSP.2007.63.
9. Virtual machine escape. Wikipedia.
URL: https://en.wikipedia.org/wiki/Virtual_machine_escape.
10. Wojner Ch. Mass Malware Analysis: A Do-It-Yourself Kit. CERT.at, 2009.
URL: http://cert.at/static/downloads/papers/cert.at-mass_malware_analysis_LO.pdf.
11. What is Cuckoo? Cuckoo Sandbox. URL: https://cuckoo.sh/docs/introduction/what.html.
12. Building an Automated Behavioral Malware Analysis Environment using Open Source Software. SANS Institute, 2009.
URL: https://www.sans.org/reading-room/whitepapers/tools/buildingautomated-
behavioral-malware-analvsis-environment-open-source-software-33129.
13. VirusTotal. URL: https://www.virustotal.com/.
14. 2017 state of cyber report. F-Secure, 2017. P. 41.
URL: https://www.f-secure.com/documents/996508/1030743/cyber-securitv-report-2017.
15. WannaCrv ransomware used in widespread attacks all over the world. Kasperskv LAB, 2017.
URL: https://securelist.com/wannacrv-ransomware-used-in-widespread-attacks-all-over-theworld/78351/.
16. New Petva/NotPetva/ExPetr ransomware outbreak. Kasperskv LAB, 2017. URL: https://www.kasperskv.com/blog/new-ransomware-epidemics/17314/.
17. W'inlogon and GIN A. Microsoft.
URL: https://msdn.microsoft .com/ruru/library/windows/desktop/aa380543 (v=vs.85) .aspx.
18. Filter Manager Concepts. Microsoft, 2017.
URL: https://docs.microsoft.com / en-us / windows-hardware/drivers/ifs/filter-manager-concepts.
Поступим в редакцию 30.03.2018
