يقوم اثنان على الأقل من الجهات الفاعلة في مجال التهديد بتسليح تقنية تهرب جديدة تسمى انتحال معرف عميل OAuth في الحملات السحابية، مع تجاوز القياس عن بعد.
يتيح هذا النشاط للمستخدمين تعداد حسابات المستخدمين والتحقق من صحة بيانات الاعتماد المسروقة في بيئات Microsoft Entra ID، دون إنشاء حدث تسجيل دخول ناجح من شأنه أن ينبه المدافعين. وقد بدأت الجهات الفاعلة السيئة في استغلال هذه الثغرة للحصول على وصول غير مصرح به إلى الخدمات السحابية الخاصة بالمؤسسة.
وقالت Proofpoint في بيان: “نقطة عمياء في القياس عن بعد لتسجيل الدخول السحابي: يقوم Entra ID بإرجاع استجابات خطأ مختلفة اعتمادًا على ما إذا كان معرف عميل OAuth المقدم صالحًا”. “يستغل المهاجمون هذا لاستنتاج أسماء مستخدمين صالحة وكلمات مرور صحيحة على نطاق واسع، والتحقق بشكل فعال من قوائم بيانات الاعتماد المسروقة دون تسجيل تسجيل دخول ناجح.”
بمعنى آخر، تستفيد الهجمات من معرف عميل OAuth، وهو معرف فريد عالمي (GUID) يتم تعيينه للتطبيقات عند طلب الوصول إلى بيانات المستخدم، ويتم تمريره كـ “client_id” في طلبات المصادقة. من خلال توفير معرفات العملاء المخادعة، فإنه يتيح تعداد الحساب دون تطبيق OAuth مسجل ويسمح للمهاجمين باستنتاج كل من كلمة المرور وصلاحية الحساب دون إنشاء حدث تسجيل دخول ناجح.
وقالت راشيل رابين، الباحثة في Proofpoint، إن “سجلات تسجيل الدخول إلى Entra هي مصدر أساسي للقياس عن بعد لتحديد أنشطة المصادقة الضارة، بما في ذلك تعداد المستخدم، ورش كلمة المرور، ومحاولات الوصول الأولية”.
تمت ملاحظة مجموعات التهديدات مثل UNK_CustomCloak وهي تنتحل سلاسل وكيل المستخدم لتنظيم حملات القوة الغاشمة التي تستهدف بيئات Microsoft Entra ID من خلال استغلال تطبيق الطرف الأول القديم الذي تم إيقافه والذي يسمى Windows Live Custom Domains لتجاوز قيود تسجيل الدخول القياسية والتحقق من كلمات مرور المستخدم عبر أكثر من 4000 مستأجر.
لكن الجهود الأخيرة تمثل تطورًا في هذه التجارة عن طريق انتحال معرفات عميل OAuth عبر طلبات HTTP POST إلى نقطة نهاية الرمز المميز لـ OAuth 2.0 من Microsoft باستخدام تدفق بيانات اعتماد كلمة مرور مالك المورد (ROPC). على وجه التحديد، يتضمن ذلك توفير معرف عميل صالحًا من الناحية النحوية ولكنه لا يتوافق مع تطبيق حقيقي.
في مثل هذه السيناريوهات، يتم تسجيل معرف التطبيق فقط في سجل تسجيل الدخول إلى Entra دون اسم التطبيق المقابل. يمكن بعد ذلك استخدام الاستجابة، التي تحتوي على رمز خطأ Azure Active Directory Security Token Service (AADSTS)، لاستنتاج ما إذا كان الحساب موجودًا وما إذا كانت كلمة المرور صحيحة بدون تطبيق مسجل.
وأوضح Proofpoint: “إذا لم يكن معرف العميل المخادع UUIDv4 مناسبًا، فلن ترفض Entra الطلب تمامًا”. “وبالتالي يمكن للمهاجمين تحليل استجابة الخطأ هذه لتحديد الحسابات وكلمات المرور الصالحة، على الرغم من استخدام معرفات العميل المشوهة.”
“عند استخدام معرف عميل مزيف، لا يتم تسجيل اسم التطبيق المقابل في سجل تسجيل الدخول. وهذا يعني أن الاكتشافات التي تبحث عن زيادات مقابل اسم تطبيق معين قد تفوت هذا النشاط تمامًا، حيث أن الحقل فارغ.”
ومن خلال تسليح المهاجمين بهذه المعلومات، يمكنهم تحديد الحسابات التي يمكن استغلالها للوصول الخفي، وفي الوقت نفسه يجعل من الصعب على المدافعين تحديد الأنشطة المشبوهة.
قالت Proofpoint إنها حددت حملتين كبيرتين اعتمدتا هذه التقنية بشكل مستقل في نهاية ديسمبر 2025، مما يشير إلى أنه يتم دمج هذا النهج بشكل متزايد في أسلوب المهاجم بدلاً من كونه حادثًا معزولًا:
- UNK_pyreq2323 (من يناير إلى مارس 2026)، والتي استخدمت أكثر من 700000 معرف عميل مزيف من البنية التحتية لـ Amazon Web Services (AWS) لاستهداف أكثر من مليون حساب عبر ما يقرب من 4000 مستأجر، مما تسبب في إغلاق ما يقرب من 28٪ من المستخدمين المستهدفين بسبب المحاولات الفاشلة.
- UNK_OutFlareAZ (بدءًا من ديسمبر 2025)، والتي استفادت من البنية التحتية لـ Cloudflare لاستهداف أكثر من 2 مليون مستخدم باستخدام 3.7 مليون معرف تطبيق عشوائي مخادع.
تمت ملاحظة كلتا الحملتين باستخدام معرفات UUID صالحة بدلاً من المعرفات المشوهة وإظهار الأنماط التي تتوافق مع قوائم الكلمات لأسماء المستخدمين المترجمة مسبقًا. ومع ذلك، في حين أن UNK_OutFlareAZ قام بتعداد المستخدمين أبجديًا، فإن UNK_pyreq2323 لم يفعل ذلك. الجانب الآخر الذي اختلفوا فيه هو كيفية انتحال معرفات العملاء.
يقال إن UNK_pyreq2323 قام بتعديل الأرقام اللاحقة لمعرف التطبيق المعروف، ثم أعاد استخدام المعرفات المخادعة عبر ما يصل إلى 12 مستخدمًا. في المقابل، قام UNK_OutFlareAZ بإنشاء معرف عميل فريد لكل طلب.
وقال بروفبوينت: “من خلال تجزئة محاولات المصادقة عبر العديد من التطبيقات الخيالية، يصبح من الصعب ربط النشاط وقد يتجنب الاكتشافات لكل تطبيق وتحديد المعدل”. “قد تحاول المؤسسات التخفيف من هجمات التعداد التقليدية من خلال تطبيق سياسات الوصول المشروط التي يتم تحديد نطاقها على التطبيقات المستهدفة بشكل شائع للتعداد. ولن تؤدي معرفات العملاء المخادعة إلى تشغيل سياسات CA التي يتم تحديد نطاقها لتطبيق معين.”
