‏سوءاستفاده از AMSI Provider جعلی برای persistence

به گفتهٔ نویسنده، AMSI (رابط اسکن ضدبدافزار ویندوز) یه سازوکار مایکروسافته که محتوای احتمالاً پرخطر رو قبل از اجرا به موتور ضدبدافزار یا EDR نصب‌شده می‌سپاره تا اسکن شه. مثلاً وقتی یه دستور از طریق پاورشل اجرا می‌شه، محتوا به AMSI پاس داده می‌شه، اون هم به provider ضدبدافزار ثبت‌شده می‌فرسته و نتیجه (تمیز، مشکوک یا مخرب) برمی‌گرده. نکته اینه که مایکروسافت این رابط رو vendor-agnostic طراحی کرده و اجازه می‌ده اپ‌های ثالث هم به‌عنوان AMSI provider ثبت شن.

همین انعطاف، سطح سوءاستفاده رو باز می‌کنه. نویسنده توضیح می‌ده که یه مهاجم اگه از قبل دسترسی بالا (ادمین محلی) گرفته باشه، می‌تونه یه provider جعلی رو تو ویندوز ثبت کنه. سازوکار به این شکله که وقتی پاورشل محتوایی رو برای اسکن می‌فرسته، AMSI متد Scan همون provider جعلی رو صدا می‌زنه؛ provider هم دنبال یه‌سری «رشتهٔ تریگر» از پیش تعریف‌شده می‌گرده و به‌محض این‌که کاربر یکی از اون رشته‌ها رو تو کنسول پاورشل وارد کنه، یه تابع دلخواهِ مهاجم اجرا می‌شه. به این ترتیب مهاجم یه مکانیزم persistence می‌سازه که به‌جای یه بدافزار آشکار، پشت یه رابط امنیتی قانونی مخفی شده.

نویسنده تأکید می‌کنه که این تکنیک تازه نیست و نمونهٔ اثبات مفهوم (PoC) و کد نمونهٔ یه AMSI provider سال‌هاست به‌صورت عمومی منتشر شده؛ ولی چون نیازمند دسترسی ادمینه، بین مهاجم‌ها خیلی رایج نیست. از نظر پیاده‌سازی، provider به شکل یه فایل DLLه که با ابزار regsvr32 ثبت می‌شه و مسیرش هم زیر کلیدهای رجیستری CLSID و مسیر Software\Microsoft\AMSI\Providers نوشته می‌شه.

بخش اصلی و مفید مقاله، تشخیص (detection)ه. چون providerها تو رجیستری ذخیره می‌شن، تیم‌های SOC باید کلید Providers رو برای ورودی‌های نامعتبر پایش کنن؛ این نقطهٔ تشخیص اصلیه. مهم‌ترین توصیهٔ پیشگیرانه اینه که بررسی امضای (signing check) providerها فعال بشه؛ مایکروسافت این قابلیت رو از ویندوز ۱۰ نسخهٔ 1903 به بعد اضافه کرده ولی به‌صورت پیش‌فرض روشن نیست. با روشن کردنش، DLLهای امضانشده نمی‌تونن تو اپ‌های AMSI-aware مثل پاورشل بارگذاری شن.

برای دیدن providerهای ثبت‌شده، مقاله یه cmdlet سادهٔ پاورشل رو پیشنهاد می‌ده که کاملاً دفاعیه:

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\AMSI\Providers" -ErrorAction SilentlyContinue

نویسنده چند سیگنال تشخیص دیگه هم می‌شمره: ثبت یه provider، رویداد رجیستری با Event ID 4663 تولید می‌کنه؛ بارگذاری DLL امضانشده تو پروسهٔ پاورشل رو می‌شه با قواعد Sysmon (Event ID 7) گرفت، هرچند به‌خاطر DLLهای امضانشده ولی قانونیِ پوشهٔ NativeImages مستعد false positiveئه و باید tune شه. یه پروسهٔ پاورشل که یه پروسهٔ فرزند مشکوک می‌سازه هم باید فوراً مخرب دسته‌بندی شه؛ بیشتر EDRها این توانایی رو دارن. مقاله در نهایت یه قاعدهٔ SIGMA آزمایشی هم ارائه می‌ده که ثبت provider جدید یا ورودی COM مرتبط تو مسیرهای مشکوک (مثل AppData، Temp، Downloads) رو شناسایی می‌کنه.

جمع‌بندی نویسنده اینه که هرچند این تکنیک شایع نیست، چون PoCهاش عمومی‌ان سازمان‌ها باید ریسکو کم کنن: فعال کردن بررسی امضای providerها طبق راهنمای مایکروسافت و پایش کلید رجیستری AMSI Providers برای ورودی‌های جدید، مطمئن‌ترین شاخص‌های تشخیصن.

نکات کلیدی:

• مهاجمِ با دسترسی ادمین می‌تونه یه AMSI provider جعلی ثبت کنه تا با یه رشتهٔ تریگر تو پاورشل، کد اجرا شه و persistence بگیره.
• provider به شکل یه DLLه که با regsvr32 ثبت می‌شه و مسیرش زیر کلید AMSI\Providers رجیستری می‌ره.
• مهم‌ترین پیشگیری: فعال کردن signing check که از ویندوز ۱۰ نسخهٔ 1903 هست ولی پیش‌فرض خاموشه.
• تشخیص: پایش کلید رجیستری providerها، شناسایی DLL امضانشده تو پاورشل (Sysmon/SIGMA) و بررسی درخت پروسه.