withsecurelabs/callstackspooferتطبيق PoC لانتحال مكدسات استدعاءات عشوائية عند إجراء استدعاءات النظام (مثل الحصول على مقبض عبر NtOpenProcess)
يستعرض هذا المستودع تنفيذًا لإثبات المفهوم (PoC) لخداع أكوام استدعاءات عشوائية عند إجراء استدعاءات النظام. للحصول على شرح تقني كامل، يرجى الاطلاع على مقالة المدونة المصاحبة هنا: https://labs.withsecure.com/blog/spoofing-call-stacks-to-confuse-edrs.
بشكل افتراضي، يحتوي على ثلاث عينات من أكوام الاستدعاءات لمحاكاتها، ويمكن تحديدها عبر تمرير أي من --wmi أو --rpc أو --svchost، كما هو موضح أدناه:
تم الحصول على أكوام الاستدعاءات هذه عن طريق تشغيل SysMon مع تفعيل أحداث الوصول إلى العملية والبحث عن الأحداث التي كان فيها lsass هدفًا لعملية المقبض.
ملاحظة: ككلمة تحذير، تم اختبار هذا PoC على إصدار Windows التالي:
لم يتم اختباره على أي إصدارات أخرى، ومن الواضح أن الإزاحات قد تختلف (وبالتالي تتعطل) على إصدارات Windows المختلفة.
إذا واجهت مشكلة، فإن إحدى تقنيات تصحيح الأخطاء هي العثور على العملية التي تولّد أحداث OpenProcess في SysMon والارتباط بها في
WinDbg. بعد الارتباط، شغّل bp ntdll!NtOpenProcess وعندما يتم الوصول إلى bp قم بتشغيل knf.
سيعرض هذا مخرجات مشابهة لما يلي، والتي ستحتوي على تحليل الرموز الكامل ومساحة استخدام المكدس الصحيحة (المشار إليها بعمود 'Memory'):
0:003> knf
# Memory Child-SP RetAddr Call Site
00 00000037`f01fe300 00007ffd`221d2ea6 ntdll!NtOpenProcess+0x12
01 8 00000037`f01fe308 00007ffd`1ffee959 KERNELBASE!ProcessIdToSessionId+0x96
02 80 00000037`f01fe388 00007ffd`23b99633 lsm!RpcOpenEnum+0x129
03 430 00000037`f01fe7b8 00007ffd`23b33711 RPCRT4!Invoke+0x73
04 40 00000037`f01fe7f8 00007ffd`23bfd77b RPCRT4!Ndr64UnmarshallHandle+0xe1
05 70 00000037`f01fe868 00007ffd`23b7d2ac RPCRT4!Ndr64StubWorker+0xb0b
06 6c0 00000037`f01fef28 00007ffd`23b7a408 RPCRT4!NdrServerCallAll+0x3c
07 50 00000037`f01fef78 00007ffd`23b5a266 RPCRT4!DispatchToStubInCNoAvrf+0x18
08 50 00000037`f01fefc8 00007ffd`23b59bb8 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x1a6
09 e0 00000037`f01ff0a8 00007ffd`23b68a0f RPCRT4!RPC_INTERFACE::DispatchToStub+0xf8
0a 70 00000037`f01ff118 00007ffd`23b67e18 RPCRT4!LRPC_SCALL::DispatchRequest+0x31f
0b d0 00000037`f01ff1e8 00007ffd`23b67401 RPCRT4!LRPC_SCALL::HandleRequest+0x7f8
0c 110 00000037`f01ff2f8 00007ffd`23b66e6e RPCRT4!LRPC_ADDRESS::HandleRequest+0x341
0d a0 00000037`f01ff398 00007ffd`23b6b542 RPCRT4!LRPC_ADDRESS::ProcessIO+0x89e
0e 140 00000037`f01ff4d8 00007ffd`24ab0330 RPCRT4!LrpcIoComplete+0xc2
0f a0 00000037`f01ff578 00007ffd`24ae2f26 ntdll!TppAlpcpExecuteCallback+0x260
10 80 00000037`f01ff5f8 00007ffd`23387034 ntdll!TppWorkerThread+0x456
11 300 00000037`f01ff8f8 00007ffd`24ae2651 KERNEL32!BaseThreadInitThunk+0x14
12 30 00000037`f01ff928 00000000`00000000 ntdll!RtlUserThreadStart+0x21
كملاحظة، إجمالي مساحة المكدس المستخدمة من قبل موقع الاستدعاء الحالي موضّح في الصف أدناه (مثلًا، ntdll!NtOpenProcess يستهلك 8 بايت فقط). وكما ذُكر سابقًا، يتم تغطية شرح تقني كامل في المدونة المرتبطة في بداية هذا الملف، والتي ستشرح هذا (ومفاهيم مثل Child-SP) بمزيد من التفصيل. ويمكن بعد ذلك استخدام القيم التي يولّدها windbg للمقارنة مع ما يتم إرجاعه بواسطة CalculateFunctionStackSize() في حال وجود أي مشاكل.
نشكر مشروع unicorn_pe (https://github.com/hzqst/unicorn_pe) على الكود المثال في تحليل UNWIND_CODEs.