در بخشهای قبل از سری مقالات راهنمای جامع دور زدن EDR توسط بدافزارها، دیدیم که چگونه مهاجمان با تزریق در حافظه و حملات Fileless بسیاری از EDRهای سنتی را فریب میدهند.
در این بخش، سراغ یکی از پیشرفتهترین تکنیکهای EDR Evasion میرویم که برای متخصصان SOC و تیمهای Red Team همچون یک کابوس واقعی است:
Direct SyscallsوUnhooking
این روش، لایههای دفاعی مبتنی بر API Hooking را بهطور کامل بیاثر میکند و به مهاجم امکان میدهد بدون عبور از مسیرهای نظارتی، مستقیماً با هسته سیستمعامل (Kernel) تعامل داشته باشد.
مفهوم تکنیک Direct Syscalls و Unhooking
بسیاری از EDRها از API Hooking استفاده میکنند تا رفتارهای مشکوک را در سطح کاربر (User-Mode) زیر نظر بگیرند. به عنوان مثال، فراخوانیهایی مانند:
CreateProcess
VirtualAlloc
ReadFile
وقتی یک فرآیند این توابع را اجرا میکند، EDR میتواند رفتار را ثبت و تحلیل کند.
اما در تکنیک Direct Syscalls، مهاجم بهجای استفاده از این APIها، مستقیماً به System Call Numberها در سطح کرنل متصل میشود.
نتیجه؟ تمام Hookهایی که EDR در سطح User-Mode اعمال کرده، بیاثر میشوند.
از طرف دیگر، در Unhooking، مهاجم بهطور فعال Hookهای EDR را از حافظه حذف میکند یا DLLهای حیاتی مثل ntdll.dll را با نسخه تمیز جایگزین مینماید، تا EDR دیگر هیچ ردگیری نتواند انجام دهد.
چرا تکنیک Direct Syscalls و Unhooking مؤثر است؟
۱. عبور کامل از نظارت EDR (User-Mode Bypass)
بیشتر EDRها در User-Mode فعالیت میکنند و از طریق API Hooking، فراخوانیهای سیستمی مانند CreateProcess, VirtualAlloc, و NtWriteVirtualMemory را مانیتور میکنند.
اما Direct Syscalls این نظارت را کاملاً دور میزند:
✔️ مهاجم با استفاده از شماره Syscall ID مستقیماً دستور را به Kernel-Mode ارسال میکند، بدون اینکه مسیر Hook شده در User-Mode طی شود.
✔️ از آنجا که Context Switch مستقیم از User به Kernel انجام میشود، هیچ Event استانداردی در User-Mode ثبت نمیگردد که EDR بتواند روی آن تحلیل رفتاری انجام دهد.
این یعنی تمام لایههای نظارتی EDR که در سطح کاربر قرار دارند، عملاً بیاثر میشوند.
۲. پیچیدگی بالا و نیاز به دانش عمیق از معماری ویندوز
پیادهسازی Direct Syscalls و Unhooking نیازمند:
✔️ درک کامل از ساختار System Service Descriptor Table (SSDT)
✔️ شناسایی شماره دقیق Syscallها در نسخههای مختلف ویندوز
✔️ مدیریت Transition از User-Mode به Kernel-Mode بدون ایجاد Exception یا Crash
✔️ توانایی بازگردانی بایتهای اصلی Hook شده توسط EDR یا بارگذاری نسخه سالم از ntdll.dll در حافظه
این سطح از تخصص باعث میشود تنها گروههای APT یا مهاجمان پیشرفته بتوانند به شکل پایدار و مخفیانه از این تکنیک بهره ببرند.
۳. سکوت کامل در برابر ابزارهای امنیتی استاندارد
✔️ بسیاری از آنتیویروسها و EDRهای کلاسیک صرفاً رفتار APIهای User-Mode را بررسی میکنند و هیچ Visibility در سطح Kernel ندارند.
✔️ حتی ابزارهایی مثل Event Tracing for Windows (ETW) ممکن است فعالیت مستقیم Syscallها را ثبت نکنند، مگر بهطور خاص برای این منظور پیکربندی شوند.
Unhooking ✔️هم باعث میشود تمام Hookهایی که EDR روی توابع حساس قرار داده، حذف شود و رفتار مهاجم بهعنوان یک فعالیت قانونی سیستم دیده شود.
نتیجه:
ترکیب Direct Syscalls و Unhooking، باعث ایجاد یک لایه نامرئی از فعالیت مخرب میشود که نه تنها بسیاری از EDRها قادر به شناسایی آن نیستند، بلکه حتی ابزارهای مانیتورینگ استاندارد نیز هیچ ردپای آشکاری از آن مشاهده نمیکنند.
نحوه اجرای Direct Syscalls (اجرای مستقیم System Calls)
اجرای مستقیم Syscalls یک فرآیند چند مرحلهای است که هدف آن دور زدن APIهای User-Mode و Hookهای EDR است. مراحل کلیدی آن شامل:
۱. شناسایی شماره Syscall (Syscall Number) توابع هدف
هر تابع سطح بالا در ntdll.dll
(مثل NtAllocateVirtualMemory
، NtWriteVirtualMemory
یا NtCreateFile
) در نهایت به یک System Call Number نگاشت میشود که در جدول System Service Descriptor Table (SSDT) قرار دارد.
مهاجم با تکنیکهای زیر، شماره Syscall را پیدا میکند:
✔️ Reverse Engineering نسخههای مختلف ntdll.dll
✔️ استفاده از ابزارهایی مثل SysWhispers برای تولید هدرهای C/C++ که مستقیماً Syscallهای معتبر را بر اساس نسخه ویندوز ایجاد میکنند
✔️ تحلیل بایتکد اسمبلی توابع Nt*
برای استخراج شماره Syscall
۲. ساخت Stub اختصاصی در حافظه برای اجرای مستقیم
پس از شناسایی Syscall Number، یک Stub (قطعه کد اسمبلی کوچک) ساخته میشود که:
✔️ مستقیماً دستور syscall
را فراخوانی میکند
✔️ از رجیسترهای مناسب (مثل RCX
, R10
, R11
) برای پاس دادن پارامترهای لازم به Kernel استفاده میکند
✔️ از مسیرهای Hook شده (مثل APIهای Win32 یا User-Mode NTDLL) عبور نمیکند
نمونه اسمبلی ساده Stub :
mov r10, rcx
mov eax, [SyscallNumber]
syscall
ret
۳. اجرای تابع بدون عبور از APIهای User-Mode
در این مرحله:
✔️ فراخوانی مستقیم از User-Mode به Kernel-Mode انجام میشود، بدون اینکه تابعی در ntdll.dll
یا kernel32.dll
اجرا شود.
✔️ چون EDRها معمولاً Hookهای خود را در User-Mode قرار میدهند (در توابع NTDLL)، این مسیر کاملاً نامرئی میماند.
✔️ هیچ Event معمولی در سطح User ثبت نمیشود و حتی ابزارهایی مثل ETW یا Sysmon (بدون تنظیم خاص) ممکن است آن را مشاهده نکنند.
با این روش، مهاجم میتواند فعالیتهای حساس مانند تخصیص حافظه، نوشتن در حافظه فرآیندهای دیگر یا اجرای Remote Thread را بدون جلب توجه EDR انجام دهد.
روشهای متداول Unhooking
✔️ Restoring Original Bytes : بازگردانی بایتهای اصلی توابع Hook شده در حافظه.
✔️ Mapping Clean DLLs : بارگذاری نسخه سالم ntdll.dll و جایگزینی با نسخه آلوده در حافظه.
✔️ Inline Hook Removal : حذف مستقیم Hookهای Inline اعمالشده توسط EDR.
نمونههای واقعی از حملات Direct Syscalls و Unhooking
ابزار / بدافزار |
تکنیک استفادهشده |
جزئیات حمله |
SysWhispers |
Direct Syscalls |
ایجاد کد مخرب با دسترسی مستقیم به Syscalls بدون نیاز به API استاندارد |
Cobalt Strike |
Unhooking & Direct Syscalls |
استفاده از Unhooking هنگام اجرای Shellcode برای دور زدن EDR |
Sliver C2 |
Syscall-based Execution |
اجرای مستقیم Syscall برای فرار از ابزارهای تحلیل امنیتی |
ابزارهای معروف در این حوزه
✔️ SysWhispers / SysWhispers2
✔️ InlineWhispers
✔️ Heaven’s Gate (تکنیک معروف عبور از User/Kernel transition)
✔️ DIY Custom Syscall Stubs
چرا تکنیک Direct Syscalls و Unhooking برای EDRها کابوس است؟
۱. تعامل مستقیم با Kernel Transition Mechanisms
این تکنیک باعث میشود مهاجم از تمام لایههای نظارتی User-Mode عبور کند و بهطور مستقیم با Kernel ارتباط برقرار نماید.
از آنجا که اکثر EDRها Hookهای خود را در سطح توابع User-Mode (مانند ntdll.dll
) قرار میدهند، این انتقال مستقیم (Context Switch) به Kernel بدون عبور از مسیرهای Hook شده، عملاً دیده نمیشود.
۲. محدودیت دید EDR و نیاز به ابزارهای Kernel-Level
اکثر EDRهای سنتی برای نظارت روی فعالیتهای Kernel-Level طراحی نشدهاند. شناسایی رفتار Direct Syscalls و Unhooking تنها زمانی ممکن است که:
✔️ حسگرهای سطح Kernel یا درایورهای امنیتی اختصاصی فعال باشند
✔️ یا ابزارهای پیشرفتهای مثل Windows Kernel Debugging یا Hypervisor-based Monitoring مورد استفاده قرار گیرد
این یعنی تنها EDRهای نسل جدید یا ابزارهای EDR/XDR پیشرفته توانایی بررسی چنین حملاتی را دارند.
۳. اجرای عملیات مخرب بدون ثبت رویداد (Stealth Mode)
مهاجم میتواند تقریباً هر کاری را انجام دهد — از تزریق حافظه (Memory Injection) گرفته تا دستکاری فایلهای محافظتشده یا ایجاد Threadهای مخفی — بدون اینکه Event یا Logی در لایه User-Mode ثبت شود.
حتی ابزارهایی مثل Sysmon یا ETW، بدون تنظیمات بسیار دقیق، هیچ نشانهای از این فعالیتها را نخواهند دید.
راهکارها و اقدامات پیشگیرانه برای مدیران امنیت
اقدام |
شرح |
استفاده از EDRهای پیشرفته با Kernel Sensors |
EDRهای نسل جدید، رفتار Syscallهای غیرعادی را با حسگرهای Kernel-level تحلیل میکنند. |
فعالسازی HVCI (Hypervisor-Protected Code Integrity) |
محدودسازی شدید اجرای کدهای مشکوک در سطح حافظه. |
تحلیل دورهای Memory Dumps |
شناسایی Stubهای Syscall و Unhooking در حافظه توسط تیم Threat Hunting. |
آموزش SOC در شناسایی Unhooking |
توانایی تشخیص بارگذاری نسخههای تمیز DLLها یا تغییر در inline hooks. |
کنترل ابزارهای بالقوه مخرب |
محدودسازی اجرای ابزارهایی مانند SysWhispers در شبکه سازمان. |
جمعبندی تکنیک Direct Syscalls و Unhooking
این تکنیک، سطحی پیشرفته از حملات EDR Evasion را نمایش میدهد که ابزارهای امنیتی سنتی را بیاثر میکند.
تنها با نظارت Kernel-level، استفاده از قابلیتهایی مثل HVCI و تحلیلهای عمیق در سطح حافظه میتوان با این تهدید مقابله کرد.
ادامه مقاله:
در بخش بعدی، به سراغ LOLBins (Living-off-the-Land Binaries) خواهیم رفت؛ جایی که مهاجمان از ابزارهای قانونی ویندوز برای اهداف مخرب استفاده میکنند.
تکنیک چهارم: استفاده از ابزارهای قانونی سیستم (LOLBins)