درس Detection Engineering از CVE-2018-8440؛ چرا ALPC مهمتر از آن چیزی است که فکر میکنیم؟
وقتی از مکانیزمهای ارتباط بین پردازشها (IPC) در ویندوز صحبت میشود، اغلب متخصصان امنیت به Named Pipe فکر میکنند. دلیل آن هم روشن است؛ Named Pipe در بسیاری از ابزارهای تهاجمی مانند Cobalt Strike، PsExec و برخی بدافزارها بهکار میرود و Sysmon نیز رویدادهای مشخصی برای آن تولید میکند. اما در لایههای عمیقتر ویندوز، مکانیزم دیگری وجود دارد که کمتر دیده میشود و در عین حال نقشی حیاتی در عملکرد سیستمعامل دارد: Advanced Local Procedure Call (ALPC).
ALPC کانال ارتباطی داخلی ویندوز برای تبادل پیام بین سرویسها، پردازشهای کاربری و حتی مؤلفههای کرنل است. بسیاری از سرویسهای حیاتی ویندوز برای سرعت و کارایی بیشتر از ALPC استفاده میکنند. به همین دلیل، اگر در این مکانیزم نقصی امنیتی وجود داشته باشد، پیامد آن معمولاً بسیار جدی خواهد بود.
یکی از مشهورترین نمونههای تاریخی، آسیبپذیری CVE-2018-8440 بود که در سال ۲۰۱۸ توسط پژوهشگری با نام مستعار SandboxEscaper افشا شد. این آسیبپذیری مربوط به نحوه تعامل Windows Task Scheduler با ALPC بود. مشکل اصلی این بود که یک کاربر با سطح دسترسی عادی میتوانست از طریق فراخوانیهای خاص ALPC، مجوزهای فایلهای سیستمی را تغییر دهد و در نهایت کد خود را با سطح دسترسی SYSTEM اجرا کند. این یک نمونه کلاسیک از Local Privilege Escalation (LPE) بود؛ یعنی مهاجم پس از بهدست آوردن دسترسی اولیه، بدون دانستن رمز عبور مدیر یا سوءاستفاده از آسیبپذیری کرنل، کنترل کامل سیستم را به دست میآورد.
نکته جالب اینجاست که تنها چند روز پس از انتشار عمومی این آسیبپذیری، گروه مهاجمی با نام PowerPool آن را در حملات واقعی به کار گرفت. آنها حتی از همان کد منتشرشده استفاده نکردند، بلکه نسخه اختصاصی خود را توسعه دادند. این اتفاق نشان داد که فاصله میان انتشار یک آسیبپذیری و تبدیل آن به سلاح عملیاتی میتواند بسیار کوتاه باشد.
اما این مثال از دیدگاه Detection Engineering حتی از خود آسیبپذیری مهمتر است.
بسیاری از تحلیلگران SOC هنگام شنیدن نام ALPC، اولین سؤالشان این است: کدام Event ID آن را نشان میدهد؟ پاسخ ناامیدکننده است؛ برخلاف Named Pipe که Sysmon برای ایجاد و اتصال Pipe رویدادهای مستقلی دارد، ALPC چنین لاگ مستقیمی تولید نمیکند. بنابراین اگر Detection Engineer بخواهد صرفاً بر اساس مشاهده ALPC حمله را کشف کند، تقریباً شکست خواهد خورد.
اینجاست که فلسفه Detection Engineering تغییر میکند.
Detection Engineer به جای تمرکز بر ابزار یا API، بر رفتار مهاجم تمرکز میکند. در سناریوی CVE-2018-8440، مهم نیست که مهاجم از ALPC استفاده کرده یا از مکانیزم دیگری؛ مهم این است که در پایان زنجیره حمله، رفتارهای غیرعادی رخ میدهد.
برای مثال:
یک پردازش با سطح دسترسی معمولی ناگهان باعث اجرای فرآیندی با سطح SYSTEM میشود.
پردازشهایی مانند cmd.exe، powershell.exe یا rundll32.exe توسط یک فرآیند غیرمنتظره و با سطح SYSTEM اجرا میشوند.
فایلها یا تنظیمات مربوط به Task Scheduler بهطور غیرعادی تغییر میکنند.
زنجیره Parent-Child Process با الگوهای معمول ویندوز سازگار نیست.
EDR تغییر ناگهانی Integrity Level یا Token را گزارش میکند.
بنابراین Detection واقعی نه بر اساس مشاهده ALPC، بلکه بر اساس همبستگی چندین منبع داده انجام میشود. این همان تفاوت اساسی میان یک Rule ساده و یک Detection حرفهای است.
فرض کنید مهاجم از یک آسیبپذیری ALPC استفاده کرده است. اگر Rule شما فقط به دنبال API خاصی باشد، با تغییر نسخه ویندوز یا روش اکسپلویت احتمالاً دیگر کار نخواهد کرد. اما اگر Rule شما بر پایه رفتارهایی مانند ارتقای غیرمنتظره سطح دسترسی، ایجاد فرآیندهای SYSTEM، تغییرات حساس در فایلهای سیستمی و زنجیره غیرعادی اجرای پردازشها طراحی شده باشد، حتی اگر روش سوءاستفاده تغییر کند، Detection همچنان معتبر خواهد بود.
این دقیقاً همان فلسفهای است که امروز در Detection Engineering مدرن دنبال میشود؛ یعنی تشخیص رفتار، نه تشخیص ابزار.
به همین دلیل در SOCهای بالغ، Detection Engineer تنها نویسنده Rule نیست. او ابتدا تکنیک مهاجم را مطالعه میکند، سپس Telemetryهای موجود را بررسی میکند، شکافهای مشاهدهپذیری (Visibility Gaps) را شناسایی میکند و در نهایت Detectionهایی طراحی میکند که در برابر تغییر ابزار یا IOC مقاوم باشند.
ماجرای CVE-2018-8440 یک درس مهم دیگر نیز دارد. بسیاری از سازمانها تصور میکنند اگر Event مستقیمی برای یک فناوری وجود نداشته باشد، امکان Detection نیز وجود ندارد. اما واقعیت این است که در بسیاری از حملات پیشرفته، مهمترین بخش حمله اصلاً لاگ تولید نمیکند. هنر Detection Engineer این است که از روی اثرات جانبی، زنجیره حمله را بازسازی کند.
به همین دلیل است که امروزه Detection Engineering بیش از آنکه یک مهارت در نوشتن Rule باشد، علم طراحی قابلیت تشخیص (Detection Capability Design) محسوب میشود. متخصص این حوزه بهجای پرسیدن «این حمله چه Event IDای دارد؟» سؤال مهمتری میپرسد:
«اگر مهاجم این تکنیک را اجرا کند، چه رفتارهایی در سیستم باقی میماند که بتوان آنها را با اطمینان تشخیص داد؟»
همین تغییر زاویه نگاه، Detection Engineering را به یکی از تخصصیترین و ارزشمندترین گرایشهای امنیت سایبری در SOCهای مدرن تبدیل کرده است.
تفاوت نقشهای L1 تا L3 با Threat Detection Engineer
SOC Analyst L1
اولین خط دفاع SOC است.
Alertها را پایش، دستهبندی و اعتبارسنجی اولیه میکند.
وظیفه اصلی او تشخیص اولیه و Escalation رخدادها است.
SOC Analyst L2
رخدادهای ارجاعشده از L1 را بهصورت فنی تحلیل میکند.
علت حمله، دامنه آلودگی و اقدامات مهار اولیه را بررسی میکند.
با لاگها، EDR و شواهد فنی کار میکند.
SOC Analyst L3 / Threat Hunter
بهدنبال حملاتی میگردد که هنوز Alert تولید نکردهاند.
رفتار مهاجم، TTPها و ریشه حادثه را تحلیل میکند.
خروجی او معمولاً فرضیههای شکار تهدید و پیشنهادهای بهبود Detection است.
Threat Detection Engineer
برخلاف سه نقش قبلی، تمرکز او روی Incident نیست، بلکه روی ساخت قابلیت تشخیص است.
Detection Ruleها را طراحی، توسعه، تست، اعتبارسنجی و بهینهسازی میکند.
Detection Coverage را اندازهگیری کرده و شکافهای تشخیص را شناسایی میکند.
از روشهایی مانند Detection as Code، Sigma، Git، Purple Team و MITRE ATT&CK برای توسعه Detectionها استفاده میکند.
تفاوت اساسی
تحلیلگران L1 تا L3 با Alertهایی که امروز تولید شدهاند کار میکنند.
اما Threat Detection Engineer کاری میکند که Alertهای فردا دقیقتر، سریعتر و با خطای کمتر تولید شوند.
به همین دلیل، امروزه در SOCهای پیشرفته، Threat Detection Engineering یک گرایش تخصصی مستقل محسوب میشود؛ نقشی که بین Threat Hunting، مهندسی SIEM و معماری SOC قرار میگیرد و مسئول ارتقای مستمر توان تشخیص سازمان است.
