На этот раз я проводил анализ вредоносного файла, не имея самого файла. Вместо него есть кое-что получше — сырой бинарный дамп оперативной памяти, сделанный на заражённой системе через DumpIt. Что это значит? Это просто побайтовый «снимок» содержимого RAM как есть — один огромный файл без какой-то структуры.

Почему так вышло? Давайте почитаем описание:

«Recently, Binz received a request via email to create a 3D model for a client's family. Upon downloading and opening the provided files, he observed unusual system behavior that raised suspicion. Acting on instinct, he promptly deleted the files; however, he remained concerned that the system might still be compromised. In response, we acquired a full memory dump from the affected machine for in-depth malware analysis. The objective of this investigation is to identify indicators of compromise (IOCs) that can be integrated into our Endpoint Detection and Response (EDR) systems, as we suspect the use of a novel and sophisticated infection vector.»

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

В целом, имея такой расклад, есть не так много опций:

1. Вы можете закинуть дамп в HxD или в другой hex-редактор и искать какие-то артефакты. Я вот, к примеру, выгрузил все строки через strings и у меня вышло около 900к строк — искать там что-то тяжело, особенно если не знаешь что именно ты ищешь. Ещё я придумал, что можно по заголовку PE-файла искать бинари, которые были загружены в памяти во время снятия дампа, но получилось около 2к .exe-шников, искать среди них что-то тоже сложно, если не знаешь что именно ищешь и по какому адресу. Однако, забегая вперёд, могу сказать, что кое-что я всё же смог обнаружить путём простого поиска.

2. Использовать volatility3, либо volatility2. У них немного разный функционал, 2 версия, например, умеет дампить память процесса, а 3 версия так не умеет. А ещё 2 версия написана на python2, так что придётся ещё и его накатить - впрочем, гайдов по установке в интернете хватает.

3. Использовать MemProcFS – эта тулза проанализирует дамп, создаст на вашей системе отдельный том и разместит в нём всю собранную информацию, раскидав всё по папкам — штука удобная, полезная, быстрая.

Перейдём к заданиям:

0x0 | Узнать когда был запущен «подозрительный» процесс.

Задание подразумевает, что необходимо обнаружить «подозрительный» процесс, который был запущен после того, как был открыт вредоносный файл.

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

Выполняем команду:

«vol -f %здесь_путь_до_дампа% windows.cmdline.CmdLine»

И смотрим что есть. Надо полагать, мы ищем процесс, в котором фигурирует какой-нибудь подозрительный файл.

И такой файл находится:

Теперь можно сказать как именно файл попал в систему и что он начал делать после запуска. Это msc-скрипт, под видом изображения был отправлен жертве, хотя вроде даже не замаскирован никак. Очень странно, что пользователь не обратил внимание на его расширение. Можно увидеть, что он лежит в директории, куда MSEdge сохраняет скачанные файлы, значит пользователь получил его откуда-то с почты, открытой в браузере, скачал, открыл файлик и вредоносный процесс стартовал. PID процесса 3120 — посмотрим на этот процесс через другую опцию, которая покажет время запуска:

«vol -f %здесь_путь_до_дампа% windows.pslist –pid 3120»

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

0x1 | Узнать размер архива, в котором содержится вредоносное ПО.

Покопавшись в дампе, нашёл веб-запросы, через которые был получен даже не family_image.msc, а family_image.zip! И даже можно глянуть сурс этого файла.

То есть изначально пользователь получил архив. К сожалению, поскольку пользователь удалил все эти файлы, то в файловой системе искать их смысла нету. Но есть вариант попробовать поискать архивы через hex-редактор напрямую в дампе.

Для этого надо вспомнить какая вообще структура у zip-архива:

Есть некоторый local file header, по которому мы можем поискать какие-то заархивированные файлы в памяти. Можно также поискать central directory file хэдеры, чтобы понять сколько файлов в архиве.

Проблема в том, что файл архива «разбросан» по дампу и собрать его при всём желании не получится. Однако, можно найти directory file header, посмотреть сколько файлов в архиве, их размер, добавить также размер заголовков и мы получим по идее размер архива.

Структура CentralDirectoryFileHeader выглядит так:

Ищем “family_image.msc” и рядом байтики 0x50, 0x4b, 0x01, 0x02:

Долго искать не приходится, я выделил всё, на что стоит обратить внимание — есть второй файл, есть его сжатый размер (поле CompressedSize), ну и размер первого файла.

0x180f5b + 0x6042c = 0x1e1387 = 1971079 байт сжатых данных.

Прибавим заголовки, размер которых составит здесь 354 байта — это и поля фиксированного размера, и всякие FileName, ExtraField, .ZIP file comment field, где размер может быть произвольным.

Получится 1971433 байта. Конечно, я мог бы использовать какие-то инструменты, но мне стало интересно сколько я смогу выжать из дампа, не используя никаких инструментов.

А так можно было бы глянуть через RBCmd удалённые файлы, можно было бы найти там архив и его размер.

Также я решил ради любопытства глянуть где мог засветиться размер архива и можно было ли как-то ещё его узнать, не используя инструментов и не собирая размер заголовков и сжатых данных вручную. И вот что я нашёл:

Вот пища для размышлений. Удалённый файл оставил довольно много артефактов в дампе.

Выделен размер файла. В целом, если вы знаете название файла, можете попробовать поискать такие записи — вбиваете название файла, разделяя каждый символ байтом 0x00, отсчитываете 7 байт от первого символа и можете получить его размер. Есть шанс, что это сработает.

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

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

Ну вдобавок нашёл какие-то данные самого пользователя:

В письме злоумышленник представился как Lyoko и это позволило мне отыскать почту, с которой пришло письмо.

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

0х2 | Перечислить содержимое архива, содержащего вредоносный файл

см. 0х1

family_image.zip, family_image.obj

0х3 | Сколько нативных модулей было загружено во вредоносный процесс.

В первую очередь надо понять что есть нативный модуль. Процесс в Windows может использовать системные библиотеки.

Эти библиотеки могут быть написаны, к примеру, на С или каком-нибудь другом языке. Так вот, нативный модуль — это библиотека, написанная на С/С++, к примеру, которая скомпилирована в нативный машинный код, который выполняется процессором напрямую.

Чтобы упростить жизнь разработчикам ПО, Microsoft придумали также платформу .NET и CLR-модули (Common Language Runtime), которые в сущности позволяют писать какие-то программы на разных ЯП, а также дают кроссплатформенность. Но об этом лучше почитать в гугле самостоятельно.

Нативные модули лежат в C:\Windows\system32\

А CLR-модули лежат в C:\Windows\assembly\

Пока что это всё, что нужно знать.

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

Выполняем такую команду:

И получаем список из 102 модулей, включая сам mmc.exe

В списке есть 4 библиотеки, которые лежат в C:\Windows\assembly и являются CLR-модулями. Таким образом, получается 98 нативных модулей.

0х4 | Выяснить адреса сборки CLR-модулей которые были загружены во вредоносный процесс.

Из полученного списка мы можем увидеть 4 CLR-модуля:

mscorlib.ni.dll

System.ni.dll

System.Xml.ni.dll

SystemCore.ni.dll

Но задание намекает, что модулей 5. Вообще, я на этом этапе уже успел изучить отрывок MMC-файла и понял, что он подгружает ещё одну .dll в процессе выполнения и она, конечно же, не отображается в файловой системе. Что делать? На помощь приходит MemProcFS, который сразу сделает дампы процессов в разнообразных формах. Надо лишь забросить такой дамп в WinDbg, он умеет искать в дампах CLR-модули и может показать нам оставшийся модуль.

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

Кстати, если сделать дамп памяти процесса через Volatility2, то WinDbg почему то его не кушает и ругается, поэтому кроме как через MemProcFS других вариантов и не осталось.

Идём в \\MemProcFS\pid\3120\minidump и открываем minidump.dmp в WinDbg

Открываем View → Command

И вводим следующее:

!dumpdomain

Модуль SOS подгрузит информацию о CLR-модулях, которые присутствуют в дампе памяти процесса.

Получим ответ:

0000000004e62fd0,0000000004e630f0,0000000004f63690,0000000004f638d0,0000000004f63b10

0x5 | Выяснить название вредоносного модуля

Выгрузив информацию о CLR-модулях — там так же присутствуют и имена.

Модуль называется Ad00bce9305554c87927205710b17699f.dll

0x6 | Сдампить модуль и выяснить его хэш-сумму.

Чтобы всё это сделать, неплохо было бы восстановить сам файлик family_image.msc, точнее нагрузку, которую он в себе содержит, но в сыром дампе её строки разбросаны по кусочкам. В целом, вполне реально эти кусочки собрать — мне это удалось (не знаю, я просто решил посмотреть получится или нет). Поскольку сама нагрузка закодирована в URL и у меня было начало файла — я понял с чего начинается каждая строка, какая у неё длина. Строки обрывались на половине и чтобы понять какой фрагмент идёт следующим, я смотрел на байты файла в его раскодированном виде, искал окончание текущего фрагмента, после него сразу шли байты начала следующего. Но там ещё шеллкод довольно большой — это не самая лучшая затея.

И потому неплохо бы вспомнить про дампы виртуальной памяти — там целостность файла должна сохраниться более менее — это значит, что его можно скопировать просто без мучений. MemProcFS как раз делает такие дампы, но их много — и всё же это лучше, чем собирать файл по кусочкам из сырого дампа.

0x000000000006500000.vmem – это тот файлик, который нужен.

Открываем его в hex-редакторе и все, что лежит в выделенных мною скобочках, копируем.

Я раскодировал всё из URL просто через Burp, lol – там много декодеров есть, прям CyberChef – только десктопный и работает без интернета.

И перед нами предстаёт такая картина:

Я как-то не хотел по началу запускать VBScript и как-то копаться в нём — я саму .dll извлёк путём нехитрых манипуляций с удалением лишнего, декодировал Base64 в том же Burp, ну и просто все байты закинул в HxD. Чтобы это стало читабельно я ещё использовал экстрактор из DetectItEasy, потому что это не чистый бинарь — там ещё были «мусорные» байты в начале и в конце.

Ну и конечно я потом просто снял MD5 с получившегося файла

Хэш-сумма — e67f5692a35b8e40049e30ad04c12b41

0x7 | Выяснить какой ключ используется для XOR-шифрования строк во вредоносной .dll

Открываем этот файлик в dnSpy

Сразу в глаза бросаются какие-то манипуляции со строками, закодированными в Base64

На самом деле тут названия функций были обфусцированы — я просто попытался до этого придать им какие-то осмысленные названия.

Логику функции смотрим и сразу видим, что это XOR-шифрование строки и ключа, который указан как один из аргументов

Возвращаемся и видим ключ:

Ещё можно найти функцию, которая расшифровывает кучу строк:

Ключ там будет один и тот же — значит это то, что нам нужно для ответа.

Ключ для XOR-шифрования — a7ad965a-50b4-4846-bfb2-2282839f8d0c

0x8 | Выяснить IP-адрес C2-сервера, к которому подключается малварь

Чтобы это сделать, необходимо проанализировать шеллкод, который непосредственно всё это делает. Вредоносная .dll, которую я смотрел выше — собирает этот шеллкод и обеспечивает его работу в отдельном процессе, имеющем pid 7736 — процесс 3120 является для него родительским.

Начинается он так:

Ну и дальше идут 562 аналогичных строки, это всё размещается в переменных окружения на системе и оттуда .dll их подхватывает для сборки.

Мои попытки провернуть с шеллкодом всё то же самое, что и с вредоносной .dll, не увенчались успехом (хотя я вроде повторил процесс сборки, который был в .dll), потому придётся дебажить VBScript, который мы вырезали из дампа памяти процесса.

Процесс сборки выглядит так:

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

И у меня получилось слепить шеллкод, но почему-то в оригинале, который я получил потом, было на несколько /x00 байт больше — я так и не понял почему — судя по всему, где-то в процессе сборки эти байты добавляются.

Потому я пошёл другим путём — начал пытаться задебажить VBScript. Visual Studio наотрез отказывался мне в этом помогать, выкидывая разные ошибки о невозможности присоединиться к процессу, запущенному cscript, но я нашёл программу, которая помогла мне в дебаге — VBSEdit.

Добавляем строчку o.CreateInstance(entry_class), ставим на неё бряку, запускаем отладку, в DNSpy прикрепляемся к cscript.exe, под которым запускается скрипт (это часть WSH – Windows Script Host) — встроенного механизма отладки.

Шагаем до места в программе, которое идёт сразу после сборки шеллкода и сохраняем массив array как файл.

Ну и всё, что остаётся — проанализировать массив скриптом из GitHub (https://raw.githubusercontent.com/DidierStevens/DidierStevensSuite/refs/heads/master/1768.py)

Получаем IP-адрес и порт C2-сервера:

Это шеллкод от Cobalt Strike – стареющая классика.

0x9 | Снять MD5 хэш-сумму шеллкода

0xff | Эпилог

В завершении скажу, что это было самое сложное, что я когда-либо решал. Многое мне тут было в новинку — особенно разбираться с CLR-модулями и отладкой VBScript – это вам не нативные бинари реверсить. Опыта было получено колоссальное количество. Путь был длинный — это заняло около месяца — конечно, я не сидел сутками за задачей, но обычно со сложными задачами справляюсь максимум за неделю плотной работы, а тут пришлось сильно запотеть.

Атака, следы которой я искал в рамках данного задания, называется GrimResource, почитать поподробнее можно тут: https://www.elastic.co/security-labs/grimresource