تشخیص Living off the Land بدون انفجار False Positive

مفاهیم پایه و تعریف Living off the Land

Living off the Land (LotL) به مجموعه‌ای از تکنیک‌های تهاجمی گفته می‌شود که در آن مهاجم به جای استفاده از بدافزارهای مستقل، از ابزارها و قابلیت‌های مشروع موجود در سیستم عامل بهره می‌گیرد. این رویکرد به مهاجم امکان می‌دهد تا ردپای خود را در محیط کاهش دهد و از مکانیزم‌های امنیتی مبتنی بر امضا یا لیست سیاه برنامه‌ها عبور کند. در واقع، مهاجم با سوءاستفاده از ابزارهای معتبر و امضا شده، عملیات مخرب خود را در قالب رفتارهای به ظاهر عادی پنهان می‌کند.

در چارچوب MITRE ATT&CK، دو تکنیک اصلی برای توصیف این رفتار وجود دارد: «System Binary Proxy Execution» با شناسه T1218 و «Command and Scripting Interpreter» با شناسه T1059. تکنیک T1218 به مهاجم اجازه می‌دهد تا با استفاده از باینری‌های معتبر و امضا شده مانند rundll32.exe یا msiexec.exe، کدهای مخرب را اجرا کند. این باینری‌ها به دلیل اعتماد سیستم به امضای دیجیتال مایکروسافت، معمولاً توسط راهکارهای امنیتی مسدود نمی‌شوند. از سوی دیگر، تکنیک T1059 بر سوءاستفاده از مفسرهای خط فرمان و اسکریپت مانند PowerShell یا Unix Shell تمرکز دارد که به مهاجم امکان اجرای دستورات دلخواه را می‌دهد.

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

• تکنیک T1218 شامل زیرشاخه‌هایی مانند Regsvr32، Mshta و Rundll32 است که هر کدام می‌توانند برای اجرای کد مخرب مورد سوءاستفاده قرار گیرند.
• تکنیک T1059 شامل زیرشاخه‌هایی مانند PowerShell، Windows Command Shell و Unix Shell است که مهاجمان از آن‌ها برای اجرای دستورات و اسکریپت‌های مخرب استفاده می‌کنند.
• شناسایی دقیق این تکنیک‌ها نیازمند ترکیب داده‌های تله‌متری، تحلیل زنجیره فرآیندها و بررسی زمینه اجرای فرمان است.

تله‌متری‌ها و شواهد قابل جمع‌آوری

برای شناسایی فعالیت‌های Living off the Land (LotL) بدون ایجاد حجم بالای هشدارهای نادرست، باید بر تله‌متری‌هایی تمرکز کرد که رفتارهای غیرعادی را در استفاده از ابزارهای سیستمی نشان می‌دهند. این تله‌متری‌ها شامل لاگ‌های اجرای فرایند، آرگومان‌های خط فرمان، رویدادهای ایجاد فرایند، اتصالات شبکه، و بارگذاری ماژول‌ها هستند. به‌ویژه، ثبت دقیق رویدادهای مرتبط با اجرای باینری‌های معروف مانند rundll32.exe، msiexec.exe، regsvr32.exe و اسکریپت‌های PowerShell یا cmd.exe می‌تواند شواهد اولیه را فراهم کند. با این حال، صرف وجود این رویدادها به معنای فعالیت مخرب نیست و نیاز به تحلیل زمینه‌ای دارد.

برای کاهش هشدارهای نادرست، باید تله‌متری‌ها را با داده‌های زمینه‌ای مانند فرایند والد، کاربر در حال اجرا، مسیر فایل، و امضای دیجیتال ترکیب کرد. به عنوان مثال، اجرای rundll32.exe با آرگومان‌هایی که به یک فایل DLL در مسیر موقت اشاره می‌کند، نسبت به اجرای معمول آن با فایل‌های سیستمی، مشکوک‌تر است. همچنین، دنباله‌های غیرعادی از دستورات، مانند استفاده از ابزارهای سیستمی برای دانلود محتوا از اینترنت یا اجرای کد از طریق اسکریپت‌های تعبیه‌شده، می‌تواند نشانه‌ای از LotL باشد. این رفتارها باید با الگوهای شناخته‌شده از فعالیت‌های مخرب مقایسه شوند، نه صرفاً با لیست سیاه ابزارها.

توصیه می‌شود که تله‌متری‌ها به‌صورت متمرکز جمع‌آوری و با یکدیگر همبسته شوند تا دید کاملی از زنجیره رویدادها به دست آید. برای مثال، ترکیب لاگ‌های اجرای فرایند با رویدادهای ایجاد فایل و اتصالات شبکه می‌تواند الگوهای LotL را آشکار کند. همچنین، استفاده از تکنیک‌های آماری و یادگیری ماشین برای شناسایی ناهنجاری‌ها در رفتار کاربران و سیستم‌ها می‌تواند به تشخیص فعالیت‌های LotL کمک کند، به شرطی که مدل‌ها با داده‌های محیط خود سازمان آموزش دیده باشند. در نهایت، باید به‌طور منظم پایگاه‌های دانش تهدیدات را به‌روز کرد و از منابع معتبر مانند MITRE ATT&CK برای به‌روز نگه‌داشتن الگوهای شناسایی استفاده نمود.

در این زمینه، شواهد قابل جمع‌آوری شامل موارد زیر است: رویدادهای ایجاد فرایند (مانند رویداد 4688 در ویندوز)، لاگ‌های PowerShell (مانند رویداد 4104)، رویدادهای خط فرمان (مانند رویداد 4103)، و لاگ‌های اتصال شبکه (مانند رویداد 5156). همچنین، رویدادهای بارگذاری ماژول (مانند رویداد 4688 با جزئیات ماژول) و رویدادهای دسترسی به اشیاء (مانند رویداد 4663) می‌توانند مفید باشند. برای سیستم‌های لینوکسی، می‌توان از auditd یا sysmon برای لینوکس استفاده کرد. این شواهد باید با دقت و با در نظر گرفتن حریم خصوصی و مقررات جمع‌آوری شوند.

• رویدادهای ایجاد فرایند با جزئیات کامل (شناسه فرایند، فرایند والد، آرگومان‌ها)
• لاگ‌های خط فرمان و اسکریپت‌ها (PowerShell، cmd، bash)
• رویدادهای بارگذاری ماژول‌ها و فایل‌های DLL
• لاگ‌های اتصال شبکه (آدرس مقصد، پورت، پروتکل)
• رویدادهای ایجاد و تغییر فایل در مسیرهای حساس (مانند پوشه‌های موقت)
• اطلاعات مربوط به امضای دیجیتال باینری‌ها و اسکریپت‌ها

1. تعریف خط مبنا از رفتار عادی برای هر نقش و سیستم
2. جمع‌آوری تله‌متری‌های ذکر شده از منابع مختلف
3. همبستگی رویدادها برای شناسایی زنجیره‌های رفتاری غیرعادی
4. استفاده از الگوهای شناخته‌شده LotL از منابع معتبر
5. بررسی دستی موارد مشکوک و تصمیم‌گیری نهایی

طراحی گردش کار تشخیص

برای تشخیص رفتارهای مشکوک مرتبط با Living off the Land (LoTL) بدون ایجاد حجم بالای هشدارهای نادرست، لازم است گردش کاری طراحی شود که بر پایه تحلیل زمینه‌ای و نه صرفاً تطبیق الگوهای ساده استوار باشد. رویکرد پیشنهادی شامل سه مرحله اصلی است: جمع‌آوری داده‌های رفتاری، تحلیل زمینه‌ای، و اعمال سیاست‌های کاهش هشدار. این گردش کار باید از داده‌های موجود در منابع معتبر مانند شناسه‌های تحلیل AN0226، AN0227 و AN0228 استفاده کند و از افزودن مراحل جدید که ممکن است منجر به پیچیدگی غیرضروری یا نویز شود، خودداری نماید.

مرحله نخست، جمع‌آوری داده‌های رفتاری از اجرای باینری‌های سیستمی معتبر مانند rundll32.exe، msiexec.exe و regsvr32.exe در ویندوز، و ابزارهایی مانند split، tee و bash در لینوکس است. این داده‌ها باید شامل پارامترهای خط فرمان، ترتیب اجرا، و ارتباطات شبکه‌ای باشند. به عنوان مثال، شناسه AN0226 بر روی اجرای باینری‌های معتمد برای بارگذاری بارهای خارجی یا امضا نشده تمرکز دارد. برای کاهش هشدارهای نادرست، پیشنهاد می‌شود که رویدادها بر اساس انحراف از رفتار پایه (baseline) هر سیستم و نه صرفاً وجود الگوهای خاص، غربالگری شوند.

در مرحله دوم، تحلیل زمینه‌ای با استفاده از داده‌های جمع‌آوری شده انجام می‌شود. این تحلیل باید شامل بررسی زنجیره فراخوانی‌ها، ارتباط با آدرس‌های IP یا دامنه‌های ناشناخته، و همبستگی با سایر رویدادهای امنیتی باشد. برای مثال، اجرای یک باینری معتبر که به یک URL خارجی متصل می‌شود و سپس یک اسکریپت را اجرا می‌کند، می‌تواند مشکوک باشد. در این مرحله، استفاده از لیست سفید برنامه‌های مجاز و لیست سیاه الگوهای شناخته‌شده می‌تواند کمک کند، اما باید توجه داشت که این لیست‌ها باید به‌روز نگه داشته شوند و بر اساس محیط هر سازمان سفارشی شوند.

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

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

• استفاده از داده‌های شناسایی AN0226، AN0227 و AN0228 به عنوان پایه‌های اصلی تحلیل
• جمع‌آوری داده‌های اجرای باینری‌های معتبر با جزئیات خط فرمان و شبکه
• تحلیل زمینه‌ای بر اساس رفتار پایه و انحراف از آن
• اعمال آستانه‌های پویا و قوانین کاهش هشدار
• یکپارچه‌سازی با SIEM و EDR برای پاسخ سریع

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

فرآیند بررسی و تریاژ هشدارها

در مواجهه با هشدارهای مرتبط با اجرای ابزارهای سیستمی (Living off the Land)، نخستین گام، پرهیز از واکنش سریع و بررسی زمینه‌مند رویداد است. بسیاری از این هشدارها به دلیل فعالیت‌های مدیریتی معمول، اسکریپت‌های نگهداری یا نصب نرم‌افزارهای مجاز تولید می‌شوند. بنابراین، تریاژ مؤثر نیازمند گردآوری اطلاعات زمینه‌ای از منابع متعدد مانند لاگ‌های احراز هویت، تاریخچه فرمان‌ها، ارتباطات شبکه‌ای و وضعیت فرآیندها است. این اطلاعات باید در یک بازه زمانی مشخص (مثلاً ۲۴ ساعت قبل و بعد از رویداد) بررسی شوند تا الگوهای عادی از رفتارهای مشکوک تفکیک گردد.

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

در مرحله تریاژ، اولویت‌بندی هشدارها بر اساس معیارهایی مانند سطح دسترسی فرآیند، وجود ارتباطات شبکه‌ای به آدرس‌های پرخطر، و ترکیب زنجیره‌ای از ابزارها (مثلاً استفاده از rundll32 برای اجرای یک فایل DLL از مسیر موقت) انجام می‌شود. هشدارهایی که شامل چندین شاخص پرخطر هستند، باید در صدر بررسی قرار گیرند. برای کاهش حجم هشدارهای کاذب، می‌توان قوانین suppression را برای سناریوهای کاملاً شناخته‌شده و بی‌خطر (مانند اجرای دستور ipconfig توسط مدیر سیستم) اعمال کرد، اما این قوانین باید به دقت مستند شده و به صورت دوره‌ای بازبینی شوند تا از پوشش حملات جدید جلوگیری نشود.

• گردآوری اطلاعات زمینه‌ای از منابع متعدد (لاگ‌ها، فرآیندها، شبکه) قبل از هر تصمیم‌گیری.
• ایجاد خط مبنا از رفتار عادی برای هر میزبان و مقایسه رویدادها با آن.
• اولویت‌بندی هشدارها بر اساس سطح دسترسی، ارتباطات شبکه‌ای و زنجیره ابزارها.
• استفاده از قوانین suppression فقط برای سناریوهای کاملاً مستند و بی‌خطر.

1. بررسی هشدار در داشبورد SIEM و استخراج شناسه رویداد، زمان، میزبان و کاربر مرتبط.
2. جستجو در لاگ‌های امنیتی برای یافتن رویدادهای مرتبط (ورود، اجرای فرمان، اتصال شبکه) در بازه زمانی مشخص.
3. مقایسه رفتار با خط مبنای میزبان؛ در صورت نبود خط مبنا، با مدیر سیستم گفتگو کنید.
4. در صورت وجود شاخص‌های پرخطر (مانند آدرس IP ناشناخته یا فایل غیرعادی)، هشدار را به سطح بالا ارتقا دهید و نمونه‌برداری کنید.

مدیریت False Positive و چالش‌های آن

تشخیص Living off the Land (LoTL) به دلیل استفاده مهاجمان از ابزارهای معتبر و نرمال سیستم، همواره با چالش تولید هشدارهای نادرست (False Positive) همراه است. باینری‌های سیستمی مانند rundll32.exe، msiexec.exe و regsvr32.exe به طور معمول در فرآیندهای روزمره به کار می‌روند و هر قاعده تشخیصی که صرفاً بر اساس نام این فایل‌ها یا اجرای آن‌ها باشد، به سرعت با حجم بالایی از رویدادهای غیرمخرب مواجه می‌شود. این مسئله نه تنها بار تحلیلی را افزایش می‌دهد، بلکه اعتماد تیم امنیتی به هشدارها را کاهش می‌دهد و ممکن است منجر به نادیده گرفته شدن تهدیدات واقعی شود.

ریشه اصلی False Positive در تشخیص LoTL به تفاوت رفتاری بین استفاده عادی و سوءاستفاده از این ابزارها بازمی‌گردد. به عنوان مثال، اجرای rundll32.exe برای بارگذاری یک کتابخانه استاندارد ویندوز رفتاری عادی است، اما اگر همین فایل با پارامترهایی برای دریافت کد از یک آدرس خارجی یا اجرای یک فایل DLL غیراستاندارد فراخوانی شود، احتمال سوءاستفاده افزایش می‌یابد. بنابراین، تشخیص مؤثر نیازمند تحلیل زمینه (Context) و ترکیب چندین شاخص رفتاری است، نه صرفاً تطبیق نام فرآیند یا آرگومان‌های ساده.

برای کاهش False Positive، پیشنهاد می‌شود که قواعد تشخیصی بر اساس ترکیبی از شاخص‌های زیر طراحی شوند: (۱) زنجیره فراخوانی (Parent-Child Relationship)؛ به عنوان مثال، اجرای cmd.exe توسط یک برنامه آفیس یا مرورگر می‌تواند مشکوک باشد. (۲) آرگومان‌های خط فرمان که شامل الگوهای غیرعادی مانند استفاده از IEX، DownloadString، یا ارجاع به URLهای خارجی هستند. (۳) رفتارهای شبکه‌ای همزمان، مانند اتصال به دامنه‌های تازه‌ثبت‌شده یا آدرس‌های IP غیرمعمول. (۴) فراوانی اجرا در بازه زمانی کوتاه یا توالی غیرعادی از چند ابزار LoTL.

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

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

• استفاده از زنجیره فراخوانی و روابط والد-فرزندی به جای نام فرآیند به تنهایی
• تحلیل آرگومان‌های خط فرمان با الگوهای شناخته‌شده سوءاستفاده
• ترکیب شاخص‌های رفتاری و شبکه‌ای برای کاهش هشدارهای نادرست
• به‌کارگیری لیست سفید برای فرآیندهای مجاز در محیط
• طراحی مدل امتیازدهی با آستانه پویا

1. شناسایی ابزارهای LoTL رایج در محیط سازمان و موارد استفاده مجاز آن‌ها
2. جمع‌آوری داده‌های پایه از رفتار عادی (Baseline) برای هر میزبان
3. تعریف شاخص‌های رفتاری با وزن‌دهی مناسب
4. پیاده‌سازی قواعد تشخیصی به صورت آزمایشی و ارزیابی نرخ False Positive
5. بهینه‌سازی آستانه‌ها بر اساس بازخورد تیم تحلیل و رویدادهای واقعی

محدودیت‌های روش‌های تشخیص

تشخیص فعالیت‌های Living off the Land (LotL) به دلیل استفاده مهاجمان از ابزارهای معتبر و نصب‌شده در سیستم، با چالش‌های بنیادین مواجه است. روش‌های سنتی مبتنی بر تله‌متری، مانند شناسایی امضای بدافزار یا مسیرهای فایل غیرعادی، در برابر این تکنیک‌ها کارایی محدودی دارند؛ زیرا اجرای باینری‌های سیستمی مانند rundll32.exe یا msiexec.exe به‌تنهایی نشانه قطعی فعالیت مخرب نیست. این ابزارها به‌طور معمول در محیط‌های سالم نیز استفاده می‌شوند و همین امر، تشخیص را به یک مسئله آماری و زمینه‌محور تبدیل می‌کند.

چالش اصلی در این است که مهاجمان با بهره‌گیری از باینری‌های مورد اعتماد، امضای دیجیتال معتبر را دور می‌زنند و اجرای کدهای مخرب را در قالب فرآیندهای قانونی پنهان می‌کنند. به عنوان مثال، تکنیک System Binary Proxy Execution (T1218) نشان می‌دهد که چگونه ابزارهایی مانند InstallUtil یا Regsvr32 می‌توانند برای بارگذاری و اجرای محتوای مخرب مورد سوءاستفاده قرار گیرند. در چنین شرایطی، تله‌متری که صرفاً بر روی نام فرآیند یا مسیر فایل تمرکز دارد، به سرعت با حجم بالایی از هشدارهای نادرست (False Positive) مواجه می‌شود و تیم دفاعی را از شناسایی تهدید واقعی بازمی‌دارد.

علاوه بر این، مهاجمان از تکنیک‌های فرار برای پنهان‌سازی فعالیت خود استفاده می‌کنند؛ مانند استفاده از اسکریپت‌نویسی در PowerShell یا Windows Command Shell (T1059) که امکان اجرای دستورات پیچیده را بدون نیاز به فایل‌های اجرایی جداگانه فراهم می‌کند. این روش‌ها به مهاجم اجازه می‌دهند تا ردپای دیجیتال را به حداقل برساند و تشخیص را به داده‌های رفتاری و زمینه‌ای وابسته کند. بنابراین، هر رویکرد تشخیصی باید فراتر از رویدادهای ساده، به تحلیل زنجیره‌ای رفتارها و روابط بین فرآیندها بپردازد.

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

شاخص‌های ارزیابی عملکرد تشخیص

ارزیابی اثربخشی هر سیستم تشخیصی مستلزم تعریف معیارهای سنجش است که فراتر از نرخ خام تشخیص باشد. در حوزه تشخیص Living off the Land (LotL)، پیچیدگی اصلی در تفکیک رفتار مشروع از رفتار مخرب نهفته است؛ زیرا مهاجمان از ابزارهای بومی و معتبر سیستم استفاده می‌کنند. بنابراین، معیارهای ارزیابی باید به‌گونه‌ای طراحی شوند که هم توانایی شناسایی تهدید را بسنجند و هم هزینه‌های ناشی از خطاهای تشخیصی را در نظر بگیرند.

یکی از مهم‌ترین معیارها، دقت (Precision) است که نسبت هشدارهای صحیح به کل هشدارهای صادرشده را نشان می‌دهد. در محیط‌های عملیاتی، دقت پایین به معنای انفجار False Positive است که می‌تواند منجر به خستگی تحلیلگران و نادیده‌گرفتن هشدارهای واقعی شود. در مقابل، معیار Recall یا حساسیت، توانایی سیستم در شناسایی رویدادهای واقعی را می‌سنجد. تعادل میان این دو معیار، چالش اصلی در طراحی سیستم‌های تشخیص LotL است؛ زیرا افزایش حساسیت معمولاً با کاهش دقت همراه است.

علاوه بر دقت و Recall، معیارهای دیگری مانند زمان تشخیص (Time to Detect) و هزینه تحلیل (Analyst Workload) نیز حائز اهمیت هستند. زمان تشخیص طولانی می‌تواند به مهاجم فرصت دهد تا به اهداف خود برسد، در حالی که حجم بالای هشدارهای نیازمند بررسی دستی، منابع تیم امنیتی را تحلیل می‌برد. همچنین، معیار پایداری (Stability) سیستم در برابر تغییرات محیطی (مانند به‌روزرسانی سیستم‌عامل یا تغییر رفتار کاربران) باید ارزیابی شود تا اطمینان حاصل شود که سیستم در طول زمان کارایی خود را حفظ می‌کند.

پیشنهاد می‌شود که ارزیابی عملکرد به‌صورت دوره‌ای و با استفاده از مجموعه داده‌های برچسب‌گذاری‌شده از محیط واقعی انجام شود. این ارزیابی باید شامل سناریوهای مختلف LotL، از جمله استفاده از باینری‌های معتمد (مانند T1218) و مفسرهای خط فرمان (مانند T1059) باشد. همچنین، مقایسه عملکرد سیستم با خط پایه (Baseline) رفتاری هر میزبان، می‌تواند به کاهش False Positive کمک کند. در نهایت، توصیه می‌شود که معیارهای ارزیابی به‌صورت شفاف مستند شده و در فرآیند بهبود مستمر سیستم تشخیص لحاظ شوند.

• دقت (Precision): نسبت هشدارهای صحیح به کل هشدارها؛ کاهش False Positive.
• حساسیت (Recall): نسبت رویدادهای واقعی شناسایی‌شده؛ کاهش False Negative.
• زمان تشخیص: فاصله زمانی بین وقوع رویداد و صدور هشدار.
• هزینه تحلیل: تعداد هشدارهایی که نیاز به بررسی دستی دارند.
• پایداری: حفظ کارایی در شرایط تغییرات محیطی.

1. تعریف سناریوهای LotL رایج در محیط سازمان بر اساس ماتریس ATT&CK.
2. جمع‌آوری داده‌های آموزشی و آزمون از لاگ‌های واقعی و شبیه‌سازی‌شده.
3. اجرای سیستم تشخیص بر روی داده‌های آزمون و محاسبه معیارهای فوق.
4. تحلیل نتایج و تنظیم آستانه‌ها برای ایجاد تعادل بین دقت و حساسیت.
5. بازبینی دوره‌ای معیارها و به‌روزرسانی آنها بر اساس بازخورد تیم امنیتی.

عملیاتی‌سازی و یکپارچه‌سازی در SOC

برای استقرار عملیاتی تشخیص Living off the Land (LotL) در محیط‌های واقعی، نخستین گام، محدودسازی سطح حمله از طریق سیاست‌های کنترل اجرا است. بر اساس توصیه‌های MITRE، استفاده از Application Control برای جلوگیری از اجرای باینری‌هایی که در محیط ضروری نیستند، یکی از مؤثرترین اقدامات پیشگیرانه محسوب می‌شود. این اقدام نه‌تنها به‌طور مستقیم از سوءاستفاده‌های شناخته‌شده جلوگیری می‌کند، بلکه حجم رویدادهای امنیتی را نیز کاهش می‌دهد و در نتیجه، بار تحلیلی روی SOC را کم می‌کند.

در گام دوم، باید تشخیص را بر اساس رفتارهای غیرعادی و نه صرفاً امضای بدافزار طراحی کرد. به‌عنوان مثال، اجرای باینری‌های سیستمی مانند rundll32.exe یا msiexec.exe با پارامترهای غیرمعمول، یا زنجیره‌ای از دستورات که خارج از الگوی عادی کاربران است، می‌تواند نشانه‌ای از فعالیت خصمانه باشد. توصیه می‌شود که تحلیلگران SOC از داده‌های Telemetry سطح بالا (مانند رویدادهای ایجاد فرایند و اتصالات شبکه) استفاده کنند و هشدارها را بر اساس زمینه (Context) و نه صرفاً تطبیق الگو تنظیم نمایند.

برای کاهش False Positive، لازم است که SOC یک فرایند «بازخورد و تنظیم» مستمر داشته باشد. این فرایند شامل مستندسازی رفتارهای عادی هر نقش کاربری و هر سرور، و به‌روزرسانی منظم لیست‌های سفید (Allowlist) بر اساس نیازهای واقعی کسب‌وکار است. همچنین، توصیه می‌شود که از تکنیک‌های محدودسازی دسترسی مانند Privileged Account Management استفاده شود تا اجرای باینری‌های آسیب‌پذیر تنها به حساب‌های دارای مجوز محدود گردد. این اقدام، هم احتمال سوءاستفاده را کاهش می‌دهد و هم تشخیص را دقیق‌تر می‌کند.

• استقرار Application Control برای باینری‌های پرخطر و غیرضروری
• استفاده از داده‌های Telemetry فرایند و شبکه برای تشخیص رفتارهای غیرعادی
• طراحی هشدارها بر اساس زمینه و الگوهای رفتاری، نه صرفاً امضای ثابت
• ایجاد فرایند بازخورد برای به‌روزرسانی Allowlist و کاهش False Positive
• محدودسازی دسترسی به باینری‌های حساس از طریق مدیریت حساب‌های دارای امتیاز

1. گام ۱: شناسایی باینری‌های سیستمی موجود در محیط و تعیین موارد ضروری برای هر نقش.
2. گام ۲: پیاده‌سازی Application Control برای مسدودسازی باینری‌های غیرضروری.
3. گام ۳: فعال‌سازی لاگ‌های امنیتی مرتبط با ایجاد فرایند و اتصالات شبکه.
4. گام ۴: تعریف الگوهای رفتاری عادی برای هر گروه از کاربران و سرورها.
5. گام ۵: تنظیم هشدارها بر اساس انحراف از الگوهای عادی و بازبینی دوره‌ای آن‌ها.