في عالم البرمجيات، يُفترض أن تكون مستودعات الحزم مثل npm منصات موثوقة لتسريع التطوير وتقليل الأخطاء. لكن ما يحدث مؤخراً يفرض سؤالاً مزعجاً: ماذا لو تحولت هذه المستودعات إلى مسرح لعمليات اختراق واسعة النطاق، تُدار بذكاء من خلال أسماء متشابهة، وواجهات تبدو “عادية”، وسلاسل تنفيذ تتكيف مع نظام التشغيل؟

وفقاً لتقارير باحثين في برمجيات المصدر المفتوح وشركات تحليل التهديدات، تم رصد حزمة كبيرة من حوالي 800 حزمة خبيثة تم نشرها على سجل npm ضمن حملة تستهدف أنظمة Windows وMac وLinux عبر آليات تحميل وتنفيذ متعددة المراحل، وبقدرة على إخفاء نواياها داخل مظهر “SDK للتتبع” أو ملف README يشرح طريقة تحميل الوحدة عبر [require]. والأهم: هذه الحملة لا تبدو “هجوماً تقليدياً” يعتمد على hooks مثل [preinstall] أو [postinstall]، بل تستغل نمطاً مختلفاً: توجيه المطور لاستخدامها كجزء من الكود.

لماذا هذا النوع من الهجمات أخطر مما يبدو؟

هجمات سلسلة التوريد البرمجية (Software Supply Chain Attacks) تستغل حقيقة أن المطورين يعتمدون على مكتبات جاهزة. وعندما يتم تلويث مكتبة واحدة، يمكن أن تتسع المخاطر لتشمل آلاف المشاريع. لكن حملة “غمر الحزم” تضيف طبقة جديدة من الخطورة: التحكم عن بُعد عبر مراحل تحميل متوافقة مع البيئة.

بدلاً من تنفيذ كود خبيث فور تثبيت الحزمة، تُقدّم الحزم تعليمات في README تُشير إلى أن المطور يجب أن يقوم بتحميل الوحدة عبر دالة [require]، ثم تبدأ سلسلة تنفيذ تُحدد نظام التشغيل والمعمارية (Architecture) وتستدعي حمولة مناسبة من بنية خوادم سحابية موزعة.

هذا التصميم يرفع احتمال نجاح الهجوم لأن مراجعة “سلوك التثبيت” وحدها قد لا تكشف كل شيء. فالهجوم يتحول من “حدث تثبيت” إلى “حدث استدعاء من داخل التطبيق”.

مفاهيم أساسية لفهم الآلية

• RAT (اختصار Remote Access Trojan): برمجية تتيح للمهاجم التحكم في الجهاز عن بعد.
• Infostealer: برمجية هدفها جمع معلومات مثل بيانات المتصفح، الأسرار، أو بيانات بيئية.
• Squatting وTyposquatting: أساليب لاستغلال أخطاء الكتابة أو تشابه الأسماء لخداع المطورين.
• DNS TXT: سجل ضمن نظام أسماء النطاقات يمكنه حمل بيانات نصية يستخرجها البرنامج لاحقاً لتكوين خطوات لاحقة من الهجوم.
• Cloudflare Workers: بيئة تنفيذ سحابية يمكن استخدامها لاستضافة منطق تحميل/توزيع ديناميكي.

لمن يريد توسيع الفهم، يمكن الرجوع إلى شروحات على ويكيبيديا: RAT و Typosquatting و DNS.

كيف تعمل الحملة عملياً؟ من npm إلى حمولة متعددة المنصات

بحسب تحليل الباحث Paul McCarty والجهات التي تابعت الحملة، تبدأ القصة من حزم تبدو “عشوائية” في الأسماء (توليد تلقائي أو تشابه متعمّد)، لكنها تتفق في جوهر واحد: تسليم RAT وInfostealer عبر “منفذ تحميل” يُسمى WEL1DROPPER.

1) تحديد البيئة ثم تحميل حمولة متوافقة

تقوم الحمولة الأولى بالتحقق من نظام التشغيل والمعمارية، ثم تحاول تحميل مرحلة لاحقة من واحد من ثلاثة نطاقات مرتبطة بـ [Cloudflare Workers]. وعند فشل التحميل عبر HTTPS، ينتقل السلوك إلى مسار بديل أكثر مراوغة: استخراج بيانات من DNS TXT.

من بين النطاقات التي ذُكرت في التحليل (ضمن بنية Cloudflare Workers):

• oob-worker.cf103-070.workers[.]dev
• oob-worker.cf102-baf.workers[.]dev
• oob-worker.cf99-9b3.workers[.]dev

ثم يظهر مسار DNS الذي يستهدف نطاقاً من نوع wel1[.]ru، حيث يتم طلب سجلات TXT مرقمة (عدد “قطع” payload chunks) ثم دمجها وفك ترميزها (Base64) لبناء حمولة ثنائية جاهزة للتنفيذ.

2) تنفيذ نهائي يراوغ المراقبة

بعد تجهيز الحمولة، يتم كتابتها إلى مجلد مؤقت وتشغيلها بطرق تختلف حسب النظام:

• على Linux وMac: استخدام /bin/sh.
• على Windows: استخدام cmd.exe.

في النسخة الخاصة بـ Windows، ووفقاً لتتبع Sonatype للحملة تحت مسمى Flooding Dropper، تُطلق المرحلة النهائية كعملية “منفصلة” (detached process)، ثم تُجرى خطوات لتعطيل/إعاقة آليات الرصد، بما في ذلك تعديل يتعلق بـ [ETW] و[AMSI]، إضافة إلى:

• كشف وجود بيئات تحليل أو حوسبة افتراضية (sandboxes/virtual environments).
• إنشاء استمرارية عبر مفاتيح تشغيل في السجل (Registry Run key) ومهام مجدولة.
• تحميل حمولة مشفرة ثم تنفيذها.

على macOS، يكون تسلسل الإجراءات قريباً: فحص آثار تصحيح الأخطاء (debuggers) وأدوات التحليل، ثم استرجاع حمولة مناسبة، وإن تعذّر ذلك تُستخدم آلية DNS TXT لبناء المسار البديل، ثم إعداد الاستمرارية عبر LaunchAgent وتشغيل الملف كعملية منفصلة.

أما على Linux، فقد وُصف أن العينة الثنائية (ELF) مضغوطة باستخدام [UPX]، ثم تقوم بتنزيل حمولة مساعدة من رابط مرتبط بـ Cloudflare Worker، لينتهي الأمر إلى نشر [Sliver]، وهو إطار تحكم (Command-and-Control) مفتوح المصدر.

علامة “تضليل” داخل الكود: SDK تتبع يبدو شرعياً

من اللافت أن بعض الحزم تحتوي ملفاً باسم مثل lib/telemetry.js يقدّم واجهة تبدو مثل SDK للتتبع أو قياس الأداء. لكن التحليل يشير إلى أن هذا الملف يحتوي نفس منطق المُحمّل (downloader) بينما لا يتم استيراده كنقطة دخول أساسية. الهدف المرجح هو خلق “ضجيج” (noise) في المراجعة السريعة: قد يظن المراجع أن الملف مجرد تتبع/تحليلات بينما تمر سلسلة التنفيذ عبر نقاط أخرى.

هذا النمط ليس جديداً في عالم التهديدات—لكن تكراره ضمن حملة بهذا الحجم يعني أن هناك تصنيعاً مُنظماً وليس مجرد تجارب عشوائية.

هل يستهدف هذا حملة مالية؟ مؤشرات من أسماء نطاقات

تتضمن حمولة macOS إشارات إلى نطاقات تبدو مرتبطة بمؤسسات مالية أو مدفوعات، مثل وجود أسماء مثل tcsbank[.]ru وcloudpayments[.]ru. لا يعني ذلك وحده أن الهدف النهائي هو هذه المؤسسات بعينها، لكنه ينسجم مع نمط هجمات تستهدف قطاعات حساسة حيث تكون قيمة المعلومات مرتفعة: بيانات حسابات، مفاتيح، أسرار تطبيقات، أو معلومات بيئية قد تساعد على توسيع الاختراق.

إذا كانت الحملة تستند إلى هذه الدلالات، فهي تندرج ضمن ما نراه في السنوات الأخيرة: استغلال أسرار التطوير (Developer Secrets) وبيانات السحابة وملفات .env لتسهيل اختراق أعمق.

صلة محتملة بحملات سابقة: من “Moika” إلى “Flooding Dropper”

توجد أيضاً قرينة على أن هذه الحملة قد تمثل تطوراً لأسلوب رُصد سابقاً في أبريل، حيث تم توثيق حملة تُعرف باسم Moika تضمنت نشر أكثر من 250 حزمة على npm بهدف سرقة معلومات بيئية وتسليم حمولة ثانية متوافقة مع النظام. التطور هنا يتمثل في أمرين:

• زيادة الحجم (800 حزمة تقريباً بدل 250).
• تحسين مسارات التهرب عبر DNS TXT ومسارات تحميل بديلة.

هنا يظهر الاتجاه الأوسع: المهاجمون لا يكتفون بمحاولة واحدة؛ بل يكررون ويطورون البنية التحتية حسب ما تعمل عليه الاكتشافات الدفاعية.

لماذا هذا يتزامن مع حملات على npm وPyPI وامتدادات المتصفح؟

التقارير تشير أيضاً إلى أن جهات مثل Palo Alto Networks Unit 42 وثّقت حملات تستهدف مستودعات npm وPyPI معاً. من الأمثلة التي تم رصدها:

• حزم على npm تقوم بتنزيل [Crypto stealer] و[RAT] عبر كود جافاسكريبت مُعتم (obfuscated) داخل بنية JSON.
• حزم على npm وPyPI تستهدف سرقة سجلات/بيانات اعتماد سحابية، أو استخدام بنية تحكم مبنية على سلاسل كتل (مثل [EtherHiding] وC2 مخفي)، أو سرقة مفاتيح محافظ عملات رقمية عبر قنوات مثل [Telegram].
• هجمات تعتمد على الهندسة الاجتماعية مثل [fake-CAPTCHA] لتنفيذ كود عن بعد.
• استهداف رموز [Discord] وربما بيانات حساسة مرتبطة بـ [GitHub Actions CI/CD].

وإلى جانب الحزم، ظهرت أيضاً تهديدات في شكل امتدادات كروم تُسوّق كأدوات ألعاب أو إدارة كلمات مرور أو أدوات إنتاجية. بعض هذه الامتدادات تحول المتصفح إلى [web crawling proxy] عبر اتصال دائم (مثل [WebSocket]) مع خادم خارجي، مع استخدام شبكة بروكسي سكنية لأعمال الكشط (scraping).

وللتوضيح: حتى عندما تذكر بعض الامتدادات ذلك في وصف المتجر أو سياسة الخصوصية، فإن “الموافقة” لا تعني بالضرورة “الأمان”. فالتسويق قد يخفف من إدراك المستخدم لمستوى جمع البيانات أو طبيعة التتبع.

للمزيد عن مفهوم امتدادات المتصفح وسلامة الإضافات، يمكن الرجوع إلى: Browser extension.

ما الذي يعنيه ذلك للأمن السيبراني اليوم؟

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

1) حوكمة الحزم وتدقيقها

• تطبيق سياسة “القائمة المسموح بها” للحزم (Allowlisting) قدر الإمكان.
• فحص الحزم عند الإدخال إلى سلسلة التطوير (CI) وليس فقط عند النشر.
• مراجعة README وملفات المدخلات (entry points) للبحث عن تعليمات استدعاء غير معتادة مثل الاعتماد على [require] بشكل مباشر.

2) مراقبة سلوك التنفيذ وليس المحتوى فقط

• ربط أنظمة كشف التهديدات (EDR/XDR) بسيناريوهات تنزيل payloadات من نطاقات غير متوقعة أو عبر DNS TXT.
• تتبع إنشاء عمليات منفصلة وتشغيل أدوات النظام مثل cmd.exe و/bin/sh من سياقات غير مألوفة.
• مراعاة أن بعض الهجمات تتلاعب بآليات الرصد مثل [ETW] و[AMSI] على Windows.

3) حماية الأسرار وبيانات الاعتماد

حتى لو افترضنا أن الحزم لا تُنفذ مباشرة على الجهاز، فإن تسريب ملفات .env أو بيانات بيئة يمكن أن يحول الاختراق إلى مسار “صعود” نحو السحابة. لذلك يجب:

• تقليل امتيازات رموز الوصول (Least Privilege).
• استخدام إدارة أسرار مركزية بدل تخزينها في ملفات نصية ضمن المستودعات.
• مراقبة محاولات الوصول إلى سجلات/أسرار حساسة من داخل بيئة التطوير.

أطر ومعايير تساعد—لكن لا تكفي وحدها

المؤسسات التي تتعامل بجدية مع سلسلة التوريد البرمجية غالباً ما تستند إلى أطر مثل:

• مبادرة سلامة سلسلة التوريد البرمجية (SLSA) التي تركز على ضمانات بناء وتوثيق البرمجيات.
• أفضل ممارسات NIST في إدارة المخاطر والضوابط الأمنية.
• إرشادات OWASP ذات الصلة بالبرمجيات والاعتماد.

لكن الأهم هو ترجمة هذه الأطر إلى ضوابط تشغيلية: فالهجوم الذي يستغل README واستدعاء [require] لن يُكتشف بمجرد فحص “hooks” التقليدية. المطلوب هو تحليل مسارات التنفيذ وربط ذلك بمراقبة وقت التشغيل.

إحصاءات ولماذا الوقت عامل حاسم

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

هذا يفسر لماذا يركز المدافعون على:

• التكامل الفوري مع أنظمة فحص الحزم ضمن خط التطوير.
• الاستجابة السريعة عند اكتشاف حزم خبيثة داخل المستودعات.
• مراقبة “سلوك ما بعد التثبيت” و”سلوك ما بعد الاستدعاء”.

خلاصة وتحفيز للنقاش

الحملة التي تم رصدها—حزم كثيرة، أسماء ملتبسة، حمولة متعددة المنصات، وذخيرة تتكيف مع البيئة—تُجسد كيف أصبحت سلسلة التوريد البرمجية ساحة صراع رئيسية. والأهم أن الهجوم لا يعتمد فقط على “ماذا يحدث أثناء التثبيت”، بل على “ماذا يحدث عندما يستدعي التطبيق المكتبة”.

السؤال الذي يجب أن يواجهه كل فريق تطوير وأمن: هل لديك رؤية عملية لسلسلة التنفيذ من لحظة إدخال الحزمة إلى لحظة إطلاق الحمولة—أم أنك تعتمد على فحوصات سطحية قد تفشل أمام هجمات تستغل README وطرق الاستدعاء؟

إذا كانت لديك تجربة أو سياسة داخلية حول فحص الحزم أو مراقبة CI/CD، ما الذي تعتبره الأكثر فعالية في تقليل خطر حزم خبيثة؟

مصادر مقترحة للقراءة الموسعة:
هجمات سلسلة التوريد البرمجية
نظام أسماء النطاقات
نظام التحكم والسيطرة

فيسبوك |
X