👆👆👆


این مقاله، Surveyor را از یک ابزار ساده “جمع‌آوری اطلاعات” به یک ابزار توانمندساز برای شکار تهدید مبتنی بر فرضیه (Hypothesis-Driven Threat Hunting) ارتقا می‌دهد. فلسفه اصلی این است: به جای تکیه بر امضاها (Signatures) یا هشدارهای از پیش تعریف‌شده، شما به عنوان یک شکارچی، داده‌های خام و ساختاریافته را در مقیاس جمع‌آوری کرده و سپس با استفاده از دانش خود از TTPهای مهاجمان، به دنبال انحراف از حالت عادی (Deviation from Baseline) می‌گردید.
1. فلسفه اصلی: جمع‌آوری داده در مقیاس برای شکار مبتنی بر فرضیه

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

بحث Point-in-Time Snapshot: این ابزار یک “عکس فوری” از وضعیت حیاتی سیستم در یک لحظه خاص می‌گیرد. این عکس فوری برای ایجاد یک خط پایه (Baseline) یا مقایسه وضعیت فعلی با یک وضعیت سالم شناخته‌شده، حیاتی است.
خروجی ساختاریافته (JSON): این مهم‌ترین ویژگی برای یک شکارچی است. داده‌های خام و بدون ساختار بی‌فایده هستند. خروجی JSON به شما اجازه می‌دهد که:
داده‌ها را از صدها یا هزاران سیستم به یک مخزن مرکزی (مانند یک S3 bucket، Elasticsearch، یا حتی یک پوشه شبکه) منتقل کنید.
با استفاده از ابزارهای خط فرمان قدرتمند مانند jq یا اسکریپت‌های Python (با کتابخانه‌های pandas/polars) و PowerShell، داده‌ها را به سرعت query، فیلتر، agregare و تحلیل کنید. شما دیگر به صورت دستی فایل‌های لاگ را نمی‌خوانید؛ شما در حال query زدن روی یک پایگاه داده از وضعیت سیستم‌ها هستید.

2. تکنیک‌های شکار عملی با استفاده از داده‌های Surveyor (Practical Hunting Techniques)

مقاله به درستی به چند سناریوی شکار بسیار مؤثر اشاره می‌کند. بیایید آن‌ها را با جزئیات فنی بیشتری بررسی کنیم:

سناریوی شکار ۱: خدمات (Services) مشکوک برای پایداری (Persistence)

فرضیه (Hypothesis): مهاجمان برای حفظ دسترسی خود پس از ری‌استارت سیستم، یک سرویس مخرب نصب می‌کنند. (مرتبط با MITRE ATT&CK T1543.003: Create or Modify System Process: Windows Service)
نقاط داده کلیدی در JSON خروجی:
Service.PathName
Service.Signature.IsSigned
Service.Signature.Signer
Service.State
ناهنجاری‌هایی که باید به دنبالشان باشید:

سرویس‌های بدون امضای دیجیتال (Unsigned Services): این یک Red Flag بسیار بزرگ است. تقریباً تمام سرویس‌های اصلی ویندوز و نرم‌افزارهای معتبر، امضا شده‌اند.

Query نمونه با jq:


cat surveyor-output.json | jq '.Services[] | select(.Signature.IsSigned == false)'


مسیرهای اجرایی غیر استاندارد: سرویس‌ها معمولاً از C:\Windows\System32 یا C:\Program Files اجرا می‌شوند. سرویسی که از C:\Users\...\AppData, C:\Temp, C:\Windows\Tasks یا C:\ProgramData اجرا شود، به شدت مشکوک است.

Query نمونه با jq:


cat surveyor-output.json | jq '.Services[] | select(.PathName | test("(?i)C:\\\\(Users|Temp|ProgramData|Windows\\\\Tasks)") )'


سرویس‌هایی که از ابزارهای دوگانه (Dual-Use Tools) استفاده می‌کنند: سرویسی که خط فرمان آن شامل powershell.exe -enc ..., rundll32.exe, mshta.exe یا certutil.exe باشد، باید فوراً بررسی شود.

سناریوی شکار ۲: فرایندهای ماسک‌شده (Masquerading Processes)

فرضیه: مهاجمان نام ابزارهای خود را به نام‌های فرایندهای سیستمی مشروع (مانند svchost.exe, lsass.exe) تغییر می‌دهند تا شناسایی نشوند. (مرتبط با MITRE ATT&CK T1036: Masquerading)
نقاط داده کلیدی در JSON خروجی:
Process.Name
Process.PE.InternalName
Process.PE.OriginalFileName
Process.Parent.Name
ناهنجاری‌هایی که باید به دنبالشان باشید:

عدم تطابق نام فرایند با نام داخلی PE: یک svchost.exe واقعی، در متادیتای فایل PE خود نیز نام داخلی svchost.exe را دارد. اگر Process.Name برابر svchost.exe باشد اما Process.PE.InternalName چیزی مانند mimikatz.exe یا evil.exe باشد، شما یک تهدید را کشف کرده‌اید.

Query نمونه با jq:


cat surveyor-output.json | jq '.Processes[] | select(.Name == "svchost.exe" and .PE.InternalName != "svchost.exe")'

ادامه در پست بعد

#آکادمی_روزبه
مرکز تخصصی CISSP