#تجربه
سورپرایزی در تحلیل رجیستری
روزبه نوروزی
در این مقاله، تجربیات و یافته‌های خودم درباره نکات طلایی و کمتر موردتوجه قرارگرفته‌ی Forensics رجیستری در ویندوز به اشتراک می‌گذارم. نکاتی که بارها در دنیای واقعی، سبب موفقیت در کشف دقیق نفوذ یا Persistence مهاجمین بوده‌اند.
اول ببینیم چرا رجیستری ویندوز یک Artifact ویژه‌ست؟
رجیستری محل ذخیره تنظیمات سیستم، برنامه‌ها، کاربر، تاریخچه فعالیت و حتی گاهی ردپای بدافزار و حملات است.
اما برخلاف ظاهر ساده‌اش، لایه‌های پنهان و پیچیده‌ای دارد که بسیاری از تحلیلگران به آن بی‌توجه‌اند.
سورپرایز کلیدی: هنر بازسازی کامل رجیستری
یکی از نکات حیاتی و کمتر آموزش‌داده‌شده، لزوم ترکیب سه منبع برای بازسازی دقیق رجیستری است:
فایل ثبت‌شده روی دیسک (مانند SOFTWARE)
فایل‌های Transaction Log (مانند SOFTWARE.LOG1)
و Hiveهای لودشده در حافظه (RAM)
چرا مهم است؟
بسیاری از تحلیلگران، فقط به فایل اصلی رجیستری نگاه می‌کنند. اما:
تغییرات اخیر یا حملات سریع معمولاً ابتدا در RAM و Transaction Log ثبت می‌شوند و شاید هرگز روی فایل دیسک نوشته نشوند.
بنابراین اگر فقط دیسک را بررسی کنیم، ممکن است یک حمله کاملاً از چشم ما دور بماند، مخصوصاً در سناریوهایی مثل Persistenceهای memory-only یا هنگام crash و خاموش شدن ناگهانی سیستم.
مثال واقعی از Gap عملیاتی
فرض کنید هکری، حمله‌ای برمبنای تغییر مقدار Autostart رجیستری اجرا کرده، اما سیستم قبل از Write شدن تغییرات، کرش می‌کند یا عمداً ریست می‌شود.
در این شرایط، فقط Hive رجیستری در RAM یا Transaction Log، شواهد تغییر را نگه‌داشته است — و فایل اصلی دیسک همچنان “پاک” به‌نظر می‌رسد.
راهکار ارزیابی کامل:
برای تحلیل کامل و اصولی، لازم است همیشه این مراحل را رعایت کنید:
استخراج کامل فایل‌های Registry و Logها از هارد دیسک (اگر سیستم روشن نبود)
استخراج و dump کردن حافظه (Memory) اگر سیستم زنده بود
تحلیل همزمان با ابزارهایی نظیر Cyber Triage، Registry Explorer، Rekall، Velociraptor و…
مقایسه Memory و Disk – تغییری فقط در مموری هست و روی دیسک نوشته نشده؟
تحلیل دقیق Last Write Time و بررسی همبستگی زمانی و رفتاری برای تایم‌لاین‌سازی حملات و Persistence
نکات تکمیلی برای متخصصین
این LastWriteTime فقط نشانه یک Change است، اما چه چیزی باعث Change شده؟ اضافه کردن Value؟ تغییر Subkey؟ حذف مقدار قبلی؟
ترکیب داده‌های Transaction Log می‌تواند بعضی اوقات تغییرات موقتی و نیمه‌کاره (Partial) را هم مشخص کند.
برخلاف باور عمومی، بعضی هک‌ها در RAM باقی می‌مانند و مهاجم‌ها می‌توانند با حملات Fileless اثرشان را فقط در RAM و Transaction Log نگه دارند (و نه روی Main Registry File).
#آکادمی_روزبه
مرکز تخصصی CISSP
سورپرایزی در تحلیل رجیستری
روزبه نوروزی
در این مقاله، تجربیات و یافته‌های خودم درباره نکات طلایی و کمتر موردتوجه قرارگرفته‌ی Forensics رجیستری در ویندوز به اشتراک می‌گذارم. نکاتی که بارها در دنیای واقعی، سبب موفقیت در کشف دقیق نفوذ یا Persistence مهاجمین بوده‌اند.
اول ببینیم چرا رجیستری ویندوز یک Artifact ویژه‌ست؟
رجیستری محل ذخیره تنظیمات سیستم، برنامه‌ها، کاربر، تاریخچه فعالیت و حتی گاهی ردپای بدافزار و حملات است.
اما برخلاف ظاهر ساده‌اش، لایه‌های پنهان و پیچیده‌ای دارد که بسیاری از تحلیلگران به آن بی‌توجه‌اند.
سورپرایز کلیدی: هنر بازسازی کامل رجیستری
یکی از نکات حیاتی و کمتر آموزش‌داده‌شده، لزوم ترکیب سه منبع برای بازسازی دقیق رجیستری است:
فایل ثبت‌شده روی دیسک (مانند SOFTWARE)
فایل‌های Transaction Log (مانند SOFTWARE.LOG1)
و Hiveهای لودشده در حافظه (RAM)
چرا مهم است؟
بسیاری از تحلیلگران، فقط به فایل اصلی رجیستری نگاه می‌کنند. اما:
تغییرات اخیر یا حملات سریع معمولاً ابتدا در RAM و Transaction Log ثبت می‌شوند و شاید هرگز روی فایل دیسک نوشته نشوند.
بنابراین اگر فقط دیسک را بررسی کنیم، ممکن است یک حمله کاملاً از چشم ما دور بماند، مخصوصاً در سناریوهایی مثل Persistenceهای memory-only یا هنگام crash و خاموش شدن ناگهانی سیستم.
مثال واقعی از Gap عملیاتی
فرض کنید هکری، حمله‌ای برمبنای تغییر مقدار Autostart رجیستری اجرا کرده، اما سیستم قبل از Write شدن تغییرات، کرش می‌کند یا عمداً ریست می‌شود.
در این شرایط، فقط Hive رجیستری در RAM یا Transaction Log، شواهد تغییر را نگه‌داشته است — و فایل اصلی دیسک همچنان “پاک” به‌نظر می‌رسد.
راهکار ارزیابی کامل:
برای تحلیل کامل و اصولی، لازم است همیشه این مراحل را رعایت کنید:
استخراج کامل فایل‌های Registry و Logها از هارد دیسک (اگر سیستم روشن نبود)
استخراج و dump کردن حافظه (Memory) اگر سیستم زنده بود
تحلیل همزمان با ابزارهایی نظیر Cyber Triage، Registry Explorer، Rekall، Velociraptor و…
مقایسه Memory و Disk – تغییری فقط در مموری هست و روی دیسک نوشته نشده؟
تحلیل دقیق Last Write Time و بررسی همبستگی زمانی و رفتاری برای تایم‌لاین‌سازی حملات و Persistence
نکات تکمیلی برای متخصصین
این LastWriteTime فقط نشانه یک Change است، اما چه چیزی باعث Change شده؟ اضافه کردن Value؟ تغییر Subkey؟ حذف مقدار قبلی؟
ترکیب داده‌های Transaction Log می‌تواند بعضی اوقات تغییرات موقتی و نیمه‌کاره (Partial) را هم مشخص کند.
برخلاف باور عمومی، بعضی هک‌ها در RAM باقی می‌مانند و مهاجم‌ها می‌توانند با حملات Fileless اثرشان را فقط در RAM و Transaction Log نگه دارند (و نه روی Main Registry File).
#آکادمی_روزبه
مرکز تخصصی CISSP
Comments
Be the first to add a comment
Log in to comment