В предыдущей статье я рассказал, как создать лабораторию для анализа вирусов. Сегодня я покажу, как с помощью нашей домашней лаборатории анализировать компьютерные вирусы. Мы будем исследовать вредонос семейства PlugX, изучать взаимодействие с сетью и разрабатывать сигнатуры для его детекта.
Еще по теме: Где скачать вирусы для изучения
Анализ компьютерных вирусов в домашней лаборатории
Домашняя лаборатория которую мы создали в предыдущей статье, позволит изучить вирус, создать свои сигнатуры и выявить зараженные компьютеры в локальной сети. Сетевую сигнатуру мы напишем для Suricata IDS, а файловую — для опенсроного инструмента YARA.
В нашем подопытном модуле PlugX находятся 3 файла: один исполняемый файл и две динамические библиотеки, в одной из них сосредоточен основной вредоносный функционал.
Перед началом анализа компьютерных вирусов, нужно сделать снимок состояния виртуалки с Kali Linux и Windows 10, для того чтобы в любой момент откатить назад, к первоначальным настройкам.
Инструменты для изучения компьютерных вирусов
Большинство используемых нами инструментов лежат в папке FLARE на рабочем столе виртуалки с Windows 10. Для изучения вредоносов мы будем пользоваться утилитами:
- PeStudio — поиск артефактов исполняемых файлов.
- Detect It Easy — утилита для определения типа файлов.
- Wireshark — сниффер для анализа сетевых протоколов.
- IDA Pro — интерактивный дизассемблер и отладчик для реверс‑инжиниринга.
- SELKS — управления сетевой безопасностью.
- Burp Suite — прозрачный прокси‑сервер для исследования взаимодействий вирусов по протоколу HTTPS.
- YARA Editor — инструмент для создания и тестирования правил YARA.
- Loki Scanner — консольный сканер IOCs.
- ApiLoger — инструмент для анализа вызываемых WinAPI-функций вредоносного файла.
Анализ вредоноса будет проходить в 3 этапа:
- Статический анализ.
- Поведенческий анализ.
- Создание сигнатур для выявления вредоносного модуля.
Статический анализ
Чтобы узнать, какой компоновщик и компилятор был использован во время создания нашего подопытного файла, а также определить, упакован он или нет, подсунем его утилите Detect It Easy.
Detect It Easy указывает, что исполняемый файл написан на C/C++ для 32-разрядных ОС. Теперь поищем артефакты файла с помощью утилиту PeStudio.
Нас интересуют временные метки компиляции исполняемого файла, загружаемые библиотеки, используемые ресурсы, характерные строки, файл сборки (Manifest) и отладочная информация. Нам понадобится эти данные при создании файловой сигнатуры.
Поиск строк обнаружил информацию о загружаемой библиотеке и функции вызова.
В столбце value есть строка Goshawk.dll — это указывает на использование некой динамической библиотеки. В строке ServerEntryFun информация о функции экспорта.
Открываем наш файл в IDA Pro, находим строку Goshawk.dll и участок кода, в котором происходит загрузка динамической библиотеки. Для этого переходим в раздел Views —> OpenSubviews —> Strings, находим строку Goshawk.dll, жмем на клавишу X, для перехода к коду загрузки либы, и декомпилируем этот код нажав на клавишу F5.
Строки ServerEntyFun и Goshawk.dll обнаруживаются в дизассемблерном листинге. Они нам пригодятся для написания файловой сигнатуры.
Основной функционал модуля находится в динамической библиотеке. Пришло время ее проанализировать. открываем. Чтобы определить компилятор и компоновщик, откроем библиотеку в Detect It Easy.
Теперь посмотрим, что PeStudio сможет сказать о нашей библиотеке.
Вы можете видеть на скрине, как вирус использует библиотеку ws32_32.dll, которая предназначена для сетевых подключений TCP/IP, а также динамическую библиотеку vtcp.dll. На вкладке Strings видим следующее.
В файл Debug.log сохраняется отчет об ошибках в результате работы вредоносного файла.
Теперь загрузим вредонос в IDA Pro и поглядим на участки кода. В нашем примере, мы анализируем динамическую библиотеку и в первую очередь стоит изучить функции экспорта, для этого перейдем вкладку Exports.
Нажимаем два раза функцию ServerEntryFun и анализируем ее код.
Как видно, функция CreateThread создает поток, который выполняется в пределах виртуального адресного пространства вызывающего процесса. Параметр StartAddress указывает на адрес функции, выполняющейся в запущенном потоке. В этой функции содержится код расшифровки конфигурации модуля и код шифрования сетевого взаимодействия с управляющим сервером.
Поведенческий анализ
Проведем поведенческий анализ, а именно рассмотрим, какой трафик генерирует вредоносный файл. Для этого обратимся к виртуальной машине с Kali Linux, запустим Inetsim для эмуляции интернет‑сервисов и Burp Suite для получения HTTPS-трафика. Еще нам понадобится Wireshark, чтобы проанализировать весь трафик с хоста Windows 10.
Запустим на виртуальной машине Windows 10 вредоносный файл, а затем — утилиту ApiLogger из подпапки Utilites каталога FLARE.
Функция gethostbyname получает IP-адрес для домена www.dicemention.com, DNS-сервер, развернутый с помощью Inetsim, резолвит домен по адресу 10.10.10.1 (адрес виртуальной машины Kali Linux).
Далее создается сокет для взаимодействия с хостом 10.10.10.1 (IP-адрес виртуальной машины Kali Linux) по порту 443. Функция send, реализованная в динамической библиотеке ws2_32.dll, отправляет данные размером 22 байта.
Переходим в IDA Pro на вкладку Imports и находим эту функцию.
Отыщем участок кода, который отвечает за сетевое взаимодействие. Глубокие раскопки этого кода займут слишком много времени, а наша задача — изучить его функциональность и разработать сигнатуры.
Весь алгоритм шифрования сетевого взаимодействия основан на двух этапах: расшифровка заголовка, который содержит информацию о размере сжатых данных, и расшифровка собственно самих передаваемых данных.
Просмотрим сетевой трафик и данные, полученные в Burp Suite на виртуальной машине с Kali Linux.
В сетевом трафике мы обнаружили запрос на получение доменного имени управляющего сервера. Посмотрим генерируемый трафик по порту 443. Исследуемый модуль не использует протокол HTTPS, поэтому отключим Burp Suite и запустим nc (netcat — утилита командной строки для чтения и записи сетевых данных по протоколу TCP и UDP-данных).
На виртуальной машине Kali Linux выполним команду nc -lvnp 443 и ждем данные от вредоносного файла.
Информация, которую вредонос передает на управляющий сервер, показана на скриншоте выше.
На данном этапе мы разобрали функциональность исследуемого модуля, изучили сетевое взаимодействие с управляющим сервером. С использованием полученных строк, характерных для вредоносного файла, и домена управляющего сервера мы разработаем сигнатуры для поиска скомпрометированных компьютеров.
Создание сигнатур
Для выявления деятельности вредоноса в сети разработаем сетевую сигнатуру. При реагировании на инцидент, особенно когда у нас отсутствуют средства обнаружения атак, необходимо исследовать трафик, чтобы найти зараженные компьютеры. Можно записать трафик и отфильтровать его по известным доменам и IP-адресам, но я советую использовать программное обеспечение с открытым исходным кодом.
Для этих целей подходит стек ELK (Elasticsearch + Kibana) и Suricata. SELKS — это бесплатная платформа IDS/IPS для мониторинга сетевой безопасности на основе Debian. Информация об установке и загрузке правил есть на гитхабе. Для поиска малвари на скомпрометированных компьютерах можно воспользоваться YARA-движком.
Создание сигнатуры для Suricata IDS
Создадим alert — правило для сигнализации о сетевой активности вредоносного файла.
Правило будет выглядеть так:
1 |
alert dns any any -> any 53 (msg:"MALWARE Observed DNS Query to Known malware PlugX www[.]dicemention[.]com domain"; sid: 1000001; classtype: "malware"; dns_query; content: "dicemention.com"; reference:url,www.virustotal.com/gui/file/d3bd436119af73a1e9a2ae5360ef38c81031f6f9f2b5f389416aaeafd902e3bd/details;) |
Загрузим это правило в SELKS и протестируем на записанном трафике.
Наше правило сработало, и мы выявили активность малвари на компьютере 10.10.10.2. Следующим этапом необходимо исследовать зараженный компьютер и обнаружить сам вредоносный файл.
Пока что мы создали только сетевую сигнатуру на вредоносный домен, но этого условия недостаточно. Необходимо получить IP-адрес DNS-записи и создать дополнительное правило на IP-адрес. При взаимодействии зараженного компьютера с управляющим сервером запись DNS хранится в кеше, а взаимодействие устанавливается именно по IP-адресу.
Создание правила YARA
Правило YARA — это инструмент, позволяющий выявлять образцы вредоносных программ и находить их расположение на скомпрометированных компьютерах. Сначала создадим сигнатуру для исполняемого файла, а затем для динамической библиотеки, в которой расположена основная функциональность вредоносного модуля.
Документация по созданию правил YARA представлена здесь.
При создании правил YARA нужно обращать внимание на следующие объекты:
- строки, характерные для исследуемого модуля или семейства вредоносных программ;
- мьютексы;
- ключи реестра;
- файлы отладочной информации;
- подключаемые библиотеки;
- одинаковые участки кода, характерные для семейства вредоносных программ.
Для автоматизации создания правил на основе фрагмента исполняемого кода пригодится полезный плагин mkYARA.
Запустим YARA Editor, перейдем на вкладку Editor, загрузим пустой файл и начнем писать сигнатуру.
1 2 3 4 5 6 7 8 9 10 11 12 |
rule PlugX_downloader { meta: maltype = "PlugX" description = "Search for a malicious downloader PlugX" strings: $dll="Goshawk.dll" nocase $str1="Goshawk v2.1" $chunk_1 = {53 65 72 76 65 72 45 6e 74 72 79 46 75 6e 00} condition: uint16 (0) == 0x5A4D and $dll and $str1 and $chunk_1 } |
В разделе meta содержится описание разработанного правила. В разделе strings находятся строки, обнаруженные в результате исследования вредоносного файла. В переменной $dll — информация о загружаемой динамической библиотеке, $str1 — строка информации об исполняемом файле. Переменная $chunk_1 содержит шестнадцатеричное значение запускаемой функции экспорта ServerEntryFun. В разделе condition описывается условие поиска указанных строк в файле.
Для детектирования вредоносной библиотеки мы напишем следующее правило.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
rule PlugX_dll { meta: maltype = "PlugX" description = "Search for a malicious dll PlugX" strings: $str1 = "WS2_32.dll" nocase // use library $str2 = "vtcp.dll" nocase // backdoor dll $str3 = "ServerEntryFun" // Function export $str4 = "Debug.log" // File Debug.log to record errors condition: uint16 (0) == 0x5A4D and all of them } |
В правило YARA для динамической библиотеки мы добавили строки, содержащие информацию о либе ws2_32.dll, которую вирус использует для сетевого взаимодействия, подгружаемой библиотеке vtcp.dll, используемой функции ServerEntryFun и обнаруженном нами файле Debug.log.
Протестируем разработанные сигнатуры. Для этого переходим ко вкладке test —> Test items, нажимаем кнопку Folder и выбираем каталог, в котором расположены вредоносные модули. После нажатия кнопки Scan items YARA Editor начинает искать файлы по тестируемым сигнатурам.
На скрине видно, что в результате сканирования были обнаружены вредоносные файлы семейства PlugX, содержащие строки из наших YARA-правил.
Для поиска в файловой системе вредоносных файлов на основе IOCs можно использовать утилиту Loki Scanner, в которую есть возможность добавлять правила YARA и хеш‑суммы модулей.
Заключение
Мы провели статический и поведенческий анализ вредоносного файла и создали сигнатуры для детектирования его модуля. С помощью собранной ранее лаборатории мы смогли быстро исследовать вредоносный код и разработать собственные индикаторы компрометации.
Дальнейшие этапы при расследовании инцидентов — обнаружить зараженные компьютеры, найти точку входа злоумышленников в сеть, а также методы закрепления в системе и бокового перемещения. Но эти шаги выходят за рамки сегодняшней статьи.
Еще по теме: Удаленная отладка вредоносных программ
Как добавляли правило в SELKS?