لم يبدأ حادث DigiCert بثغرة تشفير معقدة، بل برسالة دعم بدت عادية. وفق الوصف المنشور في سجل Mozilla، تواصل مهاجم مع فريق دعم DigiCert عبر قناة دردشة للعملاء في 2 أبريل/نيسان 2026، وأرسل ملف ZIP بدا كأنه يحتوي على لقطة شاشة، لكنه أخفى ملفاً تنفيذياً بامتداد .scr يحمل حمولة خبيثة [12]. وهذا الامتداد يرتبط عادة بملفات شاشات التوقف في ويندوز، ما جعله غطاءً مناسباً لهجوم هندسة اجتماعية [
2].
الأخطر لم يكن الملف وحده، بل ما وصل إليه المهاجمون بعد ذلك. فبحسب ThreatNoir، قادت الأنظمة الداعمة المخترقة إلى الحصول على رموز تهيئة لعدد محدود من شهادات توقيع الكود، واستُخدم بعض تلك الشهادات لتوقيع برمجيات خبيثة [1].
كيف تحولت محادثة دعم إلى حادث ثقة
تصف Help Net Security الهجوم بوصفه عملية هندسة اجتماعية موجهة ضد قناة الدعم في DigiCert: ملف مضغوط متنكر في صورة لقطة شاشة، وداخله ملف شاشة توقف خبيث [2].
وتضيف SecurityWeek أن البرمجية الخبيثة أصابت نقطتي نهاية؛ اكتُشفت الأولى في 3 أبريل، بينما لم تُكتشف الثانية إلا في 14 أبريل [10]. ومن أحد الأنظمة المخترقة، انتقل المهاجمون إلى بوابة دعم داخلية [
10]. هناك، كانت لدى محللي الدعم المصادق عليهم وظيفة محدودة تتيح لهم الدخول إلى حسابات العملاء بصفة وكيل؛ ووفق SecurityWeek، أتاحت هذه الوظيفة الوصول إلى وظائف محددة، منها رموز تهيئة لشهادات معلقة [
10].
أما BleepingComputer فيصف النطاق بأنه محدود أيضاً، لكنه يوضح أن الوصول شمل رموز تهيئة لشهادات EV Code Signing كانت قد تمت الموافقة عليها ولم تُسلَّم بعد [5].
لماذا تعد شهادات EV Code Signing هدفاً ثميناً؟
شهادات توقيع الكود تساعد أنظمة التشغيل وأدوات الحماية والمستخدمين على تقييم مصدر البرنامج وسلامته. وDigiCert، باعتبارها سلطة شهادات كبرى، تؤدي دوراً مهماً في تأمين الاتصالات البرمجية وتوزيع البرمجيات؛ كما يستخدم مطورو البرمجيات شهادات توقيع الكود الصادرة عنها [11].
في العادة، تمنح شهادات EV، أي Extended Validation أو التحقق الموسع، مستوى أعلى من الثقة في هوية الجهة المالكة للشهادة. لذلك يحاول المهاجمون استغلالها كنوع من جواز المرور التقني: ملف خبيث، لكنه يحمل توقيعاً يبدو جديراً بالثقة. وتوضح Vectra هذا النمط على نحو عام: يمكن للمهاجمين استخدام شهادات EV لتوقيع ملفات خبيثة والاستفادة من الثقة الإضافية المرتبطة بالتطبيقات الموقعة بهذه الشهادات، ما يجعل المؤسسات التي تعتمد على الثقة القائمة على التوقيع وحده أكثر عرضة للخطر [15].
في حالة DigiCert، لم يكن الخطر أن التوقيع الرقمي أصبح بلا قيمة، بل أن المهاجمين استطاعوا استخدامه ضد المدافعين أنفسهم. فبعض الشهادات التي تم الحصول عليها استُخدمت لاحقاً لتوقيع برمجيات خبيثة [1].
ما الذي لا تثبته التقارير؟
من المهم عدم تضخيم الحادث خارج ما تدعمه المصادر. التقارير المتاحة تتحدث عن نقاط نهاية تابعة للدعم تم اختراقها، ووظائف داخلية في بوابة الدعم، ووصول إلى رموز تهيئة مرتبطة بشهادات توقيع كود [1][
5][
10][
12]. لكنها لا تقدم دليلاً على اختراق مفاتيح الجذر لدى DigiCert أو مفاتيح سلطة الشهادات نفسها.
هذا لا يجعل الحادث بسيطاً. لكنه يعني أن الصورة المعروفة حتى الآن ليست سيطرة كاملة على سلطة الشهادات، بل إساءة استخدام لمسار دعم وإصدار مرتبط بشهادات توقيع الكود [1][
5][
10].
حجم الضرر: لماذا تختلف الأرقام؟
ليست كل المصادر تتحدث عن الفئة نفسها من الأرقام، وهذا يفسر جانباً من الالتباس:
- ThreatNoir يتحدث عن عدد محدود من شهادات توقيع الكود، استُخدم بعضها لتوقيع برمجيات خبيثة [
1].
- Risky Business يذكر 27 شهادة توقيع كود مسروقة استُخدمت لاحقاً لتوقيع برمجيات خبيثة [
8].
- ThreatLocker يذكر أن إجمالي شهادات توقيع الكود التي أُبطلت بلغ 60 شهادة [
3].
لذلك يجب التمييز بين شهادات تم الحصول عليها، وشهادات أسيء استخدامها فعلاً، وشهادات أُبطلت احترازياً أو ضمن نطاق الاستجابة. حتى لو كان النطاق محدوداً، فإن عدداً صغيراً من الشهادات الموثوقة ظاهرياً يكفي لرفع فرص نجاح حملة برمجيات خبيثة [1][
15].
الاحتواء: إبطال الشهادات وإلغاء الطلبات المعلقة
بحسب BleepingComputer، أبطلت DigiCert الشهادات المحددة خلال 24 ساعة من اكتشافها، وجعلت تاريخ الإبطال يعود إلى تاريخ إصدار الشهادة [5]. كما أُلغيت الطلبات المعلقة ضمن الفترة المتأثرة كإجراء احترازي [
5]. وتورد ThreatNoir المعنى نفسه: إبطال الشهادات المتأثرة خلال 24 ساعة، وإلغاء الطلبات المعلقة في نافذة التأثر [
1].
لكن الإبطال لا ينهي عمل فرق الدفاع. فالملفات الموقعة تحتاج إلى تقييم أوسع: بيانات الشهادة، وسلاسل الثقة، والتوقيت، وحالة الإبطال، والهاش، وسلوك العملية، واتصالات الشبكة، وسياق معلومات التهديد. فالمهاجمون يعتمدون تحديداً على أن يرى النظام أو المحلل توقيع EV فيطمئن سريعاً [15].
تشويش إضافي: إنذارات Microsoft Defender الخاطئة
زاد الأمر تعقيداً أن Microsoft Defender تسبب في إنذارات خاطئة حول DigiCert. فقد ذكرت BleepingComputer أن Defender صنّف شهادات DigiCert خطأً على أنها Trojan:Win32/Cerdigent.A!dha [5]. ووفق daily.dev، بدأ Defender في وسم شهادات جذر شرعية تابعة لـ DigiCert بعد تحديث توقيعات في 30 أبريل، ثم أصدرت Microsoft لاحقاً تحديث Security Intelligence رقم
1.449.430.0 لمعالجة المشكلة واستعادة الشهادات التي أُزيلت [7].
بالنسبة للمؤسسات، خلق ذلك مشكلة استجابة عملية: كان على الفرق التمييز بين إساءة استخدام حقيقية لشهادات توقيع الكود، وتنبيهات على برمجيات خبيثة موقعة، وإنذارات خاطئة ضد شهادات شرعية [5][
7].
ما الذي ينبغي أن تفعله فرق الأمن؟
أبرز درس من الحادث ليس أن توقيع الكود لم يعد مفيداً، بل أنه لا يصلح كحكم نهائي بمفرده. عملياً:
- لا تقبل الملف لمجرد أنه موقع. التوقيع، حتى لو كان EV، يجب أن يكون إشارة ضمن مجموعة إشارات، لا تصريح عبور تلقائي [
15].
- افحص تفاصيل الشهادة. المُصدر، الرقم التسلسلي، سلسلة الثقة، الطابع الزمني، وحالة الإبطال كلها عناصر مهمة، خصوصاً عندما يكون الملف الموقّع مشبوهاً؛ ففي حادث DigiCert كان الإبطال وتاريخ الإبطال جزءاً أساسياً من الاحتواء [
5].
- قدّم السلوك على المظهر. راقب ما يفعله الملف: العمليات التي ينشئها، الاتصالات التي يفتحها، آليات الاستمرارية، والنتائج داخل بيئات العزل. البرمجيات الخبيثة الموقعة تستغل الثقة الشكلية تحديداً [
15].
- عامل بوابات الدعم والإدارة كمساحات عالية الخطورة. حتى وظيفة دعم محدودة قد تصبح حساسة إذا منحت وصولاً إلى حسابات عملاء أو رموز تهيئة لشهادات [
10].
- تعامل مع إنذارات الشهادات بهدوء منهجي. ليست كل إشارة من أداة الحماية تعني اختراقاً مؤكداً؛ فقد وُسمت شهادات جذر شرعية تابعة لـ DigiCert خطأً ثم عولجت المشكلة بتحديث من Microsoft [
7].
الخلاصة
حادث DigiCert مهم لأنه كشف كيف يمكن استغلال طبقة الثقة الخاصة بتوقيع الكود ضد المدافعين. المتاح من التقارير يشير إلى حادث محدود نسبياً حول أنظمة دعم ورموز تهيئة وشهادات أسيء استخدامها، لا إلى اختراق مفاتيح الجذر أو مفاتيح سلطة الشهادات [1][
5][
10][
12]. ومع ذلك، فالرسالة واضحة: في الدفاع الحديث ضد البرمجيات الخبيثة، التوقيع الرقمي دليل مهم، لكنه ليس الكلمة الأخيرة.
