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 :

ID	Stream Type
0x00	UnusedStream
0x01	ReservedStream0
0x02	ReservedStream1
0x03	ThreadListStream
0x04	ModuleListStream
0x05	MemoryListStream
0x06	ExceptionStream
0x07	SystemInfoStream
0x08	ThreadExListStream
0x09	Memory64ListStream
0x0A	CommentStreamA
0x0B	CommentStreamW
0x0C	HandleDataStream
0x0D	FunctionTableStream
0x0E	UnloadedModuleListStream
0x0F	MiscInfoStream
0x10	MemoryInfoListStream
0x11	ThreadInfoListStream
0x12	HandleOperationListStream
0x13	TokenStream
0x16	HandleOperationListStream

---

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 :