بحث Rule Tagging در Sysmon و نقش آن در Threat Hunting و Correlation

سیسمون (Sysmon) بدون شک یکی از قدرتمندترین ابزارهای مایکروسافت برای شکار تهدیدات (Threat Hunting) است. اما قدرت زیاد، مسئولیت (و پیچیدگی) زیاد هم به همراه دارد. بسیاری از تیم‌های SOC پس از نصب Sysmon با یک چالش بزرگ روبرو می‌شوند: «حالا چه Ruleهایی بنویسیم؟»

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

در این مقاله، ابتدا مفهوم مهم Rule Tagging را مرور می‌کنیم و سپس به سراغ استانداردهای طلایی جامعه امنیت (Community Configs) می‌رویم تا یاد بگیریم چگونه در کمتر از ۱۰ دقیقه، یک سیستم مانیتورینگ در سطح خوب داشته باشیم.

۱. چرا Sysmon بدون “تگ” (Tag) فقط یک تولیدکننده نویز است؟

در حالت پیش‌فرض، Sysmon فقط داده خام تولید می‌کند. مثلاً می‌گوید: «فرآیند powershell.exe اجرا شد». این برای تحلیلگر SOC کافی نیست.

قابلیت Rule Tagging که در نسخه‌های جدید اضافه شده، اجازه می‌دهد به هر رخداد، یک «معنا» اضافه کنید.

مثلاً به جای لاگ خام، شما چنین خروجی‌ای دریافت می‌کنید:

تکنیک: T1059.001

تاکتیک: Execution

توضیحات: PowerShell with Encoded Command

این یعنی Sysmon به جای یک ابزار لاگ‌گیری ساده، به یک سنسور هوشمند تشخیص رفتار تبدیل می‌شود. اما سوال اصلی اینجاست: چه کسی باید این تگ‌ها و قوانین پیچیده را بنویسد؟
Rule Tagging در Sysmon، پارادایم پایش ویندوز را از «جمع‌آوری لاگ خام» به «تولید داده‌های معنادار» تغییر داده است. تا پیش از این، Sysmon تنها یک ضبط‌کننده رویداد بود، اما با افزودن تگ‌ها (به‌ویژه کدهای استاندارد MITRE ATT&CK) به فایل کانفیگ، هر رویداد حاملِ “ماهیت” و “چرایی” وقوع خود می‌شود.

در فرآیند Threat Hunting، این قابلیت حیاتی است. شکارچی تهدید دیگر نیازی ندارد کوئری‌های پیچیده برای یافتن الگوهای مبهم بنویسد؛ بلکه می‌تواند مستقیماً و با سرعت بالا به دنبال تگ‌های رفتاری مشخص (مانند T1003_CredentialDumping) بگردد.

علاوه بر این، نقش تگ‌گذاری در Correlation (همبستگی رویدادها) در SIEM غیرقابل انکار است. تگ‌ها همانند «نخ‌های اتصال» عمل می‌کنند که رویدادهای پراکنده (مانند اجرای یک دستور و سپس برقراری یک اتصال شبکه) را به هم گره می‌زنند. این امر به SIEM اجازه می‌دهد تا به جای نمایش هزاران هشدار مجزا، یک «زنجیره حمله» (Kill Chain) کامل را بازسازی کند. به بیان ساده، Rule Tagging زبان Sysmon را از کدهای فنی و خشک، به زبان تاکتیک‌های حمله سایبری ترجمه می‌کند

۲. اشتباه رایج: نوشتن کانفیگ از صفر

بسیاری از متخصصین تلاش می‌کنند فایل config.xml را خودشان بنویسند. این کار چند اشکال اساسی دارد:

زمان‌بر بودن: تحقیق درباره هر تکنیک جدید هکرها و تبدیل آن به Rule، نیازمند یک تیم کامل تحقیقاتی است.

عدم پوشش کامل: ممکن است شما تکنیک‌های معروف را پوشش دهید، اما روش‌های دور زدن (Bypass) را ندانید.

نگهداری سخت: با هر آپدیت ویندوز یا تکنیک جدید، باید دستی فایل را ویرایش کنید.

راه حل چیست؟ ایستادن بر شانه غول‌ها و استفاده از کانفیگ‌های آزمایش شده توسط جامعه امنیت.

۳. معرفی برترین Community Configs

در دنیای Sysmon، دو نام بزرگ وجود دارد که اکثر سازمان‌های دنیا از کانفیگ آن‌ها استفاده می‌کنند:

۳-۱. SwiftOnSecurity (گزینه کلاسیک)

این کانفیگ احتمالا محبوب‌ترین نقطه شروع برای بسیاری از ادمین‌هاست.

ویژگی: تمرکز بر بیس لاین ها و حذف نویزهای معروف ویندوز.

نقطه ضعف: سیستم تگ‌گذاری (Tagging) آن خیلی دقیق نیست و بر اساس چارچوب MITRE ATT&CK طراحی نشده است. بیشتر برای مانیتورینگ عمومی خوب است تا شکار تهدید پیشرفته.

۳-۲. Olaf Hartong’s sysmon-modular گزینه حرفه‌ای و پیشنهادی من

این کانفیگ توسط Olaf Hartong، یکی از نوابغ شکار تهدید، توسعه داده شده و دقیقاً همان چیزی است که یک تیم SOC مدرن نیاز دارد.

ساختار ماژولار: برخلاف یک فایل متنی طولانی، این کانفیگ از ماژول‌های کوچک تشکیل شده است.

تگ‌گذاری MITRE: تمام Ruleها دقیقاً با کدهای MITRE ATT&CK تگ‌گذاری شده‌اند (مثلاً T1003).

پوشش بالا: تمرکز ویژه‌ای روی تکنیک‌های پیچیده مثل Process Injection و WMI Abuse دارد.

۴. چرا باید از sysmon-modular استفاده کنید؟

اگر هدف شما Threat Hunting و Detection Engineering است، کانفیگ Olaf Hartong بی‌رقیب است. بیایید ببینیم چرا:

الف) نگاشت مستقیم به MITRE ATT&CK

وقتی از این کانفیگ استفاده می‌کنید، لاگ‌های شما حاوی تگ‌هایی مثل T1021_RemoteServices هستند.

مزیت: شما می‌توانید در SIEM (مثل Splunk یا ELK) داشبوردی بسازید که دقیقاً نشان دهد “امروز چند تکنیک Lateral Movement در شبکه دیده شده است”.

ب) کاهش False Positive با تگ‌گذاری هوشمند

این کانفیگ فقط “بدها” را پیدا نمی‌کند، بلکه “خوب‌ها” را هم می‌شناسد و آن‌ها را فیلتر می‌کند تا SIEM شما زیر بار لاگ‌های بیهوده غرق نشود.

ج) آپدیت‌های مداوم

جامعه امنیت به سرعت تکنیک‌های جدید را کشف می‌کند و Olaf Hartong مخزن (Repository) خود را با Ruleهای جدید برای مقابله با آسیب‌پذیری‌های روز (مثل Log4j یا PrintNightmare در زمان خودشان) به‌روزرسانی می‌کند.

بیشتر فکر کنیم ....

اما Olaf Hartong’s sysmon-modular هم مشکلاتی دارد ....

در ادامه دلایل فنی و عملیاتی اینکه چرا این کانفیگ نمی‌تواند کامل باشد را بررسی می‌کنیم:

۱. مشکل “یک راهکار برای همه” (One Size Fits All)

بزرگترین ضعف هر کانفیگ عمومی (Community Config)، عدم آگاهی از محیط خاص شبکه شماست.

• عدم تطابق با Baseline: در شبکه شما ممکن است ادمین‌ها به‌صورت روزمره از ابزارهایی مثل PsExec یا PowerShell برای کارهای مدیریتی استفاده کنند. کانفیگ Olaf این‌ها را به عنوان فعالیت مشکوک (Suspicious) تگ می‌زند.

• نتیجه: حجم عظیمی از False Positive (هشدارهای کاذب) تولید می‌شود که باعث خستگی تحلیلگر (Alert Fatigue) شده و ممکن است باعث شود هشدارهای واقعی در میان نویزها گم شوند.

۲. شمشیر دو لبه‌ی متن‌باز بودن (Attacker Awareness)

همانطور که شما به گیت‌هاب Olaf Hartong دسترسی دارید، مهاجمین و تیم‌های Red Team هم به آن دسترسی دارند!

• تکنیک‌های Evasion: مهاجمین کانفیگ را دانلود می‌کنند، منطق Ruleها را می‌خوانند و دقیقاً کدی می‌نویسند که شرط‌های (Conditions) موجود در فایل XML را دور بزند.

• مثال: اگر در کانفیگ آمده باشد: «دستوراتی که کلمه password دارند را لاگ بگیر»، مهاجم دستور را به p^a^s^s^w^o^r^d تغییر می‌دهد و Sysmon آن را نادیده می‌گیرد (Obfuscation).

۳. محدودیت در پوشش تکنیک‌ها (Detection Coverage)

سیسمون (Sysmon) همه‌کاره نیست و کانفیگ آن هم نمی‌تواند معجزه کند.

• محدودیت‌های Sysmon: برخی تکنیک‌های پیشرفته که در سطح حافظه (In-Memory) رخ می‌دهند (مثل برخی فرم‌های پیشرفته Process Hollowing یا ترافیک‌های رمزنگاری شده خاص)، ممکن است اصلاً توسط Sysmon قابل دیدن نباشند که کانفیگ بخواهد برایشان Rule بنویسد.

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

۴. هزینه پردازش و حجم داده (Volume & SIEM Cost)

این کانفیگ برای “شکار تهدید” طراحی شده و بسیار نویزی (Verbose) است.

• حجم بالای لاگ: فعال کردن تمام ماژول‌های این کانفیگ (مخصوصاً NetworkConnect و ImageLoad) می‌تواند روزانه گیگابایت‌ها لاگ تولید کند.

• هزینه: اگر لایسنس SIEM شما (مثل Splunk) بر اساس حجم است، این کانفیگ می‌تواند هزینه‌های سازمان را خیلی زیاد کند. بسیاری از سازمان‌ها مجبورند بخش‌های زیادی از این کانفیگ را غیرفعال کنند که عملاً آن را “ناقص” می‌کند.

۵. تاخیر در بروزرسانی (Lag Time)

امنیت یک مسابقه سرعت است.

• وقتی یک آسیب‌پذیری Zero-day جدید کشف می‌شود، مدتی طول می‌کشد تا Olaf یا جامعه متن‌باز:

1. حمله را تحلیل کنند.

2. Rule مناسب برای آن بنویسند.

3. تست کنند و در گیت‌هاب Push کنند.

4. شما آن را دانلود و در شبکه Deploy کنید.

• در این فاصله زمانی (Time Gap)، شما در برابر آن تهدید خاص با استفاده از این کانفیگ محافظت نمی‌شوید.

۶. وابستگی به Excludeهای پیش‌فرض

برای کاهش نویز، این کانفیگ لیست بلندبالایی از Excludeها (استثنائات) دارد (مثلاً نادیده گرفتن پروسس‌های خاصی از ویندوز یا آنتی‌ویروس‌ها).

• ریسک: یکی از تکنیک‌های معروف مهاجمین، مخفی شدن در نام‌های معتبر است (Masquerading). اگر کانفیگ به‌صورت پیش‌فرض پوشه System32 را برای برخی رفتارها Exclude کرده باشد و مهاجم بتواند بدافزار خود را با نام سیستمی در آنجا کپی کند، Sysmon کاملاً کور می‌شود.

نتیجه‌گیری: چگونه این نقص را جبران کنیم؟

اینکه sysmon-modular کامل نیست، به معنی بد بودن آن نیست؛ بلکه به این معنی است که نقطه شروع است، نه پایان.

برای اینکه به پوشش کامل برسید، باید این چرخه را اجرا کنید:

1. Use as Base: از کانفیگ Olaf به عنوان فونداسیون استفاده کنید (۸۰٪ راه را می‌رود).

2. Tune It: بر اساس شرایط محیط خود، Excludeهای خاص سازمانتان را اضافه کنید (Tuning).

3. Layered Defense: فقط به Sysmon تکیه نکنید. EDR و لاگ‌های فایروال و... باید جاهایی که Sysmon کور است را پوشش دهند.

4. Breach & Attack Simulation: به‌طور مداوم با ابزارهایی مثل Atomic Red Team حملات را شبیه‌سازی کنید تا ببینید کانفیگ Olaf کجاها شکست می‌خورد و فقط آن نقاط ضعف را دستی ترمیم کنید.