NativeDump

تتيح أداة NativeDump تفريغ عملية lsass باستخدام NTAPIs فقط، منتجة ملف Minidump يحتوي فقط على التدفقات اللازمة لتحليلها بواسطة أدوات مثل Mimikatz أو Pypykatz (تدفقات SystemInfo و ModuleList و Memory64List).

• استخدام NTOpenProcessToken و NtAdjustPrivilegeToken للحصول على صلاحية "SeDebugPrivilege"
• استخدام RtlGetVersion للحصول على تفاصيل إصدار نظام التشغيل (الرقم الرئيسي والرقم الثانوي ورقم البناء). هذا ضروري لتيار SystemInfo
• استخدام NtQueryInformationProcess و NtReadVirtualMemory للحصول على عنوان lsasrv.dll. هذه هي الوحدة الوحيدة اللازمة لتيار ModuleList
• استخدام NtOpenProcess للحصول على مقبض لعملية lsass
• استخدام NtQueryVirtualMemory و NtReadVirtualMemory للتكرار عبر مناطق الذاكرة وتفريغ جميع المناطق الممكنة. وفي الوقت نفسه، يتم ملء تيار Memory64List

يحتوي البرنامج على وسيط اختياري لملف الإخراج، واسم الملف الافتراضي هو "proc_.dmp":

NativeDump.exe [DUMP_FILE]

تم اختبار الأداة على أحدث إصدارات Windows مع الحلول الأمنية الأكثر شيوعًا (Microsoft Defender for Endpoints، CrowdStrike...) وتعمل بشكل جيد، لكن درجة التخفي ستعتمد على "النكهة" التي تختارها: استخدم لغات غير شائعة وخصص الثنائيات للحصول على أفضل النتائج! ومع ذلك، لا تعمل الأداة إذا كان PPL مفعّلاً أو إذا كانت بنية PEB غير قابلة للقراءة. تحديث: أصبح من الممكن الآن تنفيذ البرامج دون قراءة PEB، راجع فرع peb-unreadable :)

بعض فوائد هذه التقنية هي:

• لا تستخدم الدالة المعروفة dbghelp!MinidumpWriteDump
• تستخدم فقط دوال من Ntdll.dll، مما يتيح تجاوز ربط APIs عن طريق إعادة رسم خريطة المكتبة
• لا يلزم كتابة ملف 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 + تشفير محتوى Minidump بـ XOR

• all-modules - الحصول على معلومات جميع الوحدات (وليس فقط lsasrv.dll)

• peb-unreadable - تنفيذ دون قراءة بنية PEB لعملية lsass + 3 طرق لاستبدال ntdll.dll

تفصيل التقنية: إنشاء ملف Minidump أدنى

بعد قراءة هياكل Minidump غير الموثقة، يمكن تلخيص هيكلها إلى:

• الرأس: معلومات مثل التوقيع ("MDMP")، موقع دليل التدفقات وعدد التدفقات
• دليل التدفقات: إدخال لكل تدفق، يحتوي على النوع والحجم الكلي والموقع في الملف لكل منها
• التدفقات: يحتوي كل تدفق على معلومات مختلفة متعلقة بالعملية وله تنسيقه الخاص
• المناطق: البايتات الفعلية من العملية من كل منطقة ذاكرة يمكن قراءتها

لقد قمت بإنشاء أداة تحليل قد تكون مفيدة: MinidumpParser. سنركز على إنشاء ملف صالح يحتوي فقط على القيم الضرورية للرأس ودليل التدفقات والتدفقات الثلاثة الوحيدة اللازمة لملف Minidump لكي يتم تحليله بواسطة Mimikatz/Pypykatz: تدفقات SystemInfo و ModuleList و Memory64List.

أ. الرأس

الرأس هو هيكل بحجم 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 بايت، حجم الرأس

ب. دليل التدفقات

كل إدخال في دليل التدفقات هو هيكل بحجم 12 بايت، لذا بوجود 3 إدخالات يكون الحجم 36 بايت. تعريف C# للإدخال هو:

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

يمثل الحقل "StreamType" نوع التدفق كعدد صحيح أو معرف، بعض الأنواع الأكثر أهمية هي:

ج. تدفق معلومات النظام

التدفق الأول هو تدفق معلومات النظام (SystemInformation Stream) بالمعرف 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-bit، 0 للأنظمة 32-bit
• الرقم الرئيسي والرقم الثانوي ورقم البناء: إما مدمجة بشكل ثابت أو يتم الحصول عليها عبر kernel32!GetVersionEx أو ntdll!RtlGetVersion (سنستخدم الأخير)

د. تدفق قائمة الوحدات

التدفق الثاني هو تدفق قائمة الوحدات (ModuleList Stream) بالمعرف 4. يقع عند الإزاحة 124 (0x7C) بعد تدفق معلومات النظام، وسيكون له حجم ثابت 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)

ه. تدفق قائمة الذاكرة 64

التدفق الثالث هو تدفق قائمة الذاكرة 64 (Memory64List Stream) بالمعرف 9. يقع عند الإزاحة 298 (0x12A)، بعد تدفق قائمة الوحدات وسلسلة 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: يتم الحصول عليهما لكل منطقة صالحة أثناء التكرار

و. التكرار على مناطق الذاكرة

هناك متطلبات مسبقة للتكرار على مناطق الذاكرة لعملية lsass.exe يمكن حلها باستخدام NTAPIs فقط:

1. الحصول على صلاحية "SeDebugPrivilege". بدلاً من استخدام Advapi!OpenProcessToken و Advapi!LookupPrivilegeValue و Advapi!AdjustTokenPrivilege النموذجية، سنستخدم ntdll!NtOpenProcessToken و ntdll!NtAdjustPrivilegesToken والقيمة الثابتة 20 لـ Luid (وهي ثابتة في جميع إصدارات Windows الحديثة)
2. الحصول على معرف العملية. على سبيل المثال، التكرار على جميع العمليات باستخدام ntdll!NtGetNextProcess، ثم الحصول على عنوان PEB باستخدام ntdll!NtQueryInformationProcess واستخدام ntdll!NtReadVirtualMemory لقراءة الحقل ImagePathName داخل ProcessParameters. لتجنب تعقيد الإثبات، سنستخدم طريقة .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

ز. إنشاء ملف Minidump

بعد الخطوات السابقة، لدينا كل ما هو ضروري لإنشاء ملف Minidump. يمكننا إنشاء ملف محليًا أو إرسال البايتات إلى جهاز بعيد، مع إمكانية تشفير أو ترميز البايتات قبل ذلك. بعض هذه الاحتمالات مبرمجة في فرع delegates، حيث يمكن تشفير الملف الذي تم إنشاؤه محليًا باستخدام XOR، وفي فرع remote، حيث يمكن تشفير الملف باستخدام XOR قبل إرساله إلى جهاز بعيد.

TrickDump

للحصول على نهج بديل يتجنب إنشاء ملف Minidump، تحقق من TrickDump: فهو يُنشئ ثلاثة ملفات JSON وأرشيف ZIP، ثم يتم إعادة بناء Minidump على جهاز المهاجم. يمكن أن يساعد هذا في تجنب الحلول الأمنية التي تراقب إنشاء أو نقل Minidump.