ابزار کشنده EDR که توسط Sophos X-Ops به مدت سه سال مورد پیگیری قرار گرفته است، همچنان سازمانهای هدفگیری شده توسط باندهای باجافزاری را دچار مشکل میکند.
در سالهای ۲۰۲۲ و ۲۰۲۳، Sophos X-Ops تحقیقاتی درباره مجموعه ابزاری منتشر کرد که برای خراب کردن عملکرد نرمافزارهای حفاظت از نقطه پایانی (endpoint protection software) توسعه داده شده و در کنار چندین باند بزرگ باجافزاری استفاده میشد. Mandiant قبلاً این ابزار را Poortry و برنامه بارگذاری آن را Stonestop نامیده بود.
سازندگان ابزار Poortry موفق به دریافت امضای درایورهای سفارشی در سطح هسته (kernel-level drivers signed) ازطریق فرآیند تأیید امضای مایکروسافت شدند. پس از انتشار تحقیقات توسط وبسایت خبری سوفوس و بسته شدن راهحلهایی که اجازه میداد این درایورها امضا شوند، سازندگان این ابزارمتوقف نشدند و به افزودن ویژگیها و قابلیتهای جدید به درایور Poortry ادامه دادند تا به طور مداوم از شناسایی فرار کنند و راههای جدیدی برای غیرفعال کردن EDR و نرمافزارهای حفاظت از نقطه پایانی پیدا کنند.
چگونه درایورهای ویندوز میتوانند حفاظت را خراب کنند ؟
بیشتر ابزارهای کشنده EDR به بارگذاری یک درایور دستگاه در هسته سیستمعامل وابسته هستند که به آنها دسترسی به نوعی عملکردهای سطح پایین را میدهد تا بتوانند نرمافزارهای حفاظتی مختلف را غیر فعال کنند.
در ویندوز(که از انواع مختلف سختافزارها و اجزای متصل پشتیبانی میکند)، درایورهای حالت هسته (kernel-mode drivers) مجاز به انجام این نوع عملکردها هستند.در شرایط عادی، این درایورها با نرمافزار یا سختافزار شرکتها یا تولیدکنندگان دیگر تعامل نمیکنند، اما هیچ اجباری برای انجام ندادن این تعامل وجود ندارد. بنابراین، اگر یک درایور معتبر امضا شده نتواند به درستی فرآیندهایی که با آن تعامل دارند را تأیید کند، EDR killer ها میتوانند از برخی ویژگیهای آن برای حذف تدابیر حفاظتی استفاده کنند.
مایکروسافت روشهای مختلفی برای کنترل بارگذاری درایورها در سیستمعاملهای خود توسعه داده است، مانند مکانیزم اجرای امضای درایور( Driver Signature Enforcement): درایورها باید توسط یک ناشر نرمافزاری که مایکروسافت به آن اعتماد دارد، به صورت دیجیتالی امضا شوند تا بتوانند بارگذاری شوند.
توسعه دهندگان EDR killer ها از شکافهای موجود در این مدل اعتماد سوءاستفاده میکنند: آنها ممکن است از یک درایور آسیبپذیر که قبلاً توسط یک شرکت نرمافزاری معتبر منتشر شده است استفاده کنند؛ همچنین ممکن است درایور خود را با یک گواهی امضای معتبر امضا کنند (و راههای زیادی برای به دست آوردن گواهیهای دزدیده شده یا نشت یافته وجود دارد).
به طور کلی، سه روش وجود دارد که توسعه دهندگان EDR killer ها از امضای کد سوءاستفاده کنند:
این ساده ترین روش برای حل مشکل است: یک گواهی امضای کد نشت یافته، دزدیده شده یا به نوعی آسیبدیده از یک شرکت معتبر پیدا می کنند و از آن برای امضای درایور خود استفاده می کنند.
برای تمام نسخههای ویندوز که پس از نسخه ۱۰، نسخه ۱۶۰۷ منتشر شدهاند، مایکروسافت از تمام توسعه دهندگان شخص ثالث درایورهای kernel-mode خواسته است تا درایور خود را به پرتال توسعه دهنده مایکروسافت ارسال کنند تا توسط مایکروسافت امضا شود. با این حال، درایورهای متقابل امضا شده که توسط مایکروسافت امضا نشدهاند هنوز هم اگر یکی از شرایط زیر را برآورده کنند اجازه بارگذاری دارند:
– رایانه از نسخه قبلی ویندوز به ویندوز ۱۰، نسخه ۱۶۰۷ ارتقا یافته باشد.
– Secure Boot در BIOS سیستم خاموش باشد.
– درایور با یک گواهی end-entity که قبل از ۲۹ ژوئیه ۲۰۱۵ صادر شده و به یک CA متقابل معتبر متصل است، امضا شده باشد.
برای حفظ سازگاری با درایورهای قدیمیتر، ویندوز درایورهایی را بارگذاری میکند که با “گواهیهای end-entityکه قبل از ۲۹ ژوئیه ۲۰۱۵ صادر شده و به یک CA متقابل معتبر متصل است” امضا شدهاند.
وقتی که یک درایور هستهای (kernel driver) امضا میشود، مایکروسافت ابزاری به نام signtool.exe را در اختیار ناشر نرمافزار قرار میدهد. علاوه بر امضای فایل ارائهشده، signtool همچنین بررسی میکند که آیا گواهی ارائهشده هنوز معتبر است یا خیر. یکی از راهها برای اطمینان از این موضوع، استفاده از تابعی خاص است.
با استفاده از مجموعهای از هوکها(Hooks) به این تماسهای API در سطح پایین داخل سیستمعامل، حملهکنندگان میتوانند فرآیند امضا را تغییر داده و این بررسیها را دور بزنند تا درایور هستهای(Kernel Driver) خود را امضا کنند. یکی از توابعی که در این تکنیک هوک میشود، GetLocalTime است که زمان جعلی را برای عبور از بررسیهای signtool.exe برمیگرداند.
روش نهایی این است که از فرآیند امضای تأیید مایکروسافت عبور کرده و درایور هستهای(Kernel Driver) را مستقیماً توسط مایکروسافت امضا کنند. این احتمالاً دشوارترین روش برای دستیابی است، اما همچنین امضایی با گواهی WHQL قوی که توسط خود مایکروسافت صادر شده را فراهم میکند که مانند یک گنجینه مقدس از امضاهای دیجیتال است.
نیاز حملهکنندگان برای سوءاستفاده از این روش:
– یک گواهی EV معتبر
– دسترسی به پورتال توسعهدهندگان مایکروسافت
اگر این الزامات برآورده شود، آنها میتوانند یک فایل CAB آماده کنند که شامل خود درایور باشد، آن را با گواهی EV امضا کنند و به داشبورد ارسال نمایند.
پس از ارسال، درایور تحت چندین بررسی قرار میگیرد تا اطمینان حاصل شود که درایور مخرب نیست. اگر درایور این تستها را با موفقیت پشت سر بگذارد، به امضای “ناشر سازگاری سختافزار مایکروسافت ویندوز” (Microsoft Windows Hardware Compatibility Publisher) مجهز میشود.
نمونهای از درایور امضا شده با گواهی WHQL در حملات ۲۰۲۲-۲۰۲۳
Poortry (که گاهی اوقات BurntCigar نیز نامیده میشود) یک درایور مخرب هستهای(Kernel Driver) است که به همراه یک بارگذار به نام Stonestop استفاده میشود. این ابزار نخستین بار توسط Mandiant گزارش شد. این درایور با استفاده از یکی از سه تکنیک ذکر شده، محدودیتهای امضای درایور را دور میزند. هر دو ابزار به شدت با استفاده از پککنندههای(Packers) تجاری یا متن باز، مانند VMProtect، Themida یا ASMGuard، پنهانسازی شدهاند.
از پایان سال ۲۰۲۲ تا نیمه سال ۲۰۲۳، نسخههای Poortry دارای گواهی WHQL مایکروسافت بودند. با این حال، به دلیل همکاری مشترک بین Sophos X-Ops و مایکروسافت، اکثر نمونههای امضا شده شناسایی شدند و مایکروسافت حسابهایی را که برای امضای این درایورها سوءاستفاده شده بودند، غیرفعال کرد.
سازندگان Poortry امید خود را از دست ندادند؛ بلکه به جای آن، به جعل زمان امضا(Signature Timestamp Forging) یا کسب یک گواهی معتبر نشت یافته روی آوردند.
در طول سال گذشته، استفاده از Poortry به حملات مرتبط با حداقل پنج خانواده بزرگ باجافزاری متصل شده است:
– CUBA
– BlackCat
– Medusa
– LockBit
– RansomHub
از سال ۲۰۲۳، مشاهده شده است که عوامل تهدید(Threat Actors)، به طور مکرر از Poortry در حملات استفاده میکنند. یکی از ویژگیهایی که در تحقیقات قبلی مشاهده شده، این است که سازندگان Poortry پککننده خود را به طور مکرر تغییر میدهند و نسخههایی با تغییرات کم بر اساس نسخه اصلی ایجاد میکنند. تحقیقات بیشتر، سبب پیداشدن چندین نسخه مختلف امضا شده WHQL شده است که با Packer تجاری یا غیرتجاری متفاوت بستهبندی شده بودند.
از آنجایی که آن روش برایشان مسدود شده بود، سازندگان Poortry اکنون درایورهایی را با گواهیهای متنوع غیر مایکروسافتی امضا میکنند.
شکل زیر زمانبندی نامهای امضاکنندهای را که توسط درایور بارگذاری Poortry در یک دوره ۱۵ ماهه مشاهده شده است، نشان میدهد.
شایان ذکر است که گاهی اوقات این مشاهدات در حین پاسخ به حوادث و در مواقع دیگر این اطلاعات از راه دور(Telemetry) سنجیده میشوند. نکتهای که میتوان به آن اطمینان داشت این است که تعداد کل و تنوع گواهینامهها بیشتر از آن است که فقط با مشاهدات قابل تعیین باشد.
سوفوس، هر از گاهی، مشاهده کرده است که یک عامل تهدید، نسخههای مختلفی از Poortry را در ماشینهای مختلف در یک مجموعه واحد در طول یک حمله مستقر میکند. این نسخهها حاوی همان payload هستند، اما با گواهی متفاوتی نسبت به درایوری که اولین بار در طول حمله استفاده شده بود، امضا شدهاند. در آگوست ۲۰۲۳، در طی یک تحقیق Sophos X-Ops، مشخص شد که مهاجمان از طریق یک ابزار دسترسی از راه دور به نام SplashTop به شبکه دسترسی اولیه پیدا کردند. به محض اینکه مهاجمان به شبکه دسترسی پیدا کردند، Poortry و Stonestop را مستقر کردند. اما نام امضاکننده، “bopsoft”، قبلاً به عنوان یک گواهی سرقت شده شناخته شده بود و با استفاده از یک قانون رفتاری مسدود شد.
در عرض ۳۰ ثانیه پس از آخرین تلاش با کد امضا شده “Bopsoft”، مهاجمان در حال بارگذاری یک درایور Poortry متفاوت بودند که توسط “Evangel Technology (HK) Limited” امضا شده بود، اما میزبان به سرعت ایزوله شد و حمله خنثی گردید.
انتقال از EDR کشنده به EDR پاککننده
در جولای ۲۰۲۴، در حین یک حادثه که در آن مهاجمان سعی داشتند باجافزار RansomHub را مستقر کنند، در حالی که تحلیلگران نقاط دسترسی مهاجمان را مسدود میکردند، Sophos CryptoGuard تلاش آنها برای رمزگذاری دادهها را ناکام گذاشت،. تحلیلهای پس از حادثه نشان داد که دو فایل اجرایی اضافی قبل از حمله نهایی باجافزاری بر روی چندین دستگاه بارگذاری شده بودند.
<d>\Users\<u>\desktop\c7iy3d.exe
<d>\Users\<u>\appdata\local\temp\usnnr.sys
از طریق ترکیبی از تحلیلهای ایستا و پویا، مشخص شد که فایلها Poortry و Stonestop هستند. از جمله تفاوتهایی که بین نسخه قبلی و این نسخه مشاهده شد، این بود Poortry اکنون به جای اینکه فقط فرآیندهای EDR را متوقف کند، قادر است بهطور کامل اجزای حیاتی EDR را حذف کند.
Trend Micro در سال ۲۰۲۳ گزارش داد که Poortry قابلیت حذف فایلها از دیسک را توسعه داده است، اما این اولین باری بود که این ویژگی در یک حمله استفاده شده است.
نگاهی دقیقتر به آخرین نسخهها
هم فایل اجرایی Stonestop و هم درایور Poortry به شدت فشرده و مبهم شدهاند. این Loader توسط یک Packer با منبع بسته به نام ASMGuard مبهم شده است که در Github موجود است.
ویژگیهای درایور PoorTry که در CFF Explorer نمایش داده شدهاند، نشان میدهند که فایل در آگوست ۲۰۲۴ ایجاد شده است.
درایور با یک گواهی که نام امضا کننده آن «FEI XIAO» است، امضا شده است. تیم X-Ops شرکت Sophos با اطمینان بالا معتقد است که زمان امضای این درایور جعل شده است. بهطور خاص، این درایور سعی میکند خود را به عنوان درایور نرمافزار تجاری «Internet Download Manager» از شرکت Tonec Inc معرفی کند و از همان اطلاعات در برگه مشخصات خود استفاده میکند (idmtdi.sys). اما این درایور مربوط به این بسته نرمافزاری نیست و مهاجمان فقط اطلاعات آن را کپی کردهاند.
برگه ویژگیهای درایور PoorTry با تاریخهای اعتبار که بیش از یک دهه قبل ایجاد شده است.
برای توضیحات بیشتر، روند اجرای این برنامه را به سه مرحله مجزا تقسیم میکنیم.
مرحله اولیه
در حوادثی که پیگیری شده است، مهاجمان نرمافزارهای Poortry و Stonestop را همزمان در یک پوشه قرار میدهند. هنگام اجرا، Stonestop به دنبال درایور مربوطه در همان پوشه میگردد.
خطا نمایش داده شده زمانی که لودر نمیتواند به درایور Kernel متصل شود.
نام فایل و نام دستگاه درایور به صورت ثابت در بارگذار (لودر) کدگذاری شدهاند. هنگام شروع، بارگذار شناسه درایور مخرب Kernel را دریافت کرده و با ارسال یک رشته کدگذاری شده به درایور از طریق فراخوانی DeviceIoControl API، یک دست دادن (Handshake) را آغاز میکند.
به طور کلی، ارتباط بین اجزا از طریق DeviceIoControl API انجام میشود. هر ویژگی که توسط جزء هستهای(Kernel) ارائه میشود، با ارسال یک کد IOCTL متفاوت فعال میشود. نسخههای قبلی از طریق هندل IRP_MJ_DEVICE_CONTROL ارتباط برقرار میکردند، در حالی که نسخه فعلی اکنون از هندل IRP_MJ_MAXIMUM_FUNCTION برای دریافت بستههای درخواست I/O استفاده میکند.
شایان ذکر است که نگاشتها از کد IOCTL به ویژگیها، از زمان آخرین تحلیل تغییر کرده است. به عنوان مثال، فرمانی که برای پایان دادن به یک فرآیند خاص با استفاده از شناسه فرآیند (PID) ارسال میشد، فعال سازی آن با ارسال یک بسته درخواست I/O با کد ۰x222094 بود. نمونه جدید کد IOCTL 0x222144 را به همان عملکرد نگاشت میکند.
از گزارش Trend Micro در سال ۲۰۲۳، توسعهدهندگان Poortry تعداد کدهای IOCTL قابل دریافت را از ۱۰ به ۲۲ افزایش دادهاند. تحلیلها از تمامی ویژگیهای موجود هنوز در حال انجام است.
مانند نسخههای قبلی، یک دست دادن(Handshake) با ارسال یک رشته کدگذاری شده به درایور آغاز میشود. هنگامی که مقدار دست دادن پذیرفته میشود، یک پرچم در باینری تنظیم میشود که قابلیتهای درایور مخرب را فعال میکند.
مقدار Handshake ارسالی به Poortry
مرحله دوم بر روی غیرفعالسازی محصولات EDR (تشخیص و پاسخ به تهدیدات) از طریق مجموعهای از تکنیکهای مختلف متمرکز است، مانند حذف یا تغییر روالهای اطلاعرسانی Kernel.
درایورهای امنیتی از ویژگیهای مختلفی که توسط سیستمعامل ویندوز ارائه شدهاند، برای ثبت بازخوردها (callback) هنگام وقوع رویدادهای خاص در سیستم ویندوز استفاده میکنند. به عنوان مثال، تابع PsSetCreateProcessNotifyRoutine، یک روال بازخورد ارائهشده توسط درایور را هنگام ایجاد یک فرآیند جدید اضافه میکند.
حذف این روالهای بازخورد معمولاً یک مرحله حیاتی برای بیفایده کردن محصولات EDR است. در سال ۲۰۲۲، درباره مورد مشابهی که در آن باجافزار BlackByte از یک درایور آسیبپذیر قانونی برای حذف روالهای اطلاعرسانی هستهای(Kernel) حیاتی سوءاستفاده کرد، تحقیقی انجام شده بود.
در مرحله دوم، مشاهده شده که مجموعاً هفت کد IOCTL مختلف به مؤلفه حالت Kernel ارسال میشود، اما تنها عملکرد مرتبط با کد ۰x222400اجرا میشود. ویژگیهای دیگر به دلیل تنظیم پرچمهای خاص در باینری زودتر متوقف میشوند. عملکردهای غیر فعال شده ممکن است یا تجربی باشند، یا تنها در سیستمهای خاص فعال شوند، یا به سادگی غیرفعال شده باشند.
کدهای IOCTL و رفتارهای مرتبط با آنها به شرح زیر است:
– ۰x2220C0 (غیرفعال)
وقتی دریافت میشود، Poortry به یک روال اولیه اضافی وارد میشود و آدرسهای ساختارها و توابع حیاتی مختلف را دریافت میکند.
– ۰x222100 (غیرفعال)
وقتی دریافت میشود، Poortry تلاش میکند تا با تغییر پرچم PspNotifyEnableMask، روالهای اطلاعرسانی Kernel را غیرفعال یا فعال کند. این یک ترفند رایج است که توسط روتکیتها برای فعال یا غیرفعال کردن روالهای اطلاعرسانی Kernel استفاده میشود.
– ۰x222104 (غیرفعال)
وقتی این کد IOCTL دریافت میشود، Poortry روالهای اطلاعرسانی هستهای انواع اشیاء مانند PsProcess، PsThread و ExDesktopObj را تغییر میدهد. این موارد ساختارهای دادهای حالت هستهای میباشند که نمایانگر اشیاء خاص در هسته ویندوز هستند. نوع شیء PsProcess نمایانگر یک شیء فرآیند(Process Object) است. این نوع اشیاء همچنین شامل یک متغیر هستند که به روالهای ثبتشده برای شیء مربوطه اشاره دارد.
از آنجا که این ویژگی غیرفعال شده است، اطمینانی نیست که رقبا چگونه ممکن است این لیستهای بازخورد را تغییر دهند. یکی از سناریوهای ممکن این است که آنها را به طور کامل با تنظیم بازخوردها به یک تابع سفارشی بدون هیچ عملکردی غیرفعال کنند و فقط به سرعت بازگردند.
اصلاح لیستهای پاسخ تماس نوع Object
۰x222108 (غیرفعال)
زمانی که این کد دریافت میشود، Poortry متغیر CmpCallbackCount را تغییر میدهد تا یا روالهای اطلاعرسانی هستهای رجیستری را فعال یا غیرفعال کند. این متغیر برای شمارش تعداد روالهای اطلاعرسانی ثبتشده استفاده میشود. ممکن است اگر این مقدار به صفر تغییر یابد، روالهای اطلاعرسانی بیفایده شوند.
۰x22210C (غیرفعال)
زمانی که این کد دریافت میشود، Poortry تلاش میکند درایور fltMgr.sys را از دستگاههای (FileSystem، FastFat، FileSystem و Ntfs) با استفاده از تابع DeviceIoDetachDevice حذف کند. این تابع معمولاً توسط درایورهای معتبر برای پاکسازی در هنگام خاموش شدن استفاده میشود. با این حال، روتکیتها میتوانند از این تابع برای جلوگیری از دریافت هرگونه درخواست I/O بیشتر توسط درایورهای هدف استفاده کنند.
درایور fltMgr.sys مدیر فیلتر در ویندوز است. این درایور برای گسترش یا تغییر عملکرد قابلیتهای موجود در سیستم ویندوز استفاده میشود و اغلب نیز توسط محصولات EDR به کار گرفته میشود.
این امکان وجود دارد که با جدا کردن آن از طریق IoDetachDevice، فیلترهای نصبشده در سیستم هدف بیفایده شوند.
۰x2221C0 (غیرفعال)
زمانی که این کد دریافت میشود، Poortry وارد روالهایی میشود تا آدرس رسیدگیکنندههای(Handlers) توابع اصلی ClassPnp.sys و ntfs.sys را به دست آورد. (مانند NtfsFsdClose یا NtfsFsdRead از ntfs.sys.) بنابراین این روال میتواند به عنوان یک روال اولیه اضافی برای به دست آوردن آدرسهای توابع حیاتی که توسط ویژگیهای دیگر استفاده میشوند، به کار رود.
۰x222400 (فعال)
زمانی که این کد دریافت میشود، Poortry روالهای اطلاعرسانی هستهای نصبشده را از طریق مجموعهای از تکنیکهای مختلف غیرفعال میکند. مؤلفه کاربر، شامل نام درایور هدف در زمان ارسال بسته درخواست I/O میباشد.
مروری بر روالهای پچ و بررسی Handshake
روالهای اطلاعرسانی هستهای(Kernel) که از طریق توابع PsSetLoadImageNotifyRoutine، PsSetCreateThreadNotifyRoutine و PsSetCreateProcessNotifyRoutine نصب شدهاند، تغییر داده شدهاند. در ابتدای تابع روال اطلاعرسانی، Poortry اولین دستور را طوری تغییر میدهد که به محض ورود، مقدار صفر را برگرداند.
مقایسه قبل و بعد از پچ آغازین
تا کنون، تکنیکهای زیر را برای بیاثر کردن تماسهای هستهای و درایورهای امنیتی شناسایی شدهاند:
– ساختارهای داخلی مورد استفاده توسط توابع PsSetLoadImageNotifyRoutine، PsSetCreateThreadNotifyRoutine و PsSetCreateProcessNotifyRoutine بررسی میشوند، اگر تماس به یک درایور امنیتی علامتگذاری شده تعلق داشته باشد، در نتیجه، تابع تماس ثبتشده بلافاصله بدون اجرای هیچیک از عملیات مورد نظر خود خارج میشود.
– هسته ویندوز ساختارهای داده مهمی مانند PsProcess، PsThread و ExDesktopObject را پیادهسازی میکند که عناصر بنیادی سیستمعامل ویندوز را نمایندگی میکنند. این ساختارها شامل یک متغیر به نام CallbackList هستند که تمام روالهای تماس مرتبط با شیء خاص را مدیریت میکند. Poortry این لیست را بررسی میکند و اگر تماس به یک درایور امنیتی علامتگذاری شده تعلق داشته باشد، در نتیجه، تابع تماس ثبتشده بلافاصله بدون اجرای هیچیک از عملیات مورد نظر خود خارج میشود.
– یک لیست پیوندی داخلی که توسط CmRegisterCallback و CmUnregisterCallback استفاده میشود نیز بررسی میشود. این لیست پیوندی شامل نقاط تابعی است که به تماسهای ثبتشده در رجیستری و اشیاء اشاره دارد. اگر تماس به یک درایور امنیتی علامتگذاری شده تعلق داشته باشد، مقدمه تابع اصلاح میشود.
– Poortry از تابع صادراتی FltEnumerateFilters در fltMgr.sys برای بررسی فیلترهای اعمالشده استفاده میکند. اگر فیلتر به یک درایور امنیتی علامتگذاری شده تعلق داشته باشد، مقدمه تابع اصلاح میشود.
– در حالی که مستقیماً این عملکرد فعال نشد، شواهدی پیدا شده است که Poortry میتواند از تابع IoDetachDevice برای جدا کردن یک شیء دستگاه از پشته(Stack) دستگاههای سیستم سوءاستفاده کند. بر خلاف عملکرد ارائهشده توسط کد IOCTL 0x22210C، این روش کمتر قابل شناسایی است و تنها در صورتی دستگاهها را جدا میکند که نام دستگاه با نام ورودی ارسالشده از طریق DeviceIoControl مطابقت داشته باشد.
مرحله پاکسازی
پس از تضعیف، قاتل EDR هدفش خاتمه دادن به فرآیندهای مرتبط با امنیت و بیاثر کردن عامل EDR با حذف فایلهای حیاتی از دیسک است.
ابتدا، مؤلفه مد کاربر چندین درخواست I/O با کد IOCTL 0x222144 به مؤلفه مد هسته ارسال میکند که شامل شناسه فرآیند برای خاتمه دادن است.
لودر شامل لیستی از مسیرهای کدگذاری شده است که به محل نصب محصولات EDR اشاره دارد. این لودر تمام زیرپوشهها و فایلها در پوشه را بررسی کرده و فایلهای حیاتی برای عامل EDR مانند فایلهای EXE یا DLL را با ارسال یک درخواست IOCTL با کد ۰x222180 به درایور حذف میکند. درخواست ارسالشده شامل مسیر فایل برای حذف است.
قابل توجه است که مؤلفه مد کاربر میتواند در دو حالت عمل کند:
حذف فایلها بر اساس نوع
حذف فایلها بر اساس نام
این شک وجود دارد که نویسنده این حالتهای عملیاتی را برای اطمینان از انعطافپذیری هنگام هدفگیری اهداف مختلف اضافه کرده است. همچنین لیست مسیرهای کدگذاری شده که به پوشههای نصب محصولات EDR اشاره دارد بسته به هدف تغییر میکند.
پیادهسازی حذف فایلها بر اساس نوع
Poortry و لودر مرتبط با آن، Stonestop، در ۲۰ ماه گذشته از زمانی که Sophos و Microsoft گزارشی مشترک درباره سوءاستفاده EDR killer از مکانیزم امضای WHQL منتشر کردند، به طور جدی بهبود ویژگی یافتهاند. آنچه زمانی ابزاری نسبتاً ساده برای غیرفعال کردن اجزای “مزاحم” حفاظت از نقاط پایانی بود، اکنون به خودی خود به یک ابزار کامل با قابلیتهای مخرب تبدیل شده است که از منبع تقریباً نامحدودی از گواهیهای امضای کد دزدیدهشده یا بهطور نادرست استفادهشده، سوءاستفاده میکند تا از حفاظتهای تأیید امضای درایور عبور کند.
توسعهدهندگان Poortry ویژگی متمایزکنندهای برای ابزار خود قرار دادهاند که میتواند بیشتر از یک غیرفعالکننده EDR یا درایور ضد دستکاری حفاظت از نقطه پایانی(ٍEndPoint) عمل کند. Poortry به چیزی شبیه به یک روتکیت تکامل یافته است که همچنین کنترلهای محدودی بر روی تعدادی از تماسهای API مختلف دارد که برای کنترل عملکردهای سطح پایین سیستمعامل استفاده میشوند. همچنین قادر است دشمنان خود و نرمافزارهای امنیتی را به طور کامل از دیسک پاک کند تا راه را برای استقرار باجافزار هموار کند.
گروه X-Ops شرکت Sophos نشانههای نفوذ (IOCs) را در GitHub منتشر کرده است.
منبع: News.Sophos