یکی از مسئله های جدی پیاده سازی حملات مبتنی بر باینری، دیگر خود Injection نیست. این مسئله است که Injection را طوری انجام بدهیم که EDR اصلا آن را Injection نبیند. در System32 ابزارهایی وجود دارند که در این رابطه به ما کمک می کنند. مثلا ابزار nslookup که اساسا قرار است فقط نام را resolve کند ولی در این لابراتواری همین باینری والد یک زنجیره ابزارهای credential harvest می شود، بی آنکه ما به عنوان مهاجم اقدام به استفاده از VirtualAllocEx و WriteProcessMemory یا CreateRemoteThread کرده باشیم. نام تکنیک CNPI یا همان Console Named-Pipe Injection است. فقط این مورد و باید ذکر کنم که واریانتی که اینجا نمایش داده شده است با PoC عمومی 26 سپتامبر یکی نیست. در ادامه بیشتر توضیح خواهم داد.
مهاجم یک کنسول interactive از جنس nslookup را با stdin پایپ شده بالا می آورد و یک بلاب روی انتهای همان pipe قرار میدهد. این نوشتن، از دید رویکردهای نظارتی APIها یک WriteFile روی هندل استاندارد است، نه NtWriteVirtualMemory. کنسول هاست ویندوز در ادامه بایت ها را در مسیر عادی خودش با ReadFile بر می دارد و داخل فضای آدرسی قرار می دهد که سیستم عامل برای ورودی کنسول از قبل ساخته.
بعد ترد اصلی به LoadLibraryW بر می گردد، یعنی به داخل ماژولی که لودر ویندوز با SEC_IMAGE مپ کرده است. در ادامه DllMain بالا میاد و atom_orch که در حقیقت ارکستر زنجیره بدافزار ما است، اجرا می شود. زنجیره باینری های به صورت فرزندان nslookup یا diskpart و ... اجرا می شوند، نه داخل یک ترد اینجکت شده.
خلاصه در این رویکرد هیچ اینجکشنی و دستکاری ریموت حافظه و ... در کار نیست. هیچ WPMای در کار نیست. CRT درگیر نمی شود و بلاب ما کلا سوار بر pipe است. همچنین شل کد هم نیست که نیاز باشد PAGE_EXECUTE داشته باشیم، پس به VirtualProtectEx نیاز نیست که در PoC اصلی هنوز مشکل اساسی بود. همه نقاط ضعف این تکنیک در ابزار پرپل تیم ما به کل حذف شده است.
@aioooir | #cnpi #injection
Post #2605
315
- ❤ 5
- 🤯 1