‏ModuleStomped؛ لو دادن DLLهای دستکاری‌شده

تو تکنیکی به اسم module stomping، مهاجم به‌جای اینکه یه ماژول جدید و مشکوک لود کنه، کد مخربشو روی بخش کدِ یه DLL معتبرِ از قبل لودشده می‌نویسه تا لای ماژول‌های سالم گم بشه. نویسنده این ابزار متن‌باز رو (که خودش می‌گه یه PoC خیلی خامه) نوشته تا دقیقاً همین حالتو تشخیص بده.

ایده‌ی اصلی اینه که به‌جای چک کردن بخش .text (که کدِ اجرایی توشه و طبیعتاً موقع استمپ عوض می‌شه)، بخش pdata هر ماژول بررسی بشه. به گفته‌ی نویسنده pdata در حالت عادی نباید تغییر کنه، برای همین مقایسه‌اش راه قابل‌اعتمادتری برای پیدا کردن دستکاریه.

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

نویسنده یه دور زدنِ واضح رو هم قبول می‌کنه: مهاجم می‌تونه یه بخش text به‌قدر کافی بزرگ پیدا کنه که کل DLLش جا بشه و بعد بخش pdata رو دستی اضافه کنه. البته می‌گه همینم با هم‌بستگی فریم‌های استک با pdata قابل‌تشخیصه، ولی این قسمتو پیاده نکرده. تو تست رو ماشین خودش، ابزار از بین همه‌ی پروسه‌ها فقط همون C2ای که داشته module stomping می‌کرده رو بیرون کشیده.

نکات کلیدی:

• ابزار متن‌بازِ تشخیص module stomping، یه PoC خامه که رو بخش pdata تکیه می‌کنه نه .text.
• منطقش اینه که pdata نباید تغییر کنه، پس دستکاریش راحت‌تر لو می‌ره.
• دو حالت داره: مبتنی بر ETW و اسکن کامل پروسه‌ها (با دسترسی ادمین).
• نویسنده یه بایپس ممکن رو هم گفته که با هم‌بستگی استک‌فریم‌ها قابل‌شناساییه ولی پیاده نشده.