NativeDump

NativeDump permet de dumper le processus lsass en utilisant uniquement des NTAPIs, générant un fichier Minidump avec uniquement les flux nécessaires pour être analysés par des outils comme Mimikatz ou Pypykatz (SystemInfo, ModuleList et Memory64List Streams).

• NTOpenProcessToken et NtAdjustPrivilegeToken pour obtenir le privilège « SeDebugPrivilege »
• RtlGetVersion pour obtenir les détails de la version du système d'exploitation (version majeure, version mineure et numéro de build). Cela est nécessaire pour le flux SystemInfo
• NtQueryInformationProcess et NtReadVirtualMemory pour obtenir l'adresse de lsasrv.dll. C'est le seul module nécessaire pour le flux ModuleList
• NtOpenProcess pour obtenir un handle du processus lsass
• NtQueryVirtualMemory et NtReadVirtualMemory pour parcourir les régions mémoire et dumper toutes celles possibles. En même temps, cela remplit le flux Memory64List

Le programme a un argument optionnel pour le fichier de sortie, le nom de fichier par défaut est "proc_<PID>.dmp" :

NativeDump.exe [DUMP_FILE]

L'outil a été testé sur les dernières versions de Windows avec les solutions de sécurité les plus courantes (Microsoft Defender for Endpoints, CrowdStrike...) et fonctionne bien, mais la furtivité dépendra de la « flavour » que vous choisissez : utilisez des langages peu courants et personnalisez les binaires pour de meilleurs résultats ! Cependant, il ne fonctionne pas si PPL est activé ou si la structure PEB n'est pas lisible. Mise à jour : Il est désormais possible d'exécuter les programmes sans lire la PEB, consultez la branche peb-unreadable :)

Certains avantages de cette technique sont :

• Elle n'utilise pas la fonction bien connue dbghelp!MinidumpWriteDump
• Elle utilise uniquement des fonctions de Ntdll.dll, il est donc possible de contourner le hooking d'API en remappant la bibliothèque
• Le fichier Minidump n'a pas besoin d'être écrit sur le disque, vous pouvez transférer ses octets (codés ou chiffrés) vers une machine distante

Vous pouvez trouver le projet dans différentes « flavours » (ou langages) :

• main - Implémentation .NET de base (cette branche)

• python-flavour - Implémentation Python avec 3 méthodes d'écrasement de ntdll.dll + Exfiltration vers machine distante

• golang-flavour - Implémentation Golang avec 3 méthodes d'écrasement de ntdll.dll + Exfiltration vers machine distante

• c-flavour - Implémentation C/C++ avec 3 méthodes d'écrasement de ntdll.dll

• bof-flavour - Fichier BOF avec 3 méthodes d'écrasement de ntdll.dll

• rust-flavour - Implémentation Rust par @safedv

• crystal-flavour - Implémentation Crystal avec capacités d'écrasement de ntdll.dll

• nim-flavour - Implémentation Nim avec capacités d'écrasement de ntdll.dll

Autres branches intéressantes utilisant .NET :

• remote - Exfiltration vers machine distante + 3 méthodes d'écrasement de ntdll.dll + Résolution dynamique de fonctions + Chiffrement AES des chaînes + Codage XOR du contenu Minidump

• all-modules - Obtenir les informations pour tous les modules (pas seulement lsasrv.dll)

• peb-unreadable - Implémentation sans lire la structure PEB de lsass + 3 méthodes d'écrasement de ntdll.dll

Technique en détail : Création d'un fichier Minidump minimal

Après avoir lu les structures non documentées de Minidump, sa structure peut se résumer à :

• En-tête : Informations comme la signature (« MDMP »), l'emplacement du répertoire des flux et le nombre de flux
• Répertoire des flux : Une entrée pour chaque flux, contenant le type, la taille totale et l'emplacement dans le fichier de chacun
• Flux : Chaque flux contient des informations différentes liées au processus et a son propre format
• Régions : Les octets réels du processus provenant de chaque région mémoire qui peuvent être lus

J'ai créé un outil d'analyse qui peut être utile : MinidumpParser. Nous nous concentrerons sur la création d'un fichier valide avec uniquement les valeurs nécessaires pour l'en-tête, le répertoire des flux et les 3 seuls flux nécessaires pour qu'un fichier Minidump soit analysé par Mimikatz/Pypykatz : SystemInfo, ModuleList et Memory64List Streams.

A. En-tête

L'en-tête est une structure de 32 octets qui peut être définie en C# comme suit :

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

Les valeurs requises sont :

• Signature : Valeur fixe 0x504d44d (chaîne « MDMP »)
• Version : Valeur fixe 0xa793 (constante Microsoft MINIDUMP_VERSION)
• NumberOfStreams : Valeur fixe 3, les trois flux requis pour le fichier
• StreamDirectoryRVA : Valeur fixe 0x20 ou 32 octets, la taille de l'en-tête

B. Répertoire des flux

Chaque entrée dans le répertoire des flux est une structure de 12 octets, donc avec 3 entrées, la taille est de 36 octets. La définition de la structure C# pour une entrée est :

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

Le champ « StreamType » représente le type de flux sous forme d'entier ou d'ID, certains des plus pertinents sont :

C. Flux SystemInformation

Le premier flux est un flux SystemInformation, avec l'ID 7. La taille est de 56 octets et sera située au décalage 68 (0x44), après le répertoire des flux. Sa définition C# est :

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

Les valeurs requises sont :

• ProcessorArchitecture : 9 pour les systèmes Windows 64 bits et 0 pour les systèmes 32 bits
• Version majeure, version mineure et BuildNumber : Codées en dur ou obtenues via kernel32!GetVersionEx ou ntdll!RtlGetVersion (nous utiliserons ce dernier)

D. Flux ModuleList

Le deuxième flux est un flux ModuleList, avec l'ID 4. Il est situé au décalage 124 (0x7C) après le flux SystemInformation et aura également une taille fixe de 112 octets, car il contiendra l'entrée d'un seul module, le seul nécessaire pour que l'analyse soit correcte : « lsasrv.dll ».

La structure typique de ce flux est une valeur de 4 octets contenant le nombre d'entrées suivie d'entrées de 108 octets pour chaque module :

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

Comme il n'y en a qu'un, cela se simplifie en :

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

Les valeurs requises sont :

• NumberOfStreams : Valeur fixe 1
• BaseAddress : En utilisant psapi!GetModuleBaseName ou une combinaison de ntdll!NtQueryInformationProcess et ntdll!NtReadVirtualMemory (nous utiliserons ce dernier)
• Size : Obtenu en ajoutant toutes les tailles de régions mémoire depuis BaseAddress jusqu'à une avec une taille de 4096 octets (0x1000), la section .text d'une autre bibliothèque
• PointerToName : Structure de chaîne Unicode pour la chaîne « C:\Windows\System32\lsasrv.dll », située après le flux lui-même au décalage 236 (0xEC)

E. Flux Memory64List

Le troisième flux est un flux Memory64List, avec l'ID 9. Il est situé au décalage 298 (0x12A), après le flux ModuleList et la chaîne Unicode, et sa taille dépend du nombre de modules.

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

Chaque entrée de module est une structure de 16 octets :

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

Les valeurs requises sont :

• NumberOfEntries : Nombre de régions mémoire, obtenu après avoir parcouru les régions mémoire
• MemoryRegionsBaseAddress : Emplacement du début des octets des régions mémoire, calculé après avoir ajouté la taille de toutes les entrées mémoire de 16 octets
• Address et Size : Obtenus pour chaque région valide lors de leur parcours

F. Parcourir les régions mémoire

Il y a des prérequis pour parcourir les régions mémoire du processus lsass.exe qui peuvent être résolus en utilisant uniquement des NTAPIs :

1. Obtenir la permission « SeDebugPrivilege ». Au lieu des typiques Advapi!OpenProcessToken, Advapi!LookupPrivilegeValue et Advapi!AdjustTokenPrivilege, nous utiliserons ntdll!NtOpenProcessToken, ntdll!NtAdjustPrivilegesToken et la valeur codée en dur 20 pour le Luid (qui est constante dans toutes les dernières versions de Windows)
2. Obtenir l'ID du processus. Par exemple, parcourir tous les processus en utilisant ntdll!NtGetNextProcess, obtenir l'adresse PEB avec ntdll!NtQueryInformationProcess et utiliser ntdll!NtReadVirtualMemory pour lire le champ ImagePathName dans ProcessParameters. Pour éviter de trop compliquer la PoC, nous utiliserons .NET's Process.GetProcessesByName(<PROCESS_NAME>)
3. Ouvrir un handle de processus. Utiliser ntdll!OpenProcess avec les permissions PROCESS_QUERY_INFORMATION (0x0400) pour récupérer les informations du processus et PROCESS_VM_READ (0x0010) pour lire les octets mémoire

Avec cela, il est possible de parcourir la mémoire du processus en appelant :

• ntdll!NtQueryVirtualMemory : Retourne une structure MEMORY_BASIC_INFORMATION avec le type de protection, l'état, l'adresse de base et la taille de chaque région mémoire
  • Si la protection mémoire n'est pas PAGE_NOACCESS (0x01) et que l'état mémoire est MEM_COMMIT (0x1000), c'est-à-dire qu'elle est accessible et validée, l'adresse de base et la taille remplissent une entrée du flux Memory64List et les octets peuvent être ajoutés au fichier
  • Si l'adresse de base correspond à l'adresse de base de lsasrv.dll, elle est utilisée pour calculer la taille de lsasrv.dll en mémoire
• ntdll!NtReadVirtualMemory : Ajouter les octets de cette région au fichier Minidump après le flux Memory64List

G. Créer le fichier Minidump

Après les étapes précédentes, nous avons tout ce qui est nécessaire pour créer le fichier Minidump. Nous pouvons créer un fichier localement ou envoyer les octets vers une machine distante, avec la possibilité de coder ou chiffrer les octets avant. Certaines de ces possibilités sont codées dans la branche delegates, où le fichier créé localement peut être codé avec XOR, et dans la branche remote, où le fichier peut être codé avec XOR avant d'être envoyé vers une machine distante.

TrickDump

Pour une approche alternative qui évite de créer un fichier Minidump, consultez TrickDump : il génère trois fichiers JSON et une archive ZIP, et le Minidump est reconstruit sur la machine de l'attaquant. Cela peut aider à contourner les solutions de sécurité qui surveillent la création ou l'exfiltration de Minidump.