تُظهر التهديدات السيبرانية المتجددة كيف يمكن استغلال منصات موثوقة، حيث أصبحت Microsoft Entra ID هدفًا متزايدًا عبر تقنية تُعرف بإساءة استخدام موافقة OAuth. وثق سيناريو هجوم جديد كيف يمكن لتطبيق طرف ثالث خبيث، أو ذي صلاحيات مفرطة، أن يحصل على وصول إلى بريد المستخدمين دون الحاجة لكلمة المرور.
تُعد OAuth، أو التفويض المفتوح، بروتوكولًا قياسيًا يسمح للتطبيقات بالوصول إلى بيانات المستخدمين بإذنهم. في Entra ID، عندما يربط المستخدم تطبيق طرف ثالث بحسابه، تظهر له نافذة طلب موافقة توضح الصلاحيات التي يطلبها التطبيق. يستغل المهاجمون هذا بإنشاء أو إخفاء تطبيق يطلب صلاحيات حساسة مثل `Mail.Read`، والتي تمنح التطبيق وصولاً كاملاً لقراءة كل شيء في صندوق البريد الخاص بالمستخدم بمجرد الموافقة.
استغلال OAuth في Entra ID بواسطة ChatGPT
في حالة دراسة قام بها محللو Red Canary، قام مستخدم مؤسسي بإضافة ChatGPT كخدمة رئيسية طرف ثالث ضمن نطاق Entra ID، ووافق كمستخدم غير إداري على صلاحيات OAuth التالية: `Mail.Read`، `offline_access`، `profile`، و `openid`. كانت هذه العملية، التي جريت في 2 ديسمبر 2025، قد تتبعت إلى عنوان IP 3.89.177.26.
رغم أن هذا التحقيق خلص إلى أن التطبيق كان ChatGPT الأصلي المملوك لـ OpenAI، إلا أن خطوات التحقيق تتبع نفس تسلسل الهجوم الذي لوحظ سابقًا في حوادث حقيقية. الخطر الحقيقي لا يكمن في ChatGPT تحديدًا، بل في نمط الهجوم نفسه؛ فأي تطبيق طرف ثالث، سواء كان شرعيًا أو خبيثًا، يحصل على إذن `Mail.Read` عبر موافقة المستخدم يمكنه قراءة جميع الرسائل في صندوق البريد المستهدف بصمت.
في هجوم حقيقي، يمكن لممثل تهديد تصميم تطبيق يحمل اسمًا مقنعًا، ونشره عبر رابط تصيد احتيالي، ثم جمع رسائل البريد الإلكتروني الحساسة، أو المراسلات الداخلية، أو بيانات الاعتماد دون أن يدرك الضحية أن حسابه قد تم اختراقه. ما يزيد من هذا الخطر هو السماح لـ Entra ID، افتراضيًا، للمستخدمين العاديين غير الإداريين بالموافقة على التطبيقات التي لا تتطلب موافقة إدارية.
آلية عمل هجوم الموافقة
عند توجيه المستخدم لربط تطبيق، سواء عبر بريد إلكتروني تصيدي، أو هندسة اجتماعية، أو تصفح عادي، يتم تسجيل حدثين محددين في سجلات التدقيق داخل Entra ID: “إضافة كيان خدمة” و “الموافقة على التطبيق”. يحمل كلا الحدثين `CorrelationId` مشترك، مما يمكّن فرق الأمان من ربطهما وتتبع سلسلة الموافقة الكاملة وصولاً إلى إجراء واحد قام به المستخدم.
يركز نهج الكشف لدى Red Canary على تمييز منح الموافقة من قبل المستخدمين غير الإداريين المرتبطة بتطبيقات طرف ثالث جديدة تتضمن نطاق OAuth واحدًا أو أكثر يتم إساءة استخدامه بشكل متكرر. مؤشر رئيسي هو حقل `AppOwnerOrganizationId` داخل سجل التدقيق؛ عندما لا يتطابق هذا المعرف مع معرف المستأجر الخاص بالمؤسسة أو معرفات Microsoft الأولى المعروفة، فإن التطبيق يكون تابعًا لطرف ثالث ويجب التعامل معه بشبهة فورية. تشمل النطاقات التي يتم إساءة استخدامها بشكل متكرر في هذه الهجمات `Mail.Read`، `Files.Read.All`، `Chat.Read`، و `Sites.Read.All`.
الإجراءات الوقائية والمعالجة
عند تأكيد منح موافقة خبيثة أو غير مصرح بها، يجب اتخاذ خطوتين للعلاج فورًا. أولاً، يجب إلغاء صلاحيات OAuth باستخدام معرف المنحة المستخرج من حدث تدقيق “الموافقة على التطبيق”، تليها إزالة الكيان الخدمي من المستأجر باستخدام معرف الكائن الخاص به. يمكن إكمال كلا المهمتين باستخدام أوامر Microsoft Graph PowerShell.
على جانب الوقاية، توفر Microsoft ثلاثة خيارات سياسة موافقة قابلة للتكوين. النهج الأكثر أمانًا يتطلب موافقة المسؤول على جميع طلبات الموافقة، مما يلغي قدرة المستخدمين غير الإداريين على تفويض أي تطبيقات. إعداد أكثر توازنًا يقيد الموافقة على الناشرين الموثوق بهم ذوي الأذونات المعتمدة مسبقًا ومنخفضة المخاطر. التكوين الموصى به من Microsoft يطبق تلقائيًا إرشادات موافقة المستخدم الحالية الخاصة بها على المؤسسة، مما يوفر حلاً وسطًا عمليًا بين الأمان والراحة التشغيلية.