شکار تهدید در ویندوز: شناسایی Persistence از طریق سرویس‌ها، Scheduled Tasks و Registry

مفهوم پایداری از طریق سرویس‌های ویندوز و وظایف زمان‌بندی‌شده

پایداری (Persistence) یکی از اهداف اصلی مهاجمان در مراحل پس از نفوذ است. در ویندوز، دو سازوکار رایج برای حفظ دسترسی، سرویس‌های ویندوز و وظایف زمان‌بندی‌شده هستند. سرویس‌های ویندوز برنامه‌هایی هستند که در پس‌زمینه اجرا می‌شوند و معمولاً با شروع سیستم بارگذاری می‌گردند. مهاجمان می‌توانند با ایجاد یک سرویس جدید یا تغییر مسیر اجرای یک سرویس موجود، کد مخرب خود را به‌صورت خودکار و با سطح دسترسی بالا (اغلب SYSTEM) اجرا کنند. این رفتار در ماتریس ATT&CK با شناسه T1543.003 ثبت شده است.

وظایف زمان‌بندی‌شده نیز امکان اجرای برنامه‌ها را در زمان‌های مشخص یا رویدادهای خاص مانند ورود کاربر فراهم می‌کنند. مهاجمان با استفاده از ابزارهایی مانند schtasks یا PowerShell می‌توانند وظایفی ایجاد کنند که به‌صورت دوره‌ای یا هنگام شروع سیستم اجرا شوند. این تکنیک با شناسه T1053.005 در ATT&CK شناخته می‌شود. هر دو روش به مهاجم اجازه می‌دهند تا بدون نیاز به تعامل کاربر، کد خود را اجرا کرده و دسترسی خود را حفظ کند.

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

• سرویس‌های ویندوز: ایجاد یا تغییر سرویس از طریق ابزارهایی مانند sc.exe یا ویرایش مستقیم رجیستری (مسیر HKLM\SYSTEM\CurrentControlSet\Services) انجام می‌شود.
• وظایف زمان‌بندی‌شده: ایجاد وظیفه با schtasks یا PowerShell (مثلاً Register-ScheduledTask) و تنظیم زمان اجرا برای رویدادهایی مانند ورود کاربر یا شروع سیستم.
• هر دو روش می‌توانند برای اجرای کد با سطح دسترسی SYSTEM یا حساب مشخص مورد سوءاستفاده قرار گیرند.

1. برای شناسایی سرویس‌های مشکوک، خروجی دستور sc query را با لیست سرویس‌های شناخته‌شده مقایسه کنید.
2. برای بررسی وظایف زمان‌بندی‌شده، از دستور schtasks /query /v استفاده کنید و وظایف غیرعادی را بررسی کنید.
3. تغییرات در رجیستری مربوط به سرویس‌ها و وظایف را با ابزارهای SIEM یا Sysmon ثبت و پایش کنید.

sc query type= service state= all | findstr /i "SERVICE_NAME"

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

برای شناسایی ماندگاری (Persistence) از طریق سرویس‌ها و وظایف زمان‌بندی‌شده در ویندوز، نخستین گام، آگاهی از منابع تله‌متری استاندارد و در دسترس در محیط‌های سازمانی است. این منابع شامل لاگ‌های رویداد ویندوز (Windows Event Logs)، لاگ‌های Sysmon و رجیستری ویندوز می‌شوند. هر یک از این منابع می‌توانند نشانه‌های ارزشمندی از ایجاد یا تغییر غیرعادی در این سازوکارها ارائه دهند. تحلیلگران امنیتی باید با شناسه رویدادهای کلیدی و نحوه تفسیر آن‌ها آشنا باشند تا بتوانند فعالیت‌های مشکوک را از ترافیک عادی تفکیک کنند.

در حوزه سرویس‌های ویندوز، رویداد 7045 در لاگ سیستم (System Log) هنگام نصب یک سرویس جدید ثبت می‌شود و اطلاعاتی مانند نام سرویس، نوع آن و مسیر فایل اجرایی را در بر دارد. همچنین رویداد 4697 در لاگ امنیتی (Security Log) نیز به ایجاد سرویس اشاره دارد و می‌تواند مکمل رویداد 7045 باشد. برای وظایف زمان‌بندی‌شده، رویداد 106 در لاگ Microsoft-Windows-TaskScheduler/Operational هنگام ایجاد یا تغییر یک وظیفه ثبت می‌شود. علاوه بر این، رویداد 1 در Sysmon (ایجاد فرآیند) و رویداد 13 (تغییر در رجیستری) می‌توانند سرنخ‌های مهمی از اجرای دستورات schtasks یا تغییرات در کلیدهای رجیستری مرتبط با وظایف ارائه دهند.

تغییرات رجیستری نیز منبع حیاتی دیگری برای شناسایی ماندگاری است. مسیرهایی مانند HKLM\SYSTEM\CurrentControlSet\Services برای سرویس‌ها و HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks برای وظایف زمان‌بندی‌شده باید به دقت پایش شوند. رویداد 13 Sysmon می‌تواند برای ردیابی تغییرات در این کلیدها پیکربندی شود. لازم به ذکر است که برخی از تکنیک‌های پیشرفته، مانند حذف توصیفگر امنیتی (SD) برای مخفی‌سازی وظایف، ممکن است رویدادهای استاندارد را دور بزنند و نیازمند بررسی عمیق‌تر و تطبیق با سایر شواهد باشند.

• رویداد 7045 در لاگ سیستم: ثبت نصب سرویس جدید با جزئیات مسیر اجرایی
• رویداد 4697 در لاگ امنیتی: ثبت ایجاد سرویس (در صورت فعال بودن سیاست ممیزی)
• رویداد 106 در لاگ TaskScheduler/Operational: ثبت ایجاد یا تغییر وظایف زمان‌بندی‌شده
• رویداد 1 در Sysmon: شناسایی اجرای فرآیندهای مرتبط مانند schtasks.exe یا sc.exe
• رویداد 13 در Sysmon: ردیابی تغییرات در کلیدهای رجیستری سرویس‌ها و وظایف

1. پیکربندی جمع‌آوری لاگ‌های امنیتی و سیستمی برای همه سیستم‌های حیاتی و اطمینان از فعال بودن سیاست‌های ممیزی مرتبط با ایجاد سرویس و وظایف زمان‌بندی‌شده.
2. نصب و پیکربندی Sysmon با قوانین مناسب برای ثبت رویدادهای 1 و 13 و اطمینان از ارسال لاگ‌ها به یک SIEM مرکزی.
3. ایجاد یک خط پایه (Baseline) از سرویس‌ها و وظایف زمان‌بندی‌شده مجاز در محیط و مقایسه دوره‌ای آن با وضعیت فعلی برای شناسایی تغییرات غیرعادی.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} | Select-Object TimeCreated, Message

Detection Workflow and Hunting Queries

برای شناسایی تداوم (Persistence) از طریق سرویس‌ها و وظایف زمان‌بندی شده، ابتدا باید یک خط پایه از وضعیت عادی محیط تهیه شود. این کار شامل ثبت لیست سرویس‌های موجود، وظایف زمان‌بندی شده و مقادیر رجیستری مربوطه در حالت سالم است. هرگونه تغییر در این اجزا، به‌ویژه اگر با نام‌های مشابه با مؤلفه‌های سیستمی همراه باشد، باید به‌عنوان یک هشدار در نظر گرفته شود.

هنگام بررسی رویدادها، روی شناسایی ایجاد یا تغییر سرویس‌ها و وظایف زمان‌بندی شده توسط حساب‌های کاربری غیرمجاز تمرکز کنید. به مسیر اجرایی (ImagePath) سرویس‌ها و دستورات (Task Action) وظایف توجه ویژه‌ای داشته باشید. مسیرهای غیرعادی مانند دایرکتوری‌هایی خارج از Program Files یا استفاده از اسکریپت‌ها می‌توانند نشانه‌های خطر باشند.

برای جستجو در لاگ‌ها، کوئری‌های زیر بر اساس رویدادهای استاندارد ویندوز و فیلدهای مستند تهیه شده‌اند. این کوئری‌ها را می‌توان در SIEMهایی مانند Splunk یا Microsoft Sentinel استفاده کرد. دقت کنید که این کوئری‌ها بر اساس شناسه رویدادهای رایج هستند و ممکن است بسته به تنظیمات محیط، نیاز به تنظیم داشته باشند.

// Detection for new services via Splunk
index=windows EventCode=7045
| table _time, host, Service_Name, Service_File_Name, Service_Start_Type, Service_Type, User
| where Service_File_Name != "C:\\Windows\\System32\\svchost.exe -k"

// Detection for scheduled tasks using KQL
WindowsEvent | where EventID == 4698 or EventID == 4699 or EventID == 4700 or EventID == 4701 or EventID == 4702 | project TimeGenerated, Computer, SubjectUserName, TaskName=EventData.TaskName, TaskContent=EventData.TaskContent, Command=EventData.TaskCommand

Triage and Investigation of Alerts

هنگام دریافت هشدار مرتبط با ایجاد یا تغییر سرویس، Scheduled Task یا کلیدهای Registry، نخستین گام، اعتبارسنجی اولیه هشدار است. این اعتبارسنجی باید بر پایه مقایسه با الگوهای شناخته‌شده و نه صرفاً بر اساس شهرت ابزار یا نام فرآیند انجام شود. برای نمونه، مسیر اجرایی سرویس یا وظیفه باید با مسیرهای استاندارد سیستم (مانند System32) مقایسه شود. وجود مسیرهایی مانند Temp، AppData یا پوشه‌های عمومی (Public) می‌تواند نشانه‌ای از رفتار غیرعادی باشد. همچنین نام سرویس یا وظیفه که به‌طور غیرعادی به نام فرآیندهای سیستمی (مانند svchost یا winlogon) شباهت دارد، نیازمند بررسی دقیق‌تر است.

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

در گام سوم، باید از ابزارهای استاندارد برای جمع‌آوری اطلاعات تکمیلی استفاده شود. برای سرویس‌ها، دستور sc query و بررسی رجیستری در مسیر HKLM\SYSTEM\CurrentControlSet\Services می‌تواند جزئیات مسیر اجرایی و نوع راه‌اندازی را نشان دهد. برای Scheduled Taskها، دستور schtasks /query /v و بررسی فایل‌های XML در پوشه Task Scheduler مفید است. همچنین باید به دنبال نشانه‌های پنهان‌سازی مانند حذف Security Descriptor یا تغییر در Index رجیستری مرتبط با وظایف بود. این بررسی‌ها باید با دقت و بدون فرض‌های بی‌پایه انجام شود و هر یافته باید مستند شود.

• مسیر اجرایی را با لیست سفید مسیرهای معتبر سیستم مقایسه کنید.
• نام سرویس یا وظیفه را با الگوهای شناخته‌شده ماسک‌کردن (مانند شباهت به نام‌های سیستمی) بررسی کنید.
• زمینه اجرا (کاربر، زمان‌بندی، استدلال‌ها) را استخراج و با رفتارهای عادی مقایسه کنید.
• تاریخچه ایجاد و تغییر رکورد را از رویدادهای امنیتی (مانند Event ID 7045 برای سرویس جدید) بررسی کنید.
• به دنبال نشانه‌های پنهان‌سازی مانند حذف Security Descriptor یا تغییر در Index رجیستری باشید.

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

sc qc <ServiceName>
schtasks /query /tn <TaskName> /v /fo LIST
reg query "HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>"

تحلیل و کاهش خطاهای مثبت کاذب

در پایش تداوم (Persistence) در ویندوز، رویدادهای مرتبط با ایجاد یا تغییر سرویس‌ها، وظایف زمان‌بندی شده (Scheduled Tasks) و کلیدهای رجیستری ممکن است به دلیل فعالیت‌های مشروع و روزمرهٔ سیستم، هشدارهای مثبت کاذب تولید کنند. برای نمونه، نصب به‌روزرسانی‌های نرم‌افزاری توسط ابزارهای مدیریتی مانند SCCM یا Windows Update می‌تواند به‌طور موقت سرویس‌هایی ایجاد یا وظایفی زمان‌بندی کند که از نظر تله‌متری مشابه رفتارهای مخرب هستند. همچنین، مدیران سیستم برای اجرای اسکریپت‌های نگهداری یا پشتیبان‌گیری، اغلب از Task Scheduler استفاده می‌کنند که این امر به‌تنهایی نشانهٔ نفوذ نیست.

برای کاهش نویز، پیشنهاد می‌شود که تحلیلگران ابتدا فهرست سفیدی از مسیرهای اجرایی معتبر، نام‌های سرویس و وظایف شناخته‌شدهٔ سازمانی تهیه کنند. این فهرست باید بر اساس مستندات رسمی فروشندگان نرم‌افزار و الگوهای تأییدشدهٔ مدیریتی باشد، نه حدس و گمان. به‌عنوان مثال، وظایفی که توسط ابزارهای معتبر مانند Microsoft Endpoint Configuration Manager ایجاد می‌شوند، معمولاً دارای امضای دیجیتال و مسیرهای استاندارد هستند. در گام بعد، باید زمینهٔ (Context) رویداد بررسی شود؛ از جمله حساب کاربری که تغییر را انجام داده، زمان وقوع، و ارتباط آن با سایر رویدادهای شبکه.

روش مؤثر دیگر، استفاده از تحلیل رفتاری مبتنی بر ناهنجاری است؛ به‌جای هشدار برای هر تغییر، باید به دنبال الگوهای غیرعادی مانند ایجاد هم‌زمان چند سرویس جدید با نام‌های مشابه، یا تغییر مسیر ImagePath در سرویس‌های سیستمی به مسیرهای غیرمعمول مانند پوشهٔ Temp بود. همچنین، توصیه می‌شود که هشدارها بر اساس سطح خطر طبقه‌بندی شوند؛ برای نمونه، تغییر در کلیدهای رجیستری Run که توسط فرآیندهای ناشناخته انجام شود، باید اولویت بالاتری نسبت به تغییرات ناشی از نصب نرم‌افزار امضا شده داشته باشد. در نهایت، بازخورد منظم از تیم عملیات امنیتی برای تنظیم دقیق قوانین تشخیص، ضروری است.

توجه: تمامی توصیه‌های فوق جنبهٔ دفاعی دارند و بر اساس موارد مستند و شناخته‌شدهٔ خطاهای مثبت کاذب ارائه شده‌اند. تحلیلگران باید از اعمال قوانین سخت‌گیرانه بدون بررسی زمینهٔ کامل رویداد خودداری کنند، زیرا این امر می‌تواند منجر به نادیده گرفته شدن هشدارهای واقعی به دلیل خستگی هشدار (Alert Fatigue) شود.

• ایجاد فهرست سفید از سرویس‌ها و وظایف معتبر بر اساس مستندات رسمی فروشندگان
• بررسی زمینهٔ رویداد شامل حساب کاربری، زمان و ارتباط با سایر فعالیت‌های شبکه
• استفاده از تحلیل ناهنجاری برای شناسایی الگوهای غیرعادی به‌جای هشدار برای هر تغییر
• طبقه‌بندی هشدارها بر اساس سطح خطر و اولویت‌بندی تغییرات در کلیدهای حساس رجیستری

1. مستندسازی و به‌روزرسانی دوره‌ای فهرست سفید از نرم‌افزارهای مجاز و وظایف مدیریتی
2. پیاده‌سازی قوانین تشخیص با شرط بررسی امضای دیجیتال و مسیرهای استاندارد
3. تنظیم مکانیزم بازخورد برای تحلیلگران جهت گزارش خطاهای مثبت کاذب و اصلاح قوانین

Get-ScheduledTask | Where-Object {$_.TaskPath -notlike '\Microsoft\*'} | Select-Object TaskName, TaskPath, State

محدودیت‌های شناسایی و شکاف‌ها

شناسایی تداوم (Persistence) از طریق سرویس‌های ویندوز و وظایف زمان‌بندی‌شده، همواره با محدودیت‌های ذاتی مواجه است که ریشه در طراحی سیستم‌عامل و رفتار ابزارهای بومی دارد. نخستین محدودیت، نبودِ ثبت رویداد (Logging) جامع برای برخی عملیات‌های سطح پایین است. به‌عنوان مثال، تغییر مستقیم رجیستری برای ایجاد یا اصلاح یک سرویس (مانند تغییر مقدار ImagePath) ممکن است در لاگ‌های امنیتی استاندارد (Security Log) ثبت نشود و تنها در لاگ‌های سیستم (System Log) با جزئیات ناکافی ظاهر شود. این شکاف اطلاعاتی، تحلیلگر را در تشخیص زمان دقیق و عامل تغییر دچار ابهام می‌کند.

دومین محدودیت، بهره‌گیری مهاجمان از ابزارهای بومی و مشروع (Living-off-the-Land) است. استفاده از ابزارهایی مانند sc.exe یا schtasks.exe که به‌طور معمول توسط مدیران سیستم استفاده می‌شوند، تمایز بین فعالیت مشروع و مخرب را دشوار می‌سازد. این ابزارها امضای دیجیتال معتبر دارند و رفتار آن‌ها در محیط، مشابه عملیات مدیریتی روزمره است؛ بنابراین، راهکارهای مبتنی بر لیست سیاه یا امضای فایل، در برابر این تکنیک‌ها کارایی چندانی ندارند و نیاز به تحلیل رفتاری و زمینه‌محور (Context-Aware) دارند.

سومین محدودیت، تکنیک‌های پنهان‌سازی پیشرفته است که مستندات امنیتی به آن‌ها اشاره کرده‌اند. برای نمونه، مهاجمان می‌توانند با استفاده از دستور sc sdset و زبان SDDL، مجوزهای یک سرویس را به‌گونه‌ای تغییر دهند که از دید ابزارهای شمارش استاندارد مانند Get-Service یا services.msc پنهان بماند. به‌طور مشابه، برای وظایف زمان‌بندی‌شده، حذف مقدار امنیتی Descriptor در رجیستور (با سطح دسترسی SYSTEM) می‌تواند وظیفه را از دید دستور schtasks /query و رابط گرافیکی Task Scheduler مخفی کند. این روش‌ها، اگرچه نیازمند دسترسی بالا هستند، اما در سناریوهای نفوذ پیشرفته مشاهده شده‌اند و چالش جدی برای ابزارهای شناسایی خودکار ایجاد می‌کنند.

در نهایت، باید اشاره کرد که بسیاری از ابزارهای شناسایی، بر اساس الگوهای شناخته‌شده و امضای رفتاری کار می‌کنند. مهاجمان با تغییر نام سرویس یا وظیفه به نام‌های مشابه با مؤلفه‌های سیستمی (Masquerading) یا تغییر ابرداده‌هایی مانند مقدار Index در رجیستور وظایف، می‌توانند از این الگوها فرار کنند. این امر نشان می‌دهد که تکیه صرف بر ابزارهای خودکار کافی نیست و ترکیب آن با بررسی دستی و عمیق رجیستری و پیکربندی سیستم، برای کاهش شکاف‌های شناسایی ضروری است.

• عدم ثبت رویدادهای تغییر مستقیم رجیستری در لاگ‌های امنیتی استاندارد
• دشواری تمایز بین استفاده مشروع و مخرب از ابزارهای بومی مانند sc.exe و schtasks.exe
• پنهان‌سازی سرویس‌ها از طریق تغییر SDDL با دستور sc sdset
• مخفی‌سازی وظایف زمان‌بندی‌شده با حذف مقدار Security Descriptor در رجیستور
• استفاده از نام‌های مشابه با مؤلفه‌های سیستمی برای فرار از شناسایی مبتنی بر امضا

شاخص‌های سنجش اثربخشی شناسایی

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

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

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

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

پوشش تکنیک‌ها (Coverage) مشخص می‌کند که سیستم شناسایی چه نسبتی از تکنیک‌های مرتبط با ماندگاری را پوشش می‌دهد. این شاخص بر اساس چارچوب‌هایی مانند MITRE ATT&CK تعریف می‌شود و باید به‌روزرسانی منظم داشته باشد. برای هر تکنیک، باید مشخص شود که آیا شناسایی به صورت مستقیم، غیرمستقیم یا از طریق داده‌های کمکی انجام می‌شود.

• نرخ شناسایی: درصد تشخیص صحیح نمونه‌های واقعی.
• زمان تا شناسایی: میانگین زمان بین ایجاد و تشخیص.
• نرخ مثبت کاذب: نسبت هشدارهای اشتباه.
• پوشش تکنیک‌ها: درصد تکنیک‌های پوشش‌داده‌شده از چارچوب مرجع.

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

Operationalization and Response Playbook Integration

برای عملیاتی‌سازی شناسایی ماندگاری در ویندوز، لازم است که تیم دفاعی ابتدا یک خط پایه از وضعیت عادی سرویس‌ها، وظایف زمان‌بندی‌شده و کلیدهای رجیستری مرتبط در محیط خود ایجاد کند. این خط پایه باید شامل نام سرویس‌ها، مسیر اجرایی، حساب کاربری، زمان‌بندی وظایف و مقادیر رجیستری در مسیرهای شناخته‌شده مانند HKLM\SYSTEM\CurrentControlSet\Services باشد. هرگونه انحراف از این خط پایه باید به‌عنوان یک رویداد مشکوک در نظر گرفته شود و بر اساس شدت آن، آستانه هشدار تعیین گردد. به‌عنوان مثال، ایجاد یک سرویس جدید با نامی شبیه به سرویس‌های سیستمی یا تغییر مسیر اجرایی یک سرویس موجود، باید بلافاصله هشدار سطح بالا تولید کند.

برای یکپارچه‌سازی این شناسایی‌ها در عملیات روزانه، پیشنهاد می‌شود که از چارچوب‌های پاسخ به حادثه مانند NIST SP 800-61 یا SANS PICERL استفاده شود. در فاز شناسایی، تیم باید از ابزارهای معتبر مانند Sysmon با شناسه رویدادهای مرتبط با ایجاد سرویس (Event ID 7045) و ایجاد وظیفه زمان‌بندی‌شده (Event ID 4698) استفاده کند. همچنین، پایش تغییرات رجیستری در مسیرهای حساس از طریق Windows Audit Policy یا ابزارهای EDR باید فعال باشد. در فاز مهار، باید به‌سرعت سرویس یا وظیفه مشکوک غیرفعال شده و نمونه‌برداری از حافظه و دیسک انجام شود. هماهنگی با تیم پاسخ به حادثه باید از طریق یک کانال ارتباطی مشخص و با ثبت دقیق زمان‌بندی اقدامات صورت گیرد.

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

• تعریف آستانه هشدار بر اساس تعداد رویدادهای مشکوک در یک بازه زمانی (مثلاً بیش از ۳ ایجاد سرویس جدید در یک ساعت).
• استفاده از چارچوب‌های پاسخ به حادثه مانند NIST SP 800-61 برای هماهنگی بین تیم‌های SOC و IR.
• فعال‌سازی لاگ‌های امنیتی مرتبط با ایجاد و تغییر سرویس‌ها و وظایف زمان‌بندی‌شده.
• انجام بازبینی دوره‌ای خط پایه و به‌روزرسانی قوانین شناسایی بر اساس تهدیدات جدید.

1. گام ۱: ایجاد خط پایه از سرویس‌ها، وظایف زمان‌بندی‌شده و کلیدهای رجیستری در محیط با استفاده از اسکریپت‌های مجاز.
2. گام ۲: پیکربندی ابزارهای جمع‌آوری لاگ (مانند Sysmon و Windows Event Log) برای ثبت رویدادهای مرتبط.
3. گام ۳: تعیین آستانه هشدار و ایجاد قوانین همبستگی در SIEM.
4. گام ۴: مستندسازی مراحل پاسخ به حادثه در playbook و آموزش تیم.
5. گام ۵: اجرای مانورهای دوره‌ای برای ارزیابی اثربخشی شناسایی و پاسخ.

Get-Service | Export-Csv -Path baseline_services.csv -NoTypeInformation
schtasks /query /fo CSV > baseline_tasks.csv
reg export HKLM\SYSTEM\CurrentControlSet\Services baseline_services.reg /y