حذر باحثون في مجال الأمن السيبراني من “هجوم آلي ضخم ومستمر لرش كلمات المرور” يستهدف واجهة سطر أوامر Azure من Microsoft (CLI)، مما يعرض العشرات من الحسابات للخطر في هذه العملية.
ينشأ النشاط، بحسب Huntress، من نطاق عناوين IPv6 (2a0a:d683::/32) الذي يتحكم فيه موفر البنية التحتية للإنترنت LSHIY LLC (AS32167).
وقالت الشركة في بيان: “بين 12 و26 يونيو، قام ممثل التهديد الذي يقف وراءه بأكثر من 81 مليون محاولة تسجيل دخول ونجح في اختراق ما لا يقل عن 78 حسابًا لشركة Microsoft عبر 64 مؤسسة”. “يبدو أن استهداف هذه الهجمات يعتمد كليًا على انتشار كلمات المرور في قوائم التحرير والسرد لكلمات المرور المخترقة، ولا يقتصر على نوع العمل أو الصناعة.”
ما يجعل هجوم رش كلمة المرور جديرًا بالملاحظة ليس فقط حجمه، ولكن أيضًا حقيقة أن العديد من المؤسسات المخترقة لديها سياسات الوصول المشروط ممكّنة. على وجه التحديد، تبين أن الحملة تستفيد من تدفق OAuth المهمل المسمى بيانات اعتماد كلمة مرور مالك المورد (ROPC) لتجاوز إجراءات حماية سياسة الوصول المشروط (CAP).
ROPC هو نوع منح OAuth 2.0 قديم حيث يقدم المستخدم اسم المستخدم وكلمة المرور الخاصة به مباشرة إلى تطبيق العميل، والذي يرسل بعد ذلك بيانات الاعتماد هذه إلى خادم ترخيص لاستبدالها برمز وصول. تم إهماله في OAuth 2.1.
في وثائقها، توصي Microsoft العملاء بعدم استخدام ROPC، بحجة أنه غير متوافق مع المصادقة متعددة العوامل (MFA).
يقول عملاق التكنولوجيا: “في معظم السيناريوهات، تتوفر بدائل أكثر أمانًا ويوصى بها”. “يتطلب هذا التدفق درجة عالية جدًا من الثقة في التطبيق، وينطوي على مخاطر غير موجودة في التدفقات الأخرى. يجب عليك استخدام هذا التدفق فقط عندما لا تكون التدفقات الأكثر أمانًا قابلة للتطبيق.”
ويقال إن هجمات رش بيانات الاعتماد والرمز المميز أدت إلى عدد قليل من عمليات تسجيل الدخول الناجحة يوميًا بين 12 و21 يونيو 2026، بمتوسط حسابين إلى أربعة حسابات يتم اختراقها يوميًا، باستثناء 19 يونيو، عندما تم اختراق 12 حساب مستخدم (المعروف أيضًا باسم الهويات). تغير الإيقاع الثابت في 22 يونيو، حيث تأثرت 30 هوية عبر 23 شركة.
وبشكل إجمالي، تم اختراق 78 حساب مستخدم عبر 64 مؤسسة كجزء من الحملة. الغالبية العظمى من نشاط رش كلمة المرور صادرة عن شركة LSHIY LLC. بعض عناوين IP تتجه إلى الولايات المتحدة، في حين أن البعض الآخر يتجه إلى الصين.
وقالت Huntress: “تعد هذه الهجمات جزءًا من موجة كبيرة من هجمات رش بيانات الاعتماد عبر عدد قليل من شبكات ASN المختلفة”، مضيفة أنها شهدت زيادة في حجم هجمات رش بيانات الاعتماد بأكثر من 155 مرة عبر قاعدة عملائها. “لقد ارتفعت الهجمات بشكل خاص في أواخر مايو وحتى أوائل يونيو، حيث يبلغ متوسط القيمة الحالية حوالي 1,964 هجومًا فاشلاً شهريًا لكل مستأجر محمي بواسطة Huntress.”
يبدو أن هذا النشاط يستخدم بشكل خاص مجموعات اسم المستخدم/كلمة المرور القديمة كسلاح والتي تم اختراقها سابقًا ولكن لم يتم تغييرها مطلقًا. يعني استخدام متجه ROPC أن المهاجمين كانوا قادرين على استهداف المؤسسات التي طبقت MFA، ولكن لم يتم فرضه أو تكوينه لحساب عمليات تسجيل دخول Azure CLI ROPC.
وشمل ذلك السيناريوهات التي لم يتم فيها تشغيل أسلوب MFA –
- فرض MFA لتطبيقات محددة فقط، بدلاً من “جميع التطبيقات السحابية”، وبالتالي الفشل في تغطية عمليات تسجيل الدخول إلى Azure CLI التي يستخدمها ممثلو التهديد
- فرض MFA فقط على مجموعات مستخدمين محددة، مثل المسؤولين
- تطبيق MFA فقط عندما تنشأ الطلبات من مواقع غير موثوقة
وقالت هنتريس: “من الجدير بالذكر أن ثماني شركات تأثرت بالحملة لم يكن لديها سياسة التمويل الأصغر على الإطلاق”. “بينما تمكنت الجهات الفاعلة في مجال التهديد في هذه الحملة من الدخول على الرغم من إعداد MFA، لا ينبغي أن تكون النتيجة أن MFA لا يعمل على الإطلاق؛ بدلاً من ذلك، يجب على المؤسسات التأكد من تكوين سياسات MFA الخاصة بها بشكل صحيح لمعالجة تدفق التفويض المستخدم عبر هذه الحوادث.”
لمواجهة خط الهجوم هذا، ننصح المؤسسات بطلب MFA لجميع المستخدمين، وجميع التطبيقات السحابية، وجميع أنواع تطبيقات العميل عند تمكين CAP، وتقييد تطبيق Azure CLI للمستخدمين غير الإداريين، وإعطاء الأولوية للاستجابة من خلال صلاحية بيانات الاعتماد.
وخلص باحثو Huntress إلى أن “هذا الهجوم يكشف عن شقوق في CAPs لم يتم تكوينها بشكل مناسب”. “لا تزال هناك نقاط ضعف محتملة في كيفية نشر CAPs والتي يمكن أن تسمح للجهات الفاعلة في مجال التهديد بالتسلل. أحد الأخطاء الصارخة هنا هو أن البروتوكولات القديمة مثل ROPC يمكنها تجاوز بعض CAPs سيئة التكوين تمامًا نظرًا لأنها لا تمر عبر نقطة نهاية التفويض حيث يتم فرض السياسات.”
