الهندسة الاجتماعية على المطوّر — نقطة البداية
لم يبدأ اختراق Axios في مارس 2026 باستغلال تقني، بل بحملة هندسة اجتماعية استهدفت Jason Saayman، المطوّر الرئيسي المسؤول عن Axios على npm. انتحل المهاجمون شخصية مؤسس شركة، وبنوا مساحة عمل مزيفة على Slack مكتملة بقنوات وأعضاء واقعيين، ورتّبوا مكالمة على Microsoft Teams مع مشاركين يبدون شرعيين. أقنعوا Saayman بتثبيت حصان طروادة بحجة تحديث نظام مطلوب. وما إن تُمكّن المهاجمون من جهازه حتى أصبح نشر إصدارات خبيثة على npm أمراً يستلزم بيانات اعتماد جلسته فحسب.
في 30-31 مارس 2026، نشر المهاجمون [email protected] (موسوم “latest”) و[email protected] (موسوم “legacy”) — مستهدفين قناتَي التوزيع الحديثة والقديمة على حدٍّ سواء لتعظيم التعرض عبر المشاريع المثبَّتة على كلٍّ منهما. نشر الباحث الأمني Joe Desimone تحذيراً عاجلاً على X في 31 مارس إثر رصده سلوكاً شاذاً. أُزيل الإصداران الخبيثان من npm في غضون نحو ثلاث ساعات.
خلال تلك الساعات الثلاث، رصد Huntress أكثر من 135 نقطة نهاية متضررة عبر أنظمة التشغيل كافة تتصل ببنية الهجوم التحتية للتحكم والسيطرة. نسب Google الحملة إلى UNC1069، مجموعة تهديد كورية الشمالية ذات دوافع مالية نشطة منذ عام 2018 على الأقل.
لا تتمثل أهمية الهجوم في كون Axios ضخماً بشكل استثنائي — إذ تمتلك حزم كثيرة أعداداً مماثلة من التنزيلات — بل لأنه يُثبت أن أي مطوّر لحزمة هو هدف محتمل بصرف النظر عن مستوى أمان السجل نفسه. بنية npm التحتية لم تُخترق؛ بل نموذج الثقة هو ما انهار.
التشريح التقني لحصان الطروادة متعدد المنصات
نشر Elastic Security Labs أول تحليل تقني مفصّل للحمولة الخبيثة. استخدم الهجوم آلية تسليم ثنائية المرحلة.
المرحلة الأولى — الحاقن (Dropper): أدرجت إصدارات Axios الخبيثة تبعيةً واحدة جديدة: [email protected]، التي نفّذت خطاف ما بعد التثبيت (postinstall) تلقائياً عند تشغيل npm install. استخدم ملف JavaScript الخاص بالخطاف (setup.js) طبقتَي تشفير — عكس السلسلة النصية يعقبه فك ترميز Base64، ثم تشفير XOR — لإخفاء حمولته. نفّذ تنظيفاً مضاداً للتحقيق الجنائي بعد تشغيل الحاقن: حذف setup.js نفسه وأبدل package.json الخبيث بإصدار حميد 4.2.0 لا يحتوي على خطافات postinstall، محواً الأدلة من فحص node_modules.
المرحلة الثانية — الزارعات (Implants): نزّل الحاقن زارعات خاصة بكل منصة من sfrclak[.]com:8000:
- Windows: سكريبت PowerShell (6202033.ps1)
- macOS: برنامج ثنائي مُصرَّف بـ C++ (com.apple.act.mond)
- Linux: سكريبت Python (ld.py)
تشاركت المتغيرات الثلاثة بروتوكول تحكم وسيطرة متطابق: HTTP POST بحمولات JSON مشفّرة بـ Base64، فترة إشارة 60 ثانية، معرفات جلسة عشوائية مكونة من 16 حرفاً، وسلسلة وكيل مستخدم (user-agent) عتيقة عن قصد: “mozilla/4.0 compatible; msie 8.0; windows nt 5.1; trident/4.0” — وهي المؤشر الأكثر موثوقية للكشف، ولا سيما في أنظمة macOS وLinux.
غطّت مجموعة الأوامر المدعومة: الإنهاء الذاتي (kill)، وتنفيذ السكريبتات والأوامر (runscript)، وتسليم الحمولات الثنائية (peinject)، وتعداد المجلدات (rundir). أثار التشغيل الأولي استطلاعاً شاملاً للنظام: اسم المضيف، اسم المستخدم، إصدار نظام التشغيل، المنطقة الزمنية، وقت التشغيل، طراز الجهاز، نوع المعالج، وقوائم العمليات الكاملة.
أظهر البرنامج الثنائي لـ macOS تداخلاً مع WAVESHAPER، باب خلفي يتتبعه Mandiant ويُنسب إلى UNC1069. يربط هذا الإسناد حملة Axios بمجموعة تهديد كورية الشمالية ذات تاريخ موثّق في العمليات ذات الدوافع المالية — بما فيها سرقة العملات المشفّرة وحصاد بيانات الاعتماد — مستهدفةً البنية التحتية للمطوّرين تحديداً.
إعلان
موجة سلسلة التوريد الأوسع في أبريل 2026
لم يقع اختراق Axios بمعزل عن غيره. جاء في خضم موجة مركّزة من هجمات سلسلة التوريد عبر سجلات متعددة في مارس-أبريل 2026.
في سبتمبر 2025، أفضى هجوم تصيد على المطوّر “qix” إلى اختراق 18 حزمة npm تستهدف معاملات العملات المشفّرة. انتشرت دودة Shai-Hulud ذاتية التكاثر وسرقت أسراراً غير مشفّرة ورفعتها علناً على GitHub. في مارس 2026، تزامنت حملة Axios مع اختراق TeamPCP لماسح الحاويات Trivy الخاص بـ Aqua Security، والذي انتشر لاحقاً في منظومة npm. وثّق تحليل Huntress بعد الحادثة في أبريل 2026 نمطاً واضحاً: الجهات التهديدية ذات الدوافع المالية — ولا سيما المجموعات المرتبطة بـ DPRK — تستهدف بشكل منهجي سلسلة أدوات المطوّرين بدلاً من تطبيقات المستخدم النهائي، لأن اختراق سلسلة أدوات المطوّرين يحقق أعلى نصف قطر تدمير دفعيٍّ لكل وحدة جهد.
أشار تحليل itBrew للموجة إلى أن هجمات سلسلة التوريد ضد مشاريع المصدر المفتوح تمثّل فئةً لا تُوفّر فيها ضوابط الأمان التقليدية — جدران الحماية المحيطية، وجدران حماية تطبيقات الويب، ومكافحات الفيروسات على نقاط النهاية — سوى حمايةٍ ضئيلة في الجوهر. تصل البرامج الخبيثة معبّأةً داخل أداة طلبها الهدف بنفسه، مثبَّتةً بواسطة نظام البناء الخاص به، في بيئته التطويرية أو الإنتاجية.
ما يجب على قادة الهندسة تغييره في إدارة التبعيات
1. تعامل مع الوسم “latest” باعتباره غير موثوق في أي خط أنابيب إنتاجي
استغل هجوم Axios الحل الافتراضي لـ npm للوسم “latest”. أي ملف package.json يُحدّد "axios": "^1.13.0" أو "axios": "latest" تلقائياً استقبل الإصدار 1.14.1 المخترق عند تشغيل npm install التالي. يجب على قادة الهندسة فرض تثبيت الإصدارات الدقيقة لجميع التبعيات الإنتاجية — باستبدال محدّدات النطاق (^، ~، >=) بأرقام إصدارات دقيقة — والالتزام بملف القفل (package-lock.json أو yarn.lock أو poetry.lock) في نظام التحكم بالمصدر. يجب تكوين خطوط أنابيب CI/CD لتفشل إذا انحرف ملف القفل عن package.json دون التزام تحديث صريح.
هذه ليست توصية جديدة؛ فهي تسبق حادثة Axios بسنوات. يعني رصد أكثر من 135 نقطة نهاية متضررة خلال ثلاث ساعات أن شريحةً كبيرة من مستهلكي npm الإنتاجيين لم يكونوا يستخدمون إصدارات مثبّتة أو ملفات قفل في CI/CD. الوسم “latest” مناسب لبيئات التطوير؛ أما في خطوط الأنابيب الإنتاجية فهو مسؤولية.
2. طبّق التحقق من منشأ الحزمة والإصدارات الموقّعة كبوابة نشر
npm provenance (مدعوم من npm 7+) يربط تشفيرياً إصدار الحزمة المنشور بسير عمل GitHub Actions المحدد الذي أنتجه. يمكن التحقق من أن الحزم المزوّدة بشهادة منشأ قد بُنيت من التزام مصدر محدد ومعروف. رغم أن اختراق حساب Jason Saayman كان سيسمح للمهاجم بنشر حزمة مُوثَّقة بالمنشأ (إذ كان بإمكانه التحكم بالحساب)، فإن التحقق من المنشأ مقروناً بمراقبة المستودع — تنبيهات على نشر حزم غير متوقع خارج أنماط الالتزام المعتادة — يُنشئ طبقة كشف كانت ستُطلق إنذاراً أبكر في حادثة Axios.
على مستوى السجل، الجواب أكثر جوهريةً: يجب أن تتجه سجلات الحزم نحو متطلبات أمان الحساب (مفاتيح الأمان المادية، مفاتيح المرور) التي تقاوم الهندسة الاجتماعية على مستوى موفّري الهوية المؤسسيين. متطلبات MFA الحالية في npm غير كافية للحزم ذات أعداد التنزيل المرتفعة. نشر OpenSSF (مؤسسة أمان المصدر المفتوح) أدوات — Sigstore وSLSA (مستويات سلسلة التوريد لمنتجات البرمجيات) — توفر إطار تحقق تشفيري لعمليات بناء الحزم. اشتراط مستوى SLSA 2 لأي حزمة تتجاوز 10 ملايين تنزيل أسبوعياً كان سيحول دون نشر Axios RAT دون منشأ بناء قابل للتحقق.
3. افحص التبعيات العابرة، لا فقط التبعيات المباشرة
تُركّز معظم فرق الهندسة في عمليات فحص التبعيات على إدخالات package.json المباشرة. استخدم هجوم Axios تبعيةً عابرة — [email protected] التي أدرجها إصدار Axios الخبيث — بوصفها حاقن البرامج الخبيثة الفعلي. لم يكن الكود الضار في Axios نفسه؛ بل في حزمة سحبها Axios، وهي حزمة لم تكن معظم أدوات الأمان الفاحصة لـ package.json ستُشير إليها قبل اكتمال npm install.
يستلزم فحص التبعيات العابرة تشغيل npm audit بعد التثبيت (لا قبله)، ومراجعة شجرة التبعيات الكاملة، وتطبيق إنشاء SBOM (قائمة مكوّنات البرمجيات) لكل عملية بناء. تُولّد أدوات من بينها Syft وcdxgen وOWASP Dependency-Track SBOMات كاملة من node_modules المثبّتة في أقل من 30 ثانية. SBOM من بناء الإنتاج السابق للحادثة، مقارنةً بـ SBOM من تثبيت جديد، كانت ستُبرز [email protected] فوراً بوصفها تبعية عابرة جديدة غير متوقعة — أبكر إشارة كشف آلية ممكنة لهذه الفئة من الهجمات.
السؤال الهيكلي: هل يمكن الوثوق بسجلات الحزم؟
يطرح اختراق Axios سؤالاً معمارياً مزعجاً. يفترض نموذج سجل الحزم مفتوحة المصدر أن مطوّري الحزم موثوقون، وأن البنية التحتية للسجل آمنة، وأن المستهلكين من اتجاه المصب يستطيعون تقييم الثقة من خلال فحص أعداد التنزيلات والسمعة المجتمعية. يُبطل هجوم Axios الافتراضات الثلاثة في آنٍ واحد: مطوّر موثوق خضع للهندسة الاجتماعية، والبنية التحتية للسجل لم تُخترق لكنها استُخدمت قناةً للتوزيع، و100 مليون تنزيل أسبوعياً منحت ثقةً استغلّها الهجوم تحديداً.
الجواب الهيكلي ليس التخلي عن تبعيات المصدر المفتوح — فالتكلفة الإنتاجية ستكون باهظة. بل إعادة تصميم نموذج الثقة: معاملة كل حزمة باعتبارها محتملة الاختراق حتى يثبت العكس عبر منشأ تشفيري، وفرض تثبيت الإصدارات الدقيقة وملفات القفل كبوابات CI/CD غير قابلة للتفاوض، وتطبيق مراقبة التبعيات العابرة كخطوة بناء قياسية لا كتدقيق أمني متقطع.
أظهرت جهات التهديد المرتبطة بـ DPRK اهتماماً مستداماً بالبنية التحتية للمطوّرين منذ عام 2018 على الأقل. حملة Axios ليست حادثة معزولة — بل تصعيد في حملة موثّقة. قادة الهندسة الذين لم يُعيدوا تصميم نموذج ثقة التبعيات لا ينتظرون الهجوم التالي؛ بل هم بالفعل ضمن دائرة تأثيره.
الأسئلة الشائعة
كيف اخترق المهاجمون حساب المطوّر المسؤول عن Axios، وماذا يعني ذلك للمطوّرين الآخرين؟
اخترق المهاجمون حساب Jason Saayman عبر الهندسة الاجتماعية: انتحال شخصية مؤسس شركة، وبناء مساحة عمل مزيفة على Slack بأعضاء وقنوات واقعية، وإجراء مكالمة على Teams انتهت بتثبيت Saayman لحصان طروادة بحجة تحديث نظام. بالنسبة للمطوّرين الآخرين — ولا سيما المسؤولين عن حزم ذات أعداد تنزيل مرتفعة — يعني هذا أن الهندسة الاجتماعية التي تستهدف حسابات المطوّرين ناقل هجوم موثّق ونشط. على المطوّرين معاملة أي طلب غير متوقع لتثبيت برنامج خلال مكالمة مرئية بوصفه مؤشر خطر أحمر، واستخدام مفاتيح الأمان المادية بدلاً من TOTP لـ MFA الخاص بـ npm، والتحقق من جهات الاتصال الجديدة عبر قنوات اتصال معروفة قبل التعاون معها.
ما هو SLSA وكيف يساعد في منع هجمات سلسلة التوريد كـ Axios RAT؟
SLSA (مستويات سلسلة التوريد لمنتجات البرمجيات، تُلفظ “salsa”) إطار أمني من Google وOpenSSF يُحدد سلسلة من المستويات للتحقق التشفيري من سلامة بناء البرمجيات. عند مستوى SLSA 2، تتضمن كل حزمة منشورة شهادة موقّعة تربطها ببناء CI/CD المحدد الذي أنتجها، بما في ذلك تجزئة التزام المصدر. لو نُشرت الحزمة من حساب مخترق دون سلسلة بناء CI/CD قابلة للتحقق، لأخفقت في التحقق عند مستوى SLSA 2 — مُقدِّمةً إشارة تشفيرية بأن الحزمة لم تُبنَ عبر العملية المتوقعة. تعمل npm وPyPI على توسيع دعم SLSA؛ واشتراط الحزم المُتحقَّق منها عبر SLSA ممكن تقنياً لأي فريق يستخدم GitHub Actions اليوم.
لماذا استخدم Axios RAT سلسلة وكيل مستخدم خاصة بـ IE8/Windows XP، وكيف يساعد ذلك في الكشف؟
سلسلة وكيل المستخدم المشفّرة “mozilla/4.0 compatible; msie 8.0; windows nt 5.1; trident/4.0” عبر المتغيرات الثلاثة للمنصات (Windows وmacOS وLinux) عتيقة — Internet Explorer 8 على Windows XP لم يكن في الاستخدام الإنتاجي منذ أكثر من عقد. حدّدها Elastic Security Labs بوصفها المؤشر الأكثر موثوقية للكشف عبر المنصات، لأنها تُولّد بصمة حركة شبكة شاذة: أنظمة macOS وLinux الحديثة لا تُنتج طلبات HTTP بوكلاء مستخدم IE8/Windows XP في أي عملية مشروعة. تستطيع فرق الأمان اكتشاف تثبيتات Axios المخترقة عبر الاستعلام في سجلات الشبكة عن هذه السلسلة، التي تُرسل إشارات كل 60 ثانية إلى بنية التحكم والسيطرة التابعة للمهاجم.
—
