كيف اخترقت كوريا الشمالية مكتبة Axios المُحمَّلة 100 مليون مرة أسبوعياً؟
آخر تحديث: 2025 | الفئة: Cybersecurity – Supply Chain Attack – Social Engineering
مقدمة
في عالم الأمن السيبراني، الهجمات الأكثر خطورةً ليست تلك التي تعتمد على ثغرات تقنية معقدة — بل تلك التي تستغل الإنسان نفسه. وهذا بالضبط ما فعله فريق القراصنة الكوري الشمالي المعروف بـ UNC1069 حين استهدف مطوراً واحداً يعمل على إحدى أشهر مكتبات JavaScript في العالم.
Axios ليست مجرد مكتبة عادية — إنها واحدة من أكثر الحزم تحميلاً في نظام npm بأكمله، تُحمَّل أكثر من 100 مليون مرة كل أسبوع، وتوجد في آلاف التطبيقات والشركات حول العالم. اختراقها لا يعني اختراق مشروع واحد — بل يعني فتح باب خلفي محتمل في كل شركة تعتمد عليها.
ما حدث هنا يستحق الدراسة والتحليل بعمق: ليس لأنه هجوم تقني بارع، بل لأنه هجوم إنساني بالغ الاحتراف، نفّذه فريق مُنظَّم استثمر وقتاً طويلاً في التخطيط لاختراق هدف بدا آمناً تماماً.
- ما هي مكتبة Axios ولماذا هي هدف بالغ الأهمية؟
- من هم UNC1069؟ — ذراع كوريا الشمالية الرقمية
- ما هو Supply Chain Attack؟
- تسلسل الهجوم خطوة بخطوة
- تشريح الـ Social Engineering في هذا الهجوم
- الـ RAT وكيف تجاوز الـ MFA
- حجم التأثير وما الذي كان ممكناً
- الدروس المستفادة للمطورين والشركات
- Best Practices للحماية من Supply Chain Attacks
- الأخطاء الشائعة التي تُسهّل هذا النوع من الهجمات
- الأسئلة الشائعة (FAQ)
- الخاتمة
- مقالات مرتبطة
1. ما هي مكتبة Axios ولماذا هي هدف بالغ الأهمية؟
Axios هي مكتبة JavaScript مفتوحة المصدر تُستخدم لإجراء HTTP Requests من المتصفح أو من بيئة Node.js. بمعنى أبسط: إذا كان تطبيقك يحتاج للتواصل مع API خارجي أو داخلي، فمن المرجح جداً أنه يستخدم Axios للقيام بذلك.
حجم انتشارها يجعلها هدفاً استثنائياً:
- تُحمَّل أكثر من 100 مليون مرة أسبوعياً عبر npm.
- موجودة في ملايين المشاريع حول العالم — من تطبيقات ناشئة صغيرة حتى منصات مالية وبنكية.
- تُستخدم من قِبل شركات Fortune 500 وحكومات ومؤسسات أكاديمية.
- تُثبَّت تلقائياً ضمن سلاسل تبعيات (Dependency Chains) دون أن يعلم المطور النهائي بوجودها أحياناً.
2. من هم UNC1069؟
UNC1069 هو مجموعة تهديد متقدمة (Advanced Persistent Threat — APT) تعمل تحت إشراف مباشر من وحدات الاستخبارات الكورية الشمالية. تتميز بعدة خصائص تجعلها من أخطر الجهات في مجال الاختراق الرقمي:
- التخصص في Supply Chain Attacks: استهداف سلاسل التوريد البرمجية هو أسلوبهم المميز — يبحثون عن الحلقة الأضعف في سلسلة طويلة.
- Social Engineering متقدم: يستثمرون وقتاً طويلاً في بناء هويات وهمية كاملة وموثوقة قبل الاقتراب من الهدف.
- أهداف مالية وجيوسياسية: سرقة العملات المشفرة ومعلومات الشركات التقنية الكبرى هي مصدر تمويل رئيسي لبرامج الأسلحة وفق تقارير الأمم المتحدة.
- بنية تحتية موزعة: يستخدمون خوادم في دول متعددة لإخفاء مصدر الهجمات وتعقيد عملية التتبع.
3. ما هو Supply Chain Attack؟
Supply Chain Attack أو هجوم سلسلة التوريد هو نهج هجومي يستهدف طرفاً ثالثاً موثوقاً — كمزوّد برمجيات أو مطوّر مكتبة أو أداة تطوير — بدلاً من استهداف الضحية النهائية مباشرةً. الفكرة هي الاستفادة من علاقة الثقة بين الضحية ومزوّدها للوصول إليها دون إثارة الشك.
"بدلاً من اختراق عشرين شركة بعشرين هجوم… اخترق الأداة التي تستخدمها العشرون شركة جميعاً."
لماذا هذا النهج فعّال للغاية؟
- الثقة العمياء في الأدوات المعتمدة: المطور لا يفحص كود كل مكتبة يُثبّتها — بل يثق في npm وGitHub والمجتمع المفتوح.
- التوزيع التلقائي: حين تُدرَج الـ Backdoor في نسخة المكتبة المُحدَّثة، تُوزَّع تلقائياً لجميع المشاريع التي تعتمد عليها.
- صعوبة الاكتشاف: الكود الخبيث مُدمَج مع كود حقيقي ومفيد، ويصعب اكتشافه بالأدوات التقليدية.
- التأثير الهائل بجهد محدود: اختراق واحد قد يُفضي إلى آلاف الضحايا المحتملين.
أمثلة موثّقة على Supply Chain Attacks:
| الحادثة | السنة | الهدف | التأثير |
|---|---|---|---|
| SolarWinds Orion | 2020 | أداة إدارة شبكات مؤسسية | أكثر من 18,000 جهة |
| 3CX Desktop App | 2023 | تطبيق اتصالات شركات | مئات الآلاف من الشركات |
| XZ Utils Backdoor | 2024 | مكتبة ضغط Linux | اكتُشف قبل الانتشار الواسع |
| Axios (UNC1069) | 2025 | مكتبة JS — 100M تحميل/أسبوع | لا يزال يُقيَّم |
4. تسلسل الهجوم خطوة بخطوة
ما يميّز هذا الهجوم هو دقة تسلسله وعمق تخطيطه. كل خطوة مُصمَّمة لتُعزّز مصداقية الخطوة التي تسبقها:
نسخ اسم شركة حقيقية وبراندها — موقع إلكتروني، حسابات LinkedIn لأشخاص وهميين بصور حقيقية، وتاريخ عمل موثوق على الملفات الشخصية.
التواصل مع المطور بأسلوب مهني مدروس — فرصة عمل، عرض تعاون، أو نقاش تقني. يبدو الأمر كاهتمام حقيقي من شركة حقيقية.
يُدخلون المطور في Workspace يبدو نشطاً: قنوات متعددة، محادثات جارية، زملاء يتحدثون — كل شيء يوحي بالحيوية والمصداقية.
اجتماع فيديو بأكثر من شخص يتحدثون بشكل طبيعي. الحوار مهني، والجو العام يجعل المطور يثق أنه في اجتماع حقيقي.
أثناء الاجتماع تظهر رسالة بأن برنامجاً قديماً يجب تثبيته للمتابعة. في لحظة يبدو فيها كل شيء طبيعياً، يُثبّت المطور ما يُعتقد أنه أداة مساعدة — لكنه في الواقع برنامج تحكم عن بُعد (RAT) متكامل.
عبر برنامج التحكم عن بُعد، وصلوا لكلمات المرور والمفاتيح الخاصة والـ Cookies — مما مكّنهم من الدخول لحسابات نشر المكتبة وحقن كود خبيث في نسخة Axios التي انتشرت لمدة 3 ساعات قبل اكتشافها.
5. تشريح الـ Social Engineering في هذا الهجوم
ما يجعل هذا الهجوم استثنائياً هو أنه لم يعتمد على أي ثغرة تقنية في نظام الضحية. الثغرة الوحيدة المُستغَلة كانت الثقة الإنسانية. إليك العناصر النفسية التي جعلته يعمل:
| مبدأ التأثير النفسي | كيف طُبِّق في الهجوم | لماذا نجح؟ |
|---|---|---|
| Authority (السلطة) | شركة تبدو راسخة بموقع وفريق وتاريخ | البشر يثقون في المؤسسات الموثوقة الظاهر |
| Social Proof (الإثبات الاجتماعي) | Slack نشط بمحادثات وأشخاص | "إذا يستخدمها ناس كثيرون فهي شرعية" |
| Urgency (الإلحاح) | "يجب تثبيت هذا الآن لنكمل الاجتماع" | الضغط الزمني يُقلّل من التفكير النقدي |
| Context Consistency (اتساق السياق) | كل عنصر مترابط ومنطقي مع السابق | السياق المتسق يُخدّر الشك |
6. برنامج التحكم عن بُعد (RAT) وكيف تجاوز الـ MFA
ما هو الـ RAT؟
RAT (Remote Access Trojan) هو برنامج خبيث يمنح المهاجم تحكماً كاملاً في جهاز الضحية عن بُعد — كأنه جالس أمام الجهاز مباشرةً. يستطيع من خلاله:
- الوصول لجميع الملفات وقراءتها ونسخها.
- تسجيل كل ما يُكتب على لوحة المفاتيح (Keylogging).
- الوصول لمدير كلمات المرور والمفاتيح الخاصة (Private Keys).
- سرقة Session Cookies — وهنا يكمن سر تجاوز الـ MFA.
كيف تجاوز الـ MFA؟
كثيرون يعتقدون أن Multi-Factor Authentication يُوقف كل الهجمات. لكن الـ RAT استخدم ثغرة مختلفة: سرقة الـ Session Cookies.
عندما تُسجّل دخولك في GitHub أو npm وتُكمل التحقق بخطوتَين، يُخزَّن في متصفحك ملف Cookie يُثبت نجاح تسجيل الدخول. إذا سرق المهاجم هذا الـ Cookie واستخدمه، فإن المنصة "تظن" أنه أنت — ولا تطلب منه MFA مجدداً لأن الجلسة قائمة بالفعل.
✔ أنت دخلت المنصة وأكملت MFA بنجاح
← الـ RAT سرق الـ Cookie من المتصفح
← المهاجم استخدم الـ Cookie في متصفحه
✔ المنصة: "أهلاً، أنت مُسجّل دخولك مسبقاً"
→ MFA لم يُطلَب لأن الجلسة قائمة
لماذا دعم الـ RAT أنظمة التشغيل الثلاثة؟
البرنامج الخبيث المُستخدَم صُمِّم ليعمل على Windows وmacOS وLinux، لأن المطورين يستخدمون أنظمة تشغيل مختلفة، والمهاجمون أرادوا ضمان أعلى نسبة نجاح ممكنة بصرف النظر عن بيئة الهدف. هذا التصميم يؤكد أن الهجوم كان مُخطَّطاً له بعناية وليس ارتجالياً.
7. حجم التأثير وما الذي كان ممكناً
استمرت النسخة الملوّثة من Axios في الانتشار لمدة 3 ساعات قبل اكتشافها وإيقافها. هذه المدة القصيرة تبدو بسيطة — لكن في عالم npm وأنظمة CI/CD الحديثة التي تُحدَّث تلقائياً، ثلاث ساعات كافية لأن تُحمَّل الحزمة آلاف المرات وتُنشر في بيئات إنتاجية حقيقية حول العالم.
| السيناريو | التأثير المحتمل |
|---|---|
| مشاريع نفّذت npm install خلال الـ 3 ساعات | تثبيت النسخة الملوّثة في بيئة الإنتاج |
| أنظمة CI/CD ذات تحديث تلقائي | نشر الكود الخبيث في تطبيقات مباشرة |
| لو استمر الهجوم 24 ساعة | ملايين التنزيلات وآلاف الشركات مُعرَّضة |
8. الدروس المستفادة للمطورين والشركات
- المطور يُمثّل سطح هجوم بقدر ما يُمثّله الكود نفسه: حماية بيانات اعتماد المطور وأجهزته تستحق نفس الاهتمام الذي نُعطيه لأمن الخوادم والـ APIs.
- الـ MFA وحده لا يكفي في كل السيناريوهات: Session Hijacking عبر Cookie Theft يتجاوز الـ MFA بالكامل. الحل الأقوى: Hardware Security Keys التي تربط الجلسة بالجهاز الفيزيائي.
- كل طلب تثبيت يجب أن يخضع للتحقق — حتى في منتصف اجتماع: إذا طُلب منك تثبيت شيء أثناء Meeting، أوقف كل شيء وتحقق من المصدر باستقلالية تامة قبل المتابعة.
- الشركات الحديثة تستهدف المطورين لا الأنظمة مباشرةً: المطور يملك مفاتيح نشر المكتبات وصلاحيات الـ CI/CD وأدوات GitHub — مما يجعله هدفاً مركزياً بالغ الأهمية.
9. Best Practices للحماية من Supply Chain Attacks
- 1. استخدم Package Lock Files دائماً: ثبّت نسخاً محددة من المكتبات (Version Pinning) بدلاً من السماح بالتحديث التلقائي. نسخة اختبرتها آمنة — لكن النسخة التالية قد تكون ملوّثة.
-
2. فعّل npm audit في بيئة CI/CD:
شغّل
npm auditفي كل Pipeline قبل النشر واجعله يُوقف العملية عند وجود ثغرات حرجة. - 3. استخدم Hardware Security Keys للحسابات الحساسة: أدوات مثل YubiKey تربط الجلسة بالجهاز الفيزيائي — لا يمكن سرقتها عبر Cookie Theft.
- 4. اعتمد مبدأ Least Privilege في صلاحيات النشر: لا يحتاج كل مطور في الفريق صلاحية نشر الحزمة على npm. قلّل عدد الحسابات ذات صلاحية النشر إلى الحد الأدنى الضروري.
- 5. تحقق من هوية الأطراف عبر قناة مستقلة: قبل أي اجتماع مع طرف خارجي، تحقق من هويته عبر قناة مستقلة: اتصال هاتفي مباشر أو بريد رسمي من نطاق مُتحقَّق منه.
- 6. راقب التغييرات في Dependency Graph بأدوات متخصصة: أدوات مثل Snyk وSocket.dev وDependabot تُنبّهك عند أي تغيير مشبوه في تبعيات مشروعك.
- 7. لا تُثبّت أي برنامج أثناء اجتماعات — مهما كان المبرر: هذا القانون الذهبي الذي كان يمكنه تجنّب هذه الحادثة بالكامل. أي طلب تثبيت أثناء Meeting = علامة حمراء فورية.
10. الأخطاء الشائعة التي تُسهّل هذا النوع من الهجمات
- ❌ الاعتقاد بأن MFA يحمي من كل شيء: MFA يحمي من Password Theft — لكن لا يحمي من Cookie Theft أو Session Hijacking. الحماية الكاملة تحتاج Hardware Keys وإدارة دورة حياة الجلسات.
- ❌ عدم التحقق من هوية الطرف الآخر في الاجتماعات: "الملف الشخصي على LinkedIn يبدو حقيقياً" ليس دليلاً كافياً. الهويات الوهمية أصبحت أسهل في البناء مع الذكاء الاصطناعي.
-
❌ السماح بالتحديث التلقائي للمكتبات في بيئة الإنتاج:
axios: "^1.7.0"في package.json يعني قبول أي نسخة 1.7.x — وهذا يعني أن نسخة ملوّثة قد تُثبَّت تلقائياً. - ❌ إعطاء صلاحيات نشر واسعة لأكثر من الضروري: كل حساب بصلاحية نشر هو نقطة هجوم محتملة. قلّلها واحمها بشكل مستقل.
- ❌ الاستهانة بحجم الخطر على المطور الفرد: "أنا مطور عادي، من سيهاجمني؟" — هذه القصة تُثبت أن المطور الذي يملك مفاتيح حزمة شعبية هو هدف أولوية.
11. الأسئلة الشائعة (FAQ)
12. الخاتمة
ما حدث مع Axios ليس حادثة استثنائية لن تتكرر — بل هو نموذج لنهج هجومي متصاعد يستهدف سلاسل التوريد البرمجية بشكل مُمنهَج. الرسالة الأهم ليست تقنية بحتة: إنها أن الثقة الإنسانية هي الثغرة الأصعب في الترقيع.
مهما كنت تعتقد أن جهازك محمي وحساباتك مؤمَّنة، قد تكون الحلقة الرابطة في هجوم أكبر — لا يستهدفك أنت بالضرورة، بل يستهدف ما تملكه من وصول وثقة وصلاحيات. الوعي بهذا الواقع هو أول خطوات الدفاع.
الدرس الأهم والأبسط: إذا طُلب منك تثبيت أي شيء أثناء اجتماع أو عبر Slack أو Teams — توقف، تحقق، وتحقق مجدداً من مصدر مستقل تماماً قبل أن تضغط Install.
13. مقالات مرتبطة
ما وظيفة كل جهاز وكيف تحمي شبكتك بالتصميم الصحيح.
اقرأ المقال ←كيف تعزل الأقسام والخوادم لتقليل سطح الهجوم في شبكتك.
اقرأ المقال ←كيف تبني بيئة معزولة وآمنة لخدماتك الحساسة.
اقرأ المقال ←كيف تستعيد بياناتك وخدماتك بعد أي حادثة أمنية أو كارثة.
اقرأ المقال ←© 2025 – جميع الحقوق محفوظة | تقنية المعلومات والبنية التحتية