Miasma يضرب npm وGo: هجوم سلسلة توريد يسرق أسرار المطورين

مقدمة تحليلية

كشفت أبحاث الأمن السيبراني عن تطور مقلق في حملة برمجية Miasma الخبيثة، وهي جزء من عائلة Mini Shai-Hulud وHades الأوسع، تستهدف الآن مجموعة جديدة من حزم npm وتنتشر لتشمل منظومة Go. هذا الهجوم لا يقتصر على استهداف مكتبات برمجية، بل يمتد ليشمل استغلال مساحات عمل GitHub Actions، مما يوسع نطاق التهديد بشكل كبير. الهدف الأساسي للحملة هو سرقة بيانات اعتماد المطورين والقائمين على الصيانة، ثم استغلال هذه البيانات المسروقة للتسلل عبر سجلات الحزم ومستودعات التعليمات البرمجية وسلاسل عمل المطورين الموثوقة، ما يشكل ضربة قوية لأمن سلسلة توريد البرمجيات.

تضمنت الأنشطة الأخيرة إصدارات npm خبيثة تؤثر على حزم LeoPlatform وRStreams، بالإضافة إلى إساءة استخدام سير عمل GitHub Actions، واختراق وحدة Go ذات الصلة بمشروع Verana Blockchain. هذا التوسع يشير إلى استراتيجية أكثر عدوانية ومرونة من قبل المهاجمين، حيث يسعون لاستهداف نقاط ضعف مختلفة في دورة حياة تطوير البرمجيات. إن القدرة على الانتقال بين بيئات برمجية مختلفة مثل npm وGo، واستغلال منصات CI/CD كـ GitHub Actions، يؤكد على مدى التعقيد والتطور في هذا النوع من الهجمات.

تُعد سرقة بيانات الاعتماد والرموز المميزة (tokens) هي مفتاح انتشار هذا النوع من الهجمات، حيث تُمكّن المهاجمين من انتحال هوية المطورين الشرعيين ودفع إصدارات خبيثة للحزم، أو التلاعب بسير عمل البناء والنشر. هذه العملية تتم غالبًا بسرعة فائقة لتجنب الكشف، كما حدث في دفع إصدارات مُعدّلة خلال نافذة لا تتجاوز ست ثوانٍ.

التحليل التقني

تستغل الموجة الجديدة من هجمات Miasma العديد من التكتيكات التي لوحظت في الحملات السابقة، وتضيف عليها بعض التعديلات لتجنب الكشف وتوسيع نطاق التأثير. من أبرز هذه التكتيكات:

• تسميم سجل npm (npm registry poisoning): تم دفع إصدارات مُعدّلة من حزم npm شهيرة. يُشتبه في أن حساب مطور npm مرتبط بـ LeoPlatform (المُعرّف باسم "czirker") قد تم اختراقه، ربما عبر تسريب بيانات الاعتماد، مما سمح للمهاجمين باستغلال رمز npm المميز (token) لدفع نسخ مُعدّلة خبيثة.
• تنفيذ التعليمات البرمجية وقت التثبيت (binding.gyp install-time execution): على الرغم من أن الحزم الخبيثة قد تفتقر إلى خطاف دورة حياة (lifecycle hook) نموذجي في ملف package.json، إلا أنها تدمج ملف binding.gyp لتنفيذ تعليمات برمجية عشوائية أثناء التثبيت. يؤدي هذا إلى تشغيل مُحمّل JavaScript الذي يقوم بتنزيل وتثبيت بيئة Bun runtime إذا لم تكن موجودة، ثم يبدأ في تنفيذ حمولة السارق (stealer payload).
• سرقة أسرار GitHub Actions: تقوم البرمجية الخبيثة، بالإضافة إلى وجود killswitch للغة الروسية والتحقق من وجود برامج أمن نقطة النهاية، بإسقاط سير عمل (workflow) باسم "Run Copilot". يهدف هذا السير العمل إلى التقاط أسرار بيئة CI/CD من ذاكرة المُشغّل (runner memory)، ثم يتم تحميل هذه المعلومات إلى مستودع GitHub عام بوصف "Alright Lets See If This Works". اعتبارًا من تاريخ الكتابة، يوجد 559 مستودعًا يطابق هذا الوصف.
• تغيير علامات نقل الرمز المميز (token relay markers): شهدت العلامات المستخدمة لنقل الرموز المميزة تغييرًا في التكرار الأخير. بينما كانت الموجات السابقة تستخدم سلاسل مثل "IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner"، تستخدم النسخة الحالية "RevokeAndItGoesKaboom". هذه السلسلة تم استخدامها كمحلل dead drop لـ GitHub في سياق اختراق GitHub Action "codfish/semantic-release-action".
• اختراق GitHub Action `codfish/semantic-release-action`: في 24 يونيو 2026، قام مهاجم بدفع (force-pushed) commit خبيث إلى هذا الـ Action، وأعاد توجيه العديد من علامات الإصدار (version tags) للإشارة إلى هذا الـ commit الخبيث. أي سير عمل تم تشغيله باستخدام إحدى هذه العلامات بعد هذا التاريخ، نفذ حمولة المهاجم مباشرة داخل مُشغّل GitHub Actions. تقوم الحمولة بسرقة رموز OIDC المميزة لـ GitHub، وتجمع Personal Access Tokens (PATs) التي تطابق أنماط رموز GitHub المعروفة، وتقوم بتشفير المواد التي تم جمعها باستخدام AES-128-GCM، وتحاول نشر باب خلفي (backdoor) في مستودعات أخرى يمكن الوصول إليها باستخدام بيانات الاعتماد المسروقة.
• استهداف منظومة Go: توسعت الحملة لتشمل مشروع Verana Blockchain في منظومة Go. وعلى عكس حزم npm، لا يعتمد هذا الاختراق على binding.gyp، بل يستهدف تنفيذ التعليمات البرمجية من المستودع المصدر. يمكن للمطور الذي يقوم باستنساخ أو فتح المستودع في بيئة IDE موثوقة أو مساعد ترميز الذكاء الاصطناعي، أن يقوم بتشغيل الحمولة من خلال إعدادات المشروع.

بعض الحزم المتأثرة المعروفة تشمل `[email protected]`، `[email protected]`، `[email protected]`، `[email protected]`، بالإضافة إلى `github.com/verana-labs/[email protected]` في Go. كما يتم رصد GitHub كل ساعة بحثًا عن commits تطابق السلسلة "firedalazer" لاستعادة وتنفيذ متغير Hades من البرمجية الخبيثة.

السياق وتأثير السوق

تُعد حملة Miasma امتدادًا لسلسلة هجمات أوسع نطاقًا مرتبطة بعائلة Mini Shai-Hulud وHades، مما يشير إلى وجود مجموعة تشغيلية واحدة أو مجموعة أدوات متسقة خلف هذه الهجمات المتكررة. لقد أظهرت هذه المجموعة قدرة ملحوظة على التكيف والتطور، حيث تغير مؤشرات بسيطة لتجعل آليات الكشف القديمة أقل فعالية. هذا التطور المستمر يؤكد على التحدي الذي يواجهه مجتمع الأمن السيبراني في مواكبة التهديدات المتغيرة بسرعة في سلاسل توريد البرمجيات.

تكمن أهمية هذا الهجوم في استهدافه للخدمات السحابية وأعباء العمل بدون خادم (serverless workloads)، حيث ترتبط حزم Leo/RStreams بهذا النوع من البيئات. هذا يعني أن أي اختراق هنا يمكن أن يعرض محطات عمل المطورين، وأنظمة التكامل والنشر المستمر (CI/CD)، والتطبيقات المدعومة بـ AWS، ومستودعات GitHub، وبيانات اعتماد نشر الحزم، والمستهلكين النهائيين للحزم في سلسلة التوريد للخطر الشديد. إن التأثير يتجاوز مجرد اختراق حزمة فردية ليشمل منظومة بيئية كاملة من التطوير والتشغيل.

الموجة الجديدة تبرز أيضًا توجهًا مقلقًا نحو استهداف تدفقات عمل المطورين مباشرةً، وليس فقط عبر خطافات التثبيت التقليدية لمديري الحزم. على سبيل المثال، في حالة اختراق Go، لا تعتمد الحمولة الخبيثة على منطق تحليل الوحدة أو البناء الأصلي لـ Go، بل يمكن تشغيلها عندما يقوم مطور باستنساخ المستودع أو فتحه في بيئة تطوير متكاملة (IDE) موثوقة أو مساعد ترميز يعتمد على الذكاء الاصطناعي. هذا التحول يعني أن المطورين أصبحوا نقطة ضعف رئيسية في سلسلة التوريد، وأن مجرد فحص الحزم عند التثبيت لم يعد كافيًا.

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

رؤية Glitch4Techs

من وجهة نظر Glitch4Techs، يمثل هجوم Miasma الأخير مؤشرًا واضحًا على تصاعد تعقيد وخطورة هجمات سلسلة توريد البرمجيات. البرمجية الخبيثة ليست بالضرورة جديدة جذريًا في حمولتها، ولكن قدرتها على التكيف وتغيير مؤشراتها والتنقل بين بيئات برمجية مختلفة (npm، Go، GitHub Actions) هي ما يجعلها تهديدًا مستمرًا وصعب الكشف عنه. هذه المرونة تجعل الدفاعات الثابتة القائمة على التوقيعات القديمة غير فعالة، وتتطلب نهجًا أكثر ديناميكية للتحقق والتدقيق الأمني.

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

كما أن استخدام GitHub كبنية تحتية للقيادة والتحكم (C2) – من خلال المستودعات العامة التي تحمل وصف "Alright Lets See If This Works" – يزيد من صعوبة تتبع المهاجمين ويقدم لهم منصة موثوقة لنقل البيانات المسروقة. بالإضافة إلى ذلك، فإن تضمين killswitch للغة الروسية والتحقق من وجود برامج أمن نقطة النهاية يشير إلى مستوى من الوعي الأمني من قبل المهاجمين، ومحاولة لتجنب الكشف في بعض البيئات المستهدفة، أو ربما للتهرب من تتبع جهات معينة.

نوصي في Glitch4Techs بضرورة تبني استراتيجيات أمنية متعددة الطبقات تشمل: تعزيز أمن حسابات المطورين باستخدام المصادقة متعددة العوامل (MFA) وأنظمة إدارة الهوية والوصول (IAM) الصارمة، الفحص المستمر للحزم والاعتمادات ليس فقط عند التثبيت ولكن أيضًا في جميع مراحل CI/CD، مراقبة نشاط GitHub Actions بحثًا عن أي سلوك غير طبيعي، وتدريب المطورين على ممارسات البرمجة الآمنة والتعرف على هجمات الهندسة الاجتماعية. علاوة على ذلك، يجب على المؤسسات النظر في حلول أمن سلسلة التوريد البرمجية المتخصصة التي يمكنها الكشف عن السلوكيات الخبيثة في البيئات المختلفة وتقديم تحليل معمق للمخاطر.