پژوهشگر Entra ID، Dirk‑jan Mollema، نشان داد کدی که در نشست کاربری واردشدهٔ ویندوز اجرا می‌شود می‌تواند بدون دسترسی ادمین از کلید Windows Hello for Business برای احراز هویت در Microsoft Entra ID استفاده کند و به مهاجم مسیر دستیابی بلندمدت به سرویس‌های ابری بدهد.

مکانیزم حمله

اگر مهاجم بتواند اجرای کد را در نشست تعاملی کاربر به‌دست آورد، می‌تواند از کلید Windows Hello for Business یک assertion امضا‌شده تولید کرده و چالش احراز هویت Entra ID را پشت سر بگذارد. پس از این مرحله مهاجم می‌تواند:

  • دستگاهی جدید در Entra ثبت کند،
  • برای آن دستگاه توکن تازه‌سازی اصلی (PRT) درخواست دهد و دسترسی بلندمدت به سرویس‌های مایکروسافت به‌دست آورد،
  • در صورت اجازهٔ سیاست‌های مستأجر، روش‌های احراز هویت اضافی مانند passkey یا کلیدهای جدید Windows Hello اضافه کند.

چرا استخراج کلید یا فراخوان بیومتریک لازم نیست

روی سیستم‌های دارای TPM مهاجم نیازی به استخراج کلید خصوصی یا دانستن پین و فعال‌سازی اعلان بیومتریک ندارد. مدل تیکتینگ ویندوز عملیات مرتبط با کلید خصوصی را مادامی که کاربر به‌صورت تعاملی وارد شده حفظ می‌کند؛ بنابراین کدی که به‌عنوان همان کاربر اجرا می‌شود می‌تواند از ویندوز بخواهد داده‌های احراز هویت را امضا کند و برای این درخواست نیازی به امتیاز ادمین نیست.

نقطهٔ ضعف فنی

مولما نشان داد با رفتار دادن کلید Windows Hello for Business به‌عنوان یک کلید FIDO2 از طریق WebAuthn می‌توان چالشی پنج‌دقیقه‌ای Entra ID را از میزبان دیگری درخواست کرد و از نقطهٔ آسیب‌دیده امضای مورد نیاز را دریافت نمود. وی دریافت که این چالش به‌صورتی بسته‌بندی یا خوشه‌بندی نشده و assertion تولیدشده می‌تواند همراه با ابزارهایی مانند ROADtools برای گرفتن توکن‌ها یا باز کردن جلسه مرورگر به‌نمایندگی از کاربر استفاده شود.

محرک‌ها و محدودیت‌ها

  • الزام اجرا در نشست کاربری واردشده؛ یعنی مهاجم باید به‌صورت تعاملی روی سیستم قربانی اجرای کد داشته باشد.
  • توکن دریافتی در بررسی‌های مولما فاقد ادعای شناسهٔ دستگاه بود؛ به همین دلیل مهاجم توانست دستگاه جدیدی ثبت و PRT دریافت کند. مایکروسافت مستند کرده است که PRT می‌تواند تا 90 روز معتبر بماند و در صورت استفادهٔ فعال مداوم تمدید شود.
  • سیاست‌های مبتنی بر وضعیت دستگاه یا تطابق (device compliance) می‌توانند زنجیرهٔ پایداری را در برخی پیاده‌سازی‌ها قطع کنند؛ بنابراین همهٔ محیط‌ها به یک اندازه آسیب‌پذیر نیستند.

افشای عمومی و شواهد

مولما اسکریپت‌های اثبات‌مفهوم PowerShell را در مخزن ROADtools منتشر کرده است؛ فایل‌هایی مانند fido_assertion.ps1 و hellopoc.ps1 در این مجموعه موجود است. جستجوهای عمومی در پایگاه‌هایی مانند NVD و CVE.org تا تاریخ 6 اوت 2026 هیچ CVE مرتبط یا اطلاعیهٔ رسمی مایکروسافت در این خصوص نمایش ندادند. پیگیری‌ها برای دریافت پاسخ از مایکروسافت و پژوهشگر ادامه دارد.

کاهش ریسک — اقدامات توصیه‌شده

پیشگیری کامل در همهٔ محیط‌ها تضمین‌پذیر نیست، اما ترکیبی از مانیتورینگ، سخت‌سازی سیاست‌های ثبت دستگاه و کنترل‌های دسترسی می‌تواند سوءاستفاده را دشوار یا قابل کشف کند. اقدامات مشخص عبارت‌اند از:

  • پایش ورودها: لاگ‌های ورود Azure AD را برای رخدادهای مرتبط با Windows Hello for Business یا WebAuthn که مقدار deviceId در آن‌ها خالی است بررسی و برای موارد مشکوک هشدار تعریف کنید.
  • نظارت روی ثبت دستگاه: ثبت‌نام‌های جدید دستگاه را رصد کرده و ثبت خودکار دستگاه برای کاربران غیرمجاز را محدود کنید. مستندات مدیریتی مایکروسافت درباره مدیریت دستگاه می‌تواند راهنمایی ارائه دهد.
  • تقویت Conditional Access: سیاست‌هایی اعمال کنید که علاوه بر مقاومت در برابر فیشینگ، وضعیت و تطابق دستگاه را نیز الزامی کنند. مروری بر Microsoft Conditional Access در: این صفحه موجود است.
  • محدودسازی ثبت دستگاه کاربران: امکان ثبت دستگاه را فقط به گروه‌های تعیین‌شده یا از طریق تأیید ادمین مجاز کنید.
  • حفاظت نقاط پایانی: استفاده از EDR، محدودسازی اجرای اسکریپت‌های غیرمجاز و سیاست‌های مستحکم PowerShell باعث کاهش احتمال اجرای کد در نشست کاربری می‌شود.

نمونه‌های تشخیصی

تشخیص اولیه می‌تواند با جستجو برای ورودهای Windows Hello for Business همراه با مقدار خالی یا نامتعارف در فیلد deviceId انجام شود. توجه داشته باشید که نشست‌های مرورگر ناشناس یا موارد قانونی بدون SSO نیز ممکن است همین الگو را تولید کنند؛ بنابراین هر رخداد باید در زمینهٔ رفتار کاربر و دستگاه بررسی شود.

جمع‌بندی

این گزارش نشان می‌دهد حتی وقتی کلیدهای Windows Hello فیزیکی و محافظت‌شده‌اند، اجرای کد در نشست کاربری می‌تواند آن‌ها را به‌نام کاربر برای احراز هویت به کار بگیرد و مسیرهای دستیابی بلندمدت به سرویس‌های ابری فراهم سازد. ترکیب لاگ‌گذاری دقیق، سیاست‌های محکم ثبت و تطابق دستگاه، و ابزارهای حفاظتی نقاط پایانی برای کاهش اثر این تکنیک ضروری است.