رصدت Microsoft Threat Intelligence استغلالاً لثغرة CVE-2026-73570 في مسار إشعارات SNMP ضمن Zimbra Collaboration Suite. وتسمح الثغرة بتنفيذ أوامر نظام عن بُعد دون مصادقة أو تفاعل من المستخدم، عندما تكون حزمة zimbra-snmp الاختيارية مثبتة وتكون إشعارات SNMP مفعّلة على خادم Zimbra مكشوف عبر الإنترنت.
تقول Microsoft إن الاستغلال يبدأ برسالة SMTP مصممة خصيصاً، إذ يمكن لقيمة يتحكم بها المهاجم أن تصل إلى معالجة إشعارات SNMP، ثم تُدرج في استدعاء shell مرتبط بمراقبة حالة الخدمة. ونتيجة لذلك يستطيع المهاجم تنفيذ أوامر بصلاحيات حساب خدمة zimbra.
استغلال بدأ قبل الكشف العلني
أصدرت Zimbra الإصلاح في الإصدار 10.1.20 بتاريخ 20 يوليو 2026، بينما كُشف عن الثغرة علناً في 13 أغسطس. وبين 28 يوليو و7 أغسطس، رصدت Microsoft أدوات مسح واختبار خارجية النطاق تتحقق من قابلية تنفيذ الأوامر عبر المسار نفسه، قبل الكشف العام عن الثغرة.
استخدمت الاختبارات طلبات HTTP واستعلامات DNS وICMP وأوامر مثل curl وwget وping وnslookup وid لإثبات تنفيذ الأوامر والوصول الخارجي إلى الخادم، من دون الحاجة دائماً إلى تنزيل حمولة كاملة.
من تنفيذ الأمر إلى السيطرة على الخادم
بعد الوصول الأولي، زرع المهاجمون أبواباً خلفية بصيغة JSP داخل مسارات تطبيقات Zimbra، وأنشأوا جلسات shell عكسية، ونفذوا عمليات في الخلفية. كما رصدت Microsoft استخدام cron وsystemd وmemfd_create للحفاظ على التنفيذ أو تشغيل حمولة من الذاكرة.
وفي إحدى سلاسل الهجوم، استُغلت مكونات مسموح لها باستخدام sudo ومسار مرتبط بـ PAM لرفع صلاحيات حساب zimbra إلى root. كما ثبّت المهاجمون خدمة systemd باسم zimlog.service، وهو اسم يحاكي مكوّناً مشروعاً في Zimbra، لتشغيل الحمولة عند إقلاع النظام.
لم يتوقف النشاط عند الخادم الأول. فقد استُخدمت هوية SSH الموجودة في Zimbra والبرنامج rsync لنقل ملفات وأبواب خلفية إلى عقد أخرى داخل عنقود البريد، ما وسّع نطاق الوصول وقلل الاعتماد على نقطة اختراق واحدة.
استهداف بيانات المصادقة والبريد
جمع المهاجمون قيماً من إعدادات Zimbra المحلية، شملت بيانات اعتماد خدمات LDAP وMySQL وPostfix وAmavis والنسخ المتماثل. كما استهدفوا مفاتيح مثل zimbraPreAuthKey وzimbraAuthTokenKey وzimbraTwoFactorAuthSecret.
يشير تحليل Microsoft إلى أن بعض الأدوات حاولت قراءة قواعد بيانات البريد وبيانات الأجهزة وإعدادات خارج المكتب، إضافة إلى الشهادات والمفاتيح الخاصة وملفات إعداد Postfix. وفي حادثة واحدة، جُمعت نسخ احتياطية حديثة من صناديق البريد في أرشيف، ثم استُخدم AzCopy لمحاولة نقلها إلى تخزين Azure Blob. ولا تؤكد الأدلة المتاحة اكتمال عملية النقل.
ما الذي ينبغي على المشغلين فعله؟
التوصية الأساسية هي ترقية جميع خوادم Zimbra إلى الإصدار 10.1.20 أو أحدث. وإذا تعذر التصحيح فوراً، توصي Microsoft بإزالة حزمة zimbra-snmp الاختيارية، وتعطيل إشعارات SNMP، وتقييد الوصول إلى SNMP وSMTP على مضيفين موثوقين فقط.
كما ينبغي التعامل مع تنبيهات reverse shell على خوادم البريد المواجهة للإنترنت كحوادث عالية الأولوية، وعدم الاكتفاء بالبحث عن أسماء برمجيات خبيثة معروفة؛ فقد تضمنت بعض النتائج الأشد خطورة استخدام shell تفاعلي عادي من دون عائلة برمجية خبيثة محددة. وتشمل إجراءات الاستجابة تدوير أسرار Zimbra ومفاتيح المصادقة، وفحص خدمات systemd ووحدات PAM وsudo، والبحث عن ملفات JSP غير متوقعة وآثار servlet المولدة في جميع عقد البريد.
يوضح هذا التحقيق أن الخطر العملي لا يقتصر على تنفيذ أمر منفرد. فثغرة واحدة في خادم بريد مكشوف يمكن أن تتحول إلى نقطة انطلاق لجمع الأسرار، وزرع وسائل وصول مستمرة، والانتقال داخل العنقود، ومحاولة استخراج بيانات البريد. وفي المقابل، لا تثبت مؤشرات مثل إنشاء أرشيف أو تشغيل أداة نقل سحابية وحدها نجاح سرقة البيانات؛ إذ يتطلب ذلك ربط سجلات العمليات والملفات والاتصالات لتحديد ما حدث فعلاً.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.