Abusing Trusted Installer

موضوعاتی مثل از کار انداختن آنتی‌ویروس‌ها یا پیدا کردن متد جدیدی برای Persist، همیشه برای متخصصین تیم‌های قرمز جذاب بوده تا بتونن بدون خطر شناسایی شده، دسترسی خودشون رو تو شبکه‌ی سازمان تحت ارزیابی تثبیت کنن. تو این مقاله می‌خوام به مطلبی بپردازم که هر دو مورد ذکر شده رو پوشش می‌ده. سرفصل مطالبی که توی این مقاله بهشون پرداختم، به شرح زیره:

• بررسی Trusted Installer
• بررسی Protected Processها
• بررسی تکنیک DLL Side Loading
• از کار انداختن سرویس آنتی‌ویروس
• جلوگیری از Load شدن درایور آنتی‌ویروس
• تثبیت دسترسی

بررسی Trusted Installer

قبل از شروع مبحث، با هم ببنیم Trusted Installer چیه؟ از ویندوز 7 به بعد، شرکت مایکروسافت یه built-in user account به نام Trusted Installer به سیستم‌عامل ویندوز اضافه کرد. این اکانت قابلیت اینو داره که توی خیلی از سرویس‌ها و فایل‌های خود سیستم‌عامل، تغییر ایجاد کنه. در واقع شرکت مایکروسافت این اکانت رو درست کرد تا کسی غیر از خودش نتونه به بخش‌های مهم سیستم‌عامل دسترسی داشته باشه. یکی از استفاده‌های مهمش هم توی پروسه‌ی به‌روزرسانی سیستم‌عامل هست. مثلا وقتی که برای فایل kernel32.dll به‌روزرسانی میاد و می‌خواد یه بخشیشو تغییر بده فقط این کاربره که دسترسی جایگزین کردن فایل جدید با فایل قدیمی رو داره. هیچ‌کس نمی‌تونه کارهایی مثل rename یا Delete رو با این فایل‌ها انجام بده. همین‌طور که تو عکس می‌بینید اینجا حتی Administrator هم قابلیت Modify رو نداره. ولی Trusted Installer دسترسی Full Control داره. خب حالا فرایند کارش چطوریه؟ ویندوز اومده یه سرویس درست کرده به اسم Trusted Installer. موقعی که این سرویس میاد بالا یه پروسس ایجاد می‌کنه که قابلیت تغییرات توی بخش‌های محافظت شده رو داره. حالا ویندوز از کجا می‌فهمه که این پروسس دسترسی لازم برای اعمال تغییرات رو داره؟ از روی توکن این پروسس. همون‌طور که تو تصویر زیر هم می‌بینید، پروسس Trusted Installer توکن Trusted Installer رو هم داره. از اون‌جایی که وقتی می‌خوایم به یه آبجکت دسترسی داشته باشیم، سیستم‌عامل برای این‌که بدونه ما اجازه‌ی انجام این کار رو داریم یا نه، میاد توکن مارو بررسی می‌کنه. بر همین اساس، اینجا هم با بررسی توکن TrustedInstaller.exe می‌فهمه که این پروسس اجازه تغییرات توی فایل‌های محافظت شده رو داره. نکته‌ی مهمی که اینجا باید بهش بپردازیم اینه که سرویس Trusted Installer از نوع Protected نیست (در ادامه توضیح می‌دم که منظور از Protected چیه( برای همین ما می‌تونیم بیایم start اش کنیم، Stop اش کنیم و حتی ازش هندل بگیریم. این نقطه آغازیه برای انجام سو استفاده از این سرویس مهم!

بررسی Protected Processها

خب حالا که فهمیدیم Trusted Installer چیه و چطوری کار می‌کنه، لازمه که یه مرور کلی هم روی شیوه‌ی عملکرد Protected Processها داشته باشیم. این پروسس‌ها از ویندوز ویستا به بعد به وجود اومدن. ایده شکل گیریشون هم به این صورت بود که اون زمان هیچ مکانیزمی برای جلوگیری از کپی شدن اطلاعات CD/DVDها وجود نداشت. حتی وقتی میومدن دیتای روی CD رو Encrypt می‌کردن، باز موقع پخش مجبور بودن دیتای Decrypt شده رو به پروسسی که صدا و تصویر رو توی ویندوز هندل می‌کرد ارسال کنن. همین جا هم بود که افراد سودجو با خوندن فضای حافظه‌ی کارت صدا یا پخش کننده‌ی تصویر، اطلاعات رو سرقت می‌کردند و دوباره روز از نو، روزی از نو. تا اینکه صدای خیلی از شرکت‌ها به اعتراض بلند شد و از مایکروسافت خواستند که یه فکری برای این داستان بکنه و اینجا بود که ایده‌ی Protected Processها شکل گرفت. به این معنی که وقتی پروسسی به صورت Protected اجرا می‌شد هیچ Non-Protectedای نمی‌تونست از اون پروسس هندل قوی بگیره، اون رو ببنده یا حتی داخلش کد Inject کنه. حتی DLLهایی که Sign مایکروسافت نبودند هم نمی‌تونستند توی این پروسس‌ها اجرا شن. اما اینجا این قابلیت فقط دست مایکروسافت بود و به هیچ شرکت Third-Partyای این امکان رو نداده بود که بتونه از این قابلیت استفاده کنه. تا این‌که ویندوز 8.1  رو عرضه و تو این سیستم‌عامل قابلیت مذکور رو برای شرکت‌های آنتی‌ویروس فراهم کرد. این شرکت‌ها باید درخواست خودشونو ثبت می‌کردن و اگه مایکروسافت تایید می‌کرد یک Sign در اختیار اون‌ها قرار می‌داد که به وسیله اون می‌تونستن سرویس خودشون رو به صورت Protected اجرا کنن. دیگه اینجا نمی‌شد دستکاری‌ای روی این سرویس‌ها انجام داد یا اختلالی توی کارشون به وجود آورد. فقط یه هندل بسیار ضعیف می‌شد از این پروسس‌ها گرفت که اطلاعات محدودی مثل اسم فایل رو برمی‌گردوند و در نتیجه این هندل‌ها هم بسیار ناکارآمد بودن. حالا اگه یادتون باشه گفتیم سرویس Trusted Installer که یه سرویس خیلی مهم توی ویندوز هست به صورت Protected بالا نمیاد. پس می‌تونیم ازش هندل بگیریم و هرکاری که می‌خوایم رو انجام بدیم.

بررسی تکنیک DLL Side Loading

یکی از تکنیک‌های مورد علاقه بسیاری از APTهای دنیاست و  توی گزارشاتی که هر روز منتشر می‌شه، می‌بینیم که از طرق مختلف و همچنین توی فازهای مختلف اومدن از این روش استفاده کردن. حالا این روش چطوری کار می‌کنه؟ ویندوز یه سری قواعد برای بارگذاری DLL توی برنامه داره که در این لینک می‌تونید جزییاتشو بخونید:

https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

نکته‌ی مهمش اینه که غیر از  Known-DLLها، برای اجرای بقیه ماژول‌های سیستمی، اولین جایی که سیستم جستجو می‌کنه، فولدر جاری خودش هست. اینجا نفوذگرها میان یه DLL هم‌نام مثلا Advapi32.dll رو میزارن توی فولدر یه برنامه‌ی شناخته شده مثل Word و در نتیجه سیستم هم اونو اجرا می‌کنه. حالا اینجا برای جلوگیری از کرش کردن برنامه، نفوذگرها میان تابع‌هایی که توی DLL اصلی هست رو برمی‌دارن و توی دل DLL خودشون وارد می‌کنن. به این صورت هم DLL نفوذگر اجرا می‌شه، هم DLL اصلی. مزیت این روش هم اینه که DLL مورد نظر شما رو یه برنامه با Sign مایکروسافت اجرا می‌کنه و به همین دلیل Payload ما از چشم آنتی‌ویروس‌ها و EDRها مخفی می‌شه.  چون پیاده‌سازی‌های زیادی ازش توی اینترنت هست دیگه به جزییات بیشتر درباره‌ی این موضوع نمی‌پردازیم و می‌ریم سراغ مبحث بعدی.

از کار انداختن سرویس آنتی‌ویروس

خب حالا که فهمیدیم Trusted Installer چیه و چطوری کار می‌کنه، قصد داریم تا با سو استفاده از اون، بیایم سرویس آنتی‌ویروس رو از کار بندازیم. شاید براتون سوال باشه که با وجود درایورهای آنتی‌ویروس‌ها، از کار انداختن سرویسشون به تنهایی چه مزیتی داره؟ اینجا باید یه نکته مهم رو یادآور بشم که توی بسیاری از EDRها و آنتی‌ویروس‌ها، کرنل فقط اطلاعات رو جمع آوری می‌کنه و تصمیم‌گیر اصلی سرویس سمت User-mode هست. پس یعنی اگه ما بیایم و اونو از کار بندازیم، دیگه هیچ کسی نیست که تصمیم بگیره و حتی فایلی مثل mimikatz رو بدون هیچ مشکلی می‌تونیم اجرا کنیم. اما شیوه‌ی انجام این‌کار به چه شکل هست؟ ما باید بتونیم توکن Trusted Installer رو بدست بیاریم و بعد اونو روی Thread جاری خودمون بزاریم و بعدش دستورات مورد نظر خودمونو اجرا کنیم! اول از همه ما باید با تابع OpenProcess یک Handle از TrustedInstaller بگیریم. اگه اینکار با موفقیت انجام بشه، ما یه هندل از این پروسس داریم که باید این هندل رو توی تابع OpenProcessToken استفاده کنیم. این تابع وظیفش چیه؟ میاد یه Handle از توکن پروسسی که ما Handle شو بهش پاس دادیم به ما برمی‌گردونه که می‌تونیم با این توکن یا پروسس جدید بسازیم، یا روی ترد جاری خودمون اعمالش کنیم. که ما اینجا کار دوم رو انجام دادیم. از الان به بعد ما هر دستوری که اجرا کنیم، با توکن Trusted Installer اجرا می‌شه. گفتیم که این توکن دسترسی اینو داره که سرویس‌های مهم رو دست‌کاری کنه. پس می‌ریم سراغ از کار انداختن سرویس Windows Defender مطابق شکل زیر: و تمام، اینجا  Windows Defender از کار خواهد افتاد و تا بازیابی بعدی سیستم‌عامل دیگه بالا نمیاد و شما تا اون موقع می‌تونید هر فایل مخربی رو بدون این‌که آنتی‌ویروس تشخیص بده، اجرا کنید.

جلوگیری از Load شدن درایور آنتی‌ویروس

یه مشکلی که تو روش قبلی وجود داشت این بود که با ریست شدن سیستم، آنتی‌ویروس دوباره شروع به فعالیت خواهد کرد. حالا می‌خوایم با توجه به دسترسی که داریم، کاری کنیم که دیگه درایور آنتی‌ویروس اجرا نشه. اگه یادتون باشه گفتیم که دسترسی Trusted Installer میتونه فایل‌های سیستم‌عامل رو دستکاری کنه. خب اینجا فقط کافیه ما بیایم فایل درایور Windows Defender رو Rename کنیم. برای اینکار باید اول سرویسی که این درایور رو Load می‌کنه پیدا کنیم. خب حالا فقط کافیه بیایم Rename اش کنیم. از دفعه‌ی بعد که سیستم میاد بالا چون این فایل رو پیدا نمی‌کنه، سرویسی هم بالا نمیاد و آنتی‌ویروس برای همیشه از کار افتاده.

تثبیت دسترسی

خب حالا که ما قابلیت تغییر توی فایل‌های موجود در فولدر SYSTEM32 رو داریم، می‌خوایم بیایم تغییری به وجود بیاریم که Payload ما همیشه در هر بار ریست اجرا شه و ما تحت Explorer بیایم بالا. البته اینجا محدود نیستیم به اینکه بخوایم فقط تحت Explorer بیایم بالا ولی باید به یک نکته‌ی مهم دقت کنیم که ما DLLهایی رو می‌تونیم دست‌کاری کنیم که Sign مایکروسافت نداشته باشند. چون در این‌صورت برنامه‌های Protected نمی‌تونن اجرا بشن و عملکرد سیستم با مشکل مواجه می‌شه. من تو اینجا DLLهای Load شده توی Explorer رو بررسی کردم و یکی از اون‌هارو پیدا کردم که Sign هم نداره. کاری که انجام می‌دیم اینه که فایل اصلی رو Rename می‌کنیم، فایل خودمونو به جای فایل اصلی می‌زاریم و در نهایت Exportهای DLLای که تغییرش دادیم(DLL اصلی( رو روی DLL خودمون ایجاد و روی DLL اصلی Proxy می‌کنیم. اینجا من AtlThunk رو تغییر دادم.   اتفاقی که اینجا افتاده اینه که اول اومدم فایل اصلی رو توی system32 تغییر نام دادم و بعدش Payload اصلی که کدش رو توی عکس پایین گذاشتم، به جای فایل اصلی AtlThunk قرار دادم. و اگه همه چی با موفقیت اجرا شه، بعد از ریست باید با بالا اومدن Explorer این پیام برای شما ظاهر بشه. توی این مقاله با هم دیگه دیدیم که برای به دست آوردن یه privilege کارهای خیلی زیادی می‌شه انجام داد و این تکنیک‌ها تو فازهای مختلف عملیات Red Teaming می‌تونه مورد استفاده قرار بگیره.