توییت
Crystal Kit یک پروژهی تجربی است که برای جایگزینی Sleepmask در Cobalt Strike طراحی شده است. Sleepmask (و BeaconGate) جزئی از استراتژی فرار در زمان اجرا (runtime evasion) برای Beacon هستند — نه تنها حافظهی Beacon را ماسک میکنند، بلکه بهعنوان یک API proxy برای Beacon (و BOFها) عمل میکنند. این به اپراتورها امکان میدهد تا فراخوانیهای API پشتیبانیشده را با تکنیکهای فرار سفارشی مانند call stack spoofing بپوشانند.
به نظر من، بزرگترین محدودیت BeaconGate تعداد کم APIهایی است که پشتیبانی میکند. برای مثال، پشتیبانی نکردن از CreateProcessA یعنی هر دستور postex که یک فرایند را spawn میکند (مثل shell، run، powerpick، execute-assembly و غیره) در مقابل دفاعهایی که از تحلیل call stack استفاده میکنند، مشکلساز میشود. این محدودیت همچنین روی BOFهای تزریق فرایند اثر میگذارد چون تعداد کمی از APIهای مفید برای تکنیکهای نوآورانهی تزریق را پشتیبانی میکند. و اگرچه این نکته مستقیماً ضعف Sleepmask نیست، یک شکاف نسبتاً بزرگ در فرار در زمان اجرا برای DLLهای postex وجود دارد. چون معادل Sleepmask/BeaconGate برای DLLهای postex وجود ندارد، هیچ kitی در Cobalt Strike نیست که بهطور ارگونومیک به اپراتورها اجازه دهد تکنیکهای مشابه را برای فراخوانیهای API که انجام میدهند پیادهسازی کنند.
IAT hooking تکنیکی است که قبلاً توسط reflective loaderهایی مثل TitanLdr و AceLdr نشان داده شده است. استراتژی این است که یک PIC blob را در حافظه تزریق کرده و IAT آن DLL را هنگام بارگذاری hook کنند. APIهای هکشده به PIC blob هدایت میشوند که evasions توسعهیافته توسط نویسنده را اجرا میکند.
Crystal Palace بهطور خاص طراحی شده تا چندین resource را بهصورت PIC بارگذاری کند و قراردادهایی (conventions) برای دسترسی به آنها بهصورت سمبلها (symbols) در کد فراهم آورد. این کار بار توسعهدهنده را برای هماهنگسازی همهی این مؤلفهها با یکدیگر بهشدت کاهش میدهد. دو نمونهی جالب که در «garden» گنجانده شدهاند عبارتاند از simplehook و stackcutting. نمونهی hooking نشان میدهد چگونه یک PICO میتواند IAT DLL را hook کند تا قبل و بعد از یک فراخوانی API حافظه را mask/unmask کند؛ و نمونهی stackcutting نشان میدهد چگونه یک API هکشده میتواند از طریق PIC عبور کند که یک تکنیک call stack spoofing را پیادهسازی میکند.
با ترکیب اینها، ما پایهی محکمی برای یک POC داریم، که در واقع همان چیزی است که من اساساً آماده کردهام.
Crystal Kit امکانات زیر را فراهم میکند:
دو پیروزی بزرگ این رویکرد این است که به ما اجازه میدهد APIهایی را hook کنیم که توسط BeaconGate پشتیبانی نمیشوند؛ و با DLLهای postex نیز سازگار است! این یعنی Beacon میتواند APIهایی مانند CreateProcessA را فراخوانی کند و آنها از همان تکنیکهای فرار که Sleepmask ارائه میدهد بهرهمند شوند. این کاملاً APIهایی را که یک BOF میتواند با همان تکنیکهای فرار فراخوانی کند باز میکند، بدون اینکه Beacon لازم باشد آنها را صریحاً منتشر کند. و hook کردن LoadLibrary در DLLهای postex یک فشار عظیم در برابر تشخیصهایی ایجاد میکند که بارگذاری ایمیجها را هدف میگیرند (برای مثال System.Management.Automation.dll و clr.dll).
به نظر من، بزرگترین محدودیت BeaconGate تعداد کم APIهایی است که پشتیبانی میکند. برای مثال، پشتیبانی نکردن از CreateProcessA یعنی هر دستور postex که یک فرایند را spawn میکند (مثل shell، run، powerpick، execute-assembly و غیره) در مقابل دفاعهایی که از تحلیل call stack استفاده میکنند، مشکلساز میشود. این محدودیت همچنین روی BOFهای تزریق فرایند اثر میگذارد چون تعداد کمی از APIهای مفید برای تکنیکهای نوآورانهی تزریق را پشتیبانی میکند. و اگرچه این نکته مستقیماً ضعف Sleepmask نیست، یک شکاف نسبتاً بزرگ در فرار در زمان اجرا برای DLLهای postex وجود دارد. چون معادل Sleepmask/BeaconGate برای DLLهای postex وجود ندارد، هیچ kitی در Cobalt Strike نیست که بهطور ارگونومیک به اپراتورها اجازه دهد تکنیکهای مشابه را برای فراخوانیهای API که انجام میدهند پیادهسازی کنند.
IAT hooking تکنیکی است که قبلاً توسط reflective loaderهایی مثل TitanLdr و AceLdr نشان داده شده است. استراتژی این است که یک PIC blob را در حافظه تزریق کرده و IAT آن DLL را هنگام بارگذاری hook کنند. APIهای هکشده به PIC blob هدایت میشوند که evasions توسعهیافته توسط نویسنده را اجرا میکند.
Crystal Palace بهطور خاص طراحی شده تا چندین resource را بهصورت PIC بارگذاری کند و قراردادهایی (conventions) برای دسترسی به آنها بهصورت سمبلها (symbols) در کد فراهم آورد. این کار بار توسعهدهنده را برای هماهنگسازی همهی این مؤلفهها با یکدیگر بهشدت کاهش میدهد. دو نمونهی جالب که در «garden» گنجانده شدهاند عبارتاند از simplehook و stackcutting. نمونهی hooking نشان میدهد چگونه یک PICO میتواند IAT DLL را hook کند تا قبل و بعد از یک فراخوانی API حافظه را mask/unmask کند؛ و نمونهی stackcutting نشان میدهد چگونه یک API هکشده میتواند از طریق PIC عبور کند که یک تکنیک call stack spoofing را پیادهسازی میکند.
با ترکیب اینها، ما پایهی محکمی برای یک POC داریم، که در واقع همان چیزی است که من اساساً آماده کردهام.
Crystal Kit امکانات زیر را فراهم میکند:
- یک reflective loader پیشوندشده (prepended reflective loader).
- یک PIC stub که call stack spoofing را انجام میدهد (مبتنی بر Draugr).
- یک PICO که IAT DLL را hook میکند.
- یک اسکریپت Aggressor که hooks لازم را در Cobalt Strike ثبت میکند.
دو پیروزی بزرگ این رویکرد این است که به ما اجازه میدهد APIهایی را hook کنیم که توسط BeaconGate پشتیبانی نمیشوند؛ و با DLLهای postex نیز سازگار است! این یعنی Beacon میتواند APIهایی مانند CreateProcessA را فراخوانی کند و آنها از همان تکنیکهای فرار که Sleepmask ارائه میدهد بهرهمند شوند. این کاملاً APIهایی را که یک BOF میتواند با همان تکنیکهای فرار فراخوانی کند باز میکند، بدون اینکه Beacon لازم باشد آنها را صریحاً منتشر کند. و hook کردن LoadLibrary در DLLهای postex یک فشار عظیم در برابر تشخیصهایی ایجاد میکند که بارگذاری ایمیجها را هدف میگیرند (برای مثال System.Management.Automation.dll و clr.dll).
