تحذير FBI من Kali365 عام 2026: كيف يتجاوز التصيد عبر OAuth device-code رمز MFA

موجز تنبيه FBI في 60 ثانية

يصف تنبيه FBI IC3 رقم PSA260521 أن Kali365 طقم تصيد جاهز يُباع على قنوات Telegram الناطقة بالروسية وفي المنتديات السرية. يدفع المشغلون نحو 199 دولاراً شهرياً مقابل صفحات هبوط مستضافة، وتوجيه آلي للضحايا، ولوحة تحكم تعرض جلسات Microsoft 365 المسروقة حديثاً في الوقت الفعلي تقريباً. يقول FBI إن الأهداف تشمل مزودي الخدمات المُدارة، ومكاتب المحاسبة والمحاماة، والشبكات الصحية، والمؤسسات الصغيرة والمتوسطة التي تعتمد على Microsoft 365 لكن تفتقر إلى سياسات وصول مشروط ناضجة. تضيف تغطية BleepingComputer أن عدة شركات استجابة للحوادث بدأت تشاهد مؤشرات Kali365 في أواخر فبراير 2026، مع ارتفاع حاد خلال أبريل. ما يجعل Kali365 مختلفاً عن أطقم تسجيل الدخول المزيفة المعتادة هو ما يُطلب من الضحية: ليس كتابة كلمة مرور، بل إدخال رمز جهاز قصير على نطاق microsoft.com الحقيقي.

كيف يعمل التصيد عبر OAuth device-code فعلياً

صُممت منحة تفويض الجهاز في OAuth، المعرّفة في RFC 8628 والمطبقة من Microsoft Entra ID، لأجهزة لا تملك متصفحاً حقيقياً. فكّر في أجهزة التلفاز الذكية، ووحدات Xbox، وأجهزة إنترنت الأشياء، وأدوات سطر الأوامر مثل Azure CLI أو kubectl. يبدو التدفق في يوم طبيعي على هذا النحو:

1. يطلب الجهاز من نقطة نهاية رموز Microsoft رمز جهاز جديد. تُعيد Microsoft سلسلتين: رمز جهاز طويل (يستخدمه الجهاز للاستعلام عن الرمز المميز) ورمز مستخدم قصير، يكون عادة من ثمانية أو تسعة أحرف مثل "FQRMNXSP".
2. يعرض الجهاز رمز المستخدم على شاشته ويقول: "اذهب إلى microsoft.com/devicelogin وأدخل FQRMNXSP".
3. يفتح المستخدم متصفحاً، ويسجّل دخوله إلى حساب Microsoft 365 الخاص به بشكل طبيعي (بما في ذلك MFA)، ويكتب الرمز في الصفحة على microsoft.com/devicelogin.
4. تربط Microsoft الجلسة المُصادَق عليها برمز الجهاز. الجهاز، الذي ما زال يستعلم، يتلقى رمز وصول (Access Token) ورمز تحديث (Refresh Token).

الآن استبدل كلمة "الجهاز" بـ "خادم المهاجم" وراقب كيف ينهار التدفق. يبدأ مشغّل Kali365 طلب device-code ضد نقطة نهاية Microsoft، حاصداً رمز المستخدم. ثم تصلك رسالة تصيد في بريدك الوارد تدّعي أنك بحاجة لتسجيل قاعة Teams جديدة، أو الموافقة على مزامنة SharePoint، أو تفعيل ترخيص Microsoft Defender for Endpoint. تخبرك الرسالة بزيارة microsoft.com/devicelogin ولصق رمز ولّده المهاجم. تسجّل دخولك إلى حساب Microsoft الحقيقي، تكتب الرمز، وتنقر على تأكيد. تقوم Microsoft بما صُممت لفعله بالضبط، فترسل رمز وصول ورمز تحديث إلى خادم استعلام المهاجم. لم تكتب أي بيانات اعتماد في أي شيء خبيث، ووافقت على إشعار MFA بشكل صحيح، ومع ذلك يملك المهاجم الآن جلسة تبدو لا يمكن تمييزها عن جلستك.

لماذا لا تحميك المصادقة الثنائية

تفترض المصادقة متعددة العوامل أن حالة الفشل هي إعادة تشغيل كلمة مرور مسروقة في مكان لا ينبغي إعادة تشغيلها فيه. الهدف الكامل من العامل الثاني هو كسر هذه الإعادة. يعكس التصيد عبر device-code الافتراض رأساً على عقب. لا يحاول المهاجم أبداً إعادة تشغيل كلمة المرور. أنت تُصادق بالضبط كما تتوقع Microsoft، على نطاق microsoft.com الحقيقي، من الجهاز الذي تستخدمه دائماً، أمام موفّر الهوية الحقيقي لمؤسستك. يصلك تحدي MFA فتوافق عليه لأنك في الواقع تسجّل دخولاً حقيقياً. الاحتيال ليس في خطوة المصادقة، بل في خطوة الموافقة، حيث تربط جلستك المُصادَق عليها للتو بقطعة عتاد خاطئة.

تطابق الأرقام في Microsoft Authenticator، الذي تناولناه في مقال إرهاق MFA، لا يساعد هنا أيضاً. يهزم تطابق الأرقام البريد المزعج للإشعارات بإجبار المستخدم على كتابة رقم من شاشة تسجيل دخول لم يفتحها هو. في التصيد عبر device-code يفتح المستخدم شاشة تسجيل الدخول بنفسه. لا توجد حالة شاذة لرفعها.

لهذا السبب استخدم FBI عبارة الاختراق الدائم "ما بعد MFA" في PSA260521. بمجرد أن يملك المهاجم رمز الوصول ورمز التحديث، يستطيع جلب بريد Outlook، وإرسال رسائل من عنوانك، وتعداد بيئة SharePoint، وتسجيل طريقة MFA خاصة به على حسابك، وتحديث الجلسة بصمت طوال عمر رمز التحديث. لا يصدر أي طلب MFA مستقبلي لأن المهاجم لا يعيد المصادقة أبداً. هو فقط يستمر في التحديث.

ما يراه SafeBrowz في الشبكة

يقوم فريق هندسة الكشف لدينا برسم خرائط البنية التحتية لصفحات هبوط Kali365 منذ أواخر فبراير. هناك عدة أنماط تستحق الذكر، وهي الأنماط التي ضُبط محركنا ثلاثي الطبقات تحديداً لالتقاطها.

أولاً، صفحات الهبوط لا تعيش تقريباً أبداً على microsoft.com نفسه. تعيش على مضيفات مشابهة في الشكل تُوجّه الضحية نحو عنوان microsoft.com/devicelogin الشرعي فقط بعد صفحة وسيطة مزيفة من نوع "تحقق من بيئتك" أو "سجّل جهازك". الصفحة الوسيطة هي المكان الذي تحدث فيه الهندسة الاجتماعية، وتقع تلك الصفحة الوسيطة دائماً تقريباً على نطاق مُسجَّل حديثاً. من الحملات التي حللناها، عمر النطاق المشابه النموذجي لـ Kali365 أقل من سبعة أيام عند لحظة الاختراق. بعضها أقل من اثنتي عشرة ساعة. هذه أقوى إشارة من جانب الخادم نملكها لعائلة هذا الطقم، وهي تتوافق تماماً مع كيفية عمل استعلامات السمعة في الطبقة الثانية لدينا: Google Safe Browsing وPhishTank وURLhaus جميعها تكشف النطاقات الخبيثة الجديدة خلال ساعات، ويقرأ ملحقنا تلك الموجزات عند كل تصفح.

ثانياً، أسماء المضيفات المشابهة تتجمع حول حفنة من المتغيرات الهيكلية. نرى "ms-teams-rooms-{tenant}.{tld}" و"microsoft365-activate-{region}.{tld}" و"m365-defender-onboard.{tld}" و"office-licensing-portal.{tld}" و"azureportal-verify.{tld}" و"sharepoint-sync-{department}.{tld}" وذيلاً طويلاً من الأسماء الإبداعية المنفردة. كثير منها يستخدم نطاقات TLD رخيصة أو مستغَلَّة (.shop, .top, .xyz, .live, .click) لأنها زهيدة على نطاق واسع. Microsoft واحدة من 550+ علامة تجارية في قاعدة بيانات الكشف المحلية لدينا، وتلتقط البصمة الخاصة بالعلامة كل متغير من متغيرات اللاحقة المشابهة لحظة بدء التصفح، قبل أن تُرسم الصفحة حتى.

ثالثاً، محتوى صفحة الهبوط يحمل علامة كاشفة تجيد طبقتنا الثالثة (تحليل المحتوى بالذكاء الاصطناعي) العثور عليها بشكل استثنائي. يحتاج الطقم لإقناع شخص حقيقي بنسخ رمز مستخدم OAuth حقيقي ولصقه في صفحة Microsoft حقيقية. هذا يتطلب نصّ هندسة اجتماعية مكتوب: تعليمات مثل "تم إصدار رمز إعداد لمرة واحدة لك: XXXX-XXXX"، و"افتح microsoft.com/devicelogin في علامة تبويب جديدة"، و"تنتهي صلاحية هذا الرمز خلال 8 دقائق". هذه اللغة نادرة على واجهات Microsoft الشرعية. لا تطلب Microsoft عادة من إنسان أن ينسخ رموز الأجهزة بين نافذتين. عندما يرى الفحص العميق للذكاء الاصطناعي لدينا هذا النمط مقترناً بعلامة Microsoft التجارية على مضيف غير microsoft.com، يكون الحكم خطر (Danger) في كل مرة. لم نكتب قاعدة خاصة بـ Kali365، ولم نضطر. النمط العام "علامة تجارية مشابهة في الشكل + تعليمات تسليم OAuth" يُطلق التنبيه على عائلة الطقم بأكملها لأنها لا تستطيع التوقف عن إنتاج هذه التعليمات وتستمر في العمل.

لماذا يتفوق الكشف من جانب المتصفح على الكشف من جانب البريد فقط

سيُؤطَّر تنبيه Kali365 في بعض الأماكن بوصفه سبباً لشراء بوابة بريد إلكتروني أكثر أماناً. وجهة نظرنا أكثر صرامة. بوابات البريد الإلكتروني ضرورية، لكنها بحكم التصميم غير كافية لهذا النوع من الهجمات.

SPF وDKIM وDMARC تتحقق من أن نطاق الإرسال يتحكم في الرسالة. مشغّلو Kali365 يرسلون روتينياً من بيئات شرعية مخترقة (الطقم يخطف صناديق بريد Microsoft 365 ويستخدمها منصة إطلاق للموجة التالية)، لذا تجتاز الرسالة كل فحوصات المصادقة. نطاق الإرسال حقيقي. الاسم المعروض حقيقي. كتلة التوقيع حقيقية. أيضاً، تشغيل الرابط داخل صندوق رمل (Sandbox) لا يساعد كثيراً، لأن صفحة الهبوط غالباً ما تقدّم محتوى آمناً لوكلاء المستخدمين غير البشريين، ولا تعرض الصفحة الوسيطة لـ OAuth إلا حين يُكشف أنها متصفح حقيقي.

بحلول الوقت الذي ينقر فيه المستخدم على الرابط، تكون البوابة قد وافقت على الرسالة فعلاً. يجب أن يكون الدفاع حيث يحدث العرض (Rendering). وهذا المتصفح. الماسح الذي يعمل على مستوى المتصفح ويحمل قاعدة بيانات 550+ علامة تجارية، ويقرأ موجزات السمعة العالمية، ويُشغّل تحليل محتوى بنماذج لغوية على الصفحة المعروضة هو الطبقة الوحيدة التي ترى لحظة الاختراق. تلك هي الطبقة التي يجلس فيها SafeBrowz، وذلك سبب بنائنا له بالطريقة التي بنيناه بها.

كيف يحجب SafeBrowz هذا التهديد

يعمل SafeBrowz عبر بنية الحماية ثلاثية الطبقات: محلي + واجهات + ذكاء اصطناعي.

• الطبقة 1، الكشف المحلي: 60+ نمطاً لعناوين URL إضافة إلى 550+ بصمة خاصة بالعلامات التجارية (Microsoft وMicrosoft365 / Outlook / Teams / SharePoint / Azure ومتغيراتها مُدرجة)، وكشف الكيريلية وPunycode المتشابهة بصرياً (Homograph)، وقوائم مجتمعية تعمل مباشرة داخل الملحق قبل أن تُعرض الصفحة. أنماط المضيفات المشابهة الموصوفة أعلاه (ms-teams-rooms-*, microsoft365-activate-*, m365-defender-onboard-*, office-licensing-portal-*) كلها تطابق عائلة قاعدة انتحال العلامة في الطبقة 1 وتُحجب قبل أن تُرسم.
• الطبقة 2، سمعة الواجهات (APIs): تجميع من جانب الخادم لـ Google Safe Browsing وPhishTank وURLhaus وScamAdviser و30+ فحصاً لنطاقات TLD المخادعة. النطاقات المشابهة لـ Microsoft المُسجَّلة حديثاً (عمر النطاق النموذجي لـ Kali365 أقل من سبعة أيام) تظهر في PhishTank وURLhaus خلال ساعات، وغالباً خلال دقائق. يقرأ ملحقنا تلك الإشارات عند كل تصفح.
• الطبقة 3، الفحص العميق بالذكاء الاصطناعي (Premium): محلل محتوى متعدد اللغات يقرأ الصفحة المعروضة ويفكر بنية المنشئ. بالنسبة لـ Kali365، البصمة الكاشفة هي "علامة Microsoft تجارية مشابهة + تعليمات تسليم OAuth device-code + رمز مستخدم بانتهاء صلاحية". عندما يظهر هذا النمط على مضيف غير microsoft.com، الحكم هو خطر. يعمل المحرك نفسه بأكثر من 100 لغة، وهذا مهم لأن Kali365 يطرح صفحات هبوط مُترجمة للأهداف الإسبانية والبرتغالية والعربية والفرنسية والألمانية.

توقيعات الكشف مشتقة من أبحاث استخبارات التهديد وقاعدة بيانات العلامات التجارية، وليس من بيانات تصفح المستخدم. لا يتم تخزين سجل عناوين URL لكل مستخدم على الإطلاق.

الخطوات الفورية للمؤسسات والمستخدمين

إذا كنت تدير بيئة Microsoft 365، فلا تنتظر الربع القادم لمعالجة Kali365. خطوات محددة مرتّبة حسب الأولوية:

1. راجع نشاط تسجيل الدخول على aka.ms/signin. ابحث عن منح OAuth من أسماء أجهزة لا تعرفها، وعدم تطابق جغرافي، ومدخلات أجهزة من نوع "Other client" على حسابات يجب أن تكون قائمة على المتصفح فقط.
2. أبطل الجلسات النشطة على مستوى البيئة للمستخدمين عالي الخطورة. في مركز إدارة Microsoft 365 اذهب إلى Users، اختر الحساب، افتح Sign-in activity، وانقر Revoke. تظل رموز التحديث صالحة حتى بعد إعادة تعيين كلمة المرور؛ إبطال الجلسات هو الطريقة الوحيدة لقتلها بالقوة.
3. فعّل سياسات Conditional Access التي تعطّل تدفق device-code إلا لمستخدمين محددين بوضوح. أصبح Microsoft Entra يطرح الآن قالباً جاهزاً لـ Conditional Access باسم "Block authentication flows - Device code flow" (مرجع السياسة). يجب أن تحجب معظم البيئات تدفق device-code للجميع باستثناء مشغّلي تقنية المعلومات الذين يستخدمون فعلاً Azure CLI أو kubectl. هذا التغيير وحده يُنهي Kali365 في بيئتك.
4. افحص سجل موافقات OAuth. Microsoft 365 admin → Enterprise applications → Audit logs. فلتر حسب ConsentEvents خلال آخر 30 يوماً. ابحث عن معرّفات تطبيقات غير معروفة، خصوصاً أي شيء يشبه أسماء أدوات سطر أوامر أو سكربتات عامة. الموافقات غير المعروفة الممنوحة حول وقت تسجيلات الدخول المشبوهة هي الدليل الدامغ.
5. افرض MFA مقاومة للتصيد على الفئات الأعلى خطورة. مفاتيح FIDO2 الأمنية أو مفاتيح المرور (Passkeys) للمسؤولين الماليين والقانونيين والتنفيذيين ومشغّلي تقنية المعلومات. التصيد عبر device-code هو الهجوم النادر الذي ينجح ضد MFA المعتمدة على تطبيق المصادقة. مفاتيح المرور النقية لا تزال ترفع المستوى لأن خادم استعلام المهاجم لا يستطيع قيادة جلسة مرتبطة بمفتاح مرور.
6. إذا اشتبهت أن حساب Microsoft Authenticator قد لمسه مهاجم، أزل الحساب من التطبيق، أعد ضبط MFA من جهاز نظيف، وأعد التسجيل. بينما أنت هناك، راجع طرق MFA المسجّلة على كائن المستخدم؛ يحب المهاجمون إضافة رقم هاتف بصمت أو سرّ TOTP خاص بهم كباب خلفي.
7. درّب المستخدمين على جملة واحدة بالتحديد. "لن تُرسل لك Microsoft أبداً بريداً إلكترونياً يحتوي على رمز لتلصقه في microsoft.com/devicelogin". إذا رأى المستخدم هذه الصياغة في رسالة، فالرسالة عدائية، نقطة. هذه الجملة الواحدة أكثر فعالية من أي تدريب توعية عام بالتصيد لأنها تسمي الهجوم بالاسم.

بالنسبة لحسابات Microsoft الشخصية (outlook.com، hotmail.com، Xbox)، ينطبق المنطق ذاته بصورة أضيق. افحص account.microsoft.com/security لمعرفة النشاط الأخير، سجّل خروجاً من كل مكان، ودوّر كلمة المرور. الجانب الاستهلاكي لا يكشف سياسات Conditional Access، لكن تدفق device-code أندر بكثير في السيناريوهات الاستهلاكية، لذا يجب التعامل مع أي طلب device-code غير متوقع باعتباره عدائياً مؤكَّداً.

ما القادم: توقعاتنا لتحول هجمات العلامات التجارية

Kali365 هو أول طقم تصيد كخدمة يُصنّع إساءة استخدام OAuth device-code، لكن الأسلوب ليس حكراً على Microsoft. أي موفّر هوية يطرح منحة تفويض جهاز في OAuth مكشوف هيكلياً. توقعات فريق الكشف لدينا للاثني عشر شهراً القادمة، استناداً إلى ما نراه في قاعدة بيانات العلامات التجارية وما بدأنا نجده في تسجيلات النطاقات المشابهة في المراحل المبكرة:

• تصيد device-code على Google Workspace. تدعم Google تدفق device-flow لـ Google TV وWorkspace CLI وgcloud. بيئات Workspace بدون Context-Aware Access هي الأكثر تعرّضاً. نتوقع نسخة مماثلة لـ Kali365 تستهدف هويات Google خلال أشهر.
• إساءة استخدام device-flow في GitHub. يستخدم GitHub CLI تدفق الجهاز لمصادقة المطورين. جلسة GitHub مسروقة يمكن أن تؤدي مباشرة إلى تسريب الشيفرة المصدرية، وارتكاب كومتات خبيثة في تبعيات سلسلة التوريد، وسرقة أسرار Actions. هدف ذو فائدة عالية، وقليل جداً من المؤسسات تُطبّق Conditional Access على GitHub.
• رموز مصادقة Anthropic Claude API وOpenAI API. لا تستخدم واجهات الذكاء الاصطناعي حالياً تدفق OAuth device، لكن النمط الأوسع (رموز API طويلة العمر تُصاد من المطورين عبر صفحات موافقة مشابهة) أصبح حقيقياً بالفعل. بدأنا إضافة "Claude" و"Anthropic" إلى قاعدة بيانات العلامات لدينا لهذا السبب بالذات.
• تفويض الجهاز في AWS IAM Identity Center (المعروف سابقاً بـ SSO). تدعم AWS منحة تفويض جهاز لـ CLI v2 sso login. مؤسسة تعتمد على جلسات AWS SSO طويلة العمر لمشغّلي terraform وkubectl هي على بُعد طقم بأسلوب Kali365 من أسوأ سيناريوهات اختراق السحابة.
• Atlassian وSlack وZoom. كل هذه تكشف شاشات موافقة OAuth تبدو موثوقة جداً ونادراً ما يُراجعها أحد. ستستهدفها الأطقم في النهاية بمجرد أن تُغلق إجراءات Microsoft 365 المخففة نقطة الدخول الأكثر ربحية.

ملاحظة أخيرة. النموذج الاقتصادي لـ PaaS هو القصة الحقيقية هنا، وليس الطقم بعينه. عند 199 دولاراً شهرياً مع قناة دعم على Telegram ولوحة تحكم مستضافة، يعني Kali365 أن المهاجم لم يعد بحاجة لفهم OAuth إطلاقاً. يحتاج بطاقة ائتمان (أو USDT في محفظة Telegram) وقائمة أهداف. انخفض الحد الأدنى للمهارة المطلوبة لاستيلاء دائم وعالي الفعالية ومحصّن ضد MFA على حسابات السحابة إلى ما يقارب الصفر. على كل مدافع يعمل على مستوى المتصفح أن يخطط لهذا التحول، وليس للاسم الموجود في تنبيه هذا الشهر تحديداً.

الأسئلة الشائعة

ما هو Kali365 في جملة واحدة؟

Kali365 هو طقم تصيد كخدمة، أشار إليه FBI في تنبيه PSA260521 يوم 21 مايو 2026، يسرق حسابات Microsoft 365 عبر إساءة استخدام منحة تفويض الجهاز في OAuth 2.0 بحيث يوافق الضحية على جلسة المهاجم من خلال نطاق microsoft.com الحقيقي.

كيف يختلف Kali365 عن طقم تصيد Microsoft عادي؟

أطقم تصيد Microsoft العادية تخدع المستخدم لكتابة كلمة المرور ورمز MFA في صفحة تسجيل دخول مزيفة. Kali365 لا يطلب بيانات الاعتماد أبداً. يخدع المستخدم للصق رمز device-code قصير من OAuth في عنوان microsoft.com/devicelogin الحقيقي بعد المصادقة بشكل طبيعي. يتلقى المهاجم رمز الجلسة، تكون MFA قد جرت بشكل شرعي، ولا توجد سرقة بيانات اعتماد ظاهرة لتُكتشف.

لماذا لا تحجب المصادقة متعددة العوامل Kali365؟

لأن الضحية ينفّذ تسجيل دخول حقيقياً وصالحاً إلى حساب Microsoft الخاص به، بما في ذلك تحدي MFA حقيقي يوافق عليه بشكل صحيح. الفعل الخبيث يحدث في خطوة الموافقة، حيث تُربط الجلسة المُصادَق عليها للتو برمز جهاز المهاجم. لا يجري تجاوز MFA بالمعنى التشفيري؛ بل تُصبح غير ذات صلة عبر خداع المستخدم ليُصادق نيابة عن المهاجم.

ما الإصلاح الأكثر فعالية لمؤسسة بصورة منفردة؟

احجب تدفق مصادقة device-code في Conditional Access لكل من لا يحتاجه تحديداً. يطرح Microsoft Entra قالباً بنقرة واحدة لذلك. معظم المؤسسات لا تملك أي استخدام شرعي لـ device-code خارج مشغّلي تقنية المعلومات على Azure CLI أو kubectl. حجبه على مستوى البيئة للمستخدمين العاديين يُنهي Kali365 في بيئتك فوراً.

كيف يكشف SafeBrowz عن Kali365 إذا كان الطقم يبدّل النطاقات باستمرار؟

قواعد انتحال العلامة في الطبقة 1 تُطلَق على النمط الهيكلي المشابه، لا على نطاق محدد. موجزات السمعة في الطبقة 2 (Google Safe Browsing وPhishTank وURLhaus) تكشف المضيفات المُسجَّلة حديثاً خلال ساعات من أول استخدام مسيء. تحليل المحتوى بالذكاء الاصطناعي في الطبقة 3 يتعرّف على لغة الهندسة الاجتماعية الخاصة بـ OAuth device-code بغضّ النظر عن مكان استضافة الصفحة. الطقم مضطر لمواصلة إنتاج نص يطلب من المستخدمين لصق الرموز في microsoft.com/devicelogin، وهذا النص هو ما نتعرّف عليه.

أعتقد أن مستخدماً في بيئتي وافق على رمز Kali365. ماذا أفعل في الـ 15 دقيقة القادمة؟

افتح مركز إدارة Microsoft 365، اعثر على المستخدم، افتح Sign-in activity، انقر Revoke sessions. هذا يُبطل كل رمز تحديث مرتبط بالحساب. أعد تعيين كلمة مرور المستخدم. أعد تعيين طرق MFA على كائن المستخدم وأزل أي مصادق مُسجَّل لا يتعرّفه المستخدم. افتح Enterprise applications وراجع منح OAuth لهذا المستخدم، وألغِ أي شيء لا تملكه. ثم اذهب إلى Audit log واستخرج كل إجراء قامت به جلسة المهاجم.

هل يجمع SafeBrowz أي بيانات عن عناوين URL التي يزورها مستخدمو شركتي؟

لا. يُجري SafeBrowz كشف الطبقة 1 محلياً داخل المتصفح، دون أن يغادر أي عنوان URL الجهاز. فحوصات السمعة في الطبقة 2 تستعلم القوائم العالمية بالنطاق فقط، وليس بأي هوية. الفحص العميق بالذكاء الاصطناعي في الطبقة 3، المتاح لمستخدمي Premium، يرسل مقتطفات من المحتوى المعروض للتحليل ويتجاهلها بعد إصدار الحكم. لا نخزن سجل عناوين URL لكل مستخدم، ولا معرّفات مثيلات، ولا روابط IP بـ URL. تشهد قوائم Chrome Web Store وAMO وEdge كلها بأن الملحق لا يجمع سجل الويب.

هل ستوقف MFA المقاومة للتصيد مثل مفاتيح FIDO2 طقم Kali365؟

نعم، بشكل غير مباشر. مفتاح أمان FIDO2 أو مفتاح مرور على المنصة (Passkey) لا يمكن قيادته من خادم استعلام المهاجم لأن التحدي التشفيري مرتبط بنطاق الأصل الذي يتصفحه المستخدم. حتى لو خُدع المستخدم لنسخ رمز، فإن جلسة المهاجم لا يمكن أن تكتمل إلا إذا كان تدفق الجهاز مسموحاً لهذا الحساب. اقرن MFA المقاومة للتصيد بسياسة Conditional Access تُعطّل تدفق device-code لذلك المستخدم، فيُغلق مسار الهجوم.

قراءات ذات صلة

• كيفية اكتشاف بريد Microsoft المزيف: الهجوم الأولي الذي يُوجّه غالباً نحو التصيد عبر device-code
• إرهاق MFA وهجوم البريد المزعج للإشعارات: فئة تجاوز MFA الكبرى الأخرى، ولماذا يهزمها تطابق الأرقام
• تجاوز 2FA عبر الخصم في الوسط (AiTM): التصيد بالوكيل العكسي الذي يُنتج أيضاً رموز جلسات دائمة
• احتيال نافذة الدعم الفني المزيفة من Microsoft (DOJ 2026): النسخة الاستهلاكية لانتحال هوية Microsoft المؤسسي

الخلاصة: Kali365 ليس ثغرة جديدة بارعة. هو إساءة استخدام مُمنتجة لتدفق OAuth موثّق، مُعبّأ لغير الخبراء بـ 199 دولاراً شهرياً، يحوّل نقاط نهاية المصادقة الخاصة بـ Microsoft نفسها إلى آلية تسليم لاختراق حسابات دائم. الإصلاح في بيئتك ملموس: احجب تدفق device-code في Conditional Access، وراجع سجل موافقات OAuth، وأبطل جلسات أي مستخدم نقر، وضع محرك كشف من جانب المتصفح أمام صندوق الوارد. تنبيه FBI رقم PSA260521 هو التحذير. الاثنا عشر شهراً القادمة ستحدد أي المؤسسات تعاملت معه باعتباره صيحة تنبيه، وأيها استمرت في الاعتماد على بوابات البريد وإشعارات MFA للدفاع عن سحابة لم يعد أيٌّ منهما كافياً فيها وحده.