Статья посвящена исследованию трех современных систем автоматизированного динамического анализа вредоносных файлов: CuckooSandbox, Anubis и DRAKVUF. Показано значение подобных систем в области изучения функциональности вредоносных программ. Раскрыты детали архитектуры и процесса мониторинга вредоносных файлов, а также приведены краткие выводы по каждой из исследуемых систем. Освещены общие проблемы систем автоматизированного динамического анализа.
Ключевые слова: компьютерная безопасность, вредоносные программы, автоматизированный динамический анализ.
Вредоносные программы являются одной из самых серьезных угроз компьютерной безопасности как для обычных пользователей, так для государственных и частных компаний. Под вредоносными программами можно понимать специальный класс программного обеспечения, разработанного для выполнения тех или иных деструктивных действий. Для изучения функциональности вредоносных программ (далее по тексту термины «вредоносная программа» и «образец» являются взаимозаменяемыми) специалистами применяются различные методы и инструменты. Принято разделять методы на статические и динамические. Статические методы подразумевают исследование образцов без их непосредственного исполнения. При этом применяются программы типа дизассемблеров, специальные утилиты для поиска строк в бинарном файле и т.д. Динамические методы заключаются в изучении процесса исполнения программы при помощи различных инструментов. Базовым инструментом динамического подхода является отладчик, позволяющий просматривать ход исполнения программы на уровне инструкции процессора. Дизассемблер и отладчик являются неотъемлемыми программами при ручной обратной разработке образцов для анализа. Однако, вследствие огромного роста числа вредоносных программ, а также широкого применения в целях затруднения анализа различных упаковщиков и обфускаторов при их разработке, появляется необходимость в наличии инструментов, способных ускорить и автоматизировать процесс изучения функциональности образцов, тем самым давая возможность сосредоточиться специалистам на тех программах или частях программ, которые заслуживают особого внимания. Такими инструментами являются специальные системы автоматизированного динамического анализа вредоносных файлов. Из самого названия сразу становится ясно, что в основе таких систем лежит динамический подход для анализа, т. е. информация о функциональности программы получается при непосредственном её исполнении. Целью настоящей статьи является исследование трех современных систем автоматизированного динамического анализа вредоносных файлов: CuckooSandbox, Anubis и DRAKVUF. Выбор этих трех систем не случаен. На самом деле, в настоящее время существует множество систем, реализующих автоматизированный динамический анализ вредоносных программ. Набор трех названных инструментов примечателен тем, что каждый из них внутренне отражает разные подходы, применяемые при построении подобных программных комплексов. Выбор того или иного подхода построения определяет основные характеристики системы.
Итак, сначала рассмотрим систему CuckooSandbox. В документации [1, с.1] система определяется следующим образом: «CuckooSandbox есть программное обеспечение с открытым исходным кодом для автоматизации анализа подозрительных файлов». В процессе своей работы система способна собирать следующие виды информации: трассы вызовов win32 API, производимых как самим вредоносным программным обеспечением, так и всеми процессами, порожденными вредоносным программным обеспечением; файлы созданные, удаленные и загруженные образцом; трафик сетевой в формате PCAP; скриншоты рабочего стола Windows, полученные в течение исполнения образца; трассы ассемблерных инструкций, производимых образцом. Система способна анализировать, в том числе, исполняемые файлы, файлы DLL, PDF документы, документы MicrosoftOffice, URL ссылки. Вследствие своих возможностей по расширению система позволяет разработать и интегрировать собственные средства для анализа, не предусмотренные в сборке по умолчанию.
Cuckoo состоит из хостовой машины, на которой установлены средства управления, а также нескольких гостевых машин. Хост управляет в целом анализом и процессом исполнения, в то время как гостевые машины представляют изолированные среды, где образцы непосредственно исполняются и анализируются. В состав системы входит, в том числе, модули для управления виртуальными машинами, которые определяют, как производится старт машин, их восстановление и остановка; модули расширения, куда входит, например, модуль (Humanmodule), имитирующий действия пользователя (нажатия и движения мышью); модули обработки для собирания результатов; модули отчетов, назначение которых состоит в сохранении собранных результатов и генерировании отчетов в виде файлов разных типов (например, в виде HTML или JSON).
Дадим описание процесса анализа образцов в рассматриваемой системе. Процесс анализа в CuckooSandbox начинается после доставки вредоносного файла в него [2, с.5]. Внутри виртуальной машины обязательно присутствует специальный агент, представляющий собой XMLRPC сервер, который непосредственно получает загружаемую информацию. Агент распаковывает эту информацию, которая включает в себя, помимо самого образца, ещё файлы конфигурации, а также либо специально разработанные, либо имеющиеся по умолчанию так называемые пакеты анализа. За запуск пакета анализа ответственен специальный компонент — анализатор, который также доставляется в запакованном виде. Агент запускает анализатор, который, в свою очередь, открывает канал сообщения между процессами (именованный пайп), дает настройки для первого процесса (имя именованного пайпа, IP адрес и порт сервера для результатов анализа), а также непосредственно запускает пакет анализа. Пакет анализа стартует приложение с параметрами командной строки (если таковые имеются), причем запуск происходит в режиме заморозки (путем определения параметра CREATE_SUSPENDED в функции CreateProcess), проводится инъекция DLLCuckooMonitor (главного компонента для анализа) в процесс, используя механизм APC, а после восстанавливается исполнение главного треда процесса. CuckooMonitor непосредственно устанавливает API перехватчики, а также уведомляет через именованный пайп анализатор о возможности запуска образца. Далее непосредственно запускается уже инструментированный образец. CuckooMonitor отправляет результаты анализа на хост, через TCP/IP. В CuckooMonitor предусмотрена обработка случаев запуска нового процесса либо внедрения в существующий процесс [3, с.20]. Это достигается путем общения анализатора и CuckooMonitor через именованный пайп.
Ядром процесса анализа является библиотека CuckooMonitor. Логирование вызываемых функций и соответствующих аргументов осуществляется через перехват функций путем патчинга их кода в памяти. При этом существуют некоторые особенности перехвата, выполняемого CuckooMonitor. Библиотека способна рандомизировать записываемые инструкции, что затрудняет детектирование образцом наличия перехватов. Далее, в процессе перехвата исполняются несколько блоков-трамплинов. Например, в одном из блоков проверяется, находимся ли мы уже в обработчике перехвата, и, если это так, то нет необходимости производить логирование. В других блоках-трамплинах производится правильная обработка значения LastError.
Таким образом, система CuckooSandbox представляет собой серьезный инструмент для динамического анализа вредоносных файлов. Анализирующий компонент располагается непосредственно в среде, в которой исполняется образец. По этой причине в операционной системе присутствует множество артефактов, которые могут быть использованы для детектирования CuckooSandbox. В частности, возможности детектирования перечисляются в работе [4]. Тем не менее, современные версии CuckooMonitor способны, как упоминалось выше, рандомизировать записываемые инструкции на местах перехвата функций, а также в системе присутствуют специальные механизмы, которые периодические проверяют наличие перехватов, логируют и препятствуют попыткам их перезаписи (UnhookDetection). Открытость исходного кода дает возможность разработки собственных инструментов для анализа, а также широкую свободу действий для управления системой, что является неоспоримым преимуществом CuckooSandbox.
Рассмотрим систему автоматизированного динамического анализа вредоносных файлов Anubis. Anubis расшифровывается как ANalyzingUnknownBInarieS, что дословно означает «анализ неизвестных бинарных файлов». Anubis состоит из Web/DB сервера/HTTP(s) фронтенда, хранилища образцов вредоносных программ, хранилища отчетов, специального сервера, с которым могут взаимодействовать вредоносные программы, а также множества рабочих виртуальных машин. Через HTTP(s) фронтенд происходит загрузка файлов для анализа, а также администрирование. База данных хранит отчеты и ссылки на образцы. Такая организация позволяет получать большое количество статистической информации. Хранилище вредоносных файлов архивирует загружаемые и уже проанализированные образцы. Хранилище отчетов архивирует отчеты, а также файлы, получившиеся в результате анализа (дампы трафика, скачанные файлы и т.д.) Специальный сервер («сервер-жертва») играет особую роль в архитектуре системы Anubis. Он действует как локальный сервер-ловушка для определенных сервисов и позволяет сохранять вредоносный трафик локально. Предназначение рабочих виртуальных машин очевидно — на образах этих машин запускаются неизвестные файлы для анализа.
Проанализируем ключевые аспекты внутреннего строения рассматриваемой системы. Основу Anubis составляет инструмент TTAnalyze. Данный инструмент использует эмулятор PC с открытым исходным кодом Qemu. Qemu известен тем, что применяет эффективную технику эмуляции, называемую динамической трансляцией. Как отмечают авторы TTAnalyze [5, с.5], им пришлось внести модификации в эмулятор, а именно: преобразовать Qemu в динамическую библиотеку, функции которой мог бы использовать TTAnalyze, а также модифицировать процесс трансляции Qemu таким образом, чтобы вызывались процедуры обратного вызова прежде каждого исполняющегося на виртуальном процессоре базового блока. В оригинальной версии TTAnalyze в качестве операционной системы использовалась WindowsXP.
TTAnalyze проводит анализ путем мониторинга вызовов WindowsAPI функций, а также вызовов системных сервисов в WindowsNativeAPI. Как было указано выше, TTAnalyze использует эмулятор Qemu, поэтому появляется необходимость отличать инструкции, исполняемые от имени анализируемого образца, от инструкций, которые исполняются как часть операционной системы или других работающих процессов. Для этого используется тот факт, что операционная система Windows назначает каждому работающему процессу собственную директорию страниц. Физический адрес базы данной директории страниц хранится в регистре CR3 процессора. Таким образом, определяется, какой адрес имеет директория страниц у процесса, находящегося под анализом. В итоге появляется возможность отличать инструкции, относящиеся к тестовому образцу, от других инструкций, путем сравнения текущего значения регистра CR3 с адресом директории страниц тестового образца. Важное замечание — адрес директории страниц должен быть получен прежде, чем исполнится первая инструкция анализируемого процесса. Поэтому процесс создается в замороженном режиме. Мониторинг вызовов функций происходит путем сравнения текущего значения указателя инструкций виртуального процессора со стартовыми адресами всех интересующих системных функций. Здесь используется тот факт, что стартовый адрес функции всегда соответствует первой инструкции в блоке трансляции. Поэтому, процедура обратного вызова TTAnalyze получает контроль, где происходит упомянутое выше сравнение.
TTAnalyze способен регистрировать аргументы вызываемых функций. Для этого авторы разработали специальный компонент — генератор. Этот генератор представляет собой отдельную программу, которая может исполняться независимо от TTAnalyze. Задача генератора — сконструировать необходимый код-заглушку для функции обратного вызова, который бы обрабатывал аргументы вызываемых функций. Данный генератор требует в качестве входа файл, содержащий декларации всех функций, подлежащих мониторингу. Обрабатывая декларации, генератор способен определить размеры и структуру аргументов функций и сконструировать соответствующий C++ код для их чтения. При чтении аргументов вызываемых функций возникает следующая проблема. Существует возможность, что содержимое, на которое ссылается виртуальный адрес, не представлено в эмулируемой физической памяти, а находится только на эмулируемом жестком диске (т. е. содержимое находится в файле подкачки). В этом случае чтение из виртуальной системной памяти приведет к ошибке. Для решения этой проблемы в TTAnalyze применяется следующий прием. Всякий раз, когда появляется необходимость обратиться к адресу, который не представлен в эмулируемой физической памяти, тестовый образец принуждается к чтению из этого виртуального адреса. Эта операция чтения вызывает обработчик ошибок страниц, который загружает соответствующую страницу памяти в эмулируемую физическую память. Чтение аргументов функции с этого момента становится возможным. Достигается такое принуждение чтения с помощью инъекции инструкций чтения в поток инструкций.
Оригинальная версия TTAnalyze генерирует отчет, содержащий следующую информацию: общая информация (размер файла, код выхода и т.д.), файловая активность, активность реестра, активность сервисов, активность процессов, сетевая активность.
Итак, инструмент TTAnalyze является основой для системы Anubis. TTanalyze задействует эмуляцию, а анализирующий компонент представлен функциями обратного вызова, которые располагаются за пределами среды, в которой непосредственно исполняется неизвестный образец. Такая архитектура позволяет производить анализ с большой степенью прозрачности. Нет необходимости вносить какие-либо изменения в код образца, которые могут быть детектированы самим образцом и, как результат, послужить причиной попыток уйти от анализа. С другой стороны, в работе [6] приводится расширенная классификация техник, с помощью которых анализируемая программа может детектировать свое исполнение в системе Anubis. Такое детектирование может производиться на разных уровнях: уровне аппаратного обеспечения (серийный номер диска), среды эмуляции (ошибки эмуляции работы процессора), уровне приложения (наличие определенного файла, в случае Anubis — файла C:\exec\exec.exe, и т.д.), уровне сети (проверка IP адреса сервера, проверка строк ответов известных почтовых серверов и т.д.) Однако, несмотря на эти моменты, Anubis представляет собой эффективную систему для анализа неизвестных файлов и пользуется популярностью среди исследователей.
Следующей системой, которую рассмотрим, будет система DRAKVUF. Авторы DRAKVUF определяют её как систему динамического анализа вредоносного программного обеспечения, разработанную с учетом достоинств последних расширений аппаратной виртуализации, способных предоставить прозрачную и масштабируемую среду для глубокого анализа образцов вредоносного программного обеспечения [7, с.386]. При проектировании авторами были выдвинуты следующие требования, которым должна удовлетворять система [7, с.387]: масштабируемость, что понимается как стремление к минимизации использования ресурсов при одновременной максимизации количества анализируемых образцов; точность, что означает получение большого количества информации при одновременном противодействии попыткам фальсификации результатов анализа; скрытность — среда, находящаяся под мониторингом, не должна детектировать наличие DRAKVUF; изолированность — система DRAKVUF должна быть изолирована от виртуальных машин для защиты от фальсификации.
DRAKVUF построена на основе открытого программного обеспечения XenVMM. Система создает клоны виртуальных машин с помощью интерфейса Xencopy-on-write (CoW) и возможности копирования при записи диска логического менеджера томов ОС Linux. Это делается для оптимизирования использования аппаратного обеспечения, поскольку ресурсы выделяются только тогда, когда они необходимы. Кроме того, поскольку клоны виртуальных машин не имеют доступа к эксклюзивным ресурсам друг друга, достигается необходимая изолированность виртуальных машин. Сама по себе система DRAKVUF исполняется в домене контроля (dom 0), получая прямой доступ к памяти через библиотеку LibVMI. Внутри домена контроля DRAKVUF также имеет доступ к возможностям гипервизора, таким как EPT.
Остановимся на деталях процесса мониторинга, производимого данной системой. Авторы системы отмечают ограниченность метода динамического анализа, при котором мониторингу подвергаются только системные вызовы программы. С этим можно согласиться, поскольку при таком подходе не учитывается возможность наличия компонентов, работающих в режиме ядра. DRAKVUF осуществляет прямой перехват внутренних функций ядра через инъекцию точки останова (#BP). Местонахождение функций ядра определяется через отладочную информацию. Далее, DRAKVUF способен анализировать атаки типа DKOM. Это делается с помощью перехватов выделений памяти из кучи ядра. С этой целью внедряется точка останова на используемые Windows функции AllocatePoolWithTag и ObCreateObject, ответственные за выделение памяти для структур. Таким образом становится возможным детектирование местоположения всех структур ядра без риска фальсификации представления состояния системы.
В системе DRAKVUF реализована возможность получения удаленных файлов из памяти. Вредоносное программное обеспечение обычно быстро создает и удаляет временные файлы, например, в процессе своей установки. Такие файлы могут содержать полезную для анализа информацию. С целью получения таких файлов в системе перехватываются функции типа NtSetInformationFile и ZwSetInformationFile. Далее определяется точный удаляемый файл, а также информация, относящаяся к описателю данного файла. В процессе парсинга таблицы описателей становится возможным определить местоположение соответствующего _FILE_OBJECT и автоматически достать файл из памяти с помощью инструмента Volatility.
DRAKVUF использует особую технику старта образцов для анализа. Для этого происходит поиск работающего в системе процесса, имеющего в своем адресном пространстве библиотеку kernel32.dll. Далее, происходит перехват потока исполнения данного процесса с тем, чтобы он исполнил функцию CreateProcessA, которая непосредственно запустит вредоносную программу. После отработки данной функции система возвращает перехваченный процесс в первоначальное состояние.
Таким образом, можно сделать следующие выводы. Одной из главных особенностей системы DRAKVUF является использование технологии аппаратной виртуализации в процессе анализа образцов. Анализирующий компонент системы оказывается интегрированным в процесс интроспекции виртуальных машин. Положительным моментом этого является высокая степень скрытности системы анализа для вредоносного программного обеспечения. Другим большим плюсом DRAKVUF является возможность анализа образцов, работающих на уровне ядра, причем такой анализ производится силами гипервизора, не требующего вмешательства в среду для анализа. С другой стороны, все ещё остаются возможности для детектирования образцом исполнения в виртуальной среде с помощью атак, основанных на времени. Авторы подчеркивают, что эта тема выходит за рамки их работы [7, с.388]. Также, общая проблема подхода с использование гипервизора — накладные расходы при выходе из гостевой системы и передаче управления гипервизору (возникновение событий, приводящих к VMExit).
Итак, в настоящей статье были исследованы три современные системы автоматизированного динамического анализа вредоносных файлов. Данные программные комплексы являют собой примеры различных походов к построению систем анализа: в CuckooSandbox анализирующий компонент исполняется в режиме пользователя и размещен на той же системе, где работает образец для анализа; Anubis задействует эмуляцию, а анализ производится с помощью функций обратного вызова; DRAKVUF использует в процессе анализа возможности, предоставляемые расширением аппаратной виртуализации процессора. В заключение, отметим наиболее общие вопросы и проблемы, возникающие при использовании подобных инструментов в практической деятельности. Во-первых, существует проблема имитации действий пользователя, поскольку некоторые вредоносные программы проявляют свою активность только в ответ на события взаимодействия компьютера и человека. Более того, отсутствие подобного взаимодействия может послужить индикатором наличия среды для анализа. Во-вторых, обычным является однократное исполнение программы под контролем системы анализа, что, очевидно, не дает полной картины имеющейся у вредоносной программы функциональности. Наконец, несмотря на продвинутые методы сокрытия, применяемые современными системами анализа, существуют многочисленные приемы и техники, имеющие целью определение исполнения в контролируемой среде. Тем не менее, в настоящий момент уже существуют различные технологии, направленные на преодоление с той или иной степенью эффективности обозначенных недостатков систем автоматизированного анализа. Очевидно, что данное направление исследований является одним из самых передовых в области компьютерной безопасности.
Литература:
- Cuckoo Sandbox Book. Release 0.3. — URL: https://media.readthedocs.org/pdf/cuckoo/0.3/cuckoo.pdf (дата обращения: 08.01.2016).
- Cuckoo Sandbox — open source automated malware analysis. — URL: https://media.blackhat.com/us-13/US-13-Bremer-Mo-Malware-Mo-Problems-Cuckoo-Sandbox-WP.pdf (дата обращения: 08.01.2016).
- Bremer, J. Haow do I sandbox?!?! Cuckoo Sandbox Internals / J. Bremer // RECON2013. — URL: http://recon.cx/2013/slides/recon2013-JurriaanBremer-Haow_do_I_sandbox.pdf (дата обращения: 09.01.2016).
- Ferrand, O. How to detect the Cuckoo Sandbox and hardening it? / O. Ferrand // Journal of Computer Virology and Hacking Techniques. — Springer-Verlag, Berlin, Heidelberg, 2015. — P. 51-58.
- Bayer, U. TTAnalyze: A Tool for Analyzing Malware / U. Bayer, C. Kruegel, E. Kirda. — URL: https://www.iseclab.org/papers/ttanalyze.pdf (дата обращения: 12.01.2016).
- Lindorfer, M. Detecting environment-sensitive malware / M. Lindorfer, C. Kolbitsch, P. M. Comparetti // RAID’11 Proceedings of the 14th international conference on Recent Advances in Intrusion Detection. — Springer-Verlag, Berlin, Heidelberg, 2011. — P. 338-357.
- Lengyel, T. K. Scalability, fidelity and stealth in the DRAKVUF dynamic malware analysis system / T. K. Lengyel et al. // ACSAC ’14 Proceedings of the 30th Annual Computer Security Applications Conference. — ACM New York, NY, USA, 2014. — P. 386-395.
