مجموعة الابتزاز FulcrumSec حوّلت رمز GitHub مُثبّتاً في الكود إلى اختراق 1.3 تيرابايت لدى نوفو نورديسك

كيف وقع الاختراق

تعتمد طريقة FulcrumSec، التي يُقال إن المجموعة نفسها أطلقت عليها اسم “Hardcoded Horrorshow”، على فئة ثغرات حذّرت منها فرق الأمن لسنوات باعتبارها قابلة للتجنب بشكل كبير ومستمرة الحدوث بعناد في آن واحد: بيانات اعتماد مُضمّنة مباشرة في الكود الذي يصل إلى المستخدمين النهائيين. وفق التقارير عن الحادثة، عثرت FulcrumSec على رمز وصول شخصي لبيئة Azure DevOps الخاصة بنوفو نورديسك داخل حزمة جافاسكريبت على أحد المواقع العامة للشركة، إلى جانب بيانات اعتماد إضافية وُجدت في كود جانب العميل على موقع ثانٍ.

ولأن ذلك الرمز كان رمز وصول شخصي صالحاً على GitHub، تمكّنت FulcrumSec من استخدامه مباشرة للوصول إلى مئات المستودعات الخاصة لنوفو نورديسك — دون تصيد، ودون نشر برمجيات خبيثة، ودون استغلال ثغرة برمجية بالمعنى التقليدي. كانت بيانات الاعتماد نفسها هي سطح الهجوم بأكمله. كود جافاسكريبت جانب العميل يُحمَّل وينفَّذ، بحكم تعريفه، من قِبل أي شخص يزور الصفحة، مما يعني أن أي سرّ مُضمَّن فيه يصبح عملياً علنياً لحظة نشر الصفحة، سواء لاحظه أحد فوراً أم لا.

الحجم والجدول الزمني

بدأت FulcrumSec ممارسة الضغط على نوفو نورديسك في يونيو 2026، وقضت، وفق التقارير عن عمليات المجموعة، نحو شهرين داخل شبكات الشركة قبل سحب البيانات. سحبت المجموعة في النهاية نحو 1.3 تيرابايت من المواد، بما فيها أبحاث أدوية ومعلومات تجارب سريرية ونماذج ذكاء اصطناعي داخلية — نوع الملكية الفكرية التي تترتب على فقدانها عواقب تتجاوز بكثير اختراق بيانات عملاء نموذجي لشركة أدوية في خضم تطوير أدويتها.

عندما رفضت نوفو نورديسك مطلب ابتزاز بقيمة 25 مليون دولار، نشرت FulcrumSec أكثر من تيرابايت من البيانات المسروقة وبدأت استكشاف بيع خاص للأصول المتبقية، وفق التقارير نفسها. نموذج عمل المجموعة — ابتزاز بيانات حساسة بدلاً من تشفير الأنظمة — يتجنب التعطيل التشغيلي الذي تسببه برمجيات الفدية التقليدية، ويراهن بالكامل بدلاً من ذلك على حساسية ما سُرق لإجبار الدفع.

لماذا يستمر حدوث هذا

بيانات الاعتماد المُثبّتة في الكود من أكثر فئات الثغرات ذِكراً باستمرار في أبحاث أمن المؤسسات، تحديداً لأن نمط الفشل بسيط جداً: يُضمّن مطوّر رمزاً أو مفتاحاً أو كلمة مرور مباشرة في الكود المصدري — غالباً للتسهيل أثناء الاختبار أو لأن عملية البناء لم تُهيّأ لحقن الأسرار وقت التشغيل — لينتهي به الأمر إما في الإنتاج أو في مستودع عام. خلافاً لثغرة يوم الصفر، هذه ليست تقنية هجوم متطورة؛ إنها أقرب إلى ترك مفتاح احتياطي تحت سجادة الباب مع لافتة تشير إليه.

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

ما ينبغي لفرق الأمن استخلاصه من هذا

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

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

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

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

• Novo Nordisk hack: FulcrumSec claims $25M extortion attempt — Yahoo Finance
• Novo Nordisk Data Breach Tied to Stolen GitHub Access Tokens — BankInfoSecurity