تحلیل فنی دفاعی و منبع‌محور: Passkey-themed social engineering leads to identity and cloud…

مفاهیم پایه و مرور کلی حمله

مهندسی اجتماعی با محوریت Passkey، به عنوان یک پیش‌متن فریبنده برای هدایت قربانی به سمت جریان‌های احراز هویت مخرب، به یک تهدید رو به رشد برای زیرساخت‌های هویتی سازمان‌ها تبدیل شده است. بر اساس تحلیل‌های منتشرشده توسط تیم تحقیقات امنیتی مایکروسافت (Microsoft Security Research)، این نوع حمله با یک تماس تلفنی یا پیام متنی به شماره شخصی کاربر آغاز می‌شود که در آن فردی خود را از واحد پشتیبانی فنی سازمان معرفی کرده و با ایجاد حس فوریت، کاربر را به به‌روزرسانی تنظیمات Passkey یا ورود یکپارچه (SSO) ترغیب می‌کند. نکته حائز اهمیت این است که هدف نهایی مهاجم، ثبت یک Passkey جدید نیست؛ بلکه این روایت صرفاً بهانه‌ای برای فریب کاربر جهت طی کردن یک جریان فیشینگ از نوع واسط در برابر واسط (AiTM) یا احراز هویت مبتنی بر کد دستگاه (Device Code) است.

در سناریوی فیشینگ AiTM، مهاجم اعتبارنامه و توکن‌های نشست کاربر را رهگیری می‌کند، در حالی که در حمله مبتنی بر کد دستگاه، قربانی ناآگاهانه به مهاجم اجازه می‌دهد تا از طرف او به منابع سازمانی دسترسی یابد. یکی از چالش‌های اصلی در شناسایی این حملات، کم بودن ردپای دیجیتال در مرحله اولیه است؛ چرا که کاربر اغلب لینک فیشینگ را بر روی دستگاه شخصی خود که تحت نظارت ابزارهای امنیتی سازمان نیست، باز می‌کند. در بسیاری از موارد، اولین و تنها سرنخ برای تیم‌های امنیتی، گزارش خود کاربر از تماس یا پیام دریافتی است و بازسازی زنجیره حمله نیازمند اتصال این گزارش به رویدادهای بعدی مانند ورودهای غیرعادی، تغییر روش‌های احراز هویت و فعالیت‌های مشکوک در Microsoft Graph است.

پس از دسترسی اولیه، مهاجم اقدام به ایجاد پایداری در محیط می‌کند و سپس با استفاده از ابزارهای مدیریتی مانند Microsoft Graph، به شناسایی ساختار سازمان، جستجوی محتوای حساس در SharePoint و OneDrive و جمع‌آوری ایمیل‌ها از طریق APIهای REST می‌پردازد. این توالی رفتاری که بر اساس گزارش مایکروسافت از می 2026 مشاهده شده، نشان‌دهنده یک عملیات خودکار جمع‌آوری داده با استفاده از زیرساخت‌های پروکسی است. لازم به ذکر است که مهاجم پیش از حمله، تحقیقات گسترده‌ای درباره سازمان هدف از منابع عمومی مانند شبکه‌های اجتماعی انجام می‌دهد و در برخی موارد، از حساب‌های کاربری از پیش به‌دست‌آمده برای ارسال پیام‌های فیشینگ از طریق Microsoft Teams استفاده می‌کند که این امر اعتماد قربانی را به شدت افزایش می‌دهد.

• زنجیره حمله شامل مراحل: دسترسی اولیه از طریق فیشینگ، ایجاد پایداری با افزودن روش‌های احراز هویت، شناسایی محیط با Microsoft Graph، و در نهایت جمع‌آوری و استخراج داده است.
• زیرساخت فیشینگ به سرعت حول محورهایی مانند Passkey، ثبت‌نام SSO و فعال‌سازی حساب مستقر می‌شود و دامنه‌ها و آدرس‌های IP به سرعت تغییر می‌کنند.
• برای بررسی، باید توالی رویدادها در سیگنال‌های هویت، Microsoft Graph، SharePoint، OneDrive و Exchange مورد کنکاش قرار گیرد و نشست‌های تأییدشده لغو و روش‌های احراز هویت غیرمجاز حذف شوند.

شواهد فنی و تله‌متری‌های مرتبط

بر اساس گزارش منتشرشده توسط تیم تهدیدپژوهی مایکروسافت، فعالیت‌های مشاهده‌شده در این کمپین شامل دنباله‌ای از رویدادهای قابل ردیابی در سرویس‌های ابری است. نخستین نشانه، ورودهای غیرعادی به حساب‌های کاربری است که اغلب از زیرساخت‌های پروکسی یا آدرس‌های IP غیرمنتظره صورت می‌گیرد. به دنبال این ورودها، مهاجم اقدام به افزودن روش‌های احراز هویت جدید (مانند دستگاه‌های اضافی یا کلیدهای سخت‌افزاری) به حساب قربانی می‌کند که نشانه‌ای قوی از تلاش برای ایجاد ماندگاری (Persistence) است. این تغییرات معمولاً در گزارش‌های حسابرسی Microsoft Entra ID قابل مشاهده است و باید به‌عنوان هشدار جدی در نظر گرفته شود.

پس از تثبیت دسترسی، مهاجم فعالیت‌های گسترده‌ای در Microsoft Graph انجام می‌دهد. این فعالیت‌ها شامل جستجو و شمارش اشیا، بررسی اعضا و گروه‌ها، و استعلام از ساختار سازمانی است. به‌طور هم‌زمان، حجم بالایی از دانلود فایل‌ها از SharePoint و OneDrive ثبت می‌شود که الگوی آن با جمع‌آوری خودکار داده‌ها مطابقت دارد. علاوه بر این، استفاده از REST API برای جمع‌آوری ایمیل‌ها از صندوق‌های پستی (مانند Outlook) مشاهده شده است. این مجموعه رفتارها نشان‌دهنده یک فرایند خودکار برای استخراج داده‌های حساس از هویت‌های در معرض خطر است.

لازم به تأکید است که این شواهد برگرفته از گزارش رسمی مایکروسافت است و برای تکمیل تصویر، تیم‌های دفاعی باید داده‌های تله‌متری داخلی خود را با این الگوها تطبیق دهند. به‌عنوان مثال، ثبت رویدادهای لاگین، تغییرات در روش‌های احراز هویت، و فعالیت‌های غیرعادی در Graph API می‌تواند نشانه‌های اولیه کمک‌کننده‌ای باشد. توصیه می‌کنیم تحلیلگران به دنبال الگوهای تکرارشونده مانند ورود از آدرس‌های IP ناشناس یا استفاده از توکن‌های دسترسی با طول عمر کوتاه باشند. همچنین توجه به این نکته ضروری است که ممکن است بخشی از فعالیت‌ها در تله‌متری دستگاه‌های شخصی قربانی (که خارج از حوزه مدیریت سازمان هستند) ثبت نشده باشد.

• ورودهای غیرعادی از آدرس‌های IP یا دستگاه‌های ناشناس که با الگوی رفتاری کاربر همخوانی ندارد.
• افزودن روش‌های احراز هویت جدید (مانند ثبت دستگاه تلفن همراه یا کلید امنیتی) بدون درخواست کاربر.
• حجم بالای تراکنش‌های Microsoft Graph شامل شمارش کاربران، جستجوی گروه‌ها و بررسی اشتراک‌ها.
• دانلود انبوه فایل‌ها از SharePoint یا OneDrive در یک بازه زمانی کوتاه.
• جمع‌آوری ایمیل‌ها از طریق REST API با استفاده از توکن‌های دسترسی معتبر.

1. فعال‌سازی لاگ‌های حسابرسی برای Microsoft Entra ID و نگهداری آن‌ها برای حداقل ۹۰ روز.
2. استفاده از Microsoft Defender for Cloud Apps برای شناسایی فعالیت‌های غیرعادی در برنامه‌های ابری.
3. بررسی دستی رویدادهای تغییر روش احراز هویت در هویت‌های حساس (مانند مدیران).
4. راه‌اندازی هشدار برای دانلودهای حجیم از SharePoint/OneDrive و فراخوانی‌های REST API در حجم غیرمعمول.
5. در صورت مشاهده موارد مشکوک، بی‌درنگ نشست‌های کاربر را لغو کرده و روش‌های احراز هویت تأییدنشده را حذف کنید.

گردش کار شناسایی و بررسی

در مواجهه با گزارش‌های کاربری مبنی بر تماس یا پیام مرتبط با به‌روزرسانی passkey یا SSO، نخستین گام، ثبت دقیق اظهارات کاربر و مستندسازی زمان، کانال ارتباطی (تلفن شخصی، پیامک، یا Teams) و نشانی وب ارائه‌شده است. این اطلاعات، پایهٔ بازسازی زنجیرهٔ حمله را فراهم می‌کند، زیرا در بسیاری از موارد، شواهد فنی اولیه از جمله لاگ‌های دستگاه شخصی کاربر در دسترس نیست. تحلیلگر باید این گزارش را به‌عنوان یک سرنخ آغازین در نظر گرفته و آن را با سایر سیگنال‌های موجود تلفیق کند.

پس از ثبت گزارش، باید ورودهای غیرعادی به سرویس‌های ابری (مانند Microsoft Entra ID) در بازهٔ زمانی مرتبط بررسی شود. جستجو باید شامل رویدادهای ورود با آدرس IP غیرمعمول، استفاده از عامل کاربری ناشناخته، یا ورود از طریق جریان کد دستگاه باشد. همچنین، رویدادهای مرتبط با افزودن روش‌های احراز هویت جدید (مانند ثبت کلید سخت‌افزاری یا برنامهٔ Authenticator) باید به‌دقت ممیزی شوند، زیرا این اقدام نشان‌دهندهٔ تثبیت دسترسی توسط مهاجم است. توصیه می‌شود که تحلیلگران به‌جای تکیه بر یک شاخص واحد، به الگوی ترکیبی رفتارها توجه کنند.

در گام بعدی، بازبینی فعالیت‌های Microsoft Graph، SharePoint، OneDrive و Exchange ضروری است. این بازبینی باید شامل شناسایی دسترسی‌های حجیم به فایل‌ها، دانلودهای غیرعادی از کتابخانه‌های اسناد، و جستجوهای REST API برای استخراج ایمیل‌ها باشد. همچنین، تغییرات در تنظیمات صندوق پستی (مانند قانون ارسال خودکار) باید مدنظر قرار گیرد. در نهایت، برای موارد تأییدشده، باید نشست‌های فعال را لغو کرده و روش‌های احراز هویت غیرمجاز را حذف کرد. توصیه می‌شود که این اقدامات با هماهنگی تیم امنیتی سازمان و ظرف چند ساعت انجام شود تا از گسترش دسترسی مهاجم جلوگیری شود.

• بررسی تمام رویدادهای ورود در ۹۰ روز گذشته با تمرکز بر موفقیت‌آمیز بودن و ناهنجاری در مکان یا IP.
• ممیزی کامل تغییرات روش‌های احراز هویت برای هر حساب کاربری، از جمله افزودن، حذف یا تغییر کلیدهای سخت‌افزاری.
• بازبینی فعالیت‌های Graph API برای شناسایی فراخوانی‌های غیرعادی، به‌ویژه درخواست‌های مکرر برای دریافت توکن یا دسترسی به منابع.
• پایش دانلودهای SharePoint و OneDrive با حجم بالا یا در ساعات غیرکاری.
• بررسی قوانین صندوق پستی Exchange و اطمینان از عدم وجود ارسال خودکار به آدرس‌های خارجی.
• لغو همهٔ نشست‌های فعال بلافاصله پس از تأیید سازش، و سپس حذف روش‌های احراز هویت اضافه‌شده توسط مهاجم.

1. استخراج اطلاعات گزارش کاربر و ثبت در سیستم تیکتینگ.
2. پرس‌وجو از لاگ‌های ورود با استفاده از KQL برای بازهٔ زمانی مرتبط و فیلتر بر اساس فعالیت‌های مشکوک.
3. اجرای گزارش تغییرات روش احراز هویت و بررسی مواردی که در بازهٔ زمانی حمله رخ داده‌اند.
4. بازبینی فعالیت‌های Graph با استفاده از Microsoft 365 Defender و جستجو برای رویدادهای با حجم غیرعادی.
5. مقایسهٔ الگوی فعالیت با رفتارهای معمول کاربر و شناسایی موارد پرت.
6. صدور هشدار برای تیم امنیت و اطلاع‌رسانی به کاربر در صورت تأیید سازش.

// نمونه KQL برای شناسایی افزودن روش احراز هویت غیرمجاز
AuditLogs
| where OperationName == "Add authentication method"
| where TimeGenerated > ago(7d)
| project TimeGenerated, UserPrincipalName, AuthenticationMethod, ResultStatus
| order by TimeGenerated desc

راهنمای غربالگری و تریاژ

برای غربالگری مؤثر هشدارها در برابر زنجیره‌ی حمله‌ی توصیف‌شده، تحلیلگران باید به‌جای اتکا به یک رویداد منفرد، به دنبال توالی رفتاری بگردند که نشان‌دهنده‌ی مصالحه‌ی هویتی و دستکاری بعدی است. الگوی اصلی که در گزارش منبع برجسته شده، ترکیب «ورود غیرعادی» با «افزودن روش احراز هویت توسط مهاجم» و سپس «فعالیت حجیم Microsoft Graph» است. این توالی، حتی اگر هر جزء به‌تنهایی کم‌خطر به نظر برسد، در کنار هم سیگنال قوی برای تریاژ ایجاد می‌کند. بنابراین، معیار اولویت‌بندی باید بر اساس تشخیص هم‌زمان این سه مؤلفه در یک بازه‌ی زمانی کوتاه تعریف شود، نه صرفاً وجود یک رویداد مشکوک.

در مرحله‌ی تریاژ، تحلیلگر باید به رویدادهای مرتبط با «دستگاه کد» (Device Code) و «تغییر روش‌های احراز هویت» توجه ویژه‌ای داشته باشد. گزارش منبع تأکید می‌کند که مهاجم از طریق فیشینگ AiTM یا جریان‌های دستگاه کد، اعتبارنامه و توکن‌های نشست را به دست می‌آورد. بنابراین، هر هشداری که نشان‌دهنده‌ی تکمیل جریان دستگاه کد از یک آدرس IP ناشناخته یا خارج از محدوده‌ی جغرافیایی معمول باشد، باید به‌عنوان کاندیدای پرخطر علامت‌گذاری شود. همچنین، رویدادهای «افزودن روش احراز هویت جدید» (مانند ثبت کلید عبور یا برنامه‌ی احراز هویت) که بلافاصله پس از یک ورود غیرعادی رخ می‌دهند، باید به‌عنوان شاخص اصلی مصالحه در نظر گرفته شوند.

برای جلوگیری از هشدارهای کاذب، لازم است که زمینه‌ی سازمانی در نظر گرفته شود. برای مثال، یک ورود غیرعادی از یک کارمند بخش فناوری اطلاعات که به‌تازگی درخواست تغییر روش احراز هویت داده است، ممکن است مشروع باشد. اما اگر همان ورود با دانلود انبوه از SharePoint یا OneDrive همراه باشد، احتمال مخرب بودن افزایش می‌یابد. بنابراین، معیار تریاژ باید شامل «ترکیب رویدادهای هویتی با فعالیت‌های داده‌محور» باشد. به‌عبارت دیگر، اولویت با هشدارهایی است که هم تغییر در هویت و هم دسترسی به حجم بالای داده را نشان می‌دهند. در نهایت، تحلیلگران باید به‌جای جستجوی آستانه‌های عددی خاص (که در منبع ذکر نشده)، بر روی الگوهای تکرارشونده و توالی زمانی تمرکز کنند.

• ترکیب ورود غیرعادی با افزودن روش احراز هویت جدید را به‌عنوان سیگنال اصلی در نظر بگیرید.
• رویدادهای تکمیل جریان دستگاه کد از آدرس‌های IP ناشناخته را با اولویت بالا بررسی کنید.
• فعالیت حجیم Microsoft Graph (مانند جستجو یا دانلود) را در کنار تغییرات هویتی ارزیابی کنید.
• هرگونه دانلود از SharePoint یا OneDrive را که با ورود غیرعادی همراه است، به‌عنوان هشدار پرخطر علامت‌گذاری کنید.

1. مرحله ۱: هشدارهای ورود غیرعادی را بر اساس موقعیت جغرافیایی، آدرس IP و ویژگی‌های دستگاه فیلتر کنید.
2. مرحله ۲: در همان بازه‌ی زمانی، رویدادهای تغییر روش احراز هویت (افزودن، حذف یا تغییر) را جستجو کنید.
3. مرحله ۳: فعالیت‌های Microsoft Graph شامل دسترسی به ایمیل، فایل‌ها و جستجوهای گسترده را بررسی کنید.
4. مرحله ۴: در صورت تطابق الگو، نشست‌های کاربر را باطل کرده و روش‌های احراز هویت غیرمجاز را حذف کنید.

مثبت‌های کاذب و چالش‌های تشخیص

در تحلیل فنی این کمپین مهندسی اجتماعی با محوریت Passkey، یکی از چالش‌های اصلی برای تیم‌های دفاعی، تشخیص فعالیت‌های مشروع از رفتارهای مخرب است. گزارش مایکروسافت به صراحت اشاره می‌کند که بسیاری از تعاملات اولیه، مانند باز کردن لینک فیشینگ بر روی دستگاه‌های شخصی که به Microsoft Defender for Endpoint متصل نیستند، هیچ ردی در تله‌متری سازمانی باقی نمی‌گذارند. بنابراین، سناریوی ورود موفق یک کاربر مجاز از دستگاه شخصی یا انجام فعالیت‌های عادی Graph توسط مدیران یا کارکنان، می‌تواند به عنوان مثبت کاذب در سیستم‌های تشخیص نفوذ (IDS) یا راهکارهای SIEM ظاهر شود. این موضوع به ویژه زمانی چالش‌برانگیز می‌شود که فعالیت‌های بعدی مانند دانلود فایل از SharePoint یا OneDrive، با الگوهای کاری روزمره کاربر مطابقت داشته باشد.

محدودیت دیگر در تشخیص، عدم وجود تله‌متری جامع در دستگاه‌های غیرتحت‌نظر است. اگر مهاجم از طریق دستگاه شخصی قربانی (مثلاً گوشی موبایل) به هویت دست یابد و سپس از یک نشست توکن معتبر استفاده کند، تیم دفاعی هیچ داده‌ای از فرآیند احراز هویت اولیه (مانند آدرس IP منبع یا نوع مرورگر) در اختیار نخواهد داشت. در چنین شرایطی، تکیه صرف بر سیگنال‌های سنتی مانند ناهنجاری در مکان جغرافیایی یا امضای دستگاه، بی‌اثر است. به عنوان مثال، یک رویداد «Device code authentication» که از یک آدرس IP عمومی و پراکسی ناشناخته انجام می‌شود، ممکن است در نگاه اول شبیه به تلاش مشروع یک کاربر از راه دور باشد، به‌ویژه اگر سازمان دارای نیروی کار دورکار باشد. این امر تشخیص را به شدت پیچیده می‌کند.

برای غلبه بر این چالش‌ها، تیم‌های دفاعی باید به جای جستجوی صرف برای «نشانه‌های مخرب»، بر روی تحلیل رفتاری و همبستگی سیگنال‌های سطح بالا تمرکز کنند. به عنوان مثال، ترکیب یک رویداد تغییر روش احراز هویت (مانند افزودن یک روش جدید MFA) با فعالیت‌های غیرعادی Microsoft Graph مانند جستجوی انبوه ایمیل‌ها یا دانلود حجم بالای داده، می‌تواند نشانه قوی از سازش باشد. همچنین، بازبینی گزارش‌های کاربران در مورد تماس‌های تلفنی یا پیامک‌های مشکوک، که در گزارش مایکروسافت به عنوان «تنها شواهد اولیه» ذکر شده، باید به عنوان یک منبع معتبر تله‌متری در نظر گرفته شود. در نهایت، توصیه می‌شود که سازمان‌ها سیاست‌های «دسترسی شرطی» را بر اساس ریسک (Risk-based Conditional Access) پیاده‌سازی کنند تا نشست‌های پرخطر را به چالش بکشند، حتی اگر از نظر فنی معتبر به نظر برسند.

در نتیجه، چالش اصلی در این سناریو، تمایز بین «فعالیت مجاز اما غیرعادی» و «فعالیت مخرب اما پنهان» است. این امر نیازمند یک رویکرد لایه‌ای است که در آن تله‌متری دستگاه‌های مدیریت‌شده با گزارش‌های انسانی و تحلیل رفتار هویت ترکیب می‌شود. به عنوان یک توصیه عملی، پیشنهاد می‌شود که تیم‌های امنیتی برای همه رویدادهای تغییر احراز هویت، هشدارهای خودکار و بررسی دوره‌ای (مانند بازبینی هفتگی) تنظیم کنند و از قابلیت‌هایی مانند «Microsoft Entra ID Protection» برای شناسایی ریسک‌های مرتبط با توکن و نشست استفاده نمایند. این اقدامات، اگرچه قطعی نیستند، اما می‌توانند سطح نویز را کاهش داده و تمرکز را بر روی سیگنال‌های واقعی سازش افزایش دهند.

• ورود از دستگاه شخصی غیرمدیریت‌شده را به عنوان یک رویداد پرخطر در نظر بگیرید، حتی اگر اعتبارنامه معتبر باشد.
• فعالیت‌های Graph که شامل جستجوی انبوه یا دانلود غیرعادی است را با پروفایل رفتاری کاربر مقایسه کنید.
• گزارش‌های کاربران در مورد تماس‌های تلفنی یا پیامک‌های مشکوک را به عنوان یک منبع تله‌متری معتبر ثبت و تحلیل کنید.

1. پیاده‌سازی هشدار برای رویدادهای «افزودن روش احراز هویت» و «استفاده از Device code authentication» در Microsoft Entra.
2. اتصال گزارش‌های ورود به سیستم با داده‌های تهدید (Threat Intelligence) برای شناسایی آدرس‌های IP پرخطر یا پراکسی‌های ناشناخته.
3. برگزاری جلسات منظم با کاربران برای آموزش تشخیص پیام‌های فیشینگ و تشویق به گزارش سریع تماس‌های مشکوک.

محدودیت‌های منابع و تحلیل

تحلیل حاضر مبتنی بر گزارش عمومی مایکروسافت دربارهٔ زنجیرهٔ حمله‌ای است که با مهندسی اجتماعی با مضمون passkey آغاز شده و به دسترسی ابری منجر می‌شود. با این حال، هرگونه ارزیابی باید با آگاهی از محدودیت‌های ذاتی داده‌های موجود صورت گیرد. نخست، زیرساخت مهاجم (شامل دامنه‌ها، آدرس‌های IP و ارائه‌دهندگان هاستینگ) به سرعت تغییر می‌کند و بنابراین شاخص‌های فنی ارائه‌شده در گزارش، صرفاً نمایانگر یک مقطع زمانی خاص هستند و نمی‌توانند مبنای پایداری برای شناسایی بلندمدت باشند. دوم، گزارش به صراحت اشاره می‌کند که Attribution قطعی برای این فعالیت وجود ندارد و الگوی مشاهده‌شده ممکن است با سایر عوامل تهدید نیز همپوشانی داشته باشد. بنابراین، هرگونه نسبت‌دهی به یک گروه خاص باید به‌عنوان یک فرضیهٔ کاری در نظر گرفته شود، نه یک نتیجهٔ قطعی.

سوم، در بسیاری از موارد، اولین و تنها شاهد آغاز حمله، اظهارات کاربر در مورد تماس تلفنی یا پیام متنی است. این شواهد اولیه ذاتاً ذهنی و ناقص هستند و ممکن است جزئیات مهمی مانند محتوای دقیق پیام یا آدرس وب‌سایت فیشینگ را شامل نشوند. از آنجا که کاربر ممکن است لینک را بر روی دستگاه شخصی خود باز کرده باشد که به ابزارهای نظارتی سازمان متصل نیست، ردپای دیجیتال این مرحله از حمله اغلب در تله‌متری سازمانی وجود ندارد. این شکاف اطلاعاتی، بازسازی کامل زنجیرهٔ حمله را دشوار می‌سازد و تحلیلگران را مجبور می‌کند که بر اساس نشانه‌های بعدی مانند ورود غیرعادی، تغییر روش‌های احراز هویت و فعالیت Graph، استنتاج کنند.

علاوه بر این، گزارش مایکروسافت عمدتاً بر روی مشاهدات سطح بالا متمرکز است و جزئیات فنی دقیقی دربارهٔ زیرساخت تشخیصی یا قابلیت‌های خاص محصولات امنیتی ارائه نمی‌دهد. بنابراین، در این تحلیل از ذکر هرگونه قابلیت تشخیصی خاص یا آمار کمّی که در منبع اصلی ذکر نشده است، خودداری می‌شود. همچنین، توصیه‌های ارائه‌شده در این بخش، عمدتاً جنبهٔ عمومی و مبتنی بر بهترین شیوه‌های امنیتی دارند و باید با توجه به معماری و ریسک‌پذیری هر سازمان سفارشی‌سازی شوند. در نهایت، تأکید می‌شود که این تحلیل صرفاً جنبهٔ دفاعی دارد و هدف آن افزایش آگاهی و آمادگی در برابر چنین تهدیداتی است، نه ارائهٔ هرگونه راهنمایی عملیاتی برای مقابله با مهاجم.

• تغییر سریع زیرساخت مهاجم، ارزش شاخص‌های فنی را برای شناسایی بلندمدت محدود می‌کند.
• عدم قطعیت در Attribution، نیاز به احتیاط در نسبت‌دهی فعالیت به گروه‌های خاص را نشان می‌دهد.
• اتکا به گزارش کاربر به عنوان شواهد اولیه، به دلیل ذهنی بودن و ناقص بودن، چالش‌برانگیز است.
• فقدان تله‌متری از دستگاه‌های شخصی، بازسازی کامل مراحل اولیه حمله را دشوار می‌سازد.

شاخص‌های کلیدی و معیارهای موفقیت

در ارزیابی پاسخ به تهدیدات مبتنی بر مهندسی اجتماعی با محوریت Passkey، تعریف شاخص‌های قابل اندازه‌گیری برای سنجش اثربخشی اقدامات دفاعی ضروری است. این شاخص‌ها باید بر اساس قابلیت‌های عملیاتی تیم دفاعی و بدون اتکا به اعداد مشخص از پیش تعیین‌شده تعریف شوند، چراکه هر سازمان بسته به زیرساخت و بلوغ امنیتی خود، معیارهای متفاوتی خواهد داشت. هدف اصلی، ایجاد چارچوبی است که امکان ارزیابی عینی واکنش به حادثه را فراهم کند.

یکی از مهم‌ترین معیارها، زمان تشخیص (Time to Detect) است که فاصله بین شروع حمله و شناسایی فعالیت مشکوک را اندازه‌گیری می‌کند. این شاخص به‌ویژه در حملاتی که از طریق تماس تلفنی یا پیامک آغاز می‌شوند، اهمیت بیشتری می‌یابد؛ زیرا شواهد اولیه ممکن است تنها شامل اظهارات کاربر باشد. به‌عنوان معیار دیگر، تعداد نشست‌های باطل‌شده (Revoked Sessions) پس از تأیید سازش‌یافتگی حساب‌ها مدنظر قرار می‌گیرد که نشان‌دهنده سرعت عمل تیم در خنثی‌سازی دسترسی غیرمجاز است.

همچنین، حذف روش‌های احراز هویت غیرمجاز (Unauthorized Authentication Methods) که توسط مهاجم به حساب اضافه شده، به‌عنوان شاخصی کلیدی برای پاکسازی کامل ردپای حمله تلقی می‌شود. این اقدام باید مستند شده و در گزارش نهایی منعکس شود. در نهایت، معیارهایی مانند کاهش حجم داده‌های استخراج‌شده از سرویس‌هایی مانند SharePoint و OneDrive و نیز تعداد تماس‌های Graph API که به‌صورت غیرعادی مشاهده شده‌اند، می‌توانند به‌عنوان شاخص‌های کمکی برای ارزیابی میزان موفقیت در محدودسازی خسارت مورد استفاده قرار گیرند.

توصیه می‌شود تیم‌های دفاعی این شاخص‌ها را به‌صورت دوره‌ای بازبینی کرده و آن‌ها را با سناریوهای حمله جدید تطبیق دهند. به‌عنوان مثال، اگر مهاجمان از تکنیک‌های جدیدی مانند سوءاستفاده از دستگاه‌های شخصی استفاده کنند، معیارهای مرتبط با دیدپذیری (Visibility) باید تقویت شوند. در نهایت، موفقیت نهایی در گرو ایجاد یک حلقه بازخورد است که در آن هر حادثه منجر به بهبود فرآیندهای شناسایی و پاسخ شود.

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

1. تعریف خط پایه برای فعالیت‌های عادی کاربران و سرویس‌های ابری.
2. پیاده‌سازی هشدارهای بلادرنگ برای رویدادهای مرتبط با تغییر روش‌های احراز هویت.
3. مستندسازی تمام اقدامات انجام‌شده در طول پاسخ به حادثه برای تحلیل‌های بعدی.

عملیاتی‌سازی و اقدامات دفاعی

بر اساس گزارش اخیر مایکروسافت، تیم‌های دفاعی باید زنجیره رویدادهای مرتبط با این نوع نفوذ را به‌عنوان یک الگوی رفتاری مدنظر قرار دهند؛ الگویی که با تماس یا پیامک جعلی از سوی به‌اصطلاح پشتیبانی فنی آغاز شده و سپس به تغییر روش‌های احراز هویت، جستجو در Microsoft Graph و در نهایت جمع‌آوری داده از SharePoint، OneDrive و Exchange منتهی می‌شود. توصیه می‌شود که بازبینی لاگ‌ها بر اساس این توالی انجام شود و نه صرفاً بر اساس شاخص‌های منفرد.

یکی از مهم‌ترین اقدامات، بررسی دقیق رویدادهای مرتبط با افزودن روش‌های احراز هویت جدید توسط کاربران است. هرگونه تغییر غیرعادی در روش‌های MFA یا ثبت دستگاه جدید باید به‌عنوان هشدار در نظر گرفته شود. همچنین، بازبینی فعالیت‌های Microsoft Graph با حجم بالا، به‌ویژه دانلودهای انبوه از SharePoint و OneDrive، می‌تواند نشانه‌هایی از جمع‌آوری خودکار داده‌ها را آشکار کند. برای موارد تأییدشده، باید نشست‌های فعال را لغو کرده و روش‌های احراز هویت غیرمجاز را حذف کرد.

آموزش کاربران در مورد تماس‌های IT جعلی نقشی کلیدی دارد. از آنجا که این حملات اغلب با تماس تلفنی یا پیامک به شماره شخصی آغاز می‌شوند و ممکن است هیچ اثر فنی از خود بر جای نگذارند، آگاهی‌بخشی به کاربران در مورد عدم اعتماد به درخواست‌های فوری برای به‌روزرسانی تنظیمات امنیتی ضروری است. کاربران باید تشویق شوند که هرگونه تماس مشکوک را از طریق کانال‌های رسمی تأیید کنند و آن را به تیم امنیتی گزارش دهند.

در نهایت، اعمال سیاست‌های سخت‌گیرانه‌تر برای روش‌های احراز هویت، از جمله محدود کردن استفاده از جریان‌های Device Code و الزام به استفاده از روش‌های مقاوم در برابر فیشینگ، می‌تواند سطح حمله را کاهش دهد. این توصیه‌ها صرفاً مبتنی بر یافته‌های گزارش مایکروسافت است و به‌عنوان پیشنهادهای اولیه برای تیم‌های دفاعی ارائه می‌شود.

• بازبینی منظم لاگ‌های ورود و جستجو برای رویدادهای غیرعادی مرتبط با Device Code و تغییر روش‌های احراز هویت.
• آموزش کاربران در مورد تماس‌های جعلی IT و نحوه گزارش دهی.
• اعمال سیاست‌های سخت‌گیرانه‌تر برای روش‌های احراز هویت، از جمله محدود کردن Device Code flow.

1. بررسی گزارش‌های کاربران در مورد تماس‌های مشکوک و مستندسازی آن‌ها به‌عنوان سرنخ اولیه.
2. بازبینی رویدادهای Microsoft Graph برای جستجوی فعالیت‌های با حجم بالا.
3. در صورت تأیید نفوذ، لغو نشست‌ها و حذف روش‌های احراز هویت غیرمجاز.