شکار تهدید مبتنی بر فرضیه: از سؤال دفاعی تا شواهد قابل اتکا

فرضیه شکار دقیقاً چیست؟

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

نمونه بهتر این است: مهاجمی که به حساب مدیریتی دسترسی یافته ممکن است برای اجرای کد روی چند میزبان، Service جدیدی با Binary مستقر در مسیر قابل‌نوشتن کاربر ایجاد کند. این گزاره تکنیک، Artifact و دامنه جستجو را روشن می‌کند و می‌توان آن را با داده رد یا تأیید کرد.

• رفتار مورد انتظار مهاجم را توصیف کند، نه نام یک گروه یا ابزار را.
• محدوده زمانی، دارایی‌های هدف و منبع داده قابل استفاده را مشخص کند.
• معیار پایان داشته باشد: تأیید، رد یا ناکافی‌بودن Telemetry.
• به یک تصمیم دفاعی منجر شود؛ مانند Rule جدید، بهبود Logging یا Incident Response.

از Threat Intelligence تا سؤال قابل آزمون

گزارش Threat Intelligence معمولاً مجموعه‌ای از TTP، زیرساخت، بدافزار و زمینه قربانی است. برای ساخت Hunt، بخش پایدارتر گزارش یعنی رفتار و تکنیک را از IOCهای کوتاه‌عمر جدا کنید. سپس بپرسید کدام رفتار با معماری و دارایی‌های سازمان شما سازگار است.

نگاشت MITRE ATT&CK زبان مشترکی برای نام‌گذاری تکنیک فراهم می‌کند، اما خود نگاشت جای Detection logic را نمی‌گیرد. یک Technique ممکن است چند پیاده‌سازی و چند منبع داده داشته باشد؛ در نتیجه Hunt باید Artifact مشخص همان سیستم‌عامل و محیط را تعریف کند.

1. منبع معتبر را بخوانید و ادعاهای رفتاری را از IOCها استخراج کنید.
2. تکنیک‌های مرتبط را با MITRE ATT&CK تطبیق دهید و نسخه تکنیک را ثبت کنید.
3. بررسی کنید آن رفتار در محیط شما امکان‌پذیر و از نظر ریسک بااهمیت است.
4. منبع داده و فیلدهای لازم برای تأیید یا رد رفتار را مشخص کنید.
5. فرضیه را در یک جمله با فاعل، رفتار، هدف و Artifact بنویسید.

طراحی ماتریس شواهد

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

برای مثال در Hunt ایجاد Service، وجود رویداد ساخت Service به‌تنهایی کافی نیست. مسیر Binary، امضا، والد ایجادکننده، حساب کاربری، میزبان‌های مشابه و زمان‌بندی باید کنار هم بررسی شوند. ابزارهای مدیریت سازمانی نیز Service می‌سازند و بدون Baseline می‌توانند False Positive زیادی ایجاد کنند.

• Windows Service Control Manager و رویدادهای مرتبط با ایجاد Service
• Process creation شامل Parent، Command line و Hash
• مسیر و Metadata فایل اجرایی
• اطلاعات Signer و شیوع فایل در سایر میزبان‌ها
• تغییرات Registry یا File System مرتبط
• زمینه حساب کاربری و تغییرات هم‌زمان در همان میزبان

Baseline و کاهش False Positive

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

استفاده از Allowlist بدون تاریخ انقضا خطرناک است. هر استثنا باید مالک، دلیل، دامنه و زمان بازبینی داشته باشد. استثنای گسترده براساس نام فایل یا مسیر می‌تواند همان فضای مورد نیاز مهاجم را ایجاد کند.

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

تبدیل نتیجه Hunt به کنترل پایدار

Hunt زمانی ارزش عملیاتی پیدا می‌کند که نتیجه آن در حافظه تیم باقی بماند. اگر فرضیه تأیید شد، Incident ایجاد و دامنه نفوذ تعیین می‌شود. اگر رد شد، منطق و داده‌ها ثبت می‌شوند تا همان کار دوباره تکرار نشود. اگر داده ناکافی بود، خروجی واقعی Hunt یک Gap در Telemetry است.

Detection جدید باید با داده واقعی آزموده، محدوده آن روشن و مالک نگهداری آن مشخص شود. Rule بدون تست و فرآیند بازبینی ممکن است به Alert fatigue یا حس امنیت کاذب منجر شود.

1. Query و نسخه منبع داده را ثبت کنید.
2. نمونه‌های True Positive و False Positive را نگهداری کنید.
3. منطق قابل تکرار را به Sigma، SIEM Query یا کنترل Endpoint تبدیل کنید.
4. Severity و مسیر Triage را تعریف کنید.
5. پس از تغییر سیستم‌عامل، Logging یا ابزار، Rule را دوباره اعتبارسنجی کنید.

نقش اسکن Endpoint در Hunt

Telemetry متمرکز همیشه کامل نیست؛ Agent ممکن است نصب نباشد، داده قدیمی حذف شده باشد یا مهاجم Logging را مختل کرده باشد. اسکن Endpoint می‌تواند Artifactهای فایل، Registry، Process، Event Log و نشانه‌های دیگر را در زمان ارزیابی جمع‌آوری و با قواعد YARA یا Sigma تطبیق دهد.

اسکن نقطه‌ای جای EDR یا SIEM را نمی‌گیرد. ارزش آن در تکمیل دید، بررسی میزبان‌های فاقد Agent، Compromise Assessment و اعتبارسنجی فرضیه روی Snapshot فعلی سیستم است. طراحی Hunt باید محدودیت زمانی هر منبع داده را صریح نگه دارد.