Memory Forensics برای Triage؛ چه زمانی حافظه تعیین‌کننده است؟

مفاهیم پایه‌ی Memory Forensics و نقش آن در Triage

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

ابزارهای متنوعی برای تحلیل حافظه وجود دارند که از میان آن‌ها، چارچوب متن‌باز Volatility 3 به دلیل قابلیت‌های پیشرفته و پشتیبانی گسترده از سیستم‌عامل‌های مختلف، به عنوان یک استاندارد عملی در این حوزه شناخته می‌شود. این ابزار با استفاده از پلاگین‌های متعدد، امکان استخراج اطلاعات حیاتی از تصویر حافظه را فراهم می‌کند. برای نمونه، پلاگین‌هایی مانند windows.pslist و windows.pstree به ترتیب برای فهرست‌کردن فرآیندهای در حال اجرا و نمایش درخت سلسله‌مراتب آن‌ها به کار می‌روند. این اطلاعات پایه‌ای، اولین گام برای شناسایی فرآیندهای غیرعادی یا مشکوک در یک سیستم آلوده هستند و به تحلیلگر اجازه می‌دهند تا با سرعت بیشتری به سرنخ‌های اصلی حمله دست یابد.

نکته‌ی حائز اهمیت این است که تحلیل حافظه در triage، جایگزینی برای تحلیل دیسک نیست، بلکه مکملی حیاتی برای آن محسوب می‌شود. در حالی که تحلیل دیسک می‌تواند اطلاعاتی درباره‌ی بدافزارهای ماندگار (Persistent Malware) و آثار باقی‌مانده از فعالیت‌های گذشته ارائه دهد، تحلیل حافظه برای شناسایی تهدیدات در حال اجرا، مانند بدافزارهای بدون فایل (Fileless Malware) یا تکنیک‌های فرار از شناسایی، ضروری است. بنابراین، تصمیم‌گیری در مورد اینکه چه زمانی تحلیل حافظه تعیین‌کننده است، به ماهیت حادثه و سوالات مطرح‌شده در triage بستگی دارد. اگر سوال اصلی این باشد که «چه چیزی در حال حاضر روی سیستم در حال اجراست؟»، تحلیل حافظه پاسخ قطعی را ارائه می‌دهد.

با این حال، باید در نظر داشت که تحلیل حافظه نیز محدودیت‌هایی دارد. کیفیت و کامل بودن شواهد استخراج‌شده به عواملی مانند نحوه‌ی اخذ تصویر حافظه، وضعیت سیستم در زمان اخذ، و وجود ساختارهای Symbol Table مناسب برای نسخه‌ی دقیق سیستم‌عامل بستگی دارد. بنابراین، در triage، تحلیلگر باید با آگاهی از این محدودیت‌ها، از تحلیل حافظه به عنوان یک ابزار قدرتمند اما نه بی‌خطا استفاده کند و نتایج آن را در کنار سایر منابع اطلاعاتی مورد ارزیابی قرار دهد.

• تعریف Memory Forensics: فرآیند استخراج و تحلیل شواهد دیجیتال از تصویر حافظه‌ی فرار سیستم.
• نقش در Triage: ارائه‌ی تصویری زنده از وضعیت سیستم در لحظه‌ی حادثه، که برای اولویت‌بندی واکنش حیاتی است.
• ابزار اصلی: Volatility 3 به عنوان چارچوبی متن‌باز و پیشرفته برای تحلیل حافظه.
• پلاگین‌های کلیدی: windows.pslist برای فهرست فرآیندها و windows.pstree برای نمایش درخت فرآیندها.
• مکمل بودن با تحلیل دیسک: حافظه برای تهدیدات در حال اجرا و دیسک برای آثار ماندگار حیاتی است.

شواهد و تله‌متری‌های قابل استخراج از حافظه

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

برای استخراج این شواهد، چارچوب Volatility 3 پلاگین‌های تخصصی و مستندی را ارائه می‌دهد. برای نمونه، پلاگین windows.netscan برای شناسایی اتصالات شبکه‌ی فعال و سوکت‌های باز در حافظه به کار می‌رود که می‌تواند ارتباطات مخرب با سرورهای فرماندهی و کنترل (C2) را آشکار کند. همچنین، پلاگین linux.bash می‌تواند دستورات اجراشده در تاریخچه‌ی پوسته‌ی فرمان را بازیابی کند و بینش مستقیمی از اقدامات مهاجم در سیستم‌های لینوکسی ارائه دهد. علاوه بر این، پلاگین‌هایی مانند windows.malfind برای شناسایی کدهای مخرب تزریق‌شده در حافظه‌ی فرآیندها طراحی شده‌اند که یکی از تکنیک‌های رایج فرار از شناسایی است.

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

با این حال، لازم است به این نکته توجه شود که استخراج و تفسیر این شواهد نیازمند دقت و دانش فنی بالایی است. وجود داده‌های متناقض یا ناقص در حافظه، یا عدم تطابق نسخه‌ی Symbol Table با سیستم‌عامل مورد بررسی، می‌تواند منجر به نتایج نادرست شود. بنابراین، در triage، توصیه می‌شود که یافته‌های حاصل از تحلیل حافظه به عنوان شواهد اولیه در نظر گرفته شوند و برای تأیید نهایی، با سایر منابع اطلاعاتی مانند لاگ‌های سیستم و تحلیل دیسک مورد تطبیق قرار گیرند. این رویکرد چندلایه، دقت تصمیم‌گیری‌های بعدی را به طور قابل توجهی افزایش می‌دهد.

• لیست فرآیندها: شناسایی فرآیندهای غیرعادی و مرتبط با بدافزار.
• اتصالات شبکه: کشف ارتباطات با زیرساخت‌های فرماندهی و کنترل (C2).
• دستورات اجراشده: بازیابی تاریخچه‌ی پوسته برای درک اقدامات مهاجم.
• ماژول‌های بارگذاری‌شده: شناسایی درایورها یا کتابخانه‌های مشکوک.
• هم‌راستایی با MITRE ATT&CK: مرتبط‌سازی شواهد با تکنیک‌هایی مانند T1057.

گردش کار پیشنهادی برای Memory Triage

تحلیل حافظه در فرآیند triage زمانی ارزشمند است که داده‌های موجود در دیسک پاسخ قانع‌کننده‌ای به سوالات امنیتی ندهند. گردش کار پیشنهادی با جمع‌آوری تصویر حافظه آغاز می‌شود. این مرحله باید با ابزارهای معتبر و در محیطی کنترل‌شده انجام شود تا صحت داده‌ها حفظ شود. پس از جمع‌آوری، نوبت به اجرای پلاگین‌های کلیدی می‌رسد. در این مرحله، پلاگین‌هایی مانند windows.pslist برای فهرست‌کردن فرآیندها و windows.malfind برای شناسایی کدهای مخرب تزریق‌شده در حافظه، اهمیت ویژه‌ای دارند. این پلاگین‌ها به تحلیلگر اجازه می‌دهند تا تصویری از وضعیت لحظه‌ای سیستم به دست آورد.

پس از اجرای پلاگین‌ها، تفسیر نتایج مهم‌ترین گام است. برای مثال، وجود یک فرآیند مشکوک که در خروجی windows.pslist دیده می‌شود اما در تحلیل‌های مبتنی بر دیسک اثری از آن نیست، می‌تواند نشانه‌ای از یک بدافزار بدون ردپای دیسکی باشد. در این مرحله، تحلیلگر باید خروجی پلاگین‌های مختلف را با یکدیگر مقایسه کند. برای نمونه، تطبیق‌دادن شناسه فرآیند (PID) یافت‌شده در خروجی windows.pslist با خروجی windows.pstree می‌تواند روابط والد-فرزندی را روشن کند. این تطبیق‌ها به تایید یا رد فرضیه‌های اولیه کمک می‌کند.

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

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

• جمع‌آوری تصویر حافظه با ابزارهای معتبر و حفظ زنجیره نگهداشت شواهد
• اجرای پلاگین‌های پایه مانند windows.pslist برای شناسایی فرآیندها و windows.malfind برای یافتن کدهای مخرب
• تطبیق خروجی پلاگین‌ها برای تایید فرضیه‌ها و کشف روابط پنهان
• مستندسازی یافته‌ها و ایجاد حلقه بازخورد برای تحلیل‌های تکمیلی در صورت نیاز
• تایید صحت عملکرد پلاگین‌ها با استفاده از داده‌های مرجع معتبر قبل از اتکا به خروجی آن‌ها در تصمیم‌گیری‌های حساس امنیتی
• توجه به این نکته که خروجی پلاگین‌ها باید در بستر داده‌های دیگر مانند گزارش‌های شبکه تفسیر شود تا از تحلیل‌های سطحی و گمراه‌کننده پرهیز شود.

1. گام اول: اطمینان از صحت تصویر حافظه با استفاده از هش‌های معتبر و ثبت زمان‌بندی جمع‌آوری.
2. گام دوم: اجرای پلاگین windows.pslist برای دریافت فهرست فرآیندها و ثبت شناسه‌های آن‌ها.
3. گام سوم: اجرای windows.malfind برای شناسایی نواحی حافظه‌ای که حاوی کد اجرایی مشکوک هستند.
4. گام چهارم: تحلیل خروجی‌ها و تطبیق آن‌ها با یکدیگر برای یافتن ناهنجاری‌ها.

vol -f memory.raw windows.pslist
vol -f memory.raw windows.malfind

نقش Memory Forensics در Triage اولیه و تصمیم‌گیری

در triage اولیه، تحلیل حافظه زمانی تعیین‌کننده است که شواهد دیجیتال در لایه‌های سنتی (مانند فایل‌های روی دیسک) قادر به پاسخ‌گویی به سوالات کلیدی نباشند. برای مثال، در سناریوی شناسایی بدافزارهای بدون ردپای دیسکی (fileless) که به‌طور مستقیم در حافظه اجرا می‌شوند، تحلیل حافظه تنها راه‌حل است. در این موارد، پلاگین windows.malfind از Volatility 3 می‌تواند مناطقی از حافظه را که حاوی کد اجرایی هستند و به فایل‌های مجزا نگاشت نشده‌اند، شناسایی کند. این قابلیت به تحلیلگر اجازه می‌دهد تا ردپای بدافزار را که در غیر این صورت نامرئی می‌ماند، مشاهده کند.

علاوه بر این، تحلیل حافظه در شناسایی فرآیندهای مخفی (rootkits) نقش حیاتی دارد. فرآیندهایی که با تکنیک‌های پیشرفته‌تر مانند Direct Kernel Object Manipulation (DKOM) پنهان شده‌اند، ممکن است در خروجی ابزارهای مدیریتی سیستمعامل دیده نشوند. اما پلاگین windows.pslist با دسترسی مستقیم به ساختارهای هسته، این فرآیندها را فهرست می‌کند. این قابلیت در مستندات Volatility 3 به‌عنوان یکی از کاربردهای اصلی این پلاگین ذکر شده است. بنابراین، در شرایطی که شک به وجود rootkit وجود دارد، تحلیل حافظه به یک ابزار تصمیم‌ساز تبدیل می‌شود.

با این حال، باید توجه داشت که تحلیل حافظه در همه موارد ضروری نیست. اگر شواهد دیسکی به‌اندازه کافی برای پاسخ به سوالات triage وجود داشته باشد، تحلیل حافظه می‌تواند به‌عنوان یک مرحله تکمیلی برای تایید یا رد فرضیه‌ها در نظر گرفته شود. به عبارت دیگر، تحلیل حافظه باید بر اساس یک فرضیه مشخص و با هدف پاسخ به سوالات خاص انجام شود. این رویکرد هدفمند، از اتلاف زمان و منابع جلوگیری می‌کند.

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

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

1. ارزیابی اولیه: تعیین اینکه آیا شواهد دیسکی برای پاسخ به سوالات triage کافی هستند یا خیر.
2. انتخاب پلاگین مناسب: در صورت نیاز، انتخاب پلاگین‌هایی مانند windows.pslist برای فهرست‌کردن فرآیندها یا windows.malfind برای یافتن کدهای مخرب.
3. اجرا و تفسیر: اجرای پلاگین‌ها و تفسیر نتایج در بستر فرضیه اولیه.
4. تصمیم‌گیری: استفاده از نتایج برای تصمیم‌گیری در مورد مراحل بعدی، مانند قرنطینه سیستم یا انجام تحلیل‌های تکمیلی.

vol -f memory.raw windows.pslist --pid 1234
vol -f memory.raw windows.malfind --pid 1234

مثبت‌های کاذب و چالش‌های تفسیر در Memory Forensics

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

مستندات Volatility 3 به صراحت اشاره می‌کند که برای تحلیل دقیق، وجود symbol table مناسب برای سیستم‌عامل و نسخه دقیق هسته ضروری است. بدون این جدول، پلاگین‌هایی مانند windows.pslist یا linux.pstree ممکن است نتوانند ساختارهای داده را به درستی تفسیر کنند و خروجی آن‌ها یا ناقص باشد یا شامل آیتم‌های اشتباه شود. این وابستگی یک محدودیت ذاتی است که در صورت عدم تطبیق symbol table با سیستم هدف، می‌تواند به تولید مثبت‌های کاذب یا از قلم افتادن فرآیندهای واقعی منجر شود. تحلیلگر باید همیشه از صحت و تطابق symbol table با تصویر حافظه اطمینان حاصل کند و در صورت عدم اطمینان، نتایج را با سایر منابع مانند لاگ‌ها یا تحلیل دیسک متقاطع بسازد.

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

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

محدودیت‌های Memory Forensics در Triage

Memory Forensics با وجود ارزش تحلیلی بالا، دارای محدودیت‌های ذاتی است که در فرآیند تریاژ باید در نظر گرفته شود. اولین و مهم‌ترین محدودیت، وابستگی شدید به symbol table است. همانطور که در مستندات Volatility 3 تصریح شده، برای تحلیل صحیح حافظه، به جدول نمادهای (symbol table) متناسب با سیستم‌عامل و نسخه دقیق آن نیاز است و در نبود آن، بسیاری از پلاگین‌ها از کار می‌افتند یا خروجی‌هایی با دقت پایین تولید می‌کنند. این وابستگی به ویژه در محیط‌هایی که سیستم‌عامل‌های سفارشی یا هسته‌های تغییر یافته استفاده می‌شود، می‌تواند چالش‌برانگیز باشد.

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

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

• نیاز به symbol table دقیق و متناسب با نسخه هسته، از محدودیت‌های اصلی در تحلیل حافظه است.
• حجم بالای تصویر حافظه و نیاز به منابع پردازشی، تحلیل را در زمان تریاژ چالش‌برانگیز می‌کند.
• تحلیل حافظه فقط وضعیت جاری را نشان می‌دهد و رویدادهای قبلی که اثری برجای نگذاشته‌اند را پوشش نمی‌دهد.

1. پیش از تحلیل، نسخه دقیق سیستم‌عامل و هسته را مشخص کنید و symbol table سازگار را دریافت نمایید.
2. بر اساس اهداف تریاژ، تعیین کنید که آیا تحلیل حافظه ضروری است یا با سایر شواهد پاسخ حاصل می‌شود.
3. نتایج پلاگین‌های حافظه را با سایر منابع مانند رویدادهای سیستم و تحلیل دیسک متقاطع کنید.

معیارهای ارزیابی اثربخشی Memory Triage

ارزیابی اثربخشی triage مبتنی بر حافظه نیازمند معیارهایی است که هم قابل اندازه‌گیری باشند و هم با اهداف عملیاتی تیم امنیتی هم‌راستا باشند. یکی از مهم‌ترین معیارها، زمان تحلیل است؛ یعنی مدت زمانی که از دریافت تصویر حافظه تا تولید گزارش نهایی سپری می‌شود. این معیار باید با در نظر گرفتن حجم داده و پیچیدگی صحنه رویداد تفسیر شود. برای مثال، تحلیل یک تصویر حافظه ۸ گیگابایتی با استفاده از پلاگین‌های پایه‌ای Volatility 3 مانند windows.pslist و windows.pstree می‌تواند در چند دقیقه انجام شود، اما تحلیل عمیق‌تر با پلاگین‌هایی مانند windows.malfind ممکن است زمان بیشتری ببرد. بنابراین، تعیین یک آستانه زمانی مشخص بدون در نظر گرفتن این عوامل، گمراه‌کننده خواهد بود.

معیار دوم، تعداد فرآیندهای شناسایی‌شده و کیفیت آن‌هاست. خروجی پلاگین windows.pslist در Volatility 3 شامل لیستی از فرآیندها با جزئیاتی مانند PID، PPID و زمان شروع است. ارزیابی triage باید شامل بررسی این باشد که آیا فرآیندهای مشکوک (مانند فرآیندهای بی‌نام یا با مسیر غیرعادی) به درستی شناسایی شده‌اند یا خیر. همچنین، دقت نتایج باید با مقایسه با منابع دیگر مانند لاگ‌های سیستم یا اطلاعات شبکه سنجیده شود. به عنوان مثال، اگر یک فرآیند در حافظه شناسایی شود اما در لاگ‌های ویندوز اثری از آن نباشد، این می‌تواند نشانه‌ای از فعالیت مخرب باشد.

معیار سوم، قابلیت تکرارپذیری و مستندسازی است. یک triage مؤثر باید قابل تکرار باشد؛ به این معنی که اگر تحلیلگر دیگری همان تصویر حافظه را با همان ابزار و پارامترها تحلیل کند، به نتایج مشابهی دست یابد. Volatility 3 با ارائه خروجی‌های ساختاریافته (مانند JSON) این امکان را فراهم می‌کند. همچنین، مستندسازی فرآیند تحلیل (شامل نسخه ابزار، پلاگین‌های استفاده‌شده و پارامترها) برای بازبینی‌های بعدی و ارزیابی کیفیت ضروری است. در نهایت، معیارها باید با توجه به سناریوی حمله تنظیم شوند؛ برای مثال، در حملات بدافزار بدون فایل، تمرکز بر روی پلاگین‌هایی مانند windows.malfind و windows.vadinfo خواهد بود.

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

• زمان تحلیل: اندازه‌گیری مدت زمان اجرای پلاگین‌های Volatility 3 بر روی تصویر حافظه.
• تعداد فرآیندهای شناسایی‌شده: مقایسه خروجی windows.pslist با لیست فرآیندهای شناخته‌شده سیستم.
• دقت نتایج: تطبیق فرآیندهای شناسایی‌شده با منابع دیگر مانند Event Logs.
• تکرارپذیری: اجرای مجدد تحلیل با همان پارامترها و مقایسه خروجی‌ها.

1. تعیین اهداف triage (مانند شناسایی بدافزار یا بررسی نشت داده).
2. انتخاب پلاگین‌های مناسب Volatility 3 بر اساس اهداف.
3. اجرای پلاگین‌ها و ثبت زمان اجرا و خروجی‌ها.
4. تحلیل خروجی‌ها و مقایسه با منابع دیگر.
5. مستندسازی فرآیند و نتایج برای ارزیابی بعدی.

volatility3 -f memory.dmp windows.pslist
volatility3 -f memory.dmp windows.pstree

عملیاتی‌سازی Memory Forensics در تیم‌های امنیتی

برای ادغام مؤثر Memory Forensics در فرآیندهای triage روزمره، ابتدا باید تیم‌های امنیتی آموزش‌های لازم را در زمینه استفاده از ابزارهایی مانند Volatility 3 ببینند. این آموزش‌ها باید شامل مبانی ساختار حافظه، نحوه اجرای پلاگین‌های پایه‌ای و تفسیر خروجی‌ها باشد. به عنوان مثال، آشنایی با پلاگین windows.pslist برای شناسایی فرآیندهای در حال اجرا و windows.dlllist برای بررسی ماژول‌های بارگذاری‌شده ضروری است. همچنین، تیم‌ها باید با تکنیک‌های کشف فرآیند (Process Discovery) که در MITRE ATT&CK با شناسه T1057 ثبت شده است، آشنا شوند تا بتوانند رفتارهای مشابه را در حافظه جستجو کنند.

ابزارها و اتوماسیون نقش کلیدی در عملیاتی‌سازی دارند. Volatility 3 به عنوان یک کتابخانه پایتون قابل استفاده است و می‌توان آن را در اسکریپت‌های اتوماسیون ادغام کرد. به عنوان مثال، می‌توان یک اسکریپت نوشت که به صورت خودکار تصویر حافظه را دریافت کرده، پلاگین‌های مشخصی را اجرا کند و خروجی را در قالب JSON ذخیره نماید. این خروجی می‌تواند به سیستم‌های SIEM یا SOAR ارسال شود تا هشدارهای خودکار ایجاد شود. همچنین، استفاده از Volshell (محیط تعاملی Volatility 3) به تحلیلگران امکان می‌دهد تا به صورت تعاملی به بررسی اشیاء حافظه بپردازند و تحلیل عمیق‌تری انجام دهند.

برای عملیاتی‌سازی، باید فرآیندهای مشخصی تعریف شود. به عنوان مثال، در پاسخ به حادثه، ابتدا باید تصویر حافظه به سرعت اخذ شود (با ابزارهای معتبر مانند winpmem یا LiME) و سپس triage اولیه با پلاگین‌های سریع مانند windows.pslist و windows.netscan انجام شود. در صورت مشاهده موارد مشکوک، تحلیل عمیق‌تر با پلاگین‌هایی مانند windows.malfind و windows.hollowfind (در صورت وجود) صورت می‌گیرد. این فرآیند باید در کتابچه‌های راهنمای تیم مستند شود و به طور منظم بازبینی گردد.

توصیه می‌شود که تیم‌ها یک محیط آزمایشی برای تمرین Memory Forensics ایجاد کنند و سناریوهای مختلف حمله را شبیه‌سازی نمایند. این کار به افزایش مهارت تحلیلگران و بهبود فرآیندها کمک می‌کند. همچنین، استفاده از منابع معتبر مانند مستندات Volatility 3 و پایگاه‌های داده تهدید (مانند MITRE ATT&CK) برای به‌روز نگه داشتن دانش تیم ضروری است.

• آموزش مداوم تحلیلگران در زمینه Memory Forensics.
• استفاده از Volatility 3 به عنوان کتابخانه پایتون برای اتوماسیون.
• تعریف فرآیند triage استاندارد برای پاسخ به حادثه.
• ایجاد محیط آزمایشی برای شبیه‌سازی حملات و تمرین.

1. برگزاری کارگاه‌های آموزشی با تمرکز بر Volatility 3 و پلاگین‌های کلیدی.
2. توسعه اسکریپت‌های اتوماسیون برای اجرای خودکار پلاگین‌ها و تولید گزارش.
3. مستندسازی فرآیند triage در کتابچه راهنمای تیم.
4. برگزاری مانورهای منظم برای ارزیابی آمادگی تیم.

import volatility3
from volatility3.framework import contexts
# مثال: اجرای پلاگین windows.pslist به صورت برنامه‌نویسی