Извлечение информации из дампа памяти сервера

Извлечение артефактов из дампа памяти сервера критически важно для расследования атаки. Экспертам форензики часто приходится работать с ограниченным объемом данных, например, только с образом памяти скомпрометированного сервера. Этот сценарий описывается в задаче BSidesJeddah-Part2 с ресурса CyberDefenders, который мы рассмотрим в этой статье.

Еще по теме: Команды для анализа вредоносного ПО в Volatility

Извлечение информации из дампа памяти сервера

Наша цель — найти причины взлома сервиса, работающего на Oracle WebLogic Server, и извлечь артефакты из образа оперативной памяти винды.

Для этого задания мы будем использовать следующие инструменты Volatility 2.6.1 и Volatility 3.

Что такое Volatility

Volatility — это популярный open source инструмент для анализа дампов оперативной памяти.

Возможности Volatility:

• Извлечение процессов, модулей, драйверов, открытых сетевых соединений и других данных из дампа памяти.
• Поиск скрытых и вредоносных процессов.
• Анализ запущенных dll, поиск инжекций и способов сокрытия вредоносных модулей.
• Восстановление скрытых данных из памяти процессов.
• Поиск артефактов для расследования инцидентов информационной безопасности.
• Построение временной шкалы (timelining) для выявления аномалий.

Volatility широко используется в форензике для анализа инцидентов и сбора доказательств. Он помогает эффективно исследовать состояние скомпрометированных систем.

Установка Volatility

Volatility поддерживает широкий спектр ОС — Windows, Linux, macOS, Android.

• Установка Volatility на Kali Linux
• Как установить Volatility на Windows

Анализ образа памяти

После установки скачайте архив с артефактами и извлеките файл memory.mem.

Для анализа и извлечения артефактов из дампа памяти, мы будем использовать фреймворк Volatility 2 и Volatility 3. Различие между версиями описано в документации. Достоинства третей версии в том, что она не использует профили ОС, а определяет их на лету используя таблицы символов Windows.

Но большинство плагинов разработано для второй версии (см. Популярные плагины Volatility 2 и Популярные плагины Volatility 3).

Для начала, надо получить профиль ОС для работы с Volatility 2.

Профиль операционной системы — Win2016x64_14393.

До анализа артефактов, надо определить с какой системой работаем. Для этого надо получить версию ОС, имя компа и сетевой адрес, для этого заюзаем плагин printkey.

Название машины — WIN-8QOTRH7EMHC.

Затем, получим список интерфейсов сети с помощью следующей команды.

У нас теперь есть спи­сок иден­тифика­торов сетевых интерфей­сов. Попробуем проверить каждый.

Се­тевой адрес машины — 192.168.144.131, IP-адрес получает DHCP-сер­вером 192.168.144.254.

Те­перь найдем информа­цию о вер­сии ОС.

Вер­сия ОС — Windows Server 2016 Standard Evaluation.

Определим вре­мя получения обра­за опе­ратив­ной памяти. Для это­го заюзаем пла­гин windows.info от Volatility 3.

Сис­темное вре­мя — 2021-08-06 16:13:23.

Теперь попробуем вос­ста­новить дей­ствия поль­зовате­ля в ОС. Посмотрим исто­рию бра­узе­ра Internet Explorer. Для это­го заюзаем пла­гин iehistory.

Нам уда­лось выяс­нить, что 6 августа 2021 года поль­зователь Administrator посетил стра­ницу news.google.com.

Те­перь прис­тупим к поис­ку вре­донос­ной активнос­ти. Для это­го нам необ­ходимо про­ана­лизи­ровать про­цес­сы, сетевой тра­фик, коман­ды запус­ка исполня­емых фай­лов, а так­же иссле­довать стро­ки про­цес­сов.

Для начала получим спи­сок запущен­ных в сис­теме про­цес­сов, а так­же сетевую активность и сох­раним резуль­тат работы пла­гинов в фай­лы pstree.txt и netscan.txt соот­ветс­твен­но.

В спис­ке про­цес­сов мож­но заметить прог­рамму RamCapture.exe ком­пании Belkasoft.

В фай­ле netscan.txt отме­чено две­над­цать ста­биль­ных сетевых соеди­нений, об этом нам говорит колон­ка State, демонс­три­рующая работу пла­гина netscan с уста­нов­ленным зна­чени­ем ESTABLISHED.

Про­ана­лизи­руем дерево про­цес­сов и най­дем сре­ди них ано­маль­ные. Необ­ходимо обра­щать вни­мание на про­цес­сы, которые запус­кают дочер­ний про­цесс с име­нами cmd.exe, powershell.exe, conhost.exe, а так­же на исполня­емые фай­лы с нес­тандар­тным рас­положе­нием.

Про­цес­сом java.exe (иден­тифика­тор 4752) запуще­но мно­жес­тво дочер­них powershell.exe, что может сви­детель­ство­вать о подоз­ритель­ной активнос­ти. Так­же у про­цес­са powershell.exe (иден­тифика­тор 4344) запуще­ны дочер­ние про­цес­сы conhost.exe (иден­тифика­тор 4636) и svchost.exe (иден­тифика­тор 1488).

По­лучим дамп дан­ных про­цес­сов и про­ана­лизи­руем их стро­ки.

Мы сох­ранили дамп в файл 4752.dmp.

Ре­зуль­тат работы сох­ранен в фай­ле 4344.dmp.

Те­перь с помощью ути­литы strings вытащим все стро­ки и сох­раним их в файл.

Преж­де чем ана­лизи­ровать стро­ки, получим аргу­мен­ты коман­дной стро­ки для запус­ка про­цес­сов. Для это­го вос­поль­зуем­ся пла­гином cmdline и най­дем в нем про­цесс java.exe (иден­тифика­тор 4752).

Про­цесс cmd.exe (иден­тифика­тор 4556), который явля­ется родите­лем про­цес­са java.exe (4752), запус­кает сер­вер WebLogic. Зна­чит, про­цесс java.exe — резуль­тат работы веб‑сер­вера.

Вы­ясним вер­сию WebLogic, для это­го получим спи­сок фай­лов в сис­теме.

Ана­лизи­руя спи­сок фай­лов, мы обна­ружи­ваем файл лога веб‑сер­вера WebLogic — AdminServer.log.

Вос­ста­новим его и про­ана­лизи­руем: вир­туаль­ный адрес фай­ла в обра­зе памяти — 0xb68cb2c205c0. Вос­ста­новить этот файл с исполь­зовани­ем ути­литы Volatility 2 мне не уда­лось, поп­робу­ем это сде­лать с помощью Volatility 3.

В вос­ста­нов­ленном фай­ле ука­зана вер­сия WebLogic Server — 14.1.1.0.0.

Слу­шатель WebLogic Server работа­ет на пор­те 7001, но зап­росы к веб‑сер­веру идут на 80-й порт.

Най­дем перенап­равле­ние пор­та в клю­че реес­тра PortProxy, для это­го вос­поль­зуем­ся пла­гином printkey.

В сис­теме уста­нов­лено перенап­равле­ние пор­та 80:7001.

Мы выяс­нили вер­сию веб‑сер­вера: она уяз­вима и поз­воля­ет выпол­нять уда­лен­ный код в сис­теме. В фай­ле лога AdminServer.log вид­ны резуль­таты выпол­нения фун­кции com.tangosol.coherence.mvel2.sh.ShellSession, а так­же зап­рос к /console/%2E%2E%2Fconsole.portal?_nfpb=true&_pageLabel=UnexpectedExceptionPage.

Те­перь най­дем про­цесс, через который зло­умыш­ленник получил пер­воначаль­ный дос­туп. У нас есть дамп про­цес­са 4752, мы наш­ли его стро­ки, теперь оты­щем в нем GET-зап­рос с парамет­ром:

Итак, иско­мый про­цесс — это java.exe, иден­тифика­тор 4752. Имен­но он был ответс­тве­нен за пер­воначаль­ный дос­туп к сис­теме. Зло­умыш­ленник про­экс­плу­ати­ровал уяз­вимость CVE-2020-14882 в сер­вере WebLogic вер­сии 14.1.1.0.0, поз­воля­ющую выпол­нять уда­лен­ный код в сис­теме.

Как вид­но из иллюс­тра­ции выше, хакер запус­тил обратную обо­лоч­ку с управля­ющим сер­вером 192.168.144.129:1339.

Ана­лизи­руя работу пла­гина netscan, мож­но уви­деть запущен­ный про­цесс powershell.exe (иден­тифика­тор 4344), который вза­имо­дей­ству­ет с 192.168.144.129:1339.

Вос­поль­зуем­ся пла­гином pslist и най­дем сле­дующий про­цесс в спис­ке ActiveProcessLinks, его иден­тифика­тор 4772.

Как вид­но из иллюс­тра­ции, про­цесс java.exe име­ет 44 потока. Про­дол­жим ана­лизи­ровать стро­ки про­цес­са java.exe.

В резуль­тате ана­лиза строк мож­но уви­деть заг­рузку фай­лов presist.ps1 и pastebin.ps1.

Поп­робу­ем вос­ста­новить коман­ды для заг­рузки этих фай­лов. Так как коман­ды выпол­няют­ся с исполь­зовани­ем PowerShell, получим дамп всех про­цес­сов powershell.exe, запущен­ных от име­ни java.exe (иден­тифика­тор 4752).

Для это­го вос­поль­зуем­ся пла­гином memdump. Вос­ста­новим коман­ду для заг­рузки сце­нари­ев PowerShell.

Ко­ман­да для заг­рузки сце­нария presist.ps1 выг­лядит сле­дующим обра­зом:

Заг­рузка фай­ла pastebin.ps1 выпол­нялась при помощи коман­ды:

Най­дем код pastebin.ps1 и про­ана­лизи­руем его. Для это­го будем искать этот код в стро­ках дам­па наших про­цес­сов. При иссле­дова­нии резуль­татов вывода пла­гина cmdline мы замети­ли, что про­цесс notepad.exe (иден­тифика­тор 4596) открыл файл exfiltrator.txt.

По­лучим дамп про­цес­са 4596 и про­ана­лизи­руем стро­ки.

Этот скрипт пред­назна­чен для выг­рузки тек­сто­вых фай­лов на ресурс pastebin.com, но ему в качес­тве парамет­ра необ­ходимо ука­зать ссыл­ку. Поиск ссыл­ки на выг­рузку фай­лов в стро­ках дам­па про­цес­са notepad.exe не дал резуль­татов.

В стро­ках вре­донос­ного про­цес­са 4344 уда­лось обна­ружить ссыл­ку https://pastebin.com/A0Ljk8tu для выг­рузки фай­лов. Зна­чит, скрипт pastebin.ps1 запус­кался от име­ни дан­ного про­цес­са.

Най­дем методы зак­репле­ния зло­умыш­ленни­ка в сис­теме. Для это­го вос­поль­зуем­ся пла­гином autoruns или про­ана­лизи­руем стро­ки про­цес­са 4344.

Зло­умыш­ленник соз­дал служ­бу ServiceUpdate, которая запус­кает обратную обо­лоч­ку с управля­ющим сер­вером 192.168.144.129, порт 1339. Сог­ласно мат­рице MITRE ATT&CK, иден­тифика­тор этой тех­ники — T1053.005.

Про­дол­жаем ана­лизи­ровать вре­донос­ные про­цес­сы. Получим дамп про­цес­са svchost.exe (иден­тифика­тор 1488), най­дем вир­туаль­ный адрес рас­положе­ния это­го фай­ла в сис­теме и с помощью пла­гина windows.dumpfiles ути­литы Volatility 3 выг­рузим файл.

Вир­туаль­ный адрес фай­ла в обра­зе памяти — 0xb68cb2b8a080. Вос­ста­новим его.

Пос­ле вос­ста­нов­ления получим MD5-сум­му фай­ла 2c5ae1d11a02d19ab65f5fc06a33d603 и про­верим ее на VirusTotal. Сог­ласно отче­ту анти­вирус­ных ком­паний, перед нами полез­ная наг­рузка фрей­мвор­ка Cobalt Strike. Получим дамп про­цес­са и поп­робу­ем вытащить кон­фигура­цию C2.

Заг­рузим ути­литу CobaltStrikeParser и най­дем в памяти про­цес­са кон­фигура­цию маяка.

Мы узна­ли тип маяка (HTTP), адрес управля­юще­го сер­вера (192.168.144.129), порт (1339), а так­же пуб­личный ключ. Получим MD5-сум­му клю­ча.

MD5-сум­ма пуб­лично­го клю­ча — fc627cf00878e4d4f7997cb26a80e6fc.

Заключение

Мы про­вели рас­сле­дова­ние инци­ден­та и вос­ста­нови­ли кар­тину взло­ма ресур­са: 6 августа 2021 года зло­умыш­ленник про­экс­плу­ати­ровал уяз­вимость CVE-2020-14882 в Oracle WebLogic Server, которая поз­воля­ет не про­шед­шим авто­риза­цию поль­зовате­лям выпол­нять уда­лен­ный код в сис­теме.

Та­ким обра­зом ата­кующий заг­рузил обратную обо­лоч­ку с управля­ющим сер­вером 192.168.144.129, порт 1339. Далее он зак­репил­ся в сис­теме, соз­дав служ­бу ServiceUpdate. Для это­го зло­умыш­ленник заг­рузил PowerShell-сце­нарий presist.ps1. Дан­ный сце­нарий соз­дает служ­бу ServiceUpdate, которая запус­кает обратную обо­лоч­ку.

Для эксфиль­тра­ции дан­ных зло­умыш­ленник заг­рузил сце­нарий pastebin.ps1, который отправ­ляет соб­ранные фай­лы на уда­лен­ный сер­вер. Затем ата­кующий заг­рузил маяк Cobalt Strike для пос­тэкс­плу­ата­ции в сис­теме.

В ходе нашего рас­сле­дова­ния мы научи­лись извле­кать кон­фигура­цию маяка из памяти, а так­же искать важ­ные арте­фак­ты в памяти про­цес­сов.

ПОЛЕЗНЫЕ ССЫЛКИ:

• Как изменить формат дампа памяти
• Форензик кейс взлома серверов под управлением Linux
• Использование Volatility для анализа оперативной памяти
• Дамп оперативной памяти с помощью FTK Imager Windows