NativeDump

NativeDump позволяет дампить процесс lsass, используя только NTAPI, создавая файл Minidump только с теми потоками, которые необходимы для анализа такими инструментами, как Mimikatz или Pypykatz (потоки SystemInfo, ModuleList и Memory64List).

• NTOpenProcessToken и NtAdjustPrivilegeToken для получения привилегии "SeDebugPrivilege"
• RtlGetVersion для получения деталей версии операционной системы (мажорная версия, минорная версия и номер сборки). Это необходимо для потока SystemInfo
• NtQueryInformationProcess и NtReadVirtualMemory для получения адреса lsasrv.dll. Это единственный модуль, необходимый для потока ModuleList
• NtOpenProcess для получения дескриптора процесса lsass
• NtQueryVirtualMemory и NtReadVirtualMemory для перебора областей памяти и дампа всех возможных. Одновременно заполняется поток Memory64List

Программа имеет один необязательный аргумент для выходного файла, имя файла по умолчанию — "proc_<PID>.dmp":

NativeDump.exe [DUMP_FILE]

Инструмент протестирован на последних версиях Windows с наиболее распространенными решениями безопасности (Microsoft Defender for Endpoints, CrowdStrike...) и работает нормально, но скрытность будет зависеть от выбранной "разновидности": используйте нестандартные языки и настраивайте бинарники для наилучших результатов! Однако он не работает, если включен PPL или структура PEB нечитаема. Обновление: теперь можно выполнять программы без чтения PEB, см. ветку peb-unreadable branch :)

Некоторые преимущества этой техники:

• Она не использует широко известную функцию dbghelp!MinidumpWriteDump
• Она использует только функции из Ntdll.dll, поэтому можно обойти перехват API, переотобразив библиотеку
• Файл Minidump не обязательно записывать на диск, можно передать его байты (закодированные или зашифрованные) на удаленную машину

Вы можете найти проект в различных "разновидностях" (или на разных языках):

• main — .NET базовая реализация (эта ветка)

• python-flavour — Реализация на Python с 3 методами перезаписи ntdll.dll + Экфильтрация на удаленную машину

• golang-flavour — Реализация на Golang с 3 методами перезаписи ntdll.dll + Экфильтрация на удаленную машину

• c-flavour — Реализация на C/C++ с 3 методами перезаписи ntdll.dll

• bof-flavour — BOF файл с 3 методами перезаписи ntdll.dll

• rust-flavour — Реализация на Rust от @safedv

• crystal-flavour — Реализация на Crystal с возможностями перезаписи ntdll.dll

• nim-flavour — Реализация на Nim с возможностями перезаписи ntdll.dll

Другие интересные ветки с использованием .NET:

• remote — Экфильтрация на удаленную машину + 3 метода перезаписи ntdll.dll + Динамическое разрешение функций + AES-шифрование строк + XOR-кодирование содержимого Minidump

• all-modules — Получение информации для всех модулей (не только lsasrv.dll)

• peb-unreadable — Реализация без чтения структуры PEB процесса lsass + 3 метода перезаписи ntdll.dll

Техника в деталях: Создание минимального файла Minidump

После изучения недокументированных структур Minidump его структуру можно свести к следующему:

• Заголовок: Информация, такая как сигнатура ("MDMP"), расположение каталога потоков и количество потоков
• Каталог потоков: Одна запись для каждого потока, содержащая тип, общий размер и расположение в файле каждого из них
• Потоки: Каждый поток содержит различную информацию о процессе и имеет свой собственный формат
• Регионы: Фактические байты процесса из каждой области памяти, которые можно прочитать

Я создал инструмент парсинга, который может быть полезен: MinidumpParser. Мы сосредоточимся на создании валидного файла только с необходимыми значениями для заголовка, каталога потоков и только 3 потоков, необходимых для того, чтобы файл Minidump был распарсен Mimikatz/Pypykatz: SystemInfo, ModuleList и Memory64List.

A. Заголовок

Заголовок представляет собой структуру размером 32 байта, которую можно определить в C# как:

public struct MinidumpHeader
{
    public uint Signature;
    public ushort Version;
    public ushort ImplementationVersion;
    public ushort NumberOfStreams;
    public uint StreamDirectoryRva;
    public uint CheckSum;
    public IntPtr TimeDateStamp;
}

Необходимые значения:

• Signature: Фиксированное значение 0x504d44d (строка "MDMP")
• Version: Фиксированное значение 0xa793 (константа Microsoft MINIDUMP_VERSION)
• NumberOfStreams: Фиксированное значение 3, три потока, необходимые для файла
• StreamDirectoryRVA: Фиксированное значение 0x20 или 32 байта, размер заголовка

B. Каталог потоков

Каждая запись в каталоге потоков представляет собой структуру размером 12 байт, поэтому при 3 записях размер составляет 36 байт. Определение структуры C# для записи:

public struct MinidumpStreamDirectoryEntry
{
    public uint StreamType;
    public uint Size;
    public uint Location;
}

Поле "StreamType" представляет тип потока в виде целого числа или ID, некоторые из наиболее важных:

C. Поток SystemInformation

Первый поток — это поток SystemInformation, с ID 7. Его размер составляет 56 байт, и он будет расположен по смещению 68 (0x44), после каталога потоков. Его определение в C#:

public struct SystemInformationStream
{
    public ushort ProcessorArchitecture;
    public ushort ProcessorLevel;
    public ushort ProcessorRevision;
    public byte NumberOfProcessors;
    public byte ProductType;
    public uint MajorVersion;
    public uint MinorVersion;
    public uint BuildNumber;
    public uint PlatformId;
    public uint UnknownField1;
    public uint UnknownField2;
    public IntPtr ProcessorFeatures;
    public IntPtr ProcessorFeatures2;
    public uint UnknownField3;
    public ushort UnknownField14;
    public byte UnknownField15;
}

Необходимые значения:

• ProcessorArchitecture: 9 для 64-битных и 0 для 32-битных систем Windows
• Major version, Minor version и BuildNumber: Жестко заданы или получены через kernel32!GetVersionEx или ntdll!RtlGetVersion (мы будем использовать последний)

D. Поток ModuleList

Второй поток — это поток ModuleList, с ID 4. Он расположен по смещению 124 (0x7C) после потока SystemInformation и также будет иметь фиксированный размер 112 байт, так как будет содержать запись только одного модуля, единственного, необходимого для корректного парсинга: "lsasrv.dll".

Типичная структура этого потока представляет собой 4-байтовое значение, содержащее количество записей, за которым следуют 108-байтовые записи для каждого модуля:

public struct ModuleListStream
{
    public uint NumberOfModules;
    public ModuleInfo[] Modules;
}

Поскольку запись только одна, это упрощается до:

public struct ModuleListStream
{
    public uint NumberOfModules;
    public IntPtr BaseAddress;
    public uint Size;
    public uint UnknownField1;
    public uint Timestamp;
    public uint PointerName;
    public IntPtr UnknownField2;
    public IntPtr UnknownField3;
    public IntPtr UnknownField4;
    public IntPtr UnknownField5;
    public IntPtr UnknownField6;
    public IntPtr UnknownField7;
    public IntPtr UnknownField8;
    public IntPtr UnknownField9;
    public IntPtr UnknownField10;
    public IntPtr UnknownField11;
}

Необходимые значения:

• NumberOfStreams: Фиксированное значение 1
• BaseAddress: Используя psapi!GetModuleBaseName или комбинацию ntdll!NtQueryInformationProcess и ntdll!NtReadVirtualMemory (мы будем использовать последнюю)
• Size: Получается сложением размеров всех областей памяти, начиная с BaseAddress, до тех пор, пока не встретится область размером 4096 байт (0x1000), секция .text другой библиотеки
• PointerToName: Структура строки Unicode для строки "C:\Windows\System32\lsasrv.dll", расположенная после самого потока по смещению 236 (0xEC)

E. Поток Memory64List

Третий поток — это поток Memory64List, с ID 9. Он расположен по смещению 298 (0x12A), после потока ModuleList и строки Unicode, и его размер зависит от количества модулей.

public struct Memory64ListStream
{
    public ulong NumberOfEntries; 
    public uint MemoryRegionsBaseAddress;
    public Memory64Info[] MemoryInfoEntries;
}

Каждая запись модуля представляет собой структуру размером 16 байт:

public struct Memory64Info
{
    public IntPtr Address;
    public IntPtr Size;
}

Необходимые значения:

• NumberOfEntries: Количество областей памяти, полученное после перебора областей памяти
• MemoryRegionsBaseAddress: Расположение начала байтов областей памяти, вычисленное после сложения размеров всех 16-байтовых записей памяти
• Address и Size: Получаются для каждой валидной области во время их перебора

F. Перебор областей памяти

Для перебора областей памяти процесса lsass.exe существуют предварительные требования, которые могут быть решены с использованием только NTAPI:

1. Получить разрешение "SeDebugPrivilege". Вместо типичных Advapi!OpenProcessToken, Advapi!LookupPrivilegeValue и Advapi!AdjustTokenPrivilege мы будем использовать ntdll!NtOpenProcessToken, ntdll!NtAdjustPrivilegesToken и жестко заданное значение 20 для Luid (которое является константой во всех последних версиях Windows)
2. Получить ID процесса. Например, перебрать все процессы с помощью ntdll!NtGetNextProcess, получить адрес PEB с помощью ntdll!NtQueryInformationProcess и использовать ntdll!NtReadVirtualMemory для чтения поля ImagePathName внутри ProcessParameters. Чтобы не усложнять PoC, мы будем использовать .NET's Process.GetProcessesByName(<PROCESS_NAME>)
3. Открыть дескриптор процесса. Использовать ntdll!OpenProcess с правами PROCESS_QUERY_INFORMATION (0x0400) для получения информации о процессе и PROCESS_VM_READ (0x0010) для чтения байтов памяти

С этим можно пройти по памяти процесса, вызывая:

• ntdll!NtQueryVirtualMemory: Возвращает структуру MEMORY_BASIC_INFORMATION с типом защиты, состоянием, базовым адресом и размером каждой области памяти
  • Если защита памяти не PAGE_NOACCESS (0x01) и состояние памяти MEM_COMMIT (0x1000), то есть она доступна и зафиксирована, базовый адрес и размер заполняют одну запись потока Memory64List, и байты могут быть добавлены в файл
  • Если базовый адрес равен базовому адресу lsasrv.dll, он используется для вычисления размера lsasrv.dll в памяти
• ntdll!NtReadVirtualMemory: Добавляет байты этой области в файл Minidump после потока Memory64List

G. Создание файла Minidump

После предыдущих шагов у нас есть все необходимое для создания файла Minidump. Мы можем создать файл локально или отправить байты на удаленную машину с возможностью предварительного кодирования или шифрования байтов. Некоторые из этих возможностей реализованы в ветке delegates branch, где файл, созданный локально, может быть закодирован с помощью XOR, и в ветке remote branch, где файл может быть закодирован с помощью XOR перед отправкой на удаленную машину.

TrickDump

Для альтернативного подхода, который позволяет избежать создания файла Minidump, посмотрите TrickDump: он генерирует три JSON-файла и ZIP-архив, а Minidump восстанавливается на машине атакующего. Это может помочь обойти решения безопасности, которые отслеживают создание или эксфильтрацию Minidump.