نافذة الـ 26 دقيقة التي اخترقت 317 حزمة
تتميز حملة mini-Shai-Hulud ليس بجدة تقنياتها بل بسرعة تنفيذها ودقته. سلسلة الهجوم، التي أعاد تركيبها باحثون من Rescana وAikido Security وSnyk وSocket، تطورت في ثلاث مراحل متمايزة على امتداد 10-12 مايو 2026.
المرحلة الأولى (10 مايو 2026): الاستعداد المسبق. أنشأ المهاجم نسخة من مستودع TanStack/router تحتوي على commit خبيث. لم تُنشر أي شيفرة بعد — كانت هذه خطوة التمركز.
المرحلة الثانية (11 مايو 2026، 19:06–20:46 UTC): التنفيذ. فتح المهاجم طلب سحب (pull request) ضد المستودع الرئيسي. لأن إعداد GitHub Actions للمستودع كان يستخدم سير عمل pull_request_target — نمط يعمل بصلاحيات الكتابة للمستودع الهدف حتى عند تفعيله من طلب سحب فرعي — فقد قُبل مخزن pnpm الخبيث المُحقَن في ذاكرة cache لـ GitHub Actions واستُخدم من قِبل سير عمل الإصدار. هذا أطلق نشراً آلياً لإصدارات خبيثة على npm. بين 19:20 و19:26 UTC (نافذة ست دقائق)، وُزّعت 84 نسخة خبيثة عبر 42 حزمة @tanstack. اكتشف باحثون خارجيون الهجوم في غضون 20-26 دقيقة. أهمل المطوّرون الإصدارات الخبيثة خلال ساعة؛ أزال npm الحزم الخبيثة المضغوطة في المساء ذاته.
المرحلة الثالثة (12 مايو 2026): الانتشار الثانوي. عبر المكوّن ذاتي الانتشار — الذي استعلم npm بحثاً عن الحزم التي يصونها الحسابات المطوّرة المخترقة وأعاد نشرها بحمولة مطابقة — وصلت الحملة إلى 317 حزمة إجمالاً، من بينها حزم @uipath وحزم @mistralai ومكتبات جدولة رحلات جوية وحزم Python على PyPI. أكد TechCrunch اختراق أجهزة حاسوب موظفي OpenAI إثر اختراق TanStack، وكذلك أجهزة منظمات عديدة أخرى.
نُسبت الهجمة إلى TeamPCP، مجموعة إجرامية تركّز على السحابة ظهرت أواخر 2025 وتستهدف تحديداً أنظمة بيانات اعتماد المطوّرين — بيانات اعتماد مزودي السحابة وأسرار CI/CD ومفاتيح SSH التي توفر وصولاً للبنية التحتية للإنتاج.
إعلان
البنية التقنية للحمولة الخبيثة
فهم بنية الحمولة يُوضّح لماذا أفلت من رصد برامج مكافحة الفيروسات المعتادة وكشف نقاط النهاية عند النشر الأولي. الملف الخبيث — router_init.js، ملف JavaScript مُعتّم بحجم 2.3 ميجابايت — لم يُصرَّح به في بيان الحزمة (package manifest). دُسّ في ملف حزمة tarball وأُشير إليه عبر إدخال optionalDependencies مُحقَن، مما جعله غير مرئي لفحص سريع لـ package.json لكنه يُنصَّب كاملاً عند تشغيل npm install.
استهدف وحدة حصد بيانات الاعتماد مجموعة شاملة من أسرار المطوّرين: نقاط نهاية AWS IMDS وSecrets Manager، ورموز خدمة البيانات الوصفية لـ GCP، ورموز حساب خدمة Kubernetes، ورموز HashiCorp Vault، وملفات مصادقة .npmrc، ورموز GitHub من متغيرات البيئة وإعداد واجهة سطر الأوامر و.git-credentials، ومفاتيح SSH الخاصة من محطات عمل المطوّرين. كان قناة الاستخراج Session (المُعروف سابقاً بـ Signal Fork) — تطبيق مراسلة لامركزي لا تُفلتر بروتوكوله وكلاء الويب المؤسسية المعتادة — باستخدام بنية تحتية في git-tanstack.com وapi.masscan.cloud وlitter.catbox.moe كنقاط قيادة وسيطرة.
صُمّمت آلية الثبات لضمان الأمن التشغيلي: خادم gh-token-monitor مُنصَّب كخدمة systemd على Linux أو LaunchAgent plist على macOS يُرسل استفسارات لـ GitHub كل 60 ثانية. إذا أُلغي أي رمز GitHub مسروق، نفّذ الخادم rm -rf ~/ — مدمراً جميع ملفات المطوّر قبل أن يتمكن فريق الأمن من التحقيق الجنائي في الجهاز المخترق. اختتم الهجوم نفسه بعد 24 ساعة، محدوداً النافذة الجنائية للمنظمات التي رصدته ببطء. ما تجنّبه عمداً: أهمل الخادم إدخالات متغير بيئة github_token لتفادي الكشف عن الأسرار المدمج في GitHub، الذي كان سيُطلق إلغاءً تلقائياً للرمز.
تفصيل تهرب رصد يستحق التنبيه: استهدف الحمولة الخبيثة تحديداً الحزم ذات 12 مليون تنزيل أسبوعي لأن الحزم المُستخدَمة على نطاق واسع وعالية السمعة تحمل أدنى نسبة تدقيق-لكل-تنزيل. وفق تقرير Sonatype 2026 لحالة سلسلة توريد البرمجيات، اكتُشفت أكثر من 454,600 حزمة خبيثة جديدة في 2025 وحده — مع تركّز أكثر من 99% من هذا الحجم على npm. يُنصّب المستخدمون TanStack router لثقتهم به؛ لا يفحصون ملفاته المضغوطة. استغلت الحملة هذا اللاتماثل في الثقة على نطاق صناعي.
ما يجب على قادة الهندسة استيعابه
1. مراجعة سير عمل pull_request_target وتقييدها قبل الحادثة التالية
نمط إعداد GitHub Actions الذي مكّن حملة mini-Shai-Hulud — سير عمل pull_request_target يعمل بصلاحيات كتابة استجابةً لطلب سحب من fork — موثّق بوصفه خطراً أمنياً في دليل تصليب أمان GitHub Actions، لكنه يظل شائعاً لأنه السلوك الافتراضي في كثير من قوالب سير العمل. إجراء المراجعة الفورية: ابحث في دليل .github/workflows/ لكل مستودع عن مشغّلات pull_request_target. لكل منها، تحقق من أن سير العمل لا يُنفّذ شيفرة من المستودع المتفرع بصلاحيات مرتفعة. إن كان كذلك، انتقل إلى pull_request (الذي يعمل بوصول للقراءة فقط من الفروع) واستخدم منح الأذونات الصريحة للعمليات المحددة التي تحتاجها.
للمستودعات التي تستلزم pull_request_target — عادةً سير عمل أتمتة الإصدار التي تحتاج لنشر القطع — طبّق مراجعة كود إلزامية على ملف سير العمل ذاته، مقتصراً على مراجع أمني مُسمَّى. لا تسمح أبداً بعمليات دمج آلية تُعدّل ملفات سير العمل. تدعم قواعد حماية الفروع في GitHub اشتراط مراجعين محددين للتغييرات على مسارات تتضمن .github/workflows/.
2. تطبيق إلزام ملفات القفل والتحقق من سلامة الحزم المضغوطة في كل خط أنابيب CI
كانت حملة mini-Shai-Hulud قابلة للكشف على مستوى ملف tarball: router_init.js لم يكن في بيان الحزمة لكنه كان موجوداً في tarball. أدوات تتحقق من محتوى ملفات tarball مقابل بيانات الحزم المنشورة — Socket Security وAikido Security ووحدة سلسلة التوريد في Snyk جميعها توفر هذه الإمكانية — كانت ستُنبّه للإصدارات الخبيثة قبل التنصيب. للفرق التي تفتقر لأدوات سلسلة توريد مخصصة، يكفي الحد الأدنى: npm ci (الذي يُطبّق سلامة ملف القفل ويرفض الحزم غير المطابقة لتجزئته) مقروناً بـ خيار --ignore-scripts المدمج في npm (الذي يمنع تنفيذ الشيفرة العشوائية أثناء تنصيب الحزم).
لمُشغّلي CI/CD تحديداً: قيّد أذونات السحابة للمُشغّل بأدنى ما يلزم لخطوة البناء لا خطوة النشر. مُشغّل يستطيع القراءة فقط من سجل القطع والكتابة إلى دلو مرحلي لا يمكن استخدامه لدفع نشرات إنتاج حتى لو سُرقت بيانات اعتماده.
3. بناء خطط الاستجابة للحوادث لاختراق سلسلة التوريد — قبل الحاجة إليها
تضمّنت الاستجابة لـ mini-Shai-Hulud دقةً تشغيلية حرجة: الفرق التي ألغت رموز GitHub المخترقة قبل إزالة الخادم gh-token-monitor أطلقت حمولة rm -rf ~/، مدمّرةً الأدلة الجنائية. التسلسل الصحيح للمعالجة — الموثّق في تقارير ما بعد الحوادث من Aikido Security وSocket — هو: (1) عزل الجهاز المتضرر عن الشبكة، (2) تحديد الخادم وإزالته قبل أي تدوير للبيانات الاعتماد، (3) ثم تدوير البيانات الاعتماد. هذا التسلسل غير بديهي؛ الغريزة هي إلغاء البيانات الاعتماد أولاً. بدون خطة مكتوبة تُحدّد الترتيب الصحيح، سيتبع المستجيبون تحت الضغط التسلسل الغريزي.
عمّم هذا المبدأ على اختراق سلسلة التوريد بشكل عام: ابنِ دليل تشغيل يُحدّد كيفية الاستعلام عن جرد SBOM للإصدارات المتأثرة من الحزم، وكيفية تحديد مُشغّلي CI الذين عالجوا الحزم المتأثرة، وكيفية تحديد بيانات اعتماد السحابة التي كان لتلك المُشغّلين وصول إليها، وبأي ترتيب تُعالج كل واحدة. اختبر دليل التشغيل ربع سنوياً بتمرين جدول محاكاة باستخدام حادثة تاريخية (mini-Shai-Hulud نفسها مرشحة جيدة). المنظمات التي مارست الاستجابة لحوادث سلسلة التوريد قبل 11 مايو 2026 أتمّت معالجتها في ساعات؛ تلك التي لم تمتلك خططاً استغرقت أياماً.
الأسئلة الشائعة
ماذا يجب أن تفعل المنظمة في أول 30 يوماً للاستجابة للتهديدات الموصوفة؟
أجرِ جرداً للأصول لتحديد الأنظمة المكشوفة لناقلات الهجوم الموصوفة. قيّم قدرات الكشف الحالية مقابل أنماط التهديد. أعطِ الأولوية لتصحيح أي ثغرات حرجة محددة. راجع خطة الاستجابة للحوادث لضمان تغطيتها لسيناريوهات الهجوم الموصوفة. أبلغ قيادتك عن مستويات التعرض والاستثمار الدفاعي المطلوب.
ما هو الحد الأدنى من تحسين الأمان القابل للتطبيق لمؤسسة جزائرية صغيرة ومتوسطة الحجم؟
ركّز أولاً على التدابير الأعلى تأثيراً والأقل تكلفة: المصادقة متعددة العوامل عبر جميع وصلات الوصول عن بُعد، والكشف والاستجابة للنقاط النهائية (EDR) على جميع الأجهزة المُدارة، وعملية نسخ احتياطي واسترداد مُختبرة. هذه التدابير الثلاثة تعالج غالبية الهجمات الناجحة في مشهد التهديدات الحالي.
كيف تقارن التهديدات الموصوفة بما تختبره المنظمات الجزائرية فعلياً؟
أنماط الهجوم الموثقة في تقارير الاستخبارات العالمية تتطابق إلى حد كبير مع ما تبلغ عنه المنظمات الجزائرية لـ CERT-DZ، مع التصيد الاحتيالي وسرقة بيانات الاعتماد وبرامج الفدية كأنواع هجوم سائدة.
