Mini Shai-Hulud: 630 حزمة npm مسمومة في 20 دقيقة — قائمة تحقق الدفاع

كيف سُمِّمت 630 حزمة في 20 دقيقة

حملة Mini Shai-Hulud، المنسوبة إلى مجموعة الجرائم الإلكترونية TeamPCP، تمثّل تحولاً نوعياً في منهجية هجمات سلسلة التوريد. الحملات السابقة — بما فيها البرنامج الخبيث Shai Hulud الأصلي الذي طوّرته TeamPCP في أواخر عام 2025 — كانت تعمل بسرعة بشرية. Mini Shai-Hulud كانت مختلفة.

كما وثّق تحليل CyberScoop للهجوم، نشرت الحملة أكثر من 630 نسخة ضارة عبر 317 حزمة في نحو 20 دقيقة. السرعة لم تكن مصادفة — بل كانت نتاج خط أتمتة بسرعة الآلة مصمَّم لتحديد الحزم وتسميمها أسرع مما تستطيع مجتمع الأمان الكشف والاستجابة.

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

أفادت TechCrunch بأن الحملة امتدت إلى ما وراء حزم npm، إذ اخترق المهاجمون أجهزة حاسوب موظفَين في OpenAI بعد هجوم TanStack — مما يُثبت أن قدرة انتشار البرنامج الخبيث الذاتي كانت حقيقية وعاملة.

ما الذي فعله البرنامج الخبيث — ولماذا يهم

لم تكن حمولة Mini Shai-Hulud مجرد سارق بيانات اعتماد بسيط. كانت نظاماً متعدد المراحل مصمَّماً للاستمرارية والانتشار:

سرقة بيانات الاعتماد: استخرج البرنامج الخبيث بيانات اعتماد AWS وGoogle Cloud وKubernetes وHashiCorp Vault — البنية التحتية الأساسية لمعظم تطبيقات السحابة الحديثة. كما جُمِعت مفاتيح SSH والملفات السرية من الأجهزة المحلية للمطورين.

الانتشار الذاتي: ضمّن الدودة خطافات استمرارية في Visual Studio Code وملفات إعداد Claude Code، وانتشرت إلى مشاريع أخرى بإخفاء نشاطها في هيئة commits من بوت Anthropic Claude. هذا تصعيد مهم: صُمِّم البرنامج الخبيث ليبدو كنشاط عادي لسير عمل التطوير. المطور الذي يراجع تاريخ المستودع يرى commits باسم بوت مألوف ومُصرَّح به، مما يُؤخّر الاكتشاف اليدوي ويتيح للبرنامج الخبيث الانتشار إلى مستودعات إضافية قبل رفع أي إنذار.

تجاوز المصادقة الثنائية: لم يخترق الهجوم بيانات اعتماد حساب npm مباشرةً. بدلاً من ذلك، استغل أذونات سير عمل GitHub Actions — التفاعل بين محفّزات pull_request_target والـ commits اليتيمة في المستودعات المُتفرَّعة. كانت المصادقة الثنائية على حسابات npm غير ذات صلة بمتجه الهجوم المستخدم.

قائمة تحقق دفاع المطورين

1. تطبيق مراقبة سلوك الحزمة أثناء التشغيل، لا اكتفاءً بالتحقق من التوقيع

أثبت هجوم Mini Shai-Hulud أن التحقق من التوقيع التشفيري ضابط ضروري لكنه غير كافٍ — الحزم الضارة كانت تحمل توقيعات صالحة. طبقة الدفاع التي كانت ستكشف الهجوم هي مراقبة السلوك أثناء التشغيل: الكشف عندما تحاول حزمة مُثبَّتة الوصول إلى مفاتيح SSH، أو قراءة المتغيرات البيئية التي تحتوي بيانات اعتماد السحابة، أو إجراء اتصالات شبكية صادرة إلى نقاط نهاية غير متوقعة، أو تعديل ملفات إعداد VS Code.

الأدوات التي تُفعّل تثبيت حزمة npm (مثل Socket أو Sandworm أو منصات مماثلة) تُقيّم السلوك وقت التثبيت بدلاً من الاعتماد فحسب على التوقيعات الثابتة.

2. مراجعة أذونات GitHub Actions — تحديداً محفّزات pull_request_target

استغل هجوم Mini Shai-Hulud الـ commits اليتيمة في المستودعات المُتفرَّعة، التي تتفاعل مع محفّزات pull_request_target في GitHub Actions. يوصي GitHub صراحةً بتجنّب محفّزات pull_request_target ما لم يستلزم حالة الاستخدام ذلك تحديداً.

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

3. نشر مرآة سجل حزم خاصة مع ضوابط القائمة البيضاء

لم يكن نشر 630 حزمة في 20 دقيقة ممكناً إلا لأن بيئات التطوير كانت تسحب مباشرةً من سجل npm العام دون طبقة تصفية وسيطة. مرآة سجل الحزم الخاصة (Verdaccio أو Nexus أو Artifactory أو AWS CodeArtifact) تُنشئ نقطة خنق حيث يمكن فحص الحزم قبل وصولها إلى بيئات المطورين.

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

4. تدوير جميع بيانات الاعتماد التي لامست بيئات الحزم المتأثرة

للمنظمات التي استخدمت TanStack أو UiPath أو MistralAI أو أياً من الحزم الـ317 المتأثرة خلال فترة الهجوم (مايو 2026)، تدوير بيانات الاعتماد ليس اختيارياً — بل هو الاستجابة الدنيا. جمع البرنامج الخبيث مفاتيح AWS وبيانات اعتماد Google Cloud ورموز حساب خدمة Kubernetes ورموز HashiCorp Vault ومفاتيح SSH من أجهزة المطورين.

ابدأ ببيانات الاعتماد الأعلى صلاحية: مفاتيح الجذر/المشرف لمزود السحابة، وحسابات خدمة cluster-admin في Kubernetes، ورموز الجذر في HashiCorp Vault. بالتوازي، راجع CloudTrail وسجلات GCP Audit وسجلات تدقيق Kubernetes بحثاً عن استدعاءات API شاذة في الفترة التي أعقبت تثبيت الحزم الضارة.

الأسئلة الشائعة

المصادر والقراءات الإضافية

• هجوم البرمجيات الخبيثة Mini Shai-Hulud على سلسلة التوريد — CyberScoop
• هاكرز يخترقون عشرات الحزم الشهيرة في المصدر المفتوح — TechCrunch
• تحليل هجوم سلسلة توريد Trivy — InfoQ
• تأمين سلسلة توريد المصدر المفتوح عبر GitHub — مدونة GitHub