Ouroboros: تکنیک استخراج مداوم اعتبارنامه در ویندوز سرور 2025
خلاصهٔ کاملتر
ویندوز سرور 2025 یک ویژگی جدید به نام delegated Managed Service Account یا به اختصار dMSA معرفی کرد که قرار بود از نسخه قدیمیتر یعنی gMSA امنتر باشه. در مدل قدیمی، اگه کسی میتونست attribute مربوط به پسورد رو از Active Directory بخونه، عملاً اعتبارنامههای قابل استفاده مجدد به دستش میرسید. در dMSA این مسیر بسته شده — پسورد دیگه از طریق LDAP قابل بازیابی نیست و دسترسی به اعتبارنامههای اکانت جانشین از طریق یک gate مجزا در KDC کنترل میشه.
اما محققان Akamai در همکاری با تیم امنیتی دیگهای تکنیکی پیدا کردن به اسم Ouroboros که این مدل امنیتی رو از داخل میشکنه. اسمش از اژدهای اسطورهای یونانی گرفته شده که دم خودش رو میخوره — چون این حمله یک حلقه بسته خودکفا میسازه که هیچ اکانت خارجی توش دخیل نیست.
برای اینکه بفهمیم Ouroboros چطور کار میکنه، باید با دو «دروازه» امنیتی dMSA آشنا بشیم. Gate 1 مربوط به احراز هویت به عنوان dMSA هست: چه کسی میتونه TGT بگیره و به عنوان این اکانت وارد بشه. این از طریق یک Shadow Credential کنترل میشه. Gate 2 مربوط به دریافت اعتبارنامههای اکانت جانشین (superseded) هست: attribute به نام msDS-GroupMSAMembership تعیین میکنه که چه کسی مجاز به دریافت پکیج KERB-DMSA-KEY-PACKAGE از KDC هست — یعنی هش NT اکانت هدف.
نکته حیاتی اینه که این دو gate کاملاً جدا هستن. احراز هویت به عنوان dMSA به خودی خود کافی نیست؛ باید در GroupMSAMembership هم مجاز باشی تا اعتبارنامههای اکانت اصلی رو دریافت کنی.
Ouroboros این دو شرط رو بهگونهای تنظیم میکنه که خود dMSA هر دو رو برای خودش تأمین کنه. مهاجم ابتدا یک Shadow Credential روی dMSA مینویسه تا بتونه به عنوان اون dMSA احراز هویت کنه (Gate 1). سپس SID خود dMSA رو داخل msDS-GroupMSAMembership مینویسه تا dMSA خودش رو مجاز به دریافت اعتبارنامههای اکانت هدف بکنه (Gate 2). وقتی این حلقه بسته شد، اکانت مهاجم اصلی دیگه هیچ نقشی در زنجیره نداره و میتونه حذف بشه.
نقطه شروع این تحقیق یک audit سیستماتیک روی principal به نام SELF (با SID مشهور S-1-5-10) در اسکیمای Active Directory بود. SELF یعنی «خود آبجکت» — وقتی یک ACE به SELF اجازه write میده، هر security principal میتونه اون عملیات رو روی آبجکت خودش انجام بده. کلاس dMSA از کلاس computer ارث میبره و SELF-write ACEهایی از اون به ارث میبره که در ترکیب با Owner بودن creator، مهاجم رو قادر میکنه attributeهای حساس رو روی dMSA که خودش ساخته بنویسه.
دو تحقیق قبلی هم در این حوزه بودن: BadSuccessor (Yuval Gordon, Akamai, 2025) نشون داد که CreateChild روی یک OU کافیه تا یک dMSA با هر اکانت جانشین دلخواه ساخته بشه. مایکروسافت این مشکل رو به عنوان CVE-2025-53779 پچ کرد و اعتبارسنجی bidirectional link رو به KDC اضافه کرد — یعنی هم msDS-ManagedAccountPrecededByLink روی dMSA و هم msDS-ManagedAccountSucceededByLink روی اکانت هدف باید وجود داشته باشن. Golden dMSA (Adi Malyanker, Semperis, 2025) هم نشون داد که داشتن KDS root key اجازه میده پسورد مدیریتشده rو brute-force کرد، چون ساختار ManagedPasswordId فقط ۱۰۲۴ ترکیب زمانی ممکن داره. مایکروسافت برای این مورد CVE ای صادر نکرد.
نکته مهم اینه که پچ CVE-2025-53779 فقط جلوی one-sided link رو گرفته. اگه مهاجم دسترسی کافی داشته باشه که یک bidirectional link واقعی و دوطرفه بسازه، پچ کمکی نمیکنه. Ouroboros دقیقاً از همین مسیر وارد میشه: با دو دسترسی سطح پایین (CreateChild روی OU و WriteProperty روی اکانت هدف)، یک زنجیره میسازه که:
- بعد از چرخش پسورد پایدار میمونه
- بعد از حذف اکانت مهاجم پایدار میمونه
- Domain Adminها رو از remediation باز میداره
نکات کلیدی:
- dMSA در ویندوز سرور 2025 از gMSA امنتره چون پسورد رو از طریق LDAP expose نمیکنه، اما مدل امنیتی جدیدش آسیبپذیریهای جدیدی داره
- Ouroboros یک حلقه خودکفا میسازه که dMSA با Shadow Credential خودش احراز هویت میکنه و با نوشتن SID خودش در
GroupMSAMembership، خودش را مجاز به دریافت اعتبارنامههای هدف میکنه - برای اجرای این حمله فقط CreateChild روی یک OU و WriteProperty روی اکانت هدف کافیه — دسترسیهایی که در محیطهای enterprise نسبتاً رایجن
- پچ CVE-2025-53779 جلوی one-sided link رو میگیره اما در برابر bidirectional link واقعی محافظتی نداره
- این حمله در شش دستور روی یک سیستم کاملاً پچشده قابل اجراست
- کلید شناسایی این حمله مانیتور کردن write به
msDS-GroupMSAMembershipوmsDS-KeyCredentialLinkروی آبجکتهای dMSA هست
