NativeDump

NativeDump permite despejar o processo lsass usando apenas NTAPIs, gerando um arquivo Minidump com apenas os streams necessários para serem analisados por ferramentas como Mimikatz ou Pypykatz (SystemInfo, ModuleList e Memory64List Streams).

• NTOpenProcessToken e NtAdjustPrivilegeToken para obter o privilégio "SeDebugPrivilege"
• RtlGetVersion para obter os detalhes da versão do sistema operacional (versão principal, versão secundária e número de compilação). Isso é necessário para o SystemInfo Stream
• NtQueryInformationProcess e NtReadVirtualMemory para obter o endereço da lsasrv.dll. Este é o único módulo necessário para o ModuleList Stream
• NtOpenProcess para obter um handle para o processo lsass
• NtQueryVirtualMemory e NtReadVirtualMemory para percorrer as regiões de memória e despejar todas as possíveis. Ao mesmo tempo, preenche o Memory64List Stream

O programa tem um argumento opcional para o arquivo de saída, o nome padrão é "proc_<PID>.dmp":

NativeDump.exe [DUMP_FILE]

A ferramenta foi testada nas versões mais recentes do Windows com as soluções de segurança mais comuns (Microsoft Defender for Endpoints, CrowdStrike...) e funciona bem, mas a furtividade dependerá da "variante" que você escolher: use linguagens incomuns e personalize os binários para obter os melhores resultados! No entanto, não funciona se o PPL estiver ativado ou a estrutura PEB não for legível. Atualização: Agora é possível executar os programas sem ler o PEB, confira o branch peb-unreadable :)

Alguns benefícios desta técnica são:

• Não utiliza a conhecida função dbghelp!MinidumpWriteDump
• Utiliza apenas funções da Ntdll.dll, portanto é possível contornar o API hooking remapeando a biblioteca
• O arquivo Minidump não precisa ser escrito em disco, você pode transferir seus bytes (codificados ou criptografados) para uma máquina remota

Você pode encontrar o projeto em diferentes "variantes" (ou linguagens):

• main - .NET implementação básica (este branch)

• python-flavour - Python implementação com 3 métodos de sobrescrita da ntdll.dll + Exfiltração para máquina remota

• golang-flavour - Golang implementação com 3 métodos de sobrescrita da ntdll.dll + Exfiltração para máquina remota

• c-flavour - C/C++ implementação com 3 métodos de sobrescrita da ntdll.dll

• bof-flavour - Arquivo BOF com 3 métodos de sobrescrita da ntdll.dll

• rust-flavour - Rust implementação por @safedv

• crystal-flavour - Crystal implementação com capacidades de sobrescrita da ntdll.dll

• nim-flavour - Nim implementação com capacidades de sobrescrita da ntdll.dll

Outros branches interessantes usando .NET:

• remote - Exfiltração para máquina remota + 3 métodos de sobrescrita da ntdll.dll + Resolução dinâmica de funções + Criptografia AES de strings + Codificação XOR do conteúdo Minidump

• all-modules - Obtém as informações para todos os módulos (não apenas lsasrv.dll)

• peb-unreadable - Implementação sem ler a estrutura PEB do lsass + 3 métodos de sobrescrita da ntdll.dll

Técnica em detalhes: Criando um arquivo Minidump mínimo

Após ler as estruturas não documentadas do Minidump, sua estrutura pode ser resumida em:

• Cabeçalho: Informações como a Assinatura ("MDMP"), a localização do Diretório de Streams e o número de streams
• Diretório de Streams: Uma entrada para cada stream, contendo o tipo, tamanho total e localização no arquivo de cada um
• Streams: Cada stream contém diferentes informações relacionadas ao processo e possui seu próprio formato
• Regiões: Os bytes reais do processo de cada região de memória que pode ser lida

Criei uma ferramenta de análise que pode ser útil: MinidumpParser. Vamos nos concentrar em criar um arquivo válido com apenas os valores necessários para o cabeçalho, diretório de streams e os únicos 3 streams necessários para que um arquivo Minidump seja analisado por Mimikatz/Pypykatz: SystemInfo, ModuleList e Memory64List Streams.

A. Cabeçalho

O cabeçalho é uma estrutura de 32 bytes que pode ser definida em C# como:

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

Os valores necessários são:

• Signature: Valor fixo 0x504d44d (string "MDMP")
• Version: Valor fixo 0xa793 (constante Microsoft MINIDUMP_VERSION)
• NumberOfStreams: Valor fixo 3, os três Streams necessários para o arquivo
• StreamDirectoryRVA: Valor fixo 0x20 ou 32 bytes, o tamanho do cabeçalho

B. Diretório de Streams

Cada entrada no Diretório de Streams é uma estrutura de 12 bytes, portanto com 3 entradas o tamanho é 36 bytes. A definição da struct em C# para uma entrada é:

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

O campo "StreamType" representa o tipo de stream como um inteiro ou ID, alguns dos mais relevantes são:

C. SystemInformation Stream

O primeiro stream é um SystemInformation Stream, com ID 7. O tamanho é 56 bytes e estará localizado no offset 68 (0x44), após o Diretório de Streams. Sua definição em 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;
}

Os valores necessários são:

• ProcessorArchitecture: 9 para sistemas Windows de 64 bits e 0 para 32 bits
• Major version, Minor version e BuildNumber: Codificados ou obtidos através de kernel32!GetVersionEx ou ntdll!RtlGetVersion (usaremos este último)

D. ModuleList Stream

O segundo stream é um ModuleList stream, com ID 4. Ele está localizado no offset 124 (0x7C) após o SystemInformation stream e também terá um tamanho fixo de 112 bytes, pois conterá a entrada de um único módulo, o único necessário para a análise correta: "lsasrv.dll".

A estrutura típica para este stream é um valor de 4 bytes contendo o número de entradas seguido por entradas de 108 bytes para cada módulo:

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

Como há apenas um, fica simplificado para:

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;
}

Os valores necessários são:

• NumberOfStreams: Valor fixo 1
• BaseAddress: Usando psapi!GetModuleBaseName ou uma combinação de ntdll!NtQueryInformationProcess e ntdll!NtReadVirtualMemory (usaremos este último)
• Size: Obtido somando todos os tamanhos das regiões de memória desde BaseAddress até uma com tamanho de 4096 bytes (0x1000), a seção .text de outra biblioteca
• PointerToName: Estrutura de string Unicode para a string "C:\Windows\System32\lsasrv.dll", localizada após o próprio stream no offset 236 (0xEC)

E. Memory64List Stream

O terceiro stream é um Memory64List stream, com ID 9. Ele está localizado no offset 298 (0x12A), após o ModuleList stream e a string Unicode, e seu tamanho depende do número de módulos.

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

Cada entrada de módulo é uma estrutura de 16 bytes:

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

Os valores necessários são:

• NumberOfEntries: Número de regiões de memória, obtido após percorrer as regiões de memória
• MemoryRegionsBaseAddress: Localização do início dos bytes das regiões de memória, calculada após somar o tamanho de todas as entradas de memória de 16 bytes
• Address e Size: Obtidos para cada região válida enquanto as percorre

F. Percorrendo regiões de memória

Existem pré-requisitos para percorrer as regiões de memória do processo lsass.exe que podem ser resolvidos usando apenas NTAPIs:

1. Obter a permissão "SeDebugPrivilege". Em vez do típico Advapi!OpenProcessToken, Advapi!LookupPrivilegeValue e Advapi!AdjustTokenPrivilege, usaremos ntdll!NtOpenProcessToken, ntdll!NtAdjustPrivilegesToken e o valor codificado de 20 para o Luid (que é constante em todas as versões recentes do Windows)
2. Obter o ID do processo. Por exemplo, percorrer todos os processos usando ntdll!NtGetNextProcess, obter o endereço do PEB com ntdll!NtQueryInformationProcess e usar ntdll!NtReadVirtualMemory para ler o campo ImagePathName dentro de ProcessParameters. Para evitar complicar demais a PoC, usaremos .NET's Process.GetProcessesByName(<NOME_DO_PROCESSO>)
3. Abrir um handle do processo. Use ntdll!OpenProcess com permissões PROCESS_QUERY_INFORMATION (0x0400) para recuperar informações do processo e PROCESS_VM_READ (0x0010) para ler os bytes da memória

Com isso é possível percorrer a memória do processo chamando:

• ntdll!NtQueryVirtualMemory: Retorna uma estrutura MEMORY_BASIC_INFORMATION com o tipo de proteção, estado, endereço base e tamanho de cada região de memória
  • Se a proteção de memória não for PAGE_NOACCESS (0x01) e o estado da memória for MEM_COMMIT (0x1000), significando que é acessível e com commit, o endereço base e o tamanho preenchem uma entrada do Memory64List stream e os bytes podem ser adicionados ao arquivo
  • Se o endereço base for igual ao endereço base da lsasrv.dll, é usado para calcular o tamanho da lsasrv.dll na memória
• ntdll!NtReadVirtualMemory: Adiciona bytes daquela região ao arquivo Minidump após o Memory64List Stream

G. Criando o arquivo Minidump

Após as etapas anteriores, temos tudo o que é necessário para criar o arquivo Minidump. Podemos criar um arquivo localmente ou enviar os bytes para uma máquina remota, com a possibilidade de codificar ou criptografar os bytes antes. Algumas dessas possibilidades estão codificadas no branch delegates, onde o arquivo criado localmente pode ser codificado com XOR, e no branch remote, onde o arquivo pode ser codificado com XOR antes de ser enviado para uma máquina remota.

TrickDump

Para uma abordagem alternativa que evita criar um arquivo Minidump, confira TrickDump: ele gera três arquivos JSON e um arquivo ZIP, e o Minidump é reconstruído na máquina do atacante. Isso pode ajudar a evadir soluções de segurança que monitoram a criação ou exfiltração de Minidumps.