تستجيب شركة Wiz Research وWiz CIRT لحادثة Shai-Hulud 2.0 (المعروفة أيضًا باسم Sha1-Hulud) منذ ظهور الأخبار لأول مرة في 24 نوفمبر 2025. وحتى الآن، نواصل ملاحظة الانتشار النشط، وإن كان بوتيرة أقل بكثير. وهذا يمنحنا فرصة التراجع ومشاركة ما تعلمناه خلال هذه الحادثة والتفكير في المستقبل.
يفترض منشور المدونة هذا الإلمام بمراحل Sha1-Hulud. للحصول على وصف تفصيلي للحادث الأولي، وتوصياتنا بشأن الاستجابة، راجع منشور مدونتنا السابق.
بالمقارنة مع ديدان سلسلة التوريد السابقة مثل s1ngularity وShai-Hulud 1.0، تمكن Shai-Hulud 2.0 من البقاء نشطًا لفترة أطول. لا يزال يتم إنشاء المستودعات الجديدة بعد أكثر من 6 أيام. انخفضت الوتيرة إلى عشرات المستودعات الجديدة يوميًا، لكن الأول من ديسمبر 2025 شهد ارتفاعًا متجددًا في الإصابة بأكثر من 200 مستودع جديد في ما يزيد قليلاً عن 12 ساعة. ويبقى أن نرى ما إذا كان نمط الانتشار هذا سيستمر، وكم سيكون طول ذيل هذه الدودة.
إحدى الطرق التي يمكننا من خلالها نمذجة الاتجاهات هي استخدام مشروع GHArchive، الذي يقدم بيانات تاريخية من GitHub Events API، مع الحفاظ على المعلومات حول المستودعات والمستخدمين المحذوفين الآن. ومع ذلك، لا يمكن استخدامه للأرقام المطلقة، حيث أن معدل الخسارة في ظل ظروف معينة يمكن أن يصل إلى 50%. ونتيجة لذلك، قام ردنا بإقران واجهة برمجة تطبيقات GitHub مع GHArchive، مما ترك لنا واحدة من مجموعات البيانات الأكثر شمولاً حول هذه الحادثة.
لا يزال GHArchive مفيدًا لإظهار الاتجاهات العامة بسهولة مثل وتيرة إنشاء مستودعات جديدة:
يعكس الانخفاض الكبير خلال 24/11 أنشطة الاحتواء التي قام بها PostHog وPostman وAsyncAPI وفريق npm. مستخرج من تقاريرهم:
-
PostHog: “بحلول الساعة 9:30 صباحًا بالتوقيت العالمي المنسق، حددنا الحزم الضارة وحذفناها وألغينا الرموز المميزة المستخدمة لنشرها”
ساعي البريد: “24/11/25، الساعة 3:30 صباحًا بتوقيت المحيط الهادئ [11:30 UTC]: تم تحقيق الاحتواء (جميع الإصدارات المصابة غير منشورة)”
-
AsyncAPI: “
11:46:00 UTC– الإجراء الذي اتخذه فريق أمان NPM لإلغاء نشر الحزم الضارة.”
من المهم التمييز بين المستودعات العامة الجديدة ومستخدمي GitHub الجدد. عندما تكون البرامج الضارة غير قادرة على العثور على بيانات اعتماد GitHub محليًا، فإنها ستبحث بدلاً من ذلك عن مستودع موجود من ضحية سابقة. ثم يستخدم بيانات اعتماد تلك الضحية السابقة لتحميل مستودع إضافي ضمن حساب الضحية السابقة، مع بيانات من الضحية الجديدة. يعتمد البحث عن هذه الحسابات المخترقة على ملف سيء السمعة “Sha1-Hulud: The Second Coming.” سلسلة، والتي هي بمثابة منارة للترشيح.
يوضح الرسم البياني الثاني عدد حسابات GitHub المخترقة حديثًا والتي تعمل المضيفين/الموزعين السريين. العدد الفعلي للمثيلات المخترقة أعلى، وينعكس بشكل أفضل في عدد المستودعات التي تم إنشاؤها.
إلى جانب النظام البيئي NPM، كشفت AsyncAPI أن الهجوم الأولي تمكن من تصفية ليس فقط رمز NPM المميز ولكن أيضًا مفتاح OpenVSX API. علاوة على ذلك، هناك تقارير مؤكدة عن إصابات ناجحة من ملحق AsyncAPI IDE المسموم:
بالإضافة إلى ذلك، لاحظ فريق المقبس أن الحمولة الضارة Shai Hulud v2 المستندة إلى Bun، والتي تعكس إصدار npm مخترق، قد امتدت إلى نظام Java/Maven البيئي عبر org.mvnpm:posthog-node:4.18.1 طَرد. أكد PostHog وMaven Central الإصدارات المخترقة في كل من npm وMaven بسبب آلية النسخ المتطابق الآلي. ومع ذلك، فإننا لا نلاحظ انتشارًا نشطًا للدودة في النظام البيئي Maven أو OpenVSX.
تحتوي معظم المستودعات التي تم تحميلها على ملف environment.json ملف يتضمن معلومات عن النظام الذي تم تشغيل البرامج الضارة عليه، وبيانات اعتماد GitHub المستخدمة لتصفية البيانات. بشكل عام، من مجموعة المستودعات المخترقة، تمكنا من استرداد حوالي 24000 من هذه الملفات، نصفها تقريبًا فريد من نوعه. استخدمنا خوارزمية بصمات الأصابع الأساسية لاستنتاج سمات الجهاز المخترق بناءً على القيم المتغيرة. تشير أرقامنا إلى أن 23% فقط من حالات الإصابة حدثت على أجهزة المطورين. من بين الحالات المصابة، الأغلبية المطلقة هي أجهزة Linux:
ترتبط شعبية Linux ارتباطًا وثيقًا بحقيقة أن غالبية المتسابقين هم في الواقع حاويات، مما يدعم قيمة محاولات المهاجم لدمج الهروب من الحاوية (كما ذكرنا في المدونة السابقة):
على وجه التحديد، فيما يتعلق بمشغلات CI/CD، تعد GitHub Actions المنصة الرائدة حيث تأتي Jenkins وGitLab CI وAWS CodeBuild في المركز الثاني والثالث والرابع:
أخيرًا، نظرنا إلى الحزمة الضارة المتورطة، للحصول على نظرة ثاقبة حول الحزم التي كانت الناقلات الأساسية. على وجه التحديد، متغيرات البيئة npm_package_name و npm_package_version تبين أنها مفيدة للغاية. توزيع الحزم المصابة أبعد ما يكون عن أن يكون موحدًا:
ناقل العدوى السائد هو @postman/tunnel-agent-0.6.7 الحزمة، مع @asyncapi/specs-6.8.3 تم تحديده على أنه ثاني أكثر شيوعًا. تمثل هاتين الحزمتين أكثر من 60% من إجمالي الإصابات. يوضح هذا الاكتشاف كيف أدت جهود التخفيف التي ركزت على هذه التبعيات إلى انخفاض عميق وسريع في اتجاهات العدوى.
يرتبط هذا الترتيب ارتباطًا وثيقًا بانتشار الحزمة. خاصة، @postman/tunnel-agent و @asyncapi/specs هما الحزمتان الأولى والثالثة الأكثر شيوعًا، وتربطان بشكل مباشر معدل انتشارهما المرتفع بحجم التسوية الناتجة.
فيما يلي أرقام الانتشار، المحدثة مما تمت مشاركته سابقًا في منشورنا الأخير:
وأخيراً نظرنا إلى npm_lifecycle_event و npm_lifecycle_script المتغيرات لربط مرحلة العدوى. وكما هو متوقع، فإن 99% من جميع حالات العدوى جاءت من preinstall تنفيذ الحدث node setup_bun.js. يبدو أن بعض الحالات التي لا تتبع هذا النمط هي محاولات اختبار.
قبل أن نقوم بتفصيل المقاييس المتعلقة بالأسرار المسربة، تستحق بعض الحقائق ذات الصلة اهتمامًا خاصًا. أولاً، تم إجراء عملية التسلل بين الضحايا، مما يشير إلى أنه ربما تم نشر بيانات الضحية كمستودع لمستخدم GitHub غير تابع. وهذا يخلق تحديًا كبيرًا للشركات التي تحاول تحديد ما إذا كانت قد تأثرت، حيث ستحتاج إلى الوصول إلى مجموعة البيانات المسربة بأكملها..
وأكدت تغطية قناة Sha1-Hulud وجود أسرار سرقة السحابة. ومع ذلك، فقد لاحظنا أن cloud.json لا يتم ملء الملف المخصص لهذه البيانات فعليًا أبدًا. نظريتنا هي أن افتقار المهاجم إلى try / catch أدت الظروف والدعم السحابي المتعدد إلى حدوث خطأ حيث سيؤدي فشل واجهة برمجة التطبيقات (API) في أي من الخطوات إلى فشل كتلة استخراج سر السحابة بالكامل:
let cloudSecrets = {
aws: { secrets: await awsHarvester.harvestSecrets() },
gcp: { secrets: await gcpHarvester.listAndRetrieveAllSecrets() },
azure: { secrets: await azureHarvester.listAndRetrieveAllSecrets() }
};أخيرًا، هناك قدر لا يصدق من الازدواجية في البيانات المسربة، على سبيل المثال، قد يؤدي تشغيل CI/CD إلى نشر بيانات متطابقة عبر نافذة التعرض. إن استخدام المهاجم لـ Trufflehog يعني أن هناك العديد من الأسرار التي لم يتم التحقق منها في البيانات التي يتم استخدامها لطرد FUD من بعض المعسكرات. ومع ذلك، ما زلنا نرى، كأرضية، آلاف الأسرار المهمة عبر مئات الشركات. كل واحد منها عبارة عن هجوم محتمل في انتظار حدوثه.
تتكون مجموعة البيانات الخاصة بنا من أكثر من 30000 مستودع إجمالي، منها حوالي 70% تحتوي على محتويات مميزة.json، و50% تحتوي على ملفات truffleSecrets.json مميزة (تحمل نتائج فحص trufflehog المحلي)، و80% تحتوي على ملفات بيئة.json (تحمل قيم متغيرات البيئة)، وحوالي 400 ActionSecrets.json متميزة (تحمل أسرار سير العمل).
وفيما يلي بعض الأرقام التي لاحظناها على هذه البيانات:
-
content.json تعد الملفات مصدرًا (كما هو متوقع) لأكثر من 500 اسم مستخدم ورمز مميز لـ GitHub – ويرتبط هذا جيدًا بأعداد إجمالي حسابات موزع GitHub التي أبلغنا عنها في الأقسام أعلاه.
-
truffleSecrets.json تعد الملفات مصدرًا لما يصل إلى 400000 سر فريد (استنادًا إلى القيم الأولية)، ومع ذلك، نظرًا لأن البرامج الضارة لم تستخدم
–only-verifiedالعلم، تم التحقق من حوالي 2.5٪ فقط منها. من بينها، أكثر من نصفها عبارة عن JWTs ذات فترة انتهاء صلاحية قصيرة (25 JWT فقط لا تزال صالحة اعتبارًا من 12/01).
على الرغم من أن البيانات السرية مزعجة للغاية وتتطلب جهودًا مكثفة لإلغاء البيانات المكررة، إلا أنها لا تزال تحتوي على مئات الأسرار الصالحة بما في ذلك السحابة ورموز NPM وبيانات اعتماد VCS. حتى الآن، تشكل أوراق الاعتماد هذه خطرًا نشطًا لمزيد من الهجمات على سلسلة التوريد. على سبيل المثال، لاحظنا أن أكثر من 60% من رموز NPM المسربة لا تزال صالحة.
خلال حادث كبير مثل هذا، نقوم بتتبع التغطية عبر الشركات المتضررة وموردي الأمن والباحثين المستقلين. بالإضافة إلى التحليلات والبيانات الخاصة بنا، نريد تسليط الضوء على المعلومات المفيدة التي تمت مشاركتها في مكان آخر حول هذه الحادثة.
الشركات المتأثرة
-
يوفر تشريح جثة PostHog التفصيلي منظور “المريض صفر”. في هذه المرحلة، تم التأكيد على أن وسيلة الوصول الأولية في هذه الحادثة كانت إساءة الاستخدام
pull_request_targetعبر طلب PWN. -
شارك Postman الرد الأولي، بما في ذلك الجدول الزمني للاحتواء، وتحليل السبب الجذري.
-
قامت AsyncAPI بنشر تقرير ما بعد الوفاة الخاص بها والذي يتضمن الحساب الحصري للعدوى الموازية لامتداد OpenVSX IDE الخاص بها.
-
وقد شاركت الشركات، بما في ذلك Trigger.dev وZapier، التي تأثرت بالحزم الضارة، ما تعلمته أيضًا. تتضمن كتابة Zapier مجموعة قوية من الضوابط التي يمكن للشركات المتأثرة الأخرى أن تتكيف معها من أجل التخفيف والتشديد في المستقبل.
مدونات بائعي الأمن البارزين
-
التحليل الممتاز لأمن أيكيدو؛ وكانوا أيضًا أول من نشر هذه الحادثة على نطاق واسع.
-
مقالة Datadog المكتوبة جيدًا تتضمن تحليل الاتجاهات وتحليل الحمولة المتقدم مع صور رائعة.
-
ركزت أسرار GitGuardian الأولية على التحليل والنظر في أنشطة اختبار المهاجم.
لقد مر عام منذ هجوم Ultralytics، لكن الارتباك حول أمان GitHub Actions لا يزال واضحًا. هناك رسالة واضحة في سلسلة الهجمات التي بلغت ذروتها في Sha1-Hulud: يقوم المهاجمون بإتقان عمليات جمع بيانات الاعتماد باستخدام النظام البيئي npm وGitHub. ونظرًا لتطور المهاجمين المتزايد ونجاحهم حتى الآن، فإننا نتوقع استمرار الهجمات، سواء باستخدام تقنيات TTP مماثلة أو الاستفادة من بيانات الاعتماد التي تم حصادها حتى الآن.
هل تحتاج إلى مساعدة في الرد على Sha1-Hulud؟ تواصل مع فريق الاستجابة لحوادث Wiz للحصول على المساعدة.
