‏کلید امضای ADFS؛ شبحی که توی دیتابیس جا می‌مونه

تکنیک معروف Golden SAML که از ۲۰۱۷ شناخته شده، به مهاجم اجازه می‌ده با به‌دست‌آوردن کلید خصوصی گواهی امضای توکن ADFS، خودشو جای هر کاربری جا بزنه و MFA و کنترل‌های دسترسی مشروط و بقیهٔ کنترل‌های هویتی رو دور بزنه. تو یه تمرین red team، تیم Mandiant یه حالت تازه از این حمله رو کشف کرد که به گفته‌شون چون به یه پیکربندی رایج تو محیط‌های سازمانی متکیه، شایان توجهه.

ماجرا از یه ناسازگاری (drift) تو تنظیمات شروع می‌شه. وقتی AutoCertificateRollover خاموشه و گواهی دستی چرخونده می‌شه، سرویس ADFS به گواهی جدید بایند می‌شه ولی دیتابیس پیکربندی WID آپدیت نمی‌شه و یه رکورد قدیمی به‌عنوان «گواهی شبح» باقی می‌مونه. رویداد Event ID 385 دقیقاً همین ناسازگاری بین وضعیت پیکربندی و وضعیت اجرایی رو علامت می‌ده.

نکتهٔ اصلی اینه که روش استخراج مرسوم — که فقط از دیتابیس WID و مواد DKM استفاده می‌کنه — همون گواهی شبح منقضی رو برمی‌گردونه؛ برای همین Entra ID توکن ساخته‌شده رو با خطای AADSTS500172 رد می‌کنه. کلید فعال واقعی یه جای دیگه‌ست: توی استور ماشین‌اسکوپ و زیر محافظت Machine DPAPI.

به گفتهٔ نویسنده، ADFS کلید خصوصی RSA رو تو مسیر MachineKeys ذخیره می‌کنه و با DPAPI ماشینی محافظتش می‌کنه؛ این محافظت به راز DPAPI_SYSTEM و مستر‌کی‌های ماشین تو کانتکست S-1-5-18 متکیه. منطق این طراحی مقاومت عملیاتیه: کلید بعد از تغییر پسورد اکانت سرویس، چرخش gMSA، ریبوت یا ری‌استارت سرویس هم بدون نیاز به تولید دوباره قابل استفاده می‌مونه.

اما نویسنده می‌گه همین طراحی یه پیامد امنیتی داره: چون کلید به‌جای کانتکست کاربر با DPAPI ماشین محافظت می‌شه، یه پروسه با دسترسی SYSTEM می‌تونه بدون دست‌زدن به حافظهٔ LSASS یا پروسهٔ زندهٔ ADFS کلید رو دربیاره — یعنی از دید ابزارهایی که فقط روی credential dumping تمرکز دارن پنهون می‌مونه. تو این ارزیابی، کلید بازیابی‌شده برای جعل یه SAML assertion در سطح Global Administrator استفاده شد و Entra ID قبولش کرد.

برای شناسایی، نویسنده پیشنهاد می‌ده روی مسیرهای کلید و مستر‌کی، ممیزی دسترسی (SACL) بذارین تا Security Event ID 4663 ثبت بشه، و لاگ‌های صدور توکن ADFS رو با sign-in لاگ‌های Entra ID تطبیق بدین چون هیچ‌کدوم به‌تنهایی کافی نیست. برای مقاوم‌سازی هم پیشنهادها اینه: بردن کلید امضا به HSM، اجرای سرویس با gMSA، اعمال کنترل‌های Tier 0 روی سرور ADFS، و چرخش درست گواهی با Set-AdfsCertificate (نه فقط نصب گواهی).

نکات کلیدی:

• با در اختیار داشتن کلید امضای ADFS می‌شه هویت هر کاربری رو جعل کرد و MFA رو کامل دور زد.
• خاموش‌بودن AutoCertificateRollover و چرخش دستی گواهی، یه «گواهی شبح» تو دیتابیس WID جا می‌ذاره؛ Event ID 385 علامتشه.
• کلید فعال واقعی زیر Machine DPAPI تو استور ماشین ذخیره می‌شه و با دسترسی SYSTEM بدون لمس LSASS قابل بازیابیه.
• ADFS رو مثل زیرساخت Tier 0 (هم‌سطح دامین کنترلر) در نظر بگیرین؛ HSM و gMSA و کنترل‌های Tier 0 راه‌های کاهش ریسکن.