شکار Web Shell در سرورها با ترکیب فایل، Process و شبکه

مفاهیم و تهدید Web Shell

وب‌شل‌ها اسکریپت‌های مخربی هستند که مهاجمان روی سرورهای وب در دسترس قرار می‌دهند تا از طریق آن‌ها به عنوان دروازه‌ای برای دسترسی به شبکه داخلی استفاده کنند. این ابزارها معمولاً به صورت فایل‌هایی با پسوندهای رایج مانند ASPX، PHP یا JSP نوشته می‌شوند و می‌توانند مجموعه‌ای از توابع اجرای فرمان یا یک رابط خط فرمان را روی سرور میزبان فراهم کنند. بر اساس دانشنامه MITRE ATT&CK، این تکنیک با شناسه T1505.003 در دسته مؤلفه‌های نرم‌افزار سرور قرار می‌گیرد و هدف اصلی آن ایجاد دسترسی پایدار (Persistence) در سامانه است.

وب‌شل‌ها معمولاً پس از بهره‌برداری از آسیب‌پذیری‌های سرویس‌های وب یا سرویس‌های ایمیل مانند Exchange مستقر می‌شوند. نمونه‌های شناخته‌شده شامل China Chopper، ASPXSpy و reGeorg هستند که در حملات گروه‌های تهدید مختلف مانند APT28، HAFNIUM و Sandworm مشاهده شده‌اند. این گروه‌ها از وب‌شل‌ها برای حفظ دسترسی، اجرای فرمان، جابه‌جایی جانبی و حتی تونل‌سازی پروتکل استفاده می‌کنند. با این حال، جزئیات فنی دقیق این نمونه‌ها فراتر از محدوده این مقاله است و صرفاً به عنوان مثال‌هایی از تهدیدات واقعی ذکر می‌شوند.

از دیدگاه دفاعی، شناسایی وب‌شل‌ها به دلیل ماهیت پنهان‌کار آن‌ها چالش‌برانگیز است. مهاجمان اغلب وب‌شل‌ها را با نام‌های بی‌ضرر در میان فایل‌های معتبر سرور جاسازی می‌کنند و ممکن است از روش‌های مبهم‌سازی برای فرار از امضای آنتی‌ویروس استفاده کنند. بنابراین، صرف اتکا به شناسایی مبتنی بر امضا کافی نیست و نیاز به رویکردی ترکیبی شامل بررسی فایل، فرآیند و ترافیک شبکه وجود دارد. در ادامه، روش‌های عملی برای شکار وب‌شل با استفاده از این سه منبع داده ارائه می‌شود.

• وب‌شل به عنوان ابزار دسترسی پایدار در MITRE ATT&CK با شناسه T1505.003 ثبت شده است.
• انواع رایج شامل ASPX، PHP و JSP هستند که روی پلتفرم‌های ویندوز و لینوکس اجرا می‌شوند.
• گروه‌های تهدید متعددی از جمله APT28 و HAFNIUM از وب‌شل‌ها در حملات واقعی استفاده کرده‌اند.

شواهد و تله‌متری‌های ترکیبی

برای شناسایی مؤثر Web Shell، نباید به یک منبع داده واحد اکتفا کرد؛ بلکه ترکیب شواهد از سه حوزه فایل، فرآیند و شبکه، دید جامع‌تری ارائه می‌دهد. در حوزه فایل، تغییرات غیرمنتظره در فایل‌های وب‌سرور (مانند اسکریپت‌های PHP، ASPX یا JSP) که خارج از فرآیند استقرار نرم‌افزار رخ می‌دهند، می‌تواند نشانه‌ای از نفوذ باشد. این تغییرات شامل ایجاد فایل‌های جدید، تغییر زمان‌بندی فایل‌ها، یا افزایش حجم غیرعادی در دایرکتوری‌های عمومی وب است. همچنین وجود فایل‌هایی با محتوای رمزنگاری‌شده یا مبهم، که تشخیص آن‌ها با بازبینی ساده ممکن نیست، باید به‌عنوان یک هشدار جدی در نظر گرفته شود.

در حوزه فرآیند، اجرای فرآیندهای غیرعادی توسط وب‌سرور (مانند اجرای مفسرهای خط فرمان، اسکریپت‌های کمکی یا ابزارهای مدیریتی) که در شرایط عادی توسط وب‌سرور فراخوانی نمی‌شوند، می‌تواند نشانه فعالیت Web Shell باشد. برای مثال، اگر وب‌سرور به‌طور ناگهانی فرآیندی مانند cmd یا bash را اجرا کند، این رفتار باید به‌عنوان یک رویداد مشکوک ثبت و بررسی شود. همچنین، تداوم اجرای فرآیندهای کوتاه‌مدت و متوالی که با الگوی درخواست‌های وب هماهنگ هستند، می‌تواند نشانه اجرای دستورات از طریق Web Shell باشد.

در حوزه شبکه، ارتباطات خروجی غیرعادی از وب‌سرور به آدرس‌های IP یا دامنه‌های ناشناخته، به‌ویژه در پورت‌های غیراستاندارد یا با پروتکل‌های غیرمعمول، می‌تواند نشانه برقراری کانال فرمان‌دهی و کنترل باشد. همچنین، الگوهای ترافیکی که با رفتار کاربران عادی همخوانی ندارد، مانند ارسال حجم زیادی از داده به یک مقصد خاص در زمان‌های کوتاه، باید مورد توجه قرار گیرد. ترکیب این شواهد با یکدیگر، امکان تشخیص دقیق‌تر و کاهش مثبت کاذب را فراهم می‌کند.

• تغییرات فایل‌های وب خارج از چرخه استقرار مجاز
• اجرای فرآیندهای غیرعادی توسط وب‌سرور
• ارتباطات شبکه خروجی به مقاصد ناشناخته
• همبستگی زمانی بین درخواست‌های وب و اجرای فرآیند

1. جمع‌آوری منظم هش‌های فایل‌های وب و مقایسه با پایگاه مرجع
2. ثبت و پایش فرآیندهای مرتبط با وب‌سرور و زیرفرآیندهای آن
3. تحلیل ترافیک شبکه وب‌سرور برای شناسایی ارتباطات غیرعادی
4. ایجاد هشدارهای ترکیبی که چندین شاهد را به‌طور همزمان بررسی می‌کنند

گردش کار شناسایی گام‌به‌گام

شکار وب‌شل نیازمند نگاهی ترکیبی به سه لایهٔ فایل، فرآیند و شبکه است. هیچ‌یک از این لایه‌ها به تنهایی نمی‌تواند تصویر کاملی از فعالیت مخرب ارائه دهد؛ اما همبستگی میان نشانه‌های ضعیف در هر لایه، احتمال وجود وب‌شل را به‌طور معناداری افزایش می‌دهد. در این گردش کار، ابتدا با شناسایی نامزدهای اولیه از طریق تحلیل فایل شروع می‌کنیم، سپس با بررسی فرآیندهای در حال اجرا و در نهایت با ردیابی ارتباطات شبکه، نامزدها را تأیید یا رد می‌کنیم.

رویکرد پیشنهادی بر پایهٔ فرضیه‌سازی و آزمون است. به این معنا که هر نشانهٔ مشاهده‌شده در یک لایه، باید با شواهد مکمل در لایه‌های دیگر همراه شود تا به یک نتیجهٔ مطمئن برسیم. برای مثال، وجود یک فایل اسکریپت با محتوای مبهم به تنهایی کافی نیست؛ بلکه باید بررسی شود که آیا این فایل توسط فرآیند وب‌سرور بارگذاری شده و آیا ارتباط شبکه‌ای غیرعادی از همان فرآیند برقرار شده است. این همبستگی، خطای مثبت کاذب را کاهش می‌دهد و به تحلیلگر امکان می‌دهد تا اولویت‌بندی دقیقی برای پاسخ‌گویی داشته باشد.

در این راهنما، از ذکر ابزارها یا دستورات خاص خودداری شده و تمرکز بر مفاهیم و مراحل منطقی است. تحلیلگران باید بر اساس محیط خود، ابزارهای مناسب را انتخاب کنند. همچنین تمامی مراحل باید با در نظر گرفتن ملاحظات قانونی و مجوزهای لازم انجام شود.

• مرحله ۱: شناسایی نامزدهای فایل‌محور - فایل‌های اسکریپت تازه ایجادشده یا تغییر یافته در مسیرهای وب را با تمرکز بر پسوندهای رایج (مانند asp، php، jsp) بررسی کنید. به فایل‌هایی با نام‌های غیرعادی، محتوای مبهم یا کدهای رمزنگاری‌شده توجه ویژه داشته باشید.
• مرحله ۲: پالایش با تحلیل فرآیند - فرآیندهای وب‌سرور را زیر نظر بگیرید و هرگونه رفتار غیرعادی مانند اجرای مفسرهای خط فرمان، ایجاد اتصالات خروجی یا بارگذاری کتابخانه‌های غیرمنتظره را ثبت کنید. ارتباط بین فایل نامزد و فرآیند مربوطه را بررسی کنید.
• مرحله ۳: تأیید نهایی با داده‌های شبکه - اتصالات شبکه‌ای که از فرآیند وب‌سرور به آدرس‌های ناشناخته یا غیرمعمول برقرار می‌شود را ردیابی کنید. الگوهای ترافیکی مانند ارسال منظم داده به یک مقصد خاص یا استفاده از پروتکل‌های غیراستاندارد را به عنوان نشانهٔ مکمل در نظر بگیرید.

1. فهرستی از فایل‌های اسکریپت موجود در دایرکتوری ریشهٔ وب تهیه کنید و آن را با خروجی سیستم مدیریت پیکربندی یا نسخهٔ پشتیبان مقایسه کنید.
2. برای هر فایل نامزد، امتیاز ریسک بر اساس عواملی مانند قدمت، اندازه، محتوای مبهم و سطح دسترسی تعیین کنید.
3. فرآیندهای مرتبط با وب‌سرور را شناسایی کرده و تاریخچهٔ اجرای آن‌ها را بررسی کنید؛ به دنبال فرآیندهای فرزندی باشید که از مسیر وب اجرا شده‌اند.
4. برای هر نامزد تأییدشده، اتصالات شبکهٔ فعال و گذشته را بازبینی کنید و آدرس‌های مقصد را با لیست‌های مجاز مقایسه کنید.
5. در صورت وجود شواهد کافی، نامزد را به عنوان وب‌شل قطعی علامت‌گذاری کرده و برای پاسخ‌گویی به تیم مربوطه ارجاع دهید.

غربالگری و اولویت‌بندی هشدارها

در فرآیند شکار وب‌شل، مواجهه با حجم بالایی از هشدارهای امنیتی امری رایج است. بسیاری از این هشدارها ناشی از فعالیت‌های عادی سرویس‌دهنده یا پیکربندی‌های نادرست هستند و ارزش بررسی عمیق ندارند. بنابراین، نخستین گام، طراحی یک سیستم غربالگری است که بر اساس معیارهای مشخص، هشدارهای کم‌اهمیت را حذف کرده و موارد پرخطر را برای تحلیل تخصصی نگه دارد. این معیارها باید به‌گونه‌ای عمومی تعریف شوند که با داده‌های خاص هر سازمان سازگار باشند و در عین حال، توانایی شناسایی رفتارهای غیرعادی را داشته باشند.

یکی از مهم‌ترین معیارهای اولویت‌بندی، میزان دسترس‌پذیری فایل مشکوک است. فایل‌هایی که در مسیرهای عمومی وب قرار دارند و از طریق پروتکل HTTP قابل دسترسی هستند، نسبت به فایل‌های موجود در دایرکتوری‌های خصوصی، خطر بیشتری دارند. همچنین سطح امتیاز فرآیندی که فایل را اجرا می‌کند، اهمیت دارد؛ فرآیندهایی که با حساب‌های پرامتیاز (مانند root یا Administrator) اجرا می‌شوند، در صورت بهره‌برداری، خسارت بیشتری می‌توانند وارد کنند. بنابراین، ترکیب این دو معیار (دسترس‌پذیری و سطح امتیاز) می‌تواند شاخص مناسبی برای اولویت‌بندی باشد.

علاوه بر این، باید به رفتارهای فرآیند و ارتباطات شبکه‌ای نیز توجه کرد. برای مثال، فرآیندی که به‌طور غیرمنتظره اقدام به ایجاد اتصال خروجی به آدرس‌های ناشناخته می‌کند یا دستورات پوسته را اجرا می‌کند، در مقایسه با فرآیندی که صرفاً به‌عنوان یک اسکریپت معمولی عمل می‌کند، در اولویت بالاتری قرار می‌گیرد. همچنین، تغییرات ناگهانی در محتوای فایل‌های وب یا ایجاد فایل‌های جدید با پسوندهای غیرمعمول (مانند .asp، .php، .jsp) در دایرکتوری‌های حساس، باید به‌عنوان سیگنال هشدار در نظر گرفته شود.

برای کاهش نویز، پیشنهاد می‌شود که یک سیستم امتیازدهی پویا پیاده‌سازی شود که به هر هشدار بر اساس معیارهای فوق امتیاز دهد. هشدارهایی که امتیاز آن‌ها از آستانه مشخصی بالاتر است، به‌صورت خودکار برای تحلیل عمیق به تیم امنیتی ارجاع داده شوند. همچنین، می‌توان از لیست سفید برای فایل‌ها و فرآیندهای شناخته‌شده و معتبر استفاده کرد تا هشدارهای کاذب کاهش یابد. این رویکرد به تیم امنیتی امکان می‌دهد تا زمان خود را بر روی تهدیدات واقعی متمرکز کند و از خستگی تحلیلی جلوگیری نماید.

• دسترس‌پذیری فایل از طریق وب را بررسی کنید.
• سطح امتیاز فرآیند اجراکننده را در نظر بگیرید.
• ارتباطات شبکه‌ای غیرعادی فرآیند را رصد کنید.
• تغییرات غیرمنتظره در دایرکتوری‌های وب را پایش کنید.

1. تعریف معیارهای عمومی اولویت‌بندی (دسترس‌پذیری، امتیاز، رفتار شبکه).
2. اختصاص امتیاز به هر هشدار بر اساس معیارها.
3. تعیین آستانه برای ارجاع به تحلیل تخصصی.
4. استفاده از لیست سفید برای فایل‌ها و فرآیندهای معتبر.

مثبت‌های کاذب و چالش‌ها

در فرآیند شکار Web Shell، یکی از مهم‌ترین چالش‌ها، تشخیص دقیق بین اسکریپت‌های مخرب و فایل‌های قانونی است. بسیاری از اسکریپت‌های مدیریتی که توسط توسعه‌دهندگان یا مدیران سیستم برای سهولت کار بر روی سرور قرار می‌گیرند، ممکن است رفتارهایی مشابه Web Shell داشته باشند؛ برای مثال، اسکریپت‌هایی که امکان اجرای دستورات سیستمی یا مدیریت فایل‌ها را فراهم می‌کنند. این شباهت رفتاری می‌تواند منجر به ایجاد هشدارهای نادرست (False Positive) شود که نه تنها زمان تحلیلگران را تلف می‌کند، بلکه ممکن است باعث بی‌اعتمادی به سیستم‌های تشخیصی و نادیده گرفته شدن هشدارهای واقعی شود.

یکی از نمونه‌های رایج این چالش، اسکریپت‌های به‌روزرسانی وب‌سرور هستند که ممکن است به‌صورت موقت روی سرور قرار گیرند و شامل توابعی برای اجرای دستورات یا تغییر فایل‌ها باشند. همچنین، ابزارهای مدیریتی مانند phpMyAdmin یا برخی پلاگین‌های مدیریت محتوا، به دلیل ماهیت خود، ممکن است الگوهای رفتاری مشابهی با Web Shell از خود نشان دهند. در این موارد، صرف تکیه بر امضای فایل یا تشخیص محتوای متنی کافی نیست و نیاز به تحلیل عمیق‌تر رفتاری و زمینه‌ای (Contextual Analysis) وجود دارد.

برای کاهش مثبت‌های کاذب، پیشنهاد می‌شود که فرآیند شکار به‌صورت ترکیبی از سه منبع داده (فایل، فرآیند و شبکه) انجام شود. به این معنا که یک فایل مشکوک تنها زمانی به‌عنوان Web Shell در نظر گرفته شود که علاوه بر ویژگی‌های ایستا (مانند وجود توابع خطرناک)، رفتارهای پویا نیز مشاهده شود؛ برای مثال، فرآیندی که از آن فایل اجرا می‌شود، ارتباطات شبکه‌ای غیرعادی برقرار کند یا الگوی اجرای فرمان‌های سیستمی داشته باشد. همچنین، نگهداری یک لیست سفید (Whitelist) از اسکریپت‌های قانونی شناخته‌شده در سازمان می‌تواند به کاهش نویز کمک کند. لازم به ذکر است که این توصیه‌ها بر اساس تجربیات عمومی امنیتی است و هر سازمان باید با توجه به محیط خود آنها را تنظیم کند.

• استفاده از تحلیل رفتاری به‌جای تشخیص صرفاً مبتنی بر امضا برای کاهش هشدارهای نادرست.
• تطبیق فایل‌های مشکوک با فرآیندهای در حال اجرا و ارتباطات شبکه‌ای مرتبط.
• ایجاد لیست سفید از اسکریپت‌های مدیریتی قانونی و به‌روزرسانی منظم آن.
• بررسی زمینه (Context) مانند موقعیت فایل در ساختار دایرکتوری و سابقه تغییرات آن.

محدودیت‌های روش‌های شناسایی مجزا و ضرورت ترکیب منابع

هر یک از سه منبع اصلی شناسایی وب‌شل (فایل، فرآیند، شبکه) به‌تنهایی نقاط کور مشخصی دارند. تحلیل فایل‌ها می‌تواند با رمزنگاری، ابهام‌سازی و پاک‌سازی سریع بدافزار ناکام بماند؛ مهاجم ممکن است اسکریپت را پس از اجرا حذف کند یا آن را در قالب تصاویر و فایل‌های به‌ظاهر بی‌خطر جاسازی کند. این روش همچنین در محیط‌های با حجم بالای فایل‌های وب‌سرور، هشدارهای کاذب زیادی تولید می‌کند و شناسایی نمونه‌های دست‌کاری‌شده از اسکریپت‌های معروف را دشوار می‌سازد.

ردیابی فرآیند نیز محدود است؛ وب‌سرور به‌صورت طبیعی فرآیندهای متعددی را اجرا می‌کند و تشخیص اجرای دستوری از تراکنش‌های معمولی نیازمند تحلیل رفتاری دقیق است. علاوه بر آن، برخی وب‌شل‌ها بدون ایجاد فرآیند طولانی‌مدت، دستور را در حافظه اجرا کرده و اثر چندانی بر فهرست فرآیندها برجای نمی‌گذارند. در چنین حالتی، تکیه صرف بر دفترچه‌های وقایع فرآیند، رویدادهای حیاتی را از دست می‌دهد و مهاجم می‌تواند با تزریق به فرآیند وب‌سرور یا استفاده از واسط‌های داخلی، ردهای فرآیندی را مخفی نماید.

داده‌های شبکه نیز به‌ویژه با فراگیری ترافیک رمزنگاری‌شده (HTTPS) کارایی خود را از دست می‌دهند. اتصال خروجی وب‌شل به سرور فرماندهی ممکن است از روی پروتکل‌های مجاز مانند HTTPS انجام شود که محتوای آن قابل بازرسی متعارف نیست. همچنین تونل‌سازی در قالب ترافیک عادی وب، تشخیص اهداف بدخواهانه را به سطح تحلیل رفتار طولانی‌مدت و همبستگی بین‌سروری می‌کشاند. بنابراین هر یک از منابع به‌تنهایی، پوشش ناقصی از چرخه‌ی حمله ارائه می‌دهند و مهاجم هوشمند می‌تواند از همین شکاف‌ها عبور کند.

به‌موازات این محدودیت‌ها، داده‌های می‌توانند مکمل یکدیگر باشند؛ الگوهای غیرعادی در درخواست‌های وب، هم‌زمان با ایجاد یک فایل جدید و اجرای یک فرآیند مرتبط، نشانه‌ای با قطعیت بالاتر از فعال شدن وب‌شل است. بدون این همادی، هر سیگنال به‌تنهایی به راحتی در فضای نویز محیط گم می‌شود. ترکیب منابع، هزینه تحلیل را افزایش می‌دهد اما به‌طور معناداری نرخ مثبت کاذب و منفی کاذب را مدیریت می‌کند، به‌خصوص اگر این ترکیب بر اساس مدل‌های زمانی و علیتی طراحی شود.

• محدودیت تحلیل فایل: توانایی شکست رمزنگاری و حذف سریع؛ هشدارهای کاذب ناشی از اسکریپت‌های مشروع.
• محدودیت ردیابی فرآیند: اجرای دودویی در فرآیند موجود؛ نبود فرآیند پایدار در برخی نمونه‌ها؛ دشواری تشخیص رفتار عادی.
• محدودیت تحلیل شبکه: ترافیک رمزنگاری‌شده؛ تکنیک‌های تزریق از طریق کانال‌های مجازی؛ ناتوانی در شناسایی محتوای واقعی لجن.
• نتیجه‌گیری: همبستگی بین سیگنال‌ها به‌ویژه در بازه‌های زمانی کوتاه موجب کاهش عوارض جانبی شناسایی می‌شود.

1. یک جدول زمانی واحد از داده‌های سه منبع ایجاد کنید و رویدادهای مشترک (مثلاً ایجاد فایل و اتصال خروجی هم‌زمان) را برچسب بزنید.
2. از امضای رفتاری بر اساس ترکیب داده‌ها استفاده کنید؛ برای نمونه، درخواست ورودی وب که با اجرای متد معمول فروماجت و سپس اتصال خروجی هم‌راه شود، نیازمند بررسی عمیق است.
3. فراهم کردن حالت همبستگی (correlation) در پلتفرم SIEM و تنظیم پرسش‌های پخته (feed) به‌کمک جریان‌های خبری و فرآیند.
4. بهره‌گیری از منابع ضدعفونت به‌عنوان مکمل، نه بدون در نظر گرفتن محدویت‌های آن‌ها.

شاخص‌های اندازه‌گیری کارایی

ارزیابی کمّی فرآیند شکار Web Shell مستلزم تعریف معیارهایی است که هم اثربخشی فنی و هم کارایی عملیاتی را منعکس کنند. این معیارها باید به گونه‌ای طراحی شوند که امکان مقایسه عملکرد تیم دفاعی در بازه‌های زمانی مختلف فراهم شود و در عین حال، از ارائه اعداد مطلق که ممکن است بافت سازمانی را نادیده بگیرند، پرهیز شود. شاخص‌های پیشنهادی در این بخش عمدتاً بر پایه مفاهیم استاندارد در حوزه تشخیص نفوذ و پاسخ به حادثه بنا شده‌اند.

نرخ تشخیص (Detection Rate) به عنوان نخستین شاخص، نسبت موارد واقعی Web Shell شناسایی‌شده به کل موارد موجود در محیط را نشان می‌دهد. این معیار به تنهایی کافی نیست؛ زیرا بدون در نظر گرفتن نرخ مثبت کاذب (False Positive Rate)، ممکن است تیم دفاعی به حجم بالایی از هشدارهای بی‌ارزش غلبه کند. بنابراین، تعریف آستانه‌ای برای مثبت کاذب که بر اساس ظرفیت تحلیل تیم و سطح ریسک پذیرفته‌شده تنظیم می‌شود، ضروری است. این آستانه باید به صورت دوره‌ای بازبینی شود تا با تغییرات محیطی هماهنگ بماند.

زمان پاسخ (Time to Respond) معیار دیگری است که فاصله بین اولین مشاهده سیگنال مشکوک تا مهار یا حذف قطعی تهدید را اندازه‌گیری می‌کند. این شاخص باید به دو بخش تفکیک شود: زمان تشخیص (از وقوع تا هشدار) و زمان واکنش (از هشدار تا اقدام). همچنین، پوشش (Coverage) به عنوان معیار مکمل، درصد سرورهای تحت نظارت فعال را نسبت به کل دارایی‌های وب‌سرور نشان می‌دهد. در نهایت، معیار پایداری (Stability) به بررسی تکرارپذیری نتایج در شرایط یکسان می‌پردازد و اطمینان می‌دهد که تغییرات جزئی در داده‌های ورودی منجر به نوسان شدید در خروجی نمی‌شود.

• نرخ تشخیص: نسبت موارد واقعی شناسایی‌شده به کل موارد موجود؛ باید به تفکیک نوع Web Shell (اسکریپتی، باینری، مبتنی بر قالب) گزارش شود.
• نرخ مثبت کاذب: تعداد هشدارهای نادرست در بازه زمانی معین؛ هدف کاهش این نرخ بدون افت محسوس در تشخیص است.
• زمان تشخیص: میانگین فاصله زمانی بین استقرار Web Shell و اولین هشدار معتبر؛ این معیار به ارزیابی سرعت خط لوله جمع‌آوری و تحلیل داده کمک می‌کند.
• زمان مهار: میانگین مدت زمان لازم برای قرنطینه یا حذف قطعی تهدید پس از تأیید؛ شامل زمان هماهنگی بین تیم‌های مختلف است.
• پوشش نظارتی: درصد سرورهای تحت پایش فعال نسبت به کل سرورهای دارای وب‌سرویس؛ پوشش ناقص می‌تواند نقاط کور ایجاد کند.
• نسبت سیگنال به نویز: نسبت هشدارهای تأییدشده به کل هشدارهای تولیدشده؛ این شاخص کیفیت قوانین تشخیصی را نشان می‌دهد.

عملیاتی‌سازی و بهبود مستمر

برای عملیاتی‌سازی فرآیند شکار وب‌شل، لازم است تیم دفاعی ابتدا یک چرخه مشخص شامل جمع‌آوری داده، تحلیل، اقدام و بازخورد تعریف کند. این چرخه باید به‌صورت دوره‌ای (مثلاً ماهانه) تکرار شود تا با تغییر تکنیک‌های مهاجمان همگام بماند. در هر دوره، تیم باید سناریوهای شکار را بر اساس آخرین الگوهای شناخته‌شده و نیز شاخص‌های سازشی داخلی به‌روزرسانی کند. توصیه می‌شود که این فرآیند به‌صورت مستند و با تعیین مسئولیت‌های مشخص برای هر عضو تیم اجرا شود.

یکی از جنبه‌های کلیدی بهبود مستمر، ثبت و تحلیل بازخورد حاصل از هر عملیات شکار است. برای مثال، اگر در یک دوره شکار، نمونه‌ای از وب‌شل شناسایی شود که توسط قوانین موجود پوشش داده نشده بود، باید این مورد به‌عنوان یک شکاف در پوشش تلقی شده و قوانین جدیدی برای شناسایی الگوهای مشابه تدوین شود. همچنین، نتایج منفی (عدم شناسایی) نیز باید بررسی شوند تا اطمینان حاصل شود که فرآیند به‌درستی کار می‌کند و داده‌های کافی در دسترس است. این بازخورد باید به‌صورت ساختاریافته در جلسات دوره‌ای تیم امنیتی مورد بحث قرار گیرد.

آموزش مستمر تیم امنیتی نیز بخشی از بهبود مستمر است. با توجه به اینکه تکنیک‌های وب‌شل به‌سرعت تکامل می‌یابند، تیم باید در جریان جدیدترین روش‌های شناسایی و نیز الگوهای رفتاری مهاجمان قرار گیرد. این آموزش می‌تواند شامل کارگاه‌های داخلی، مطالعه گزارش‌های معتبر امنیتی و شبیه‌سازی سناریوهای حمله باشد. همچنین، توصیه می‌شود که فرآیند شکار به‌صورت دوره‌ای با سناریوهای فرضی (مثلاً بر اساس گزارش‌های عمومی) آزمایش شود تا کارایی تیم و ابزارها سنجیده شود. در نهایت، تمامی تغییرات در قوانین، رویه‌ها و مستندات باید به‌روزرسانی و در دسترس همه اعضای تیم قرار گیرد.

برای اطمینان از پایداری فرآیند، پیشنهاد می‌شود که شاخص‌های کلیدی عملکرد (KPI) تعریف شود؛ مانند تعداد وب‌شل‌های شناسایی‌شده در هر دوره، زمان بین شناسایی و پاسخ، و درصد پوشش قوانین نسبت به نمونه‌های شناخته‌شده. این شاخص‌ها باید به‌صورت دوره‌ای پایش شده و در صورت انحراف از حد مطلوب، اقدامات اصلاحی انجام شود. همچنین، همکاری با سایر تیم‌های امنیتی (مانند تیم پاسخ به حادثه) برای تبادل اطلاعات و تجربیات می‌تواند به بهبود کلی کمک کند. لازم به ذکر است که این توصیه‌ها جنبه عمومی دارند و باید متناسب با زیرساخت و منابع هر سازمان بومی‌سازی شوند.

• تعریف چرخه منظم برای بازبینی و به‌روزرسانی قوانین شکار بر اساس بازخورد عملیات.
• برگزاری جلسات دوره‌ای برای تحلیل نتایج شکار و شناسایی شکاف‌های پوشش.
• انجام آموزش‌های هدفمند برای تیم امنیتی در زمینه تکنیک‌های نوین وب‌شل.
• اندازه‌گیری عملکرد فرآیند با شاخص‌های کلیدی و اعمال بهبودهای مستند.

1. مستندسازی رویه‌های فعلی شکار و تعیین مسئولیت‌ها.
2. اجرای دوره‌های شکار با استفاده از ترکیب داده‌های فایل، فرآیند و شبکه.
3. ثبت نتایج، شامل موارد مثبت و منفی، در یک پایگاه دانش مرکزی.
4. بررسی دوره‌ای نتایج و استخراج درس‌آموخته‌ها.
5. به‌روزرسانی قوانین، سناریوها و مستندات بر اساس درس‌آموخته‌ها.
6. آزمایش دوره‌ای فرآیند با سناریوهای شبیه‌سازی‌شده.