Анализ компьютерных вирусов в домашней лаборатории

В предыдущей статье я рассказал, как создать лабораторию для анализа вирусов. Сегодня я покажу, как с помощью нашей домашней лаборатории анализировать компьютерные вирусы. Мы будем исследовать вре­донос­ семей­ства PlugX, изу­чать вза­имо­дей­ствие с сетью и раз­рабатывать сиг­натуры для его детек­та.

Еще по теме: Где скачать вирусы для изучения

Анализ компьютерных вирусов в домашней лаборатории

Домашняя лаборатория которую мы создали в предыдущей статье, позволит изучить вирус, создать свои сигнатуры и выявить зараженные компьютеры в локальной сети. Сетевую сиг­натуру мы напишем для Suricata IDS, а фай­ловую — для опенсроного инструмента YARA.

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

Инструменты для изучения компьютерных вирусов

Большинство используемых нами инструментов лежат в папке FLARE на рабочем сто­ле вир­туалки с Windows 10. Для изучения вре­донос­ов мы будем пользоваться утилитами:

• PeStudio — поис­к арте­фак­тов исполня­емых фай­лов.
• Detect It Easy — утилита для опре­деле­ния типа фай­лов.
• Wireshark — сниффер для ана­лиза сетевых про­токо­лов.
• IDA Pro — инте­рак­тивный дизас­сем­блер и отладчик для реверс‑инжи­нирин­га.
• SELKS — управления сетевой безопасностью.
• Burp Suite — проз­рачный прок­си‑сер­вер для исследования вза­имо­дей­ствий вирусов по про­токо­лу HTTPS.
• YARA Editor — инструмент для создания и тес­тирова­ния пра­вил YARA.
• Loki Scanner — консольный сканер IOCs.
• ApiLoger — инструмент для ана­лиза вызыва­емых WinAPI-фун­кций вре­доно­сного файла.

Ана­лиз вредоноса будет проходить в 3 эта­па:

1. Ста­тичес­кий ана­лиз.
2. По­веден­ческий ана­лиз.
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 — пра­вило для сиг­нализа­ции о сетевой активнос­ти вре­донос­ного фай­ла.

Пра­вило будет выг­лядеть так:

Заг­рузим это пра­вило в SELKS и про­тес­тиру­ем на записан­ном тра­фике.

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

По­ка что мы соз­дали толь­ко сетевую сиг­натуру на вре­донос­ный домен, но это­го усло­вия недос­таточ­но. Необ­ходимо получить IP-адрес DNS-записи и соз­дать допол­нитель­ное пра­вило на IP-адрес. При вза­имо­дей­ствии заражен­ного компь­юте­ра с управля­ющим сер­вером запись DNS хра­нит­ся в кеше, а вза­имо­дей­ствие уста­нав­лива­ется имен­но по IP-адре­су.

Создание правила YARA

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

До­кумен­тация по соз­данию пра­вил YARA пред­став­лена здесь.

При соз­дании пра­вил YARA нуж­но обра­щать вни­мание на сле­дующие объ­екты:

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

За­пус­тим YARA Editor, перей­дем на вклад­ку Editor, заг­рузим пус­той файл и нач­нем писать сиг­натуру.

В раз­деле meta содер­жится опи­сание раз­работан­ного пра­вила. В раз­деле strings находят­ся стро­ки, обна­ружен­ные в резуль­тате иссле­дова­ния вре­донос­ного фай­ла. В перемен­ной $dll — информа­ция о заг­ружа­емой динами­чес­кой биб­лиоте­ке, $str1 — стро­ка информа­ции об исполня­емом фай­ле. Перемен­ная $chunk_1 содер­жит шес­тнад­цатерич­ное зна­чение запус­каемой фун­кции экспор­та ServerEntryFun. В раз­деле condition опи­сыва­ется усло­вие поис­ка ука­зан­ных строк в фай­ле.

Для детек­тирова­ния вре­донос­ной биб­лиоте­ки мы напишем сле­дующее пра­вило.

В пра­вило YARA для динами­чес­кой биб­лиоте­ки мы добави­ли стро­ки, содер­жащие информа­цию о либе ws2_32.dll, которую вирус исполь­зует для сетево­го вза­имо­дей­ствия, под­гру­жаемой биб­лиоте­ке vtcp.dll, исполь­зуемой фун­кции ServerEntryFun и обна­ружен­ном нами фай­ле Debug.log.

Про­тес­тиру­ем раз­работан­ные сиг­натуры. Для это­го перехо­дим ко вклад­ке test —> Test items, нажима­ем кноп­ку Folder и выбира­ем каталог, в котором рас­положе­ны вре­донос­ные модули. Пос­ле нажатия кноп­ки Scan items YARA Editor начина­ет искать фай­лы по тес­тиру­емым сиг­натурам.

На скрине вид­но, что в резуль­тате ска­ниро­вания были обна­руже­ны вре­донос­ные фай­лы семей­ства PlugX, содер­жащие стро­ки из наших YARA-пра­вил.

Заключение

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

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

Еще по теме: Удаленная отладка вредоносных программ