في فبراير 2026 ظهر على الساحة منصة EvilTokens، وهي خدمة تصيّد كخدمة (PhaaS) نجحت خلال خمسة أسابيع فقط في اختراق أكثر من 340 مؤسسة تستخدم Microsoft 365 عبر خمس دول. الفكرة كانت بسيطة وخبيثة: رسالة تطلب من المستخدم إدخال رمز قصير على موقع microsoft.com/devicelogin وإتمام التحدي المعتاد للمصادقة متعددة العوامل (MFA). المستخدم يعتقد أنه أتم عملية تسجيل دخول روتينية، بينما في الحقيقة منح المهاجم رمز تحديث (Refresh Token) صالحاً للوصول إلى بريده وملفاته وتقويمه وجهات الاتصال، بعمر يمتد لأسابيع أو أشهر وفق سياسة المستأجر.
لماذا لا ترى MFA منح OAuth؟
التصيّد التقليدي يسلم اسم مستخدم وكلمة مرور، ويُعاد تشغيلهما في مكان ما، فتظهر المطالبة بعامل ثانٍ. حتى أدوات التصيّد عبر وسيط (AiTM) تنتج ملفات تعريف ارتباط مرتبطة بحدث تسجيل دخول يمكن رصده.
لكن منح OAuth لا يعيد تشغيل بيانات الاعتماد. المستخدم يُصادق على مزود الهوية الشرعي، يُكمل تحدي MFA، ثم يضغط “قبول”. الرمز الناتج موقّع من مزود الهوية، قابل للتجديد، ومحدد بالنطاقات التي وافق عليها المستخدم. MFA لا تستطيع منعه لأنه حدث بالفعل قبل إصدار الرمز.
كيف أصبح القبول عادة؟
منذ أن صار OAuth معياراً، كان هذا المسار موجوداً. لكن البيئة تغيّرت: المستخدمون اعتادوا الضغط على شاشات الموافقة كما يضغطون على لافتات ملفات تعريف الارتباط. كل وكيل ذكاء اصطناعي يحتاج إلى إذن، كل إضافة إنتاجية، كل امتداد متصفح. حجم الموافقات الشرعية التي يراها الموظف المعرفي في شهر يفوق ما كان متصوراً عند كتابة نماذج التهديد الأصلية.
الأخطر أن لغة النطاقات لا تعكس حجم المخاطر بدقة. عبارة مثل “قراءة بريدك” تبدو محدودة، لكنها تعني الوصول إلى كل الرسائل والمرفقات. و”الوصول إلى الملفات في غيابك” تعني رمزاً طويل العمر يصدر دون حضور المستخدم لإلغائه.
التوليفات السامة تحت السطح
منح OAuth واحد يمنح المهاجم موطئ قدم في تطبيق واحد. لكن الخطر الحقيقي يظهر حين تتقاطع هذه الأذونات. موظف مالي يمنح أداة تلخيص الاجتماعات وصولاً إلى بريده وتقويمه، ثم يمنح مساعد إنتاجي وصولاً إلى محرك مشترك، ثم يمنح أداة CRM وصولاً إلى قاعدة العملاء. كل إذن منفصل، لكن النتيجة شبكة متقاطعة من الصلاحيات عبر هوية واحدة. هذا ما يسمى التوليفة السامة، حيث لا يملك أي مالك تطبيق رؤية كاملة للمخاطر لأنها تتشكل خارج سجلات التدقيق الفردية.
ما الذي يجب مراجعته؟
لمعالجة هذه الفجوة، يجب التعامل مع موافقات OAuth كما نتعامل مع المصادقة نفسها. هناك نقاط مراجعة أساسية:
- جرد تطبيقات OAuth: قائمة بكل التطبيقات التي تحتفظ برموز تحديث في المستأجر.
- عمر المنح وإعادة الموافقة: الرموز الأقدم من 30 يوماً دون إعادة موافقة.
- الهويات متعددة التطبيقات: حسابات تحمل أذونات عبر ثلاثة تطبيقات SaaS أو أكثر.
- الجسور بين الوكلاء والتكاملات: وكلاء ذكاء اصطناعي أو تكاملات تربط أنظمة لم يوافق أي مالك تطبيق على دمجها.
- الوصول الشرطي عند الموافقة: سياسات تُفعّل عند أحداث الموافقة وليس فقط عند تسجيل الدخول.
- إبطال الرموز على مستوى الرمز: خطط لإلغاء رمز OAuth واحد بدلاً من تعليق الحساب كله.
أين تتدخل منصات أمن الذكاء الاصطناعي؟
ظهرت فئة جديدة من المنصات مثل Reco، تقوم برسم خريطة لكل منح OAuth ووكلاء الذكاء الاصطناعي والتكاملات فور صدورها، وتربطها بالهوية التي وافقت عليها، ثم تراقب السلوك بحثاً عن انحرافات وتلغي الوصول على مستوى الرمز. هذه الرؤية المستمرة للطبقة التشغيلية حيث تتشكل العلاقات هي ما ينقص معظم المؤسسات اليوم.
التصيّد عبر الموافقة لن يبقى هامشياً طويلاً. الاستثمار في MFA كان ضخماً، لكن طبقة الموافقة ما زالت تعمل على الثقة وحدها. سد الفجوة يتطلب أن تُعامل منح OAuth واتصالات الوكلاء بنفس الانضباط والرقابة المطبقة على المصادقة.
