حين تتحول الثقة إلى بوابة للبرمجيات الخبيثة

استخدم هجوم سلسلة توريد استهدف مكتبة Axios في npm، وحملة SilverFox التي روّجت لتطبيقات Claude مزيفة، أسلوبين مختلفين للوصول إلى الضحايا، لكنهما اعتمدا على الفكرة نفسها: إخفاء البرمجيات الخبيثة خلف إشارات تبدو موثوقة.

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

ولا يعني ذلك أن مكتبة Axios الأصلية أو منتج Claude التابع لشركة Anthropic خبيثان بطبيعتهما؛ فالاختراق طال إصدارات محددة من Axios، بينما استخدمت حملة SilverFox مُثبّتات مقلّدة.

ماذا حدث لـ Axios في 31 مارس 2026؟

تمكن مهاجم من السيطرة على صلاحيات النشر في npm المرتبطة بأحد المطورين الرئيسيين في مشروع Axios، ثم نشر إصدارين ملوثين هما axios@1.14.1 وaxios@0.30.4. أضاف الإصداران التبعية المخفية plain-crypto-js@4.2.1، وهي تبعية لم تكن تؤدي وظيفة عادية ضمن Axios، بل استُخدمت لتشغيل تعليمات خبيثة أثناء التثبيت.

اتصل سكربت التثبيت ببنية تحت سيطرة المهاجمين، ثم نزّل حصان طروادة للوصول عن بُعد مخصصًا لأنظمة Windows وmacOS وLinux. وبذلك، كان من الممكن أن يتحول تثبيت حزمة اعتيادي إلى الخطوة الأولى في اختراق أوسع.

بقي الإصداران المتأثران متاحين لنحو ثلاث ساعات تقريبًا. وسجلت مجموعة Google Threat Intelligence نشاطًا بين الساعة 00:21 و03:20 بالتوقيت العالمي في 31 مارس، بينما وصفت تقارير أخرى نافذة التعرض بأنها امتدت من ساعتين إلى ثلاث ساعات. وتُعد Axios تبعية عالية التأثير؛ إذ تضع تقديرات مختلفة عدد تنزيلاتها الأسبوعية من نحو 80 مليونًا إلى أكثر من 100 مليون، بحسب المصدر.

كيف استُغل حساب المطور؟

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

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

ماذا فعلت التبعية الخبيثة؟

تنكرت plain-crypto-js@4.2.1 في هيئة تبعية عادية، لكنها وُجدت أساسًا لتشغيل سكربت postinstall. اتصل السكربت بخادم للتحكم والسيطرة، ثم جلب حمولة ثانية مصممة وفق نظام التشغيل الموجود على الجهاز.

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

npm install

هل كانت BlueNoroff وراء الهجوم؟

لا تزال نسبة الهجوم إلى جهة محددة غير محسومة في المواد المتاحة. فقد ربطت بعض التقارير العملية بجهات مرتبطة بكوريا الشمالية، من بينها BlueNoroff أو مجموعات قريبة منها، في حين نسبت Microsoft الاختراق إلى مجموعة Sapphire Sleet.

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

والخلاصة الأكثر تحفظًا هي أن اختراق Axios شمل السيطرة على حساب مطور، ونشر إصدارات ملوثة، وتوزيع حصان طروادة متعدد المنصات للوصول عن بُعد؛ أما الجهة المسؤولة فما زالت موضع خلاف بين التقييمات العلنية.

كيف استخدمت SilverFox تطبيقات Claude المزيفة؟

اتبعت SilverFox مسارًا مختلفًا إلى داخل المؤسسات، إذ وزعت تطبيقات Claude مقلدة لأنظمة Windows وmacOS وLinux. واستهدفت الحملة مؤسسات في قطاعات الصناعة والاستشارات والتجارة والنقل في الهند وإندونيسيا وجنوب أفريقيا وروسيا.

كانت هذه التطبيقات انتحالًا لعلامة Claude التابعة لشركة Anthropic، وليست مُثبّتات رسمية للمنتج. وتعتمد فاعليتها على سيناريو عملي مقنع: يبحث موظف عن أداة إنتاجية مدعومة بالذكاء الاصطناعي، وينزّل تطبيقًا يبدو مألوفًا، ثم يثبت برمجية خبيثة بدلًا منه. ووصفت تقارير Kaspersky الحملة بأنها جزء من نشاط SilverFox الذي ظهر في موجات متعددة منذ ديسمبر 2025.

من رسائل الضرائب إلى طُعم الذكاء الاصطناعي

بنت الحملة الجديدة على أسلوب سابق من التصيد الاحتيالي ذي الطابع الضريبي. ففي يناير وفبراير 2026، رصد الباحثون أكثر من 1,600 رسالة بريد إلكتروني خبيثة انتحلت صفة إخطارات رسمية بمراجعة ضريبية أو زعمت أنها تتضمن قوائم بالمخالفات الضريبية.

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

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

الدرس المشترك: الثقة نفسها أصبحت سطح هجوم

استهدفت الحملتان علاقات ثقة مختلفة:

• الثقة بالمطور: بدت إصدارات Axios وكأنها منشورة عبر جهة npm مخولة.
• الثقة بالتبعيات: تعامل مدير الحزم مع التبعية الخبيثة بوصفها جزءًا من مسار تثبيت طبيعي.
• الثقة بالعلامة التجارية: استعانت مُثبّتات Claude المزيفة بهوية منتج ذكاء اصطناعي معروف.
• الثقة بسير العمل: نفذ المطورون والموظفون إجراءات روتينية، مثل تحديث التبعيات أو تثبيت برنامج إنتاجية.

توضح واقعة Axios أن قِصر نافذة التعرض لا يعني انخفاض الخطر. فعمليات التثبيت وبناء المشاريع وخطوط CI/CD قد تعمل تلقائيًا، ما يعني أن عدد الأنظمة التي تصل إليها الإصدارات الملوثة لا يقتصر على الأشخاص الذين يفحصون الإصدار يدويًا.

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

ماذا ينبغي للمؤسسات أن تفعل الآن؟

في ما يتعلق بحادثة Axios، ينبغي تدقيق ملفات القفل، وملفات تعريف الحزم، وسجلات البناء، وذاكرات التخزين المؤقت، وقوائم التبعيات بحثًا عن axios@1.14.1 وaxios@0.30.4 وplain-crypto-js@4.2.1. ويجب التحقيق في أي جهاز ثبّت إصدارًا متأثرًا خلال نافذة التعرض، بحثًا عن حمولات جرى تنزيلها، أو آليات بقاء غير مصرح بها، أو بيانات اعتماد انكشفت. وتوصي النشرات الأمنية بالتعامل مع هذه التثبيتات على أنها معرضة للاختراق.

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

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

أما الإجراء الأوسع، فهو التحقق عند كل نقطة انتقال للثقة. فاسم الحزمة المألوف لا يضمن سلامة كل إصدار، كما أن اسم المنتج المعروف لا يثبت أن كل مُثبّت يحمل علامته التجارية أصلي.