CVE-2026-59310: حملة VMware vCenter استغلت الثغرة بعد 5 أيام فقط من ترقيعها

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

الجدول الزمني: التصحيح أولاً والاستغلال بعد خمسة أيام

أعلنت Broadcom عن CVE-2026-59310 وأصدرت الترقيعات في 29 يوليو/تموز. وأفادت QUIRSO برصد مؤشرات على استغلال فعلي بدأ في 3 أغسطس/آب، قبل أن تتسع الحملة بسرعة خلال الأيام التالية.

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

حجم الحملة والدول الأكثر ظهوراً

ربط الباحثون النشاط بـ361 عنوان IP متأثراً جرى رصده في 47 دولة. وذكرت التقارير أن ألمانيا والولايات المتحدة وتركيا وإيران وفرنسا شكّلت مجتمعة أكثر من نصف المجموعة المرصودة.

لكن ينبغي قراءة الرقم بحذر: فعنوان IP واحد لا يساوي بالضرورة مؤسسة واحدة، ولذلك لا يثبت الرقم وجود 361 شركة أو جهة مختلفة. مع ذلك، تشير التقارير المتاحة إلى حملة واسعة استهدفت أنظمة vCenter المتاحة عبر الإنترنت أو المكشوفة على شبكات يمكن الوصول إليها.

لماذا يرجّح الباحثون وجود صلة صينية؟

قيّمت QUIRSO وجود صلة صينية في الحملة بدرجة ثقة متوسطة. واستند التقييم، وفق ما أُعلن، إلى آثار وأدوات باللغة الصينية، وإعادة استخدام أبحاث منشورة علناً، ونشاط يتوافق مع ساعات العمل بتوقيت UTC+08:00، إضافة إلى نمط ضحايا بدا أنه يستثني البر الرئيسي الصيني.

تدعم هذه المؤشرات تقييماً إقليمياً أو لغوياً، لكنها لا تحدد مجموعة صينية بعينها ولا تثبت توجيهاً حكومياً للعملية. كما أن الإسناد المبني على آثار البرمجيات وأنماط التوقيت والاستهداف قد يتغير مع ظهور أدلة إضافية. لذلك فإن الوصف الأكثر دقة هو «جهة يُشتبه في ارتباطها بالصين»، وليس عملية مؤكدة ترعاها دولة.

سلسلة الاختراق المبلّغ عنها

يبدو أن المهاجمين استخدموا CVE-2026-59310 للوصول الأولي، ثم زرعوا عدة طبقات من الاستمرارية والوصول:

1. اجتياز المسارات: أُرسلت طلبات معدة إلى خدمة Syslog للخروج من المسار المسموح به وكتابة محتوى يتحكم فيه المهاجم.
2. الاستمرارية عبر cron: أفادت التقارير بأن المهاجمين أنشأوا إدخالات cron غير سليمة لتشغيل أوامر لاحقة بصورة مجدولة.
3. توصيل الباب الخلفي: استخدمت أدوات مثل curl أو wget لتنزيل باب خلفي باسم linuxFile يعتمد على WebSocket والتعمية بأسلوب XOR، وفق التقارير الخاصة بالاختراقات المرصودة.
4. Reverse SSH: ثبّت المهاجمون أدوات Reverse SSH لإنشاء اتصال صادر إلى بنية تحتية يتحكمون فيها. وذكرت Shadowserver أن هذه الآلية ظهرت لدى جميع الضحايا الواردين في تقريرها الخاص.
5. إساءة استخدام الحسابات وبيانات الاعتماد: أبلغ المحققون عن حسابات إدارية غير مصرح بها في vCenter وESXi، إلى جانب إساءة استخدام بيانات اعتماد VMware Directory Service.
6. نشر برمجية فدية: ربطت بعض التقارير النشاط بنسخة مشتقة من Babuk تضيف الامتداد .babyk.

وتبرز أهمية Reverse SSH تحديداً في أن Shadowserver خلصت إلى ضرورة التعامل مع الأنظمة التي ظهرت عليها هذه الآلية باعتبارها مخترقة بالكامل. لذلك فإن حذف ملف ثنائي أو إزالة مهمة cron، من دون إعادة بناء الثقة في الجهاز وتغيير بيانات اعتماد الحسابات المميزة، لا يمثل استراتيجية تعافٍ كافية.

هل استُخدمت برمجية الفدية لإخفاء الأدلة؟

لا تشير أنشطة الامتداد .babyk بالضرورة إلى حملة فدية تقليدية هدفها الرئيسي تشفير أكبر عدد ممكن من الملفات ثم ابتزاز الضحايا. فقد اقترح محللون أن تشفير سجلات ESXi بصورة انتقائية ربما كان يهدف إلى عرقلة التحقيق وإخفاء آثار الاختراق.

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

مستودع GitHub متنكر وأدوات معاد استخدامها

ربطت تقارير أخرى العملية بمستودع على GitHub قدّم ملفات Reverse SSH الثنائية على أنها أداة لتنظيف الملفات المؤقتة في Linux. ويمكن لهذا النوع من التنكر أن يسهل توزيع أداة الاستمرارية ويجعلها أقل لفتاً للانتباه أثناء المراجعات الإدارية المعتادة. لكن الأدلة المتاحة لا تثبت بصورة مستقلة هوية مشغّل المستودع، ولذلك لا ينبغي اعتبار وجوده دليلاً على الإسناد.

أثر الحملة على Broadcom والسوق

تراجعت أسهم Broadcom بنحو 5% إلى 6% في 14 أغسطس/آب، بالتزامن مع وصول تقارير الاستغلال النشط لبرنامج VMware إلى المستثمرين. وذكرت إحدى الروايات انتقال السهم من 417.82 دولاراً إلى 392.99 دولاراً خلال الجلسة.

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

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

ماذا يجب أن يفعل مسؤولو vCenter؟

التحديث خطوة أولى، وليس نهاية الاستجابة. ينبغي للمؤسسات:

1. تثبيت إصدارات Broadcom المصححة فوراً على كل نسخة متأثرة من vCenter، مع إعطاء الأولوية للأنظمة المتاحة عبر الإنترنت أو التي يمكن الوصول إليها من نطاقات داخلية واسعة. ولا تذكر Broadcom أي حل بديل.
2. افتراض حدوث اختراق عند ظهور مؤشرات مريبة، مثل تغييرات غير متوقعة في cron، أو آثار Reverse SSH، أو الملف linuxFile، أو تنزيلات غير مبررة عبر curl وwget، أو حسابات إدارية غير مألوفة في vCenter وESXi، أو نشاط غير طبيعي في VMware Directory Service.
3. عزل الأجهزة المشبوهة والحفاظ على صور الأقراص والسجلات والأدلة المتطايرة قبل إعادة البناء، متى كان ذلك ممكناً تشغيلياً.
4. تغيير بيانات اعتماد الحسابات المميزة، بما يشمل vCenter SSO وVMware Directory Service وحسابات ESXi أو root وحسابات واجهات البرمجة وحسابات الخدمات والحسابات الإدارية المرتبطة. كما ينبغي إبطال الجلسات النشطة ومراجعة مسارات الاتحاد والربط.
5. إعادة بناء الأنظمة بدلاً من الاكتفاء بالتنظيف عند تأكد وجود الاستمرارية. ويجب أن تتم إزالة الحسابات ومهام cron والملفات الثنائية ومفاتيح SSH والأنفاق غير المصرح بها ضمن عملية موثقة للاستجابة للحوادث.
6. البحث عبر البنية الافتراضية بأكملها عن نشاط .babyk، واتصالات SSH أو WebSocket الصادرة غير المتوقعة، والحسابات المريبة، وأدلة العبث بسجلات ESXi.
7. استعادة السجلات والبيانات الموثوقة من نسخ احتياطية سليمة وغير قابلة للتغيير عندما تكون السجلات أو الإعدادات قد عُدّلت.
8. تقليل التعرض مستقبلاً عبر حصر الوصول الإداري إلى vCenter في شبكات إدارة مجزأة، ومراقبة الاتصالات الصادرة من vCenter وESXi.

الخلاصة التشغيلية واضحة: حدّثوا كل نظام vCenter معرض للخطر، لكن لا تساووا بين نجاح التحديث وسلامة البيئة. فالاستغلال السريع، والوصول المستمر عبر Reverse SSH، وإساءة استخدام بيانات الاعتماد تعني أن الأجهزة المكشوفة يجب أن تخضع للتحقيق باعتبارها اختراقات محتملة كاملة.