هجوم VMware vCenter: زرع JSP Webshell مزيف عبر CVE-2026-59310

يستغل مهاجمون ثغرة حرجة في VMware vCenter Server لزرع باب خلفي من نوع JavaServer Pages Webshell باسم يبدو شرعياً: vmware-perf-update.jsp. الاسم يوحي بأنه تحديث لتحسين الأداء، لكنه في الحقيقة ملف خبيث يمنح المهاجم قناة مستمرة لتنفيذ الأوامر داخل منصة تدير خوادم ESXi والأجهزة الافتراضية والتخزين والصلاحيات.

ترتبط الحملة أساساً بالثغرة CVE-2026-59310، وهي ثغرة اجتياز مسار (Path Traversal) في Syslog Server داخل vCenter. توضح هذه المقالة كيف انتقل الهجوم من تنفيذ أوامر بصلاحيات root إلى إنشاء حسابات إدارية والتحكم في ESXi ونشر برمجية فدية مشتقة من Babuk، وما الذي يجب على مسؤول البنية التحتية فحصه فوراً.

الخلاصة السريعة:

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

CVE-2026-59310 CVSS 9.8 Active Exploitation JSP Webshell VMware vCenter

الخلاصة الأمنية لهجوم VMware vCenter

وفق النشرة الأمنية VMSA-2026-0006.2 من Broadcom، تسمح CVE-2026-59310 لمهاجم يملك وصولاً شبكياً إلى vCenter بتنفيذ تعليمات برمجية عشوائية. حصلت الثغرة على درجة 9.8 من 10 وفق CVSS 3.1، ولا تحتاج إلى حساب مسبق أو تفاعل من المستخدم بحسب متجه الخطورة المنشور.

العنصر	التفاصيل	الدلالة العملية
الثغرة	CVE-2026-59310	اجتياز مسار في Syslog Server يؤدي إلى تنفيذ أوامر.
درجة الخطورة	CVSS 3.1: 9.8 — Critical	لا تتطلب صلاحيات أو تفاعل مستخدم، ويكفي الوصول الشبكي إلى الخدمة المتأثرة.
حالة الاستغلال	استغلال نشط ومؤكد	أضافتها CISA إلى قائمة الثغرات المستغلة فعلياً (KEV) في 18 أغسطس 2026.
الباب الخلفي	`vmware-perf-update.jsp`	Webshell مزيف باسم يشبه مكوّنات قياس الأداء في VMware.
الحل الرسمي	تثبيت الإصدار المصحح	لا يوجد Workaround رسمي بديل عن التحديث.

رصد فريق QUIRSO أول اتصال لضحية في 3 أغسطس 2026، بعد خمسة أيام فقط من نشر التصحيح في 29 يوليو. ووفق تحقيق QUIRSO في الحملة، تتبعت الشركة 361 عنوان IP متأثراً في 47 دولة. لا يعني ذلك بالضرورة 361 مؤسسة منفصلة، لأن بعض العناوين قد تمثل بنى مشتركة أو مزودي استضافة، لكنه يوضح سرعة الانتقال من الإفصاح إلى الاستغلال الواسع.

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

اختراق محطة موظف يؤثر غالباً في جهاز واحد، أما اختراق vCenter فقد يمنح المهاجم رؤية مركزية إلى Inventory البيئة، والصلاحيات، وDatastores، وخوادم ESXi، وعشرات أو مئات الأجهزة الافتراضية. لذلك يجب تصنيف vCenter ضمن Tier 0 أو ضمن أعلى طبقة إدارية حساسة في المؤسسة.

كيف تحوّل ملف Performance Update المزيف إلى سيطرة على ESXi؟

لا يمثل vmware-perf-update.jsp تحديثاً صادراً عن VMware أو Broadcom. التمويه موجود في اسم الملف والمهام المجدولة المحيطة به فقط، بهدف جعل النشاط يبدو كأنه جزء من خدمة Perfcharts أو عمليات مراقبة الأداء المعتادة.

1. الوصول الأولي بصلاحيات root

أظهرت التحقيقات ملفات cron مشوهة داخل /etc/cron.d، منها zz-poc59310-syslog.log وzz-poc59310. لم تقابلها أحداث مصادقة طبيعية، بينما نُفذت الأوامر بصلاحيات root. يدعم ذلك فرضية استغلال Path Traversal لكتابة ملف في مكان يقرأه cron ثم تشغيل الأوامر دون تسجيل دخول تقليدي.

2. إنشاء أكثر من قناة بقاء

نزّل المهاجم أدوات وصول عن بُعد، وأنشأ خدمة نظام لإعادة تشغيل أحد الأبواب الخلفية، ثم استخدم مهاماً تحمل أسماء شبيهة بخدمات VMware:

vmware-vpxd-stats-*: لإعادة تفعيل SSH وإضافة مفتاح المهاجم إلى authorized_keys الخاص بالمستخدم root.
vmware-perf-collect-*: لزرع Webshell باسم vmware-perf-update.jsp داخل تطبيق Perfcharts.
vmware-perf-sync-*: لزرع Webshell وتنفيذ مرحلة سرقة بيانات اعتماد وإنشاء حساب إداري.

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

3. سرقة بيانات الاعتماد وإنشاء حسابات إدارية

تضمنت السلسلة ملفاً خبيثاً باسم /etc/sudoers.d/vmware-perf يمنح حساب الخدمة perfcharts صلاحية sudo إلى root دون كلمة مرور. كما رُصد السكربت المخفي .vmware-perf-upd.sh وملفات مؤقتة مرتبطة ببيانات vmdir وSSO، ثم إنشاء حسابات مثل adminuser وvcadmin وإضافتها إلى صلاحيات vSphere الإدارية.

4. الانتقال إلى خوادم ESXi وبرمجية الفدية

بعد اكتشاف Inventory البيئة، أنشأ المهاجم حسابات إدارية محلية على ESXi ونقل ملفات عبر Datastore Browser. وفي الحالة التي حققتها QUIRSO استُخدمت برمجية تشفير مشتقة من Babuk مع سكربتات لإيقاف الأجهزة الافتراضية، وتشفير بيانات VMFS، وإزالة عامل VMware High Availability. أضيف الامتداد .babyk إلى الملفات المتضررة.

يمكن ربط هذه المراحل بتكتيكات الاستمرارية وسرقة بيانات الاعتماد والحركة الجانبية والتأثير من خلال شرح MITRE ATT&CK Framework العملي.

الإصدارات المتأثرة وإصدارات vCenter المصححة

يجب الاعتماد على رقم إصدار vCenter الكامل، لا على عبارة 8.x أو 9.x فقط. يعرض الجدول التالي إصدارات الإصلاح المنشورة في أحدث تحديث للنشرة الرسمية حتى 19 أغسطس 2026.

المنتج أو الفرع	الإصدار المتأثر	الإصدار المصحح أو الإجراء
VMware vCenter / VCF / vSphere Foundation	9.1.x.x	9.1.0.0300 أو أحدث مدعوم
VMware vCenter / VCF / vSphere Foundation	9.0.x.x	9.0.2.0100 أو أحدث مدعوم
VMware vCenter	8.0 Update 3 branch	8.0 U3k أو أحدث مدعوم
VMware vCenter	8.0 Update 2 branch	8.0 U2f أو أحدث مدعوم
VMware vCenter 7.0	7.0	التواصل مع Broadcom عند وجود عقد Extended Support، مع إعداد خطة انتقال إلى إصدار مدعوم.
VMware Cloud Foundation 5.x	vCenter المضمّن	تطبيق Async Patch إلى vCenter 8.0 U3k وفق دليل Broadcom.

تحذير قبل التحديث:

في البيئة السليمة، خذ File-Based Backup مدعوماً وتأكد من نجاحه، وراجع توافق الإضافات وخطة Rollback ثم نفذ التحديث ضمن نافذة صيانة. أما عند الاشتباه باختراق فعلي، فلا تنشئ Snapshot جديدة وتتعامل معها كنسخة موثوقة، ولا تعد تشغيل الجهاز قبل قرار فريق الاستجابة، لأن ذلك قد يطمس أدلة متطايرة أو يحفظ باباً خلفياً داخل نقطة الاستعادة.

أدرجت CISA الثغرة في Known Exploited Vulnerabilities Catalog وحددت 21 أغسطس 2026 موعداً للمعالجة لدى الجهات الفيدرالية الأميركية الخاضعة للتوجيه. المؤسسات الأخرى ليست ملزمة بهذا التاريخ تلقائياً، لكن الإدراج يؤكد أن الأولوية يجب أن تكون طارئة لا دورية.

كيف تتحقق من تعرض vCenter للاختراق؟

ابدأ بتحديد نطاق التعرض: ما الإصدار الذي كان يعمل وقت بدء الحملة؟ هل كان Syslog أو واجهة vCenter قابلاً للوصول من الإنترنت أو من شبكة واسعة؟ وهل توجد أجهزة مخترقة أخرى تستطيع الوصول إلى Management VLAN؟ الوصول الشبكي لا يعني الإنترنت فقط؛ جهاز داخلي مخترق قد يصل إلى الثغرة إذا لم تكن شبكة الإدارة معزولة.

ملاحظة تشغيلية:

نفّذ أوامر الفحص التالية من جلسة إدارية معتمدة على vCenter Server Appliance، وهي أوامر قراءة وبحث فقط. لا تفعّل SSH خصيصاً من الإنترنت، ولا تحذف أي ملف يظهر في النتائج قبل حفظ نسخة منه وتوثيق التوقيت والمالك والـ hash.

فحص الملفات والمهام والخدمات

find /etc/cron.d -maxdepth 1 -type f \
  \( -name 'zz-poc59310*' \
  -o -name 'vmware-vpxd-stats-*' \
  -o -name 'vmware-perf-collect-*' \
  -o -name 'vmware-perf-sync-*' \) -ls

find / -xdev -type f -name 'vmware-perf-update.jsp' -ls 2>/dev/null

test -f /etc/sudoers.d/vmware-perf && \
  stat /etc/sudoers.d/vmware-perf

grep -nH 'perfcharts' /etc/sudoers.d/* 2>/dev/null

systemctl status sys-9436d8.service network-manager.service \
  --no-pager 2>/dev/null

راجع كذلك /tmp/.x/، والملف .vmware-perf-upd.sh، وأي نسخ غير متوقعة بأسماء linuxFile أو systemlog أو linux_x86. بعض الأسماء عامة وقد تظهر لأسباب أخرى؛ وجود اسم واحد ليس حكماً نهائياً، بل نقطة تبدأ منها مقارنة التوقيت والمالك ومحتوى الملف والاتصالات المرتبطة به.

فحص مفاتيح SSH والاتصالات الصادرة

ssh-keygen -lf /root/.ssh/authorized_keys 2>/dev/null

ss -plant

journalctl -u crond --since "2026-07-29" --no-pager | \
  grep -E 'zz-poc59310|vmware-(vpxd-stats|perf-collect|perf-sync)'

قارن بصمات مفاتيح SSH مع قائمة مفاتيح الإدارة المعتمدة، وابحث في Firewall وProxy وNDR عن اتصالات WebSocket أو SSH عكسية غير معتادة من vCenter إلى الإنترنت. لا تفترض أن الاتصال الصادر مشروع لأنه بدأ من Appliance موثوقة.

فحص vSphere SSO وESXi

راجع Users and Groups داخل vSphere SSO وابحث عن adminuser وvcadmin وأي حساب إداري أُنشئ خارج Change Record.
تعامل مع vcenter_admin كمؤشر يستحق التحقيق، مع ملاحظة أن الباحثين ربطوه بمسار نشاط محتمل ومنفصل للثغرة CVE-2026-59309.
راجع عضوية مجموعة SSO Administrators، وأحداث إنشاء الحسابات وتعديل الصلاحيات.
افحص الحسابات المحلية ومفاتيح SSH والخدمات الجديدة على كل ESXi Host يديره vCenter.
ابحث في Datastores عن ملفات غير معروفة باسم backup وrun.sh و_post_launch.sh، وعن ملفات تحمل الامتداد .babyk.
راجع أحداث إيقاف VMs وإزالة عوامل HA وعمليات نسخ الملفات عبر Datastore Browser.

قاعدة القرار:

عدم العثور على اسم الملف وحده لا يثبت سلامة البيئة؛ يستطيع المهاجم تغيير الأسماء أو إزالة الآثار. اجمع النتيجة مع Timeline السجلات، والحسابات الجديدة، والاتصالات الصادرة، وتغييرات sudoers وSSH، ونشاط ESXi وDatastores.

خطة المعالجة: متى يكفي التحديث ومتى تبدأ Incident Response؟

الحالة	التفسير	الإجراء الصحيح
إصدار متأثر، ولا توجد دلائل اختراق، ولم يكن قابلاً للوصول إلا من شبكة إدارة مقيدة	الخطر قائم لكن التعرض أقل	حدّث فوراً، ثم نفذ Threat Hunt وValidation ولا تعتمد على التحديث وحده.
إصدار متأثر وكان مكشوفاً للإنترنت أو لشبكات واسعة	احتمال الاستغلال أعلى	عامل الجهاز كحادثة محتملة، واحفظ السجلات وافحص كل مؤشرات البقاء قبل إعلان السلامة.
ظهور Webshell أو cron خبيث أو Reverse SSH أو حساب إداري غير مصرح	اختراق مؤكد أو عالي الثقة	اعزل البيئة إدارياً، وابدأ Incident Response، وافترض تعرض vCenter وخوادم ESXi وبيانات الاعتماد.
تم تثبيت التصحيح بعد تاريخ تعرض محتمل	الثغرة مغلقة لكن البقاء قد يكون موجوداً	لا تعتبر الجهاز سليماً حتى يكتمل التحقيق وإعادة بناء الثقة.

Workflow الاستجابة عند وجود مؤشر اختراق

احتواء الوصول: امنع الاتصال المباشر بالإنترنت، وقيّد Management VLAN، وحافظ على قناة تحقيق معتمدة بدلاً من تنفيذ إطفاء عشوائي.
حفظ الأدلة: اجمع سجلات vCenter وESXi وFirewall وProxy وEDR، وسجل العمليات والاتصالات والحسابات والملفات مع timestamps وhashes.
توسيع النطاق: افحص كل ESXi Host وDatastore وBackup Server يمكن الوصول إليه من vCenter، وليس Appliance وحدها.
إبطال البقاء: لا تحذف Webshell يدوياً وتعلن انتهاء الحادث. حدد كل cron jobs والخدمات والمفاتيح والحسابات وقنوات Reverse SSH.
تدوير بيانات الاعتماد: غيّر كلمات مرور SSO وroot وحسابات الإدارة والخدمة من جهاز نظيف، وبعد الاحتواء، حتى لا يلتقطها المهاجم مجدداً.
استعادة الثقة: في الاختراق المؤكد، قيّم إعادة نشر vCenter من وسائط سليمة واستعادة إعدادات موثوقة بدلاً من الاعتماد على تنظيف Appliance سبق أن نُفذت عليها أوامر root.
الاسترداد والتحقق: اختبر سلامة VMs والـ Datastores والنسخ الاحتياطية قبل إعادة فتح الإدارة، ثم راقب الاتصالات الصادرة وتغييرات الحسابات بعد العودة.

تنشر Shadowserver تقريراً خاصاً بضحايا CVE-2026-59310، وتوصي باعتبار الأنظمة التي ظهر عليها reverse_ssh مخترقة بالكامل. يمكن لمالكي الشبكات الاشتراك في تقاريرها للتحقق مما إذا ظهرت عناوينهم ضمن البيانات المتاحة.

توصيات عملية لحماية بيئة VMware بعد الحادثة

لا تنشر vCenter على الإنترنت: اجعل الوصول عبر Jump Host أو VPN إداري مع MFA وقائمة مصادر محددة.
افصل Management Plane: ضع vCenter وESXi وواجهات التخزين والنسخ الاحتياطي في شبكات إدارة منفصلة، واسمح فقط بالتدفقات المطلوبة.
راقب الاتصالات الصادرة: استخدم Allowlist أو Proxy Policy لأن Reverse SSH يعتمد على خروج الاتصال من النظام المخترق.
راقب التغييرات الحساسة: أنشئ تنبيهات لإنشاء SSO Administrator، وتعديل sudoers، وإضافة SSH keys، وإنشاء cron jobs أو services، ورفع ملفات إلى Datastores.
استخدم حسابات إدارية منفصلة: لا تستخدم حساب الإدارة اليومي للبريد والتصفح، ولا تحفظ بيانات اعتماد Tier 0 على أجهزة المستخدمين.
احمِ النسخ الاحتياطية: استخدم Repository منفصلاً، وحسابات مستقلة، ونسخة Immutable أو Offline، واختبر Restore دورياً. تذكر أن RAID ليس بديلاً عن النسخ الاحتياطي.
قلّص زمن التصحيح: ضع vCenter وESXi ضمن مسار Emergency Patching لأن هذه الحملة بدأت خلال خمسة أيام فقط من الإفصاح.
احتفظ بخط أساس: وثق الخدمات والمهام والحسابات ومفاتيح SSH والاتصالات الطبيعية حتى تستطيع تمييز الملفات التي تتنكر بأسماء VMware.

Checklist إثبات المعالجة:

لا تغلق تذكرة التغيير لمجرد نجاح التحديث. أرفق رقم الإصدار قبل التحديث وبعده، ونتيجة فحص IoCs، وقائمة حسابات SSO Administrators، ومراجعة مفاتيح SSH، ونتيجة فحص ESXi وDatastores، واختبار Backup/Restore، ومدة مراقبة لاحقة دون اتصالات أو تغييرات مشبوهة.

الأسئلة الشائعة

هل vmware-perf-update.jsp تحديث أداء رسمي من VMware؟

لا. هو اسم استخدمه المهاجم لتمويه JSP Webshell داخل تطبيق Perfcharts. لا تثق بالملف بسبب احتوائه كلمات VMware أو Performance أو Update؛ تحقق من مصدره وتوقيته ومالكه ومحتواه.

هل تثبيت تحديث vCenter يحذف Webshell؟

لا ينبغي افتراض ذلك. التصحيح يعالج مسار الاستغلال، لكنه لا يضمن إزالة Webshell أو مفاتيح SSH أو الخدمات والمهام والحسابات التي أُنشئت قبل التحديث. عند وجود تعرض سابق يجب تنفيذ Threat Hunt أو Incident Response.

هل يجب أن يكون vCenter مكشوفاً للإنترنت حتى يُستغل؟

لا. الشرط هو وصول المهاجم شبكياً إلى vCenter. قد يأتي الوصول من الإنترنت، أو من VPN مخترق، أو جهاز داخلي، أو خادم داخل شبكة تستطيع الوصول إلى Management VLAN.

هل تؤثر CVE-2026-59310 في ESXi مباشرة؟

الثغرة الموصوفة موجودة في Syslog Server داخل vCenter، لكن السيطرة على vCenter قد تستخدم للانتقال إلى ESXi عبر الصلاحيات المركزية والـ Datastores. لذلك لا يقتصر نطاق التحقيق على Appliance.

هل نُسب الهجوم رسمياً إلى مجموعة صينية محددة؟

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

الخاتمة

خطورة حملة VMware vCenter لا تأتي من Webshell واحد فقط، بل من موقع vCenter داخل البنية التحتية. بدأ الهجوم من CVE-2026-59310، ثم أضاف المهاجم قنوات بقاء متعددة وحسابات إدارية ووصولاً إلى ESXi، ووصل في إحدى الحالات إلى تشفير Datastores.

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