Threat Hunting در عمل؛ شکار تهدید از فرضیه‌سازی تا قانون تشخیص، ابزارها و اشتباهات رایج
شکار تهدید چیست و چرا با triage هشدار فرق دارد؟ چرخه چهارمرحله‌ای شکار، قالب فرضیه قابل‌آزمون، نمونه قانون Sigma و osquery، روش coverage-driven و معیارهای موفقیت برای تیم Blue Team.
شکار تهدید چیست و چرا با triage کردن هشدار فرق دارد؟
همه‌ی تیم‌های امنیتی هشدار می‌گیرند، اما اکثرشان فقط هشدارهایی را می‌بینند که سیستم تشخیصی از قبل تعریف کرده است. شکار تهدید (Threat Hunting) دقیقاً کاری است که قبل از وجود هشدار انجام می‌شود: با فرضیه‌ای شروع می‌شود که ممکن است مهاجمی بدون اینکه هشداری بزند، در شبکه حضور داشته باشد، و با جست‌وجوی فعالانه در داده‌ها ثابت یا رد می‌شود.
تفاوت کلیدی: triage واکنش به اعلانی است که از قبل وجود دارد (واکنشی). شکار جست‌وجویی است که خودتان آغاز می‌کنید (فعالانه). اگر هشداری اصلاً تعریف نشده باشد، فقط شکار می‌تواند آن را پیدا کند.
## چهار منبع فرضیه شکار
فرضیه‌ی خوب از یکی از این چهار جا درمی‌آید:
1. **تهدید شناخته‌شده:** گزارش CTI درباره کمپینی که اخیراً دیده شده. سؤال: «مهاجمان این کمپین الان از چه تکنیک‌هایی استفاده می‌کنند و آیا ما لاگ آن را داریم؟»
2. **شکاف پوشش:** تکنیکی در ATT&CK که برایش قانون تشخیص نداریم. خروجی ساده: یک coverage matrix از تکنیک‌های به‌روز ما.
3. **داده عجیب:** در داده‌های شبکه یا endpoint رفتاری هست که توضیح کسب‌وکاری ندارد (نمونه: سروری که هر شب ۳ صبح به یک IP خارجی ۴۰ کیلوبایت می‌فرستد).
4. **رفتار تغییرکرده:** baseline رفتار یک هاست یا اکانت تغییر کرده (ادمینی که از ابزارهای خارج از چرخه استفاده می‌کند، شاید نشانه سوءاستفاده از credential باشد).
## چرخه شکار: چهار مرحله با خروجی مشخص
| مرحله | کار عملی | خروجی |
|---|---|---|
| Preparation | جمع‌آوری داده، بررسی پوشش لاگ‌ها، تعیین scope | لیست منبع داده + تکنیک‌های پوشش‌داده‌شده |
| Hypothesis | نوشتن فرضیه به شکل قابل‌آزمون | یک جمله مشخص با تکنیک ATT&CK |
| Validation | جست‌وجوی داده، رد یا تأیید | شواهد + نمونه IOC/رویداد |
| Lessons | تبدیل نتیجه به قانون تشخیص یا تغییر کنترل | قانون Sigma جدید یا تیکت اصلاح |
نکته مهم: اگر خروجی مرحله Lessons چیزی نباشد، شکار به جایی نرسیده. هر شکار باید یا یک detection rule جدید تحویل دهد، یا یک تغییر در کنترل‌ها، یا یک نتیجه «پوشش کافی است» با سند مکتوب.
## ساختن فرضیه خوب
قالب قابل‌آزمون برای فرضیه:
> اگر مهاجم از تکنیک `[Txxxx]` استفاده کند، در منبع داده `[W]` رفتار `[Z]` را خواهیم دید که در baseline وجود ندارد.
مثال واقعی یک فرضیه خوب:
> اگر مهاجم برای اجرای payload از `powershell.exe -EncodedCommand` استفاده کند، در Sysmon Event ID 1 (Process Create) والد `winword.exe` یا `excel.exe`، فرایندی با `powershell.exe` و آرگومان حاوی `-enc` خواهیم دید که به‌ندرت در baseline می‌آید.
مثال بد (قابل‌آزمون نیست):
> اگر مهاجمی وارد شبکه شده باشد، چیز عجیبی می‌بینیم.
## نمونه عملی: جست‌وجوی فرضیه در داده
با یک قانون Sigma می‌توان فرضیه را روی SIEM پیاده کرد:
```yaml
title: PowerShell Encoded Command From Office Parent
id: 7c1f5a2e-9d3b-4a77-b6f1-2f0c1d9a4e10
status: experimental
logsource:
category: process_creation
product: windows
detection:
parent:
ParentImage|endswith:
- '\WINWORD.EXE'
- '\EXCEL.EXE'
- '\POWERPNT.EXE'
payload:
Image|endswith: '\powershell.exe'
CommandLine|contains:
- ' -enc '
- ' -EncodedCommand '
- ' -e '
condition: parent and payload
falsepositives:
- Legitimate automation from Office macros in the finance department
level: high
tags:
- attack.execution
- attack.t1059.001
```
اگر دسترسی EDR ندارید، osquery می‌تواند همین فرضیه را روی endpoint پرس‌وجو کند:
```sql
SELECT p.name, p.cmdline, p.parent_path, u.username
FROM processes p JOIN users u ON p.uid = u.uid
WHERE p.cmdline LIKE '%-EncodedCommand%'
OR p.cmdline LIKE '% -enc %'
ORDER BY p.start_time DESC
LIMIT 50;
```
برای شکار مبتنی بر شبکه، Zeek یک منبع داده ارزشمند است. مثلاً برای فرضیه «beaconing منظم به دامنه تازه ثبت‌شده»:
```awk
# zeek script sketch: هاست‌هایی که بیش از N بار در یک روز به یک دامنه تماس گرفته‌اند
# خروجی به dns.log اضافه می‌شود و بعد در SIEM برای rcount/count بالا هشدار می‌زنید
```
## انتخاب تکنیک برای شکار: روش coverage-driven
بهترین نقطه شروع، تحلیل پوشش است:
1. خروجی قوانین تشخیص خود را در برابر تکنیک‌های ATT&CK مربوط به صنعت خودتان نقشه بزنید.
2. تکنیک‌هایی را انتخاب کنید که **هم دیده شدن در داده‌های موجود را دارند** و **هم برای مهاجم کم‌هزینه‌اند** (مثلاً T1059.001، T1071.004، T1078).
3. تکنیک‌هایی که لاگشان را ندارید، موضوع شکار نیستند؛ موضوع «دریافت لاگ» هستند. اول لاگ را روشن کنید، بعد شکار کنید.
## شکار فرضیه‌محور در مقابل شکار داده‌محور
- **فرضیه‌محور:** سؤال مشخص، جست‌وجوی هدفمند، نتیجه سریع و قابل‌آزمون. مناسب تیم کوچک با محدودیت زمانی.
- **داده‌محور (ML/anomaly):** روی کل داده الگو می‌جوید. هزینه بالاتر، false positive بیشتر، اما گاهی تکنیکی را پیدا می‌کند که فرضیه‌سازی به آن نمی‌رسد.
قانون عملی: اول با فرضیه‌محور شروع کنید، و فقط وقتی به داده‌محور روی بیاورید که baseline رفتاری معنایی از داده‌هایتان دارید.
## اشتباهات رایج در شکار
- **ابزارمحوری:** خرید پلتفرم Threat Hunting بدون تعریف فرایند. ابزار فرضیه نمی‌سازد.
- **شکار بدون داده کافی:** اگر ۹۰ روز Sysmon ندارید، نمی‌توانید baseline بگیرید.
- **نبود خروجی مکتوب:** شکاری که به قانون Sigma یا تغییر کنترل ختم نشود، فقط یک کار دستی مقطعی است.
- **خستگی ناشی از FP:** قوانین بی‌اساس زیاد تیم را کور می‌کند؛ اول false positive را حذف کنید.
- **شکار فقط برای اثبات کار:** شکار باید به کاهش ریسک برسد، نه فقط به گزارش فعالیت.
## معیارهای موفقیت
به جای «تعداد شکارهای انجام‌شده» اینها را بسنجید:
- **Hypothesis-to-rule conversion rate:** چند درصد شکارها به قانون تشخیص جدید ختم شدند؟
- **Coverage delta:** تعداد تکنیک‌های ATT&CK که بعد از هر چرخه پوشش‌داده‌شده اضافه شد.
- **Dwell-time proxy:** آیا زمان کشف سناریوهای آزمایشی (purple team) کاهش یافته؟
- **Novel findings:** چند رفتار واقعاً ناشناخته کشف شد؟
## چکلیست شروع شکار
1. داشبورد coverage تکنیک‌های ATT&CK خود را بسازید.
2. لیست منبع داده موجود (Sysmon، Event Logs، EDR، Zeek، DNS) را مستند کنید.
3. یک فرضیه با قالب قابل‌آزمون بنویسید.
4. query و قانون تشخیص آن را در sandbox اجرا و نتیجه را بررسی کنید.
5. خروجی را مستند و در صورت نتیجه، قانون را به SIEM اضافه کنید.
6. بعد از هر شکار، آن را در رتروسپکتیو تیم مرور کنید.
---
*Published: 2026-10-19 | Category: Threat Detection | Author: Alireza Abedi*