ثغرة حرجة في VMware vCenter تتحول إلى باب خلفي للوصول عبر Reverse SSH

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

أحيانًا يكفي أن يُنشر التصحيح الأمني… ثم يبدأ السباق.

وهذا تقريبًا ما حدث مع ثغرة CVE-2026-59310 في VMware vCenter Syslog Server.

فبعد أيام قليلة فقط من إعلان Broadcom عنها وإصدار تحديث طارئ لمعالجتها، بدأت أنظمة معرضة للثغرة بالاتصال ببنية تحتية يسيطر عليها مهاجمون.

والهدف لم يكن مجرد تنفيذ أمر عابر.

المهاجمون زرعوا أداة Reverse SSH تمنحهم قناة اتصال مستمرة إلى الخادم، وقدرة على العودة إليه لاحقًا والوصول إليه عن بُعد.

وبحلول 7 أغسطس، كانت مؤشرات الحملة قد وصلت إلى 361 عنوان IP في 47 دولة.

#الخمسة أيام التي كانت كافية

في 29 يوليو، كشفت Broadcom عن الثغرة CVE-2026-59310 وصنفتها على أنها ثغرة حرجة من نوع Directory Traversal داخل خادم Syslog في vCenter.

خطورتها لا تتوقف عند الوصول إلى ملفات في مسارات غير متوقعة.

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

وهنا تصبح المسألة أكبر بكثير من ثغرة في خدمة تسجيل سجلات.

لأن vCenter ليس خادمًا هامشيًا داخل الشبكة.

إنه في كثير من البيئات مركز التحكم بالبنية الافتراضية كاملة.

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

بمعنى آخر:

بين لحظة الإعلان عن الثغرة وبدء الاستغلال المرصود، كانت نافذة الحماية قصيرة للغاية.

#لماذا vCenter هدف بهذه القيمة؟

لفهم خطورة الحملة، يجب أولًا فهم موقع VMware vCenter داخل بيئة المؤسسة.

vCenter هو منصة الإدارة المركزية التي تُستخدم للتحكم في البنية الافتراضية المبنية على VMware، بما يشمل:

• الأجهزة الافتراضية.
• خوادم ESXi.
• الإعدادات والتكوينات.
• صلاحيات الوصول.
• عمليات المراقبة والإدارة المركزية.

ولهذا السبب تحديدًا يتكرر استهدافه.

اختراق جهاز واحد عادي قد يمنح المهاجم موطئ قدم داخل الشبكة.

أما اختراق vCenter، فقد يمنحه نقطة وصول إلى منظومة كاملة من الأنظمة الحرجة.

وهذا يفتح الباب أمام سرقة البيانات، وتعطيل العمليات، والتحرك نحو أنظمة أخرى داخل البيئة.

#من عشرات الضحايا إلى المئات خلال يومين

الحملة لم تتحرك ببطء.

وفقًا لـ QUIRSO، رُصد في 4 أغسطس وحده 151 عنوان IP جديدًا لضحايا مرتبطين بالنشاط.

وفي اليوم التالي ارتفع العدد إلى 343 عنوانًا.

وبحلول 7 أغسطس، قالت الشركة إنها حددت 361 عنوان IP متضررًا موزعًا على 47 دولة.

أكثر من نصف هذه العناوين كانت موجودة في خمس دول:

ألمانيا، والولايات المتحدة، وتركيا، وإيران، وفرنسا.

الأرقام هنا لا تعني بالضرورة 361 مؤسسة مستقلة، فالعنوان الواحد لا يساوي دائمًا ضحية واحدة بالمعنى التنظيمي.

لكنها تكشف سرعة توسع حملة الاستغلال بعد وقت قصير جدًا من الإفصاح عن الثغرة.

وهذا هو الجانب الذي يجب أن يقلق مسؤولي الأنظمة أكثر من رقم الضحايا نفسه:

الثغرات الحرجة في الأنظمة المكشوفة على الشبكة لم تعد تمنحك رفاهية الانتظار طويلًا قبل التحديث.

#ما بعد الاختراق: Reverse SSH

بعد الوصول إلى أنظمة vCenter المعرضة للثغرة، لم يكتفِ المهاجم بتنفيذ أوامر ثم المغادرة.

بحسب QUIRSO، جرى نشر إطار مفتوح المصدر باسم reverse_ssh.

الفكرة هنا بسيطة وخطيرة في الوقت نفسه.

بدل أن يحاول المهاجم فتح اتصال مباشر من الإنترنت نحو النظام المخترق، يقوم النظام نفسه بإنشاء اتصال صادر نحو بنية يتحكم بها المهاجم.

وهكذا تتكون قناة Command-and-Control (C2) تسمح بالوصول عن بُعد والمحافظة على وجود المهاجم داخل البيئة.

الميزة بالنسبة للمهاجم أن الاتصالات الصادرة قد تكون أسهل في المرور من اتصالات واردة تحجبها الجدران النارية أو ضوابط الشبكة.

بعبارة أخرى:

المهاجم لا يطرق الباب من الخارج في كل مرة.

هو يجعل الخادم المخترق يتصل به من الداخل.

وهذه القناة يمكن أن تتحول إلى وسيلة للوصول المستمر، وتنفيذ أوامر إضافية، والمحافظة على الاستمرارية بعد الاختراق الأولي.

#التصحيح موجود… ولا يوجد حل بديل

Broadcom لم تقدم حلًا مؤقتًا أو إجراء تخفيف يمكن الاعتماد عليه بدل التحديث.

التوصية الأساسية واضحة:

طبّق التحديث الطارئ.

الإصدارات التي تعالج الثغرة هي:

• vCenter 9.1: الإصدار 9.1.0.0300
• vCenter 9.0: الإصدار 9.0.2.0100
• vCenter 8.0: الإصدار 8.0 U3k أو 8.0 U2f بحسب فرع الإصدار

غياب workaround فعلي يجعل إدارة المخاطر هنا مباشرة جدًا.

إذا كان النظام يعمل بإصدار متأثر، فالتحديث ليس تحسينًا اختياريًا يمكن تأجيله إلى نافذة صيانة مريحة.

إنه خط الدفاع الأساسي الذي وفره المورد لمعالجة الثغرة.

#قاعدة YARA موجودة… لكن لها ثمن

نشرت QUIRSO قاعدة YARA عامة يمكن استخدامها للكشف عن الملفات التنفيذية الخاصة بعميل reverse_ssh.

لكن هناك تفصيلًا مهمًا:

الأداة نفسها مفتوحة المصدر، وقد يكون لها استخدام مشروع في بعض البيئات.

لذلك، اكتشافها لا يعني تلقائيًا أن النظام مخترق.

القاعدة قد تطلق إنذارًا حتى في حالة استخدام شرعي للأداة.

وهنا يظهر الفرق بين Indicator وVerdict.

وجود تطابق مع قاعدة الكشف يجب أن يكون بداية للتحقيق، لا نهايته.

يجب ربط النتيجة بسياق النظام، والاتصالات الشبكية، وتاريخ تشغيل الملف، والحساب الذي نفذه، وبقية مؤشرات ما بعد الاستغلال.

#هل تقف مجموعة APT خلف الحملة؟

QUIRSO قالت إنها تعتقد أن جهة من فئة Advanced Persistent Threat – APT تقف خلف نشاط الاستغلال.

لكن الشركة لم تقدم، حتى الآن، أدلة علنية تدعم هذا الإسناد.

كما أنها امتنعت عن نشر بعض المؤشرات التفصيلية بسبب استمرار التنسيق مع جهات إنفاذ القانون.

لذلك، من المهم الفصل بين حقيقتين:

هناك حملة استغلال نشطة وثقتها الشركة.

أما هوية الجهة التي تقف خلفها، فما تزال في نطاق التقدير ولم تُدعَم علنًا بأدلة كافية في المعلومات المنشورة حتى الآن.

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

#الخلاصة

القصة هنا ليست مجرد CVE جديدة تضاف إلى قائمة طويلة من الثغرات.

القصة في السرعة.

في 29 يوليو، أُعلنت الثغرة ونُشر التصحيح.

وفي 3 أغسطس، كانت أنظمة مخترقة تتصل بالفعل ببنية المهاجم.

وبعد أيام قليلة، وصل الرصد إلى 361 عنوان IP في 47 دولة.

والهدف هذه المرة كان VMware vCenter؛ منصة قد تمثل في بعض المؤسسات المفتاح الإداري لعشرات أو مئات الأنظمة الافتراضية.

لهذا، عندما تكون الثغرة:

حرجة، لا تحتاج إلى مصادقة، تسمح بتنفيذ كود، وتصيب نظامًا مركزيًا مثل vCenter…

فالسؤال الأخطر ليس:

هل سيبدأ المهاجمون باستغلالها؟

بل:

كم بقي من الوقت قبل أن يصل الاستغلال إلى بيئتك؟