امروز صبح می‌خواستم توجه شما را به یک روش جدید برای نشت هش NetNTLM سیستم جلب کنم، حتی اگر از یک حساب کاربری با دسترسی های پایین کار می‌کنید.

همه چیز بر پایه عمق‌های RPC استوار است... خب! بیایید بررسی کنیم. در RPC، نقاط پایانی معمولی (Well-Known Endpoints) و پویا وجود دارند. نقاط پایانی پویا برای این هستند که سیستم خودش نقطه پایانی را به سرور RPC اختصاص دهد، نه اینکه سرور خودش آن را تعیین کند. برای مثال، سرور RPC فقط می‌گوید که می‌خواهد روی TCP کار کند، و پورت توسط سیستم اختصاص داده می‌شود. کلاینت ها، برای اینکه پورت تارگت برای اتصال را بدانند، به سرویس خاصی به نام RPC Endpoint Mapper مراجعه میکنند که گزارش میدهد سرور تارگت روی فلان پورت کار میکند.

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

چه می‌شود اگر اینترفیس خودمان را زودتر از سرور RPC قانونی ثبت کنیم؟ این سؤال را یک محقق از SafeBreach مطرح کرد و CVE-2025-49760 را کشف کرد. منطق کار اکسپلویت این است که ثبت اینترفیس قانونی سرویس Storage Service را پیشی بگیریم، سپس منتظر فراخوانی از سرویس دیگری Delivery Optimization Service بمانیم. سرویس دوم متد RPC به نام SvcGetStorageDeviceInfo() را فراخوانی می‌ کند، و در پاسخ، ما یک مسیر UNC برمی‌ گردانیم! و سرویس Delivery Optimization Service به این مسیر می‌ رود و اعتبارنامه‌های کامپیوتر را باقی می‌ گذارد.

ارائه از DEF CON 33 را می‌توانید اینجا ببینید.

@PfkSecurity