اختراق DigiCert — كيف سرق مهاجم 27 شهادة Code Signing عبر ملف Screensaver وفريق دعم فني
الفئة: Cybersecurity – Incident Analysis – Social Engineering – PKI – Supply Chain Attack
اختراق DigiCert — كيف تحوّل ملف Screensaver بسيط إلى أزمة ثقة رقمية عالمية
DigiCert — واحدة من أكبر جهات إصدار الشهادات الرقمية في العالم — تتعرض لاختراق أفضى إلى سرقة 27 شهادة Code Signing استُخدمت لاحقاً لتوقيع برمجيات خبيثة حقيقية.
مقدمة
إذا كانت شركة متخصصة في الأمان الرقمي وإصدار الشهادات الموثوقة تتعرض لاختراق — فما الذي يعنيه ذلك لبقية المؤسسات؟ هذا بالضبط ما كشفت عنه حادثة DigiCert الأخيرة.
الهجوم لم يستخدم ثغرة Zero-Day معقدة، ولم يكن مهاجماً عبقرياً يخترق جدرات نارية. كان أبسط من ذلك بكثير: موظف دعم فني، ملف Screensaver، وخمس محاولات صبورة. والنتيجة كانت أن برمجيات خبيثة حصلت على توقيعات رقمية موثوقة من إحدى أكثر جهات الشهادات مصداقيةً في العالم.
- من هي DigiCert؟ — لماذا الحادثة خطيرة جداً
- سرد الحادثة خطوة بخطوة
- ملف .SCR — لماذا هو أداة هجوم فعّالة؟
- ثغرات استغلّها المهاجم
- حجم الضرر ونتائج الاختراق
- ما هي شهادات Code Signing ولماذا سرقتها خطرة؟
- التأثير على سلسلة الثقة البرمجية
- فشل الـ EDR — الدرس الأكبر
- الدروس المستفادة — ماذا كان يجب أن يحدث؟
- إجراءات عملية لتطبيقها في مؤسستك
- الأسئلة الشائعة (FAQ)
- الخاتمة
- مقالات مرتبطة
1. من هي DigiCert؟ — لماذا الحادثة خطيرة جداً
DigiCert ليست شركة أمان عادية — هي واحدة من أكبر Certificate Authorities (CA) في العالم. وظيفتها الأساسية هي إصدار الشهادات الرقمية التي يثق بها العالم:
- شهادات HTTPS (TLS/SSL): تلك القفل الأخضر في المتصفح يُثبت أن الموقع آمن وموثوق.
- شهادات Code Signing: تُثبت أن برنامجاً صدر من شركة معينة ولم يُعدَّل.
- شهادات البنية التحتية الحرجة: حكومات، بنوك، شركات تكنولوجيا كبرى.
عندما تخترق شركة عادية، تسرق بياناتها. عندما تخترق DigiCert، تحصل على أداة تجعل برمجياتك الخبيثة تبدو موثوقة ومشروعة لنظام التشغيل ولأدوات الأمان. هذا اختراق لسلسلة الثقة بأكملها.
2. سرد الحادثة خطوة بخطوة
الهجوم بدأ بأبسط ما يمكن تخيّله — رسالة في نظام الدعم الفني:
المهاجم تواصل مع موظف دعم DigiCert عبر منصة الدعم الرسمية — يبدو طلباً عادياً تماماً. لا شيء مريب حتى هذه اللحظة.
المهاجم أرسل ملف ZIP يحتوي على ملف بامتداد .SCR (Screensaver). المنصة سمحت بالإرسال — ثغرة الفلترة الأولى.
في المحاولات الأربع الأولى، برنامج الحماية (EDR) رصد الملف وأوقفه. الموظف ربما ظن أنها أعطال تقنية أو ملف مضغوط تالف. المهاجم صبر وكرّر.
في المحاولة الخامسة، الملف نُفِّذ. جهاز الموظف أُصيب. الـ Malware استقر في النظام وبدأ عمله في الخفاء — دون أن يرصده أحد فوراً.
من جهاز الموظف المصاب، تمكّن المهاجم من الوصول إلى أنظمة إصدار الشهادات وسرق 27 شهادة Code Signing مع مفاتيحها الخاصة (Private Keys).
الشهادات المسروقة استُخدمت لتوقيع برمجيات خبيثة — أصبحت الـ Malware تحمل ختم DigiCert الموثوق وتمر عبر أنظمة الأمان بدون إشارة تحذير.
3. ملف .SCR — لماذا هو أداة هجوم فعّالة؟
ملف .SCR (Screensaver) هو في حقيقته ملف تنفيذي (Executable) بامتداد مختلف — يتصرف تماماً كـ .EXE لكنه يُخفي طبيعته خلف اسم "شاشة توقف بريء".
| الجانب | .EXE | .SCR |
|---|---|---|
| الطبيعة | تنفيذي صريح | تنفيذي متنكّر |
| يحجبه Email بشكل تلقائي | نعم — دائماً | ليس دائماً |
| تحذير Windows عند التشغيل | نعم | أحياناً لا |
| يُشغَّل مباشرة بالنقر | نعم | نعم |
كثير من أنظمة الدعم والبريد الإلكتروني تحجب .EXE تلقائياً، لكن تُمرّر .SCR لأنه يبدو "ملف Screensaver". المهاجم يعرف هذه الثغرة ويستغلها. إضافةً لذلك: كثير من المستخدمين لا يعرفون أن .SCR قابل للتشغيل مباشرةً.
4. ثغرات استغلّها المهاجم
المنصة قبلت ملف .SCR داخل ZIP دون رفضه تلقائياً. أي سياسة فلترة صحيحة كانت ستحجب الملفات التنفيذية بكل امتداداتها.
الموظف حاول تشغيل الملف 5 مرات رغم أن الـ EDR منعه 4 مرات. التدريب الأمني الصحيح يُعلّم: ملف مرفوض من الحماية = لا تحاول مجدداً.
جهاز ثانٍ في الشبكة كان مصاباً ولم يرصده الـ EDR. التحقيقات الأولية لم تكتشفه — مما يعني Blind Spot في تغطية الحماية.
موظف الدعم كان لديه وصول — مباشر أو غير مباشر — لأنظمة تفعيل شهادات التوقيع. Least Privilege كان سيُقلّص الضرر.
5. حجم الضرر ونتائج الاختراق
| النتيجة | التفاصيل | الأثر |
|---|---|---|
| 27 شهادة Code Signing مسروقة | مع مفاتيحها الخاصة Private Keys | بالغ الخطورة |
| توقيع Malware حقيقي | برمجيات خبيثة موثّقة رسمياً | يتجاوز أنظمة الحماية |
| إلغاء 60+ شهادة | للتخفيف من الضرر | قد يُؤثر على برامج شرعية |
| جهاز ثانٍ مصاب غير مكتشف | EDR لم يرصده في البداية | يشير لانتشار أوسع محتمل |
6. ما هي شهادات Code Signing ولماذا سرقتها خطرة؟
شهادة Code Signing هي شهادة رقمية تُستخدم لتوقيع البرمجيات — تُثبت للمستخدم ونظام التشغيل أن البرنامج صدر فعلاً من الشركة المُعلنة ولم يُعدَّل منذ توقيعه.
ماذا يحدث عند تشغيل برنامج موقَّع من شهادة موثوقة؟
- Windows يُعرض تحذيراً أخضر: "Publisher: DigiCert Inc." — المستخدم يثق ويُوافق.
- برامج الحماية والـ EDR تُقلّل من شكوكها في البرنامج الموقَّع.
- بعض سياسات AppLocker وApplication Control تسمح بالبرامج الموقَّقة تلقائياً.
- المتجر والمنصات تقبل البرامج الموقَّعة دون فحص مكثّف.
7. التأثير على سلسلة الثقة البرمجية
هذه الحادثة هي مثال صارخ على Supply Chain Attack — هجوم على سلسلة التوريد لا يستهدف المستخدم النهائي مباشرةً بل يستهدف الجهة التي يثق بها المستخدم النهائي.
عندما نثق بـ DigiCert، نثق ضمنياً بكل ما توقّعه DigiCert. المهاجم استغل هذه الثقة المتراكمة — بدلاً من خداع ملايين المستخدمين واحداً واحداً، أقنع جهةً واحدة (DigiCert) فحصل على ثقة الجميع دفعةً واحدة.
- التحقق من توقيع البرنامج لم يعد كافياً وحده — التوقيع يُثبت الهوية، لا السلامة.
- شهادات Code Signing يمكن أن تُسرق وتُستخدم ضد المستخدمين.
- مراقبة قوائم الإلغاء (CRL / OCSP) أصبحت ضرورة، لا خياراً.
8. فشل الـ EDR — الدرس الأكبر
الـ EDR أحسن عمله في البداية — منع الملف 4 مرات. لكن في المحاولة الخامسة حدث الاختراق. وفي مكان آخر من الشبكة، جهاز ثانٍ كان مصاباً ولم يرصده الـ EDR أصلاً.
ماذا يكشف هذا عن الـ EDR؟
- EDR ليس صواباً دائماً بنسبة 100%: يمكن للـ Malware المتطور أن يجد طريقة للتهرب في النهاية.
- التغطية غير المكتملة مشكلة حقيقية: جهاز واحد بدون Agent يمكن أن يُصبح نقطة انطلاق الهجوم.
- الـ EDR أداة، لا حل سحري: يحتاج مراقبة وتحديثاً وفريقاً يستجيب للتنبيهات.
- Visibility ≠ Protection: رصد التهديد لا يعني إيقافه تلقائياً — يحتاج SOC يستجيب.
9. الدروس المستفادة — ماذا كان يجب أن يحدث؟
| ما حدث | ما كان يجب أن يحدث |
|---|---|
| المنصة قبلت ملف .SCR في ZIP | فلترة تلقائية لكل الامتدادات التنفيذية: .exe, .scr, .bat, .cmd, .pif, .vbs, .js, .ps1 |
| الموظف كرّر المحاولة 5 مرات | تدريب: ملف يرفضه EDR = خطر حقيقي، أبلغ فريق الأمان فوراً |
| تغطية EDR ناقصة على جهاز آخر | NDR يراقب الشبكة بغض النظر عن Agent، Inventory كامل لكل الأجهزة |
| وصول موظف الدعم لأكواد الشهادات | Least Privilege: موظف دعم لا يحتاج وصولاً لأنظمة الشهادات |
| لم يُكتشف الجهاز الثاني فوراً | XDR يربط أحداث الشبكة بأحداث الأجهزة — يكتشف الانتشار الجانبي |
10. إجراءات عملية لتطبيقها في مؤسستك
أولاً: فلترة الملفات في منصات الدعم والبريد
قائمة الامتدادات الخطرة الواجب حجبها في كل منصة دعم وبريد إلكتروني:
الامتدادات التنفيذية الخطرة للحجب
.exe .scr .bat .cmd .pif .vbs .vbe .js .jse .wsf .wsh .ps1 .ps2 .msi .jar .hta .com .lnk
ثانياً: سياسة التعامل مع الملفات المرفوضة
- أي ملف يرفضه الـ EDR أو Antivirus → لا تُعيد المحاولة → أبلغ فريق الأمان فوراً.
- أضف هذه القاعدة للـ Security Awareness Training السنوي.
- فعّل تنبيهات تلقائية لأي ملف تنفيذي يُحظر أكثر من مرة على نفس الجهاز.
ثالثاً: التحقق من تغطية الـ EDR
أسئلة يجب الإجابة عنها كل ربع سنة:
فحص نسبة تغطية الأجهزة بالـ EDR (PowerShell + Intune/SCCM)
Get-ADComputer -Filter * | Measure-Object | Select Count
قارن العدد بعدد الأجهزة في قاعدة بيانات EDR — الفرق = Blind Spots
رابعاً: مراقبة Certificate Revocation
- تفعيل فحص OCSP Stapling في متصفحات المؤسسة.
- مراقبة قوائم إلغاء الشهادات (CRL) لكل CAs المعتمدة.
- فحص Signed binaries في بيئتك بعد أي حادثة اختراق تطال CA كبيرة.
11. الأسئلة الشائعة (FAQ)
12. الخاتمة
حادثة DigiCert تُثبت قاعدة ذهبية في الأمن السيبراني: الحلقة الأضعف دائماً هي الإنسان. ليس النظام، ليس الكود، ليس الجدار الناري — بل الموظف الذي يفتح ملفاً للمرة الخامسة بعد أن رفضه الـ EDR أربع مرات.
الدرس الأعمق: Security ≠ Trust. التوقيع الرقمي يُثبت الهوية — لا السلامة. شهادة موثوقة يمكن أن تُسرق وتُستخدم ضدك. في عالم Supply Chain Attacks، الثقة العمياء بأي جهة خطر حقيقي.
تطبيق الإجراءات العملية المذكورة أعلاه — فلترة الملفات، تدريب الموظفين، تغطية EDR الكاملة، Least Privilege — كان سيمنع هذا الاختراق أو على الأقل يُقلّص أثره جذرياً.
13. مقالات مرتبطة
Least Privilege وTier Model — درس مستفاد من هذه الحادثة.
اقرأ المقال ←© 2025 – جميع الحقوق محفوظة | كمبيوترجي — تقنية المعلومات والبنية التحتية