اختراق ConnectWise: التطبيق لا يحتاج إلى MFA

سجّل المهاجم الدخول باسم التطبيق

اجتاز مستخدموك MFA. وسجّل المهاجم الدخول باسم التطبيق. هذا هو حد الهوية في حادث ConnectWise Cloud Backup: استُخدمت بيانات اعتماد تطبيق لطلب الوصول بصلاحيات مُنحت مسبقاً داخل مستأجري العملاء. لم يكن الضابط المصمم لتحدي دخول إنسان هو البوابة على هذا المسار.

يؤكد تنبيه ConnectWise، الذي روجع في 20 أكتوبر 2026، وصولاً غير مصرح به إلى هويات تطبيقات ويصف إجراءات الاحتواء. ولا تزال طريقة كشف بيانات الاعتماد الأصلية قيد التحقيق. هذا تحليل معماري قائم على المصادر، وليس إعادة إنتاج داخل مستأجر فعلي. السؤال الدائم هو: أي وصول تحتفظ به التكاملات إذا أصبحت بيانات اعتماد مشغلها بيد مهاجم؟ [1][2]

تنشئ الموافقة هوية ذات صلاحيات مستمرة

تختلف صلاحيات التطبيق عن الصلاحيات المفوضة لمستخدم. في تدفق client-credentials، يصادق البرنامج نفسه من دون مستخدم مسجل الدخول. وللتطبيق متعدد المستأجرين service principal في كل مستأجر يستخدمه؛ وتحدد الموافقة والصلاحيات المعينة ما يستطيع فعله فيه. تغيير كلمة مرور المستخدم لا يلغي بيانات اعتماد التطبيق ولا يعيد كتابة تلك المنح. [3][4]

لذلك أبدأ مراجعة التكامل بالصلاحيات بدلاً من اسم منتج المورد. النسخ الاحتياطي والاستعادة سببان مشروعان للوصول الواسع، لكن قدرة القراءة والكتابة وتعديل الهويات تؤدي إلى عواقب مختلفة. سجّل المنح الفعلية وأدوار الدليل في مستأجرك. لا تفترض أن جميع العملاء منحوا الصلاحيات نفسها، أو أن كلمة backup تقصر التطبيق على القراءة.

Conceptual app-only path

Vendor application credential
  -> token request for customer tenant
  -> customer service principal + granted permissions
  -> access token for a resource
  -> resource operation

No user password or MFA prompt is part of this flow.

هل تشمل سياستك هذا النوع من التطبيقات؟

تستثني وثائق Microsoft الخاصة بالوصول المشروط لهويات أحمال العمل تطبيقات SaaS الخارجية ومتعددة المستأجرين من سياسات service principal هذه. شراء الترخيص المناسب لا يزيل قيد النطاق. كما تقصر وثائق Continuous Access Evaluation لأحمال العمل الدعم على service principal أحادية المستأجر والمسجلة داخله. اسم الميزة ليس دليلاً على تغطية هوية بعينها. [5][6]

المراجعة العملية تربط العناصر ببعضها: لكل تكامل، سمِّ الضابط الذي يقيّم طلب الرمز، والمورد الذي يقبله، والصلاحيات التي يمكن استعمالها. عندما لا تنطبق السياسة، سجّل الفجوة والقيود التعويضية المتاحة. تبقى MFA مهمة لوصول المستخدمين؛ وافتراض أنها تحكم بيانات اعتماد app-only يترك هوية مستقلة بلا فحص.

تعطيل التطبيق يجيب عن جزء من الاحتواء فقط

إيقاف إصدار رموز جديدة وإبطال وصول قائم عمليتان مختلفتان. توثق Microsoft مدة افتراضية لرمز الوصول بين 60 و90 دقيقة، لكنها ليست عدّاً تنازلياً عاماً للحوادث. تؤثر إعدادات الرمز وسلوك المورد وآليات الإبطال المدعومة. وتوضح ConnectWise أن الرموز الصادرة قد تبقى قابلة للاستخدام حتى انتهاء صلاحيتها أو إبطالها بطريقة أخرى. ابنِ الاستجابة على هذا الفرق بدلاً من افتراض أن التعطيل يعني خروجاً فورياً. [1][7]

هناك حالة ثالثة: وصول أُنشئ عبر هوية أخرى. تذكر Huntress إضافة بيانات اعتماد غير مصرح بها إلى تطبيقات أخرى في مستأجرين متأثرين. تعطيل تطبيق ConnectWise الأصلي لا يزيلها. لذلك تتضمن صيغة الإغلاق عندي ثلاثة بنود منفصلة: منع الإصدار الجديد، وحسم الوصول الصادر سابقاً، وإزالة الوصول اللاحق غير المصرح به. انتظار تسعين دقيقة لا يثبت البند الثالث. [2]

Containment question                 Evidence to request
New tokens still issued?             Application state + sign-in outcomes
Existing token still accepted?       Resource behavior + expiry/invalidation
New independent access established?  Credential, grant and role-change review

Elapsed time alone is not a closure record.

نجاح الدخول لا يثبت تنفيذ كل عملية ممكنة

يثبت نجاح دخول service principal أمراً أضيق من قراءة كل صناديق البريد. تصف Todyl نشاط دخول من دون تغييرات التثبيت التي بحثت عنها في المستأجرين الذين راجعتهم. وتصف Huntress تغييرات بعد الاختراق في بيئات أخرى. هذه مجموعات رصد مختلفة، وليست أساساً لتعميم أسوأ نتيجة على جميع العملاء. تحدد الصلاحية القدرة؛ وتحدد أدلة العمليات الاستخدام المرصود. [2][8]

والاختصار المعاكس خطر أيضاً. شاشة دخول المستخدمين الفارغة لا تشمل دخول service principal الذي تسجله Microsoft منفصلاً. كما أن غياب أحداث التدقيق لا يثبت أن كل قراءة محتملة كانت ستُسجَّل. اضبط العبارة بحدودها: ما البيانات المتاحة، وأي هويات وموارد تغطيها، وما العمليات التي تظهرها فعلاً؟ عدم المعرفة نتيجة مفيدة عندما يحفظ خطوة التحقيق التالية. [2][9]

اتبع التغييرات من التطبيق الأصلي إلى الهويات الأخرى

ابحث بمعرّف التطبيق، ثم اربط دخول service principal بأحداث التدقيق ضمن فترة الحادث. معرّف Cloud Backup أدناه نقطة انطلاق، وليس قائمة كاملة بالتطبيقات المتأثرة؛ استخدم قائمة المورد الحالية لتغطية العائلة كاملة. احفظ المبادر والهدف والنتيجة ومعرّفات الربط. تتبع التغييرات التي كان التطبيق فاعلها، إضافة إلى التغييرات التي استهدفته. [1]

قارن بيانات الاعتماد غير المألوفة ومنح الموافقة والأدوار بسجلات المالك المعتمدة قبل تصنيفها خبيثة. لا تحدد تواريخ صلاحية المفتاح وحدها متى أُضيف. سجّل ما أُزيل ولماذا وأي هوية أخرى أتاح استخدامها. ينتج ذلك سلسلة يمكن لمراجع آخر تتبعها، بدلاً من لقطة تُظهر تعطيل تطبيق مؤسسي واحد. [1]

Initial application ID: 506e08f9-6e9a-4da4-942b-a099a03644ae
Product label: ConnectWise Cloud Backup / formerly SkyKick

Investigation record:
  tenant + application ID + local service principal ID
  event time + initiator + target + outcome + correlation ID
  credential or permission change + approved owner record
  containment action + remaining access + evidence limits

اسأل عمّا يبقى بعد زر التعطيل

ينبغي كتابة معيار قبول التكامل الخارجي قبل الحادث: إن تسرب مفتاحه غداً، فأي إجراء لدى العميل يوقف الوصول الجديد، وماذا يحدث للرموز الصادرة، وكيف نعثر على الصلاحيات أو المفاتيح التي أُنشئت في مواضع أخرى؟ عيّن مالكين لهذه الإجابات. فالتكامل الذي لم يعد له مالك حالي يحتفظ بأي وصول لم يُسحب.

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