ZiChatBot على PyPI: حزم Python خبيثة وقيادة وتحكم عبر Zulip

الفكرة الأساسية هنا مهمة: ما كُشف ليس اختراقاً معلناً لـ PyPI أو Zulip، بل حملة توزيع حزم خبيثة استهدفت مستخدمي Python. التقارير العامة تصف حزم Python بصيغة wheel رُفعت إلى مستودع PyPI ابتداءً من يوليو 2025، وكانت تُمرّر سراً عائلة برمجيات خبيثة غير معروفة سابقاً باسم ZiChatBot على أنظمة ويندوز ولينكس.

الجزء غير المعتاد لم يكن استخدام PyPI بحد ذاته، فهجمات سلسلة التوريد عبر الحزم البرمجية باتت مألوفة نسبياً. الجديد الأبرز هو طريقة القيادة والتحكم: وفقاً للتقارير عن تحليل كاسبرسكي، لم يتصل ZiChatBot بخادم C2 تقليدي مخصص للمهاجمين، بل استخدم واجهات Zulip REST العامة كطبقة قيادة وتحكم.

ماذا وجدت كاسبرسكي؟

تقول كاسبرسكي في منشور Securelist إن باحثيها لاحظوا، ضمن عمليات الرصد اليومية للتهديدات، سلسلة من حزم wheel الخبيثة المرفوعة إلى Python Package Index، المعروف اختصاراً بـ PyPI، بدءاً من يوليو 2025. وذكرت الشركة أنها شاركت المعلومات مع مجتمع الأمن العام، وأن البرمجية الخبيثة أُزيلت من المستودع.

هذه الحزم لم تكن مجرد ملفات معطلة أو طُعم فارغ. بحسب كاسبرسكي، كانت حزم wheel تنفذ فعلاً الميزات المعلنة على صفحاتها في PyPI، لكن هدفها الحقيقي كان إيصال ملفات خبيثة بشكل خفي. ونقلت The Hacker News النتيجة نفسها: الحزم بدت وظيفية، لكنها صُممت لتسليم ZiChatBot خلسة على ويندوز ولينكس.

التقارير العامة سمّت ثلاث مكتبات PyPI مزيفة ضمن الحملة:

• uuid32-utils
• colorinal
• termncolor

أما مسألة النَّسب إلى OceanLotus فتحتاج قراءة دقيقة. منشور Securelist يقول إن العينات أُرسلت إلى Kaspersky Threat Attribution Engine، وإن الحزم قد تكون مرتبطة ببرمجية نوقشت في تقرير استخباراتي عن OceanLotus. وفي المقابل، يعرض فهرس أبحاث التهديدات لدى كاسبرسكي صياغة أكثر مباشرة، إذ يقول إن الشركة تنسب نشاط PyPI الخاص بـ ZiChatBot إلى OceanLotus APT. كما وصف ملخص عام هذا النسب بأنه بثقة متوسطة.

من حزمة wheel إلى ZiChatBot

الصورة المدعومة من المصادر العامة هي سلسلة إسقاط برمجيات خبيثة تعمل عبر أكثر من نظام تشغيل. فهرس أبحاث كاسبرسكي يقول إن حزم PyPI الخبيثة استهدفت ويندوز ولينكس، واحتوت على dropper يسلّم برمجية ZiChatBot.

ويصف أحد الملخصات العامة الخطوات التالية بأنها استخراج dropper بصيغة DLL على ويندوز أو ملف .SO على لينكس من داخل حزمة wheel، ثم إنشاء آلية بقاء عبر Windows Registry أو عبر crontab في لينكس، قبل نشر ZiChatBot.

هذا التفصيل مهم لفرق الأمن؛ لأن الخطر لا يقتصر على خوادم التطبيقات. أي محطة مطوّر، أو بيئة افتراضية، أو عامل بناء في CI، أو صورة حاوية container image ثُبّتت فيها الحزم المتأثرة قد تكون ضمن نطاق الفحص.

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

كيف استخدم ZiChatBot منصة Zulip؟

اللمسة اللافتة في ZiChatBot هي استغلال منصة تعاون مشروعة كطبقة C2. وفقاً للتقارير عن نتائج كاسبرسكي، لم يكن ZiChatBot يتواصل مع خادم قيادة وتحكم مخصص، بل استخدم سلسلة من واجهات REST API الخاصة بتطبيق الدردشة الجماعية Zulip كبنية قيادة وتحكم.

توثيق Zulip يوضح أن واجهاته تدعم عمليات يحتاجها أي تصميم C2 مبني على الرسائل، مثل إرسال الرسائل، وجلب الرسائل، ورفع الملفات، وتعديل الرسائل أو حذفها، وبناء مرشحات narrow للرسائل، والعمل مع موضوعات القنوات. كما يشرح توثيق البوتات في Zulip أن البوتات يمكنها اعتراض الرسائل التي يرسلها المستخدمون وعرضها ومعالجتها، ثم إرسال رسائل جديدة كردود.

بصياغة أبسط: يمكن تمثيل أوامر المشغّل كرسائل دردشة أو كرسائل مرتبطة بموضوع داخل قناة، بينما تسترجع البرمجية الخبيثة الرسائل المناسبة وتعيد النتائج عبر الخدمة نفسها. المصادر المتاحة هنا لا تكشف مساحة عمل Zulip المحددة، ولا بيانات اعتماد البوت، ولا تسلسل نقاط النهاية، ولا مجموعة الأوامر التي استخدمها ZiChatBot. لذلك فالوصف الأكثر دقة هو أن ZiChatBot أساء استخدام وظائف Zulip REST API المشروعة للقيادة والتحكم بدلاً من الاعتماد على بنية C2 يملكها المهاجمون مباشرة.

ما الذي لا يعنيه ذلك؟

زاوية Zulip لا تعني أن Zulip نفسه اختُرق. ما تصفه المصادر هو إساءة استخدام لوظائف REST API والرسائل الشبيهة بعمل البوتات، وليس اختراقاً لخدمة الدردشة.

وبالمثل، لا تعني الحملة أن بنية PyPI التحتية اختُرقت. تقرير كاسبرسكي يتحدث عن حزم wheel خبيثة رُفعت إلى PyPI، ثم أُزيلت البرمجية الخبيثة من المستودع لاحقاً.

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

ما الذي ينبغي على فرق الأمن فحصه؟

ابدأوا بجرد الحزم. ابحثوا في أجهزة المطورين، وعوامل البناء، والبيئات الافتراضية، وملفات قفل الاعتماديات dependency lockfiles، وصور الحاويات عن الحزم التالية: uuid32-utils وcolorinal وtermncolor.

راجعوا سجلات التثبيت من يوليو 2025 فصاعداً، وهي الفترة التي حددتها كاسبرسكي لبداية رفع حزم wheel الخبيثة. وإذا ظهرت أي من الحزم المسماة في السجلات أو الآثار البرمجية، فمن الأفضل حفظ البيئة للتحقيق بدلاً من حذف الحزمة فقط والانتقال إلى المهمة التالية.

على أنظمة ويندوز، ابحثوا عن آليات بقاء غير متوقعة داخل Registry. وعلى لينكس، افحصوا إدخالات crontab المشبوهة. هذا يتوافق مع ملخص سلسلة العدوى المنشور عن الحملة.

افحصوا كذلك سجلات الشبكة والعمليات بحثاً عن نشاط Zulip API صادر من مفسرات Python، أو عمليات تثبيت الحزم، أو عمال CI، أو الخوادم، أو حسابات الخدمة التي لا تستخدم Zulip عادة. السؤال الأمني هنا ليس: هل Zulip خدمة شرعية؟ بل: هل لهذا المضيف وهذه العملية تحديداً سبب مشروع لاستدعاء واجهات Zulip؟

وأخيراً، لا تجعلوا السلوك الوظيفي للحزمة معيار ثقة وحده. في هذه الحملة، أفادت التقارير بأن الحزم قدمت الميزات المعلنة، لكنها عملت أيضاً كـ droppers لملفات خبيثة.

الخلاصة

الحملة المرتبطة بـ OceanLotus استغلت حزم wheel خبيثة على PyPI رُفعت بدءاً من يوليو 2025، ومن بين الأسماء العامة المرتبطة بها uuid32-utils وcolorinal وtermncolor. هذه الحزم سلّمت ZiChatBot على ويندوز ولينكس، وكانت السمة التشغيلية الأبرز في ZiChatBot هي استخدام واجهات Zulip REST للقيادة والتحكم بدلاً من خادم C2 مخصص يديره المهاجمون.