Системы автоматизированного динамического анализа представляют собой особый тип инструментов исследования функциональности вредоносных программ. Статья посвящена разработке модели взаимодействия с системами автоматизированного анализа. Для моделирования используется нотация языка UML. Разработанная теоретическая модель призвана отразить особенности изучения вредоносных программ с помощью систем автоматизированного динамического анализа.
Ключевые слова: вредоносные программы, автоматизированный динамический анализ, диаграммы активностей UML.
Анализ вредоносных программ является актуальной задачей в настоящий момент. Форма процесса исследования функциональности вредоносных файлов зависит от того, какие инструменты при этом используются. Имеется в виду, что процесс исследования с помощью дизассемблера и отладчика отличается от процесса исследования с использованием систем автоматизированного динамического анализа. В данной статье приведена модель типичного взаимодействия с системами автоматизированного динамического анализа, назначением которой является демонстрация особенностей работы с инструментами данного типа. Модель разработана на основе нотации языка UML и представляет собой диаграмму активностей [1].
Итак, на рисунке 1 изображена разработанная диаграмма активностей.
Рис. 1. Модель взаимодействия на основе диаграммы активностей
Представленная диаграмма активностей в целом разделена на три дорожки, каждая из которых соответствует одному из объектов: эксперт, операционная система, система анализа. Начальное состояние представлено на стороне эксперта, который инициирует процесс анализа путем деятельности по запуску системы анализа. Это может быть, например, включением виртуальной машины либо запуском соответствующего скрипта управления виртуальными машинами (здесь мы рассматриваем начальную ситуацию, когда снимки состояния среды не представлены). Далее поток управления переходит к системе анализа, которая выполняет деятельность по подготовке среды для операционной системы, а далее непосредственно запускает саму операционную систему. Поток управления перемещается на сторону операционной системы. Она выполняет деятельность по инициализации всех необходимых своих внутренних компонент. В сущности, это обычная загрузка операционной системы. После загрузки операционной системы поток управления передается на сторону эксперта, который загружает выбранный для анализа файл. Далее происходит процесс распараллеливания потоков управления. Операционная система выполняет деятельность по созданию процесса из анализируемого файла. Система анализа инициализирует компонент анализа, то есть, здесь работает компонент инициализации. После потоки управления синхронизируются, операционная система своими средствами запускает созданный процесс на исполнение. Далее вновь происходит распараллеливание. Операционная система выполняет деятельность по обработке операций с файловой системой, с реестром, с сервисами ОС, с сетью, которые инициируются процессом, находящимся под анализом. Одновременно с этим система анализа выполняет анализирующие процедуры, что означает, по сути, работу компонента анализа. На рисунке 2 представлена детализация деятельности по выполнению анализирующих процедур в виде другой диаграммы активностей.
Рис. 2. Деятельность по выполнению анализирующих процедур в виде диаграммы активностей
На данной диаграмме представлены следующие деятельности. Во-первых, генерация элемента отчета, что означает получение названия вызванной функции и ее параметров. Во-вторых, обработка вызванной функции, что означает управление возможностью ее действительной отработки, ее возвращаемым значением. Наконец, происходит опциональное управление отчетом. Например, может происходить передача информации на хост-машину по TCP/IP (как в CuckooSandbox [2, с. 18]) либо уведомление других процессов системы через объекты уведомления (как в CWSandbox [3, с. 37]) и т. д.
Обратимся вновь к основной диаграмме на рисунке 1. После одной итерации, включающей в себя, например, вызов сетевой функции потоком процесса, находящегося под анализом, управление переходит в узел решения. Исходящие переходы данного узла решения имеют следующие сторожевые условия: специальные условия есть, специальных условий нет. Под специальными условиями здесь понимаются ситуации, при которых должно начаться завершение процесса анализа. Например, завершено отведенное время на анализ (окончание тайм-аута), завершение работы приложения, находящегося под анализом и т. д. Если таких специальных условий нет, то процесс анализа продолжается, как показано на диаграмме. При возникновении специального условия поток управления передается в деятельность по формированию окончательного отчета. Здесь может быть, например, обработка всей полученной в процессе анализа информации и представление ее в виде файла формата HTML. Далее, поток управление переходит на сторону эксперта. Эксперт выполняет некоторую деятельность по управлению системой анализа в целом. Например, он может выключить виртуальную машину либо вернуть состояние системы до запуска вредоносного файла (в случае, если имеются в наличии снимки состояния системы). После эксперт выполняет деятельность по изучению отчета, содержащего высокоуровневую информацию о работе анализируемой программы. Диаграмма активностей завершается на стороне эксперта конечным состоянием.
Таким образом, в данной статье представлена модель взаимодействия с системами автоматизированного динамического анализа вредоносных программ в виде диаграммы активностей языка UML. Можем отметить такие характерные черты работы с системами анализа. Во-первых, обращает на себя внимание большая автономность процесса исследования функциональности с применением автоматизированных систем. Во-вторых, большая скорость получения информации, на основании которой можно сделать предварительные выводы об изучаемой программе и решить, нужно ли ее изучать более подробно. При использовании инструментов типа отладчика и дизассемблера эксперту приходится тесно работать с двоичным кодом программ, что подразумевает как временные затраты, так и непосредственное участие исследователя в процессе получения информации о функциональности образца. В заключение отметим, что автоматизированный анализ не может полностью заменить ручной разбор файлов, во многих случаях он является дополнением к традиционной обратной разработке.
Литература:
1. Диаграмма активностей: крупным планом. — URL: http://www.intuit.ru/studies/courses/1007/229/lecture/5958 (дата обращения: 25.05.2016).
2. Bremer J. Haow do I sandbox?!?! Cuckoo Sandbox Internals / J. Bremer // RECON2013. — URL: https://recon.cx/2013/slides/recon2013-JurriaanBremer-Haow_do_I_sandbox.pdf (датаобращения: 25.05.2016).
3. Toward Automated Dynamic Malware Analysis Using CWSandbox / Carsten Willems, Thorsten Holz, Felix Freiling // IEEE Security and Privacy. — 2007. — Volume 5 Issue 2. — P. 32–39.
