NotPetya: أغلى هجوم سيبراني في التاريخ

25 فبراير 2026 • 9 min read

جدول المحتويات

في أواخر يونيو 2017 بدأ في أوكرانيا شيء بدا للوهلة الأولى كأنه “ransomware كالمعتاد”: أجهزة تعيد التشغيل، ملفات تصبح فجأة غير متاحة، ومطالبة بفدية تظهر على الشاشة.

بعد ساعات قليلة أصبح الأمر واضحاً: لم يكن هذا حادثاً محلياً. كان حريقاً واسعاً.

الاسم الذي بقي عالقاً حتى اليوم هو NotPetya. وهو مثال حي على كيف يمكن لما يبدو كـ“موجة مالوير بسيطة” أن يتحول إلى حدث يشل شركات حول العالم ويتسبب بخسائر بمليارات الدولارات.

في هذا المقال أريد أن أربط بين أمرين:

قصة NotPetya: ماذا حدث حينها ولماذا أصبح بهذه الكلفة؟
الجانب العملي: ماذا يعني ذلك للشركات “العادية” اليوم، وليس فقط لشركات Fortune 500؟

الجزء المزعج في NotPetya ليس أنه كان “معقداً جداً”. الجزء المزعج هو: أنه واقعي بشكل مخيف.

لماذا أكتب هذا في 2026؟ لأننا اليوم نتحدث عن هجمات phishing بديب‑فيك مدعومة بالذكاء الاصطناعي، لكن عند وقوع الكارثة ما زلنا نفشل في نفس الأساسيات “المملة” كما في 2017: غياب التقسيم (segmentation) ونسخ احتياطية مرتبطة بنفس شريان الحياة الذي تعتمد عليه بيئة الإنتاج.

NotPetya في 5 دقائق: ماذا حدث؟

لفهم الصورة، نحتاج إلى ترتيب الأحداث.

في 27 يونيو 2017 ظهر NotPetya أولاً في أوكرانيا ثم انتشر بسرعة كبيرة عالمياً. لعبت تحديثات مخترَقة لبرنامج محاسبة شائع في أوكرانيا (M.E.Doc) دوراً مركزياً. لم تدخل المالوير عبر “نقرة غبية”، بل عبر آلية تستخدمها الشركات يومياً: التحديثات.

وهنا نقطة كثيرون يستهينون بها عند النظر للخلف: كان هذا في جوهره هجوم سلسلة توريد (Supply Chain Attack). لم يكن M.E.Doc هدفاً عشوائياً، بل كان رافعة مثالية لأن التحديثات تُمنَح الثقة “افتراضياً”.

درس اليوم غير مريح لكنه مهم: يمكنك ضبط IT الداخلي لديك بشكل ممتاز، لكن إن كانت برمجيات المحاسب/المورد/موصلات ERP أو أدوات طرف ثالث قد تم تلويثها، فأنت ما زلت ضمن دائرة الخطر. مخاطر سلسلة التوريد ليست “مشكلة سحابة”؛ إنها عملياً مشكلة تحديثات.

بمجرد أن دخل NotPetya الشبكة، لم يعد الأمر يتعلق بجهاز واحد بل بـ Lateral Movement:

عبر SMB وثغرات معروفة (بما في ذلك EternalBlue / MS17-010، وهو exploit تسرب من أدوات NSA)، استطاع NotPetya الانتشار إلى أنظمة Windows أخرى دون تفاعل المستخدم.
بالتوازي، استخدم credential dumping (Mimikatz/LSASS) لاستخراج كلمات المرور/الهاشات من الذاكرة (RAM) والتحرك باستخدام صلاحيات أدمن حقيقية.
وللتنفيذ عن بُعد، استُخدمت أدوات أدمن “عادية” (مثل PsExec/WMI). هذه الخلطة خطيرة لأنها قد تبدو في السجلات كأنها “تشغيل طبيعي” في البداية.

هذه كانت “الوصفة السرية”: exploit للانتقال السريع بين الأنظمة، وcredentials من الذاكرة للحصول على الصلاحيات، ثم توسع باستخدام أدوات النظام.

النقطة الأهم: التحديثات (patching) وحدها لم تكن كافية. حتى لو كان النظام محدثاً ضد EternalBlue، كان يمكنه السقوط بمجرد أن تحصل المالوير على credentials/هاشات أدمن صحيحة من مكان آخر داخل الشبكة.

ولم يكتفِ NotPetya بذلك، بل لعب أيضاً بعامل الوقت: وضع تأخيراً ولم يُجبر “الانفجار الكبير” (reboot/wipe) فوراً، بل بعد مدة. هذا يجعل الاكتشاف أصعب، وهو أيضاً نمط كلاسيكي ضد sandboxes: المالوير لا “ينفجر” مباشرة بينما في الخلفية يكون قد بدأ بالانتشار.

والنتيجة هي ما نراه دائماً في مثل هذه الحوادث:

في البداية تبدو بعض الأنظمة “غريبة”.
ثم ينهار موقع كامل فجأة.
وإذا لم تتصرف بسرعة كبيرة (فصل الشبكات، إيقاف الحسابات، إغلاق حدود التقسيم)، يمكن أن يمتد الحادث بين المواقع.

لماذا كان “ransomware” مجرد تمويه؟

اعتُبر NotPetya في كثير من الأماكن ransomware لأنه عرض مطالبة بفدية. لكنه تقنياً وعملياً كان شيئاً آخر.

النقطة الحاسمة: NotPetya كان في الواقع wiper. هدفه ليس “الربح”، بل تدمير الأنظمة وإيقاف التشغيل.

قد يبدو هذا تدقيقاً لغوياً، لكنه في الحوادث فرق ضخم:

في ransomware التقليدي قد توجد (أحياناً) فرصة لاسترجاع البيانات عبر مفاتيح أو تفاوض.
في wiper الهدف هو “التحطيم”. دفع Bitcoin لا يساعدك.

وفي NotPetya توجد تفاصيل تقنية تؤكد ذلك: قام بكتابة MBR (Master Boot Record) من جديد وبتشفير MFT (Master File Table). وحتى آلية “ransomware” نفسها كانت معطوبة: كان installation ID المعروض يُولَّد عشوائياً ولم يكن مرتبطاً بشكل صحيح بمفتاح فك تشفير قابل للاستخدام. بمعنى آخر: تقنياً لم يكن هناك طريق عودة تقريباً.

لهذا كان NotPetya خبيثاً: دفع كثيراً من الشركات إلى تشغيل “خطة ransomware”، بينما المطلوب فعلياً كان “خطة disaster recovery”.

كما أن كون الهجوم موجهاً للتخريب أكثر من الربح يتوافق مع التقييمات اللاحقة: عدة حكومات نسبت NotPetya علناً إلى جهات روسية مدعومة من الدولة.

10 مليارات دولار: لماذا كانت التكلفة بهذا الحجم؟

إذا نظرت فقط إلى ملصق “ransomware”، تبدو الخسائر غير منطقية: “نستعيد من النسخ الاحتياطية وخلاص”.

في الواقع، كان NotPetya مكلفاً لأنّه ضرب نقطة يتم إهمالها في كثير من الميزانيات: التوافر (availability).

أكبر كتلة تكلفة لم تكن المالوير نفسها، بل التوقف.

خطوط الإنتاج تتوقف.
اللوجستيات تعود إلى الورق.
الهويات والدومينات تُعاد من الصفر.
التطبيقات والتكاملات والاعتماديات تنهار تباعاً.
وكل ذلك يحدث في أنظمة عديدة في الوقت نفسه.

لهذا يُوصَف NotPetya كثيراً بأنه “أغلى هجوم سيبراني في التاريخ”. وتُقدَّر الخسائر الإجمالية بحوالي 10 مليارات دولار أمريكي.

كما يظهر ذلك في تقارير شركات بعينها: Merck وFedEx (بما في ذلك TNT Express) وMondelez وصفوا بوضوح أن الهجوم لم يكن “موضوع IT” فقط، بل موضوع أعمال أثّر على الإيرادات والتكاليف والقدرة على التسليم.

وكان لـ NotPetya أيضاً تبعات قانونية كبيرة: شركات دخلت في نزاعات مع شركات التأمين. بعض شركات التأمين حاولت عدم الدفع باعتباره “Act of War” (أي هجوم موجَّه من دولة). من أشهر الأمثلة نزاع Mondelez مع شركة التأمين. درس اليوم واضح: هل تغطي بوليصة التأمين السيبراني هجمات الدول، أم أن War Exclusion ستمنع التعويض في أسوأ وقت؟

تحديث للقراء المتقدمين: تم حسم قضية Mondelez في 2023. وبعد ذلك (وبشكل عام بعد NotPetya) قامت الصناعة بتشديد الكثير من الصياغات: في كثير من الوثائق أصبحت الهجمات “state‑motivated” تُعرّف بشكل أضيق أو تُستثنى صراحة. هذا يجعل التأمين السيبراني مخاطرة مالية حقيقية إن لم تُفهم البنود جيداً.

ولا يجب التقليل من الاعتماديات: حتى لو كنت “تستعيد IT فقط”، فإن الواقع مليء بتشابكات تعيق التعافي.

قصة Maersk مثال معروف: لم تكن المسألة “بعض الملفات”، بل إعادة بناء أنظمة جوهرية وهويات وIT تشغيلية كي تعود الموانئ واللوجستيات للعمل.

والقصة أصبحت أسطورية: Maersk فقدت تقريباً كامل Active Directory عالمياً — باستثناء Domain Controller واحد في غانا كان خارج الخدمة بسبب انقطاع كهرباء وقت الهجوم. هذا “Lucky Punch” تحوّل إلى نسخة احتياطية offline غير مقصودة: بفضل ذلك الخادم الفيزيائي الوحيد استطاعوا إعادة بناء AD العالمي وتسريع التعافي.

وفي النهاية، لا يتضرر “الـIT” فقط، بل يتضرر العمل مباشرة:

في الغذاء: الإنتاج والتخطيط وسلاسل الإمداد تتوقف.
في الشحن البحري: الحاويات لا تتحرك.
في الأدوية: التصنيع والجودة والقدرة على التوريد تحت ضغط.

لذلك الرقم كبير: شاشة الفدية مجرد عرض، والضرر الحقيقي هو التوقف.

سيناريو عملي: الهجوم الذي أتوقعه لدى شركة “عادية”

أريد أن أصف حالة لا تبدو “هوليوودية”. ليس “دولة ضد شركة تقنية”، بل سيناريو واقعي لشركة متوسطة.

تخيل شركة متوسطة:

موقع رئيسي وموقع ثانٍ صغير.
بيئة Windows تقليدية: AD، ملفات، VMs، ERP.
إضافة إلى أنظمة لا يقترب منها أحد: تحكم آلات، برمجيات قديمة، “Windows Server 2008 شيء ما”.
نسخ احتياطية: يومياً إلى NAS، وأسبوعياً إلى نظام ثانٍ.

وهنا تأتي النقطة التي تُستهان بها غالباً:

هذه الشركة ليست “ضعيفة” لأن الجميع غير كفؤ. بل لأن التشغيل والوقت ينتصران دائماً.

التحديثات تؤجل لأن الإنتاج مشغول. التقسيم يُرحَّل إلى “لاحقاً” لأن VLANs عمل إضافي. كلمات مرور الأدمن المحلية “تاريخية”. وNAS متصل بالشبكة لأنه بدون ذلك يكون الاسترجاع مزعجاً.

الخط الزمني (واقعي، دون دراما)

في صباح الثلاثاء يدخل تحديث. قد يكون مورداً أو أداة مزود خدمة أو موصلاً — أي شيء يحدث تلقائياً. أو نظام شريك مخترَق لديه وصول عبر VPN.

08:10: أول عملاء يصبحون غير مستقرين.
08:25: أول خادم ملفات يصبح بطيئاً.
08:40: “الدومين غريب”: تسجيل الدخول بطيء وGPOs تخلط.
09:00: أدمن يسجل دخول “ليتحقق بسرعة” — وغالباً هنا يتسارع lateral movement.
09:20: موقع كامل يصبح فعلياً offline.

والآن جزء لا يُفهم بالكامل إلا لاحقاً:

إذا لم تفصل بقوة في تلك اللحظة، فإن الضرر لا ينمو خطياً بل بشكل أُسّي.

ثم يأتي السؤال المعتاد:

“هل ندفع؟”

مع NotPetya كانت الإجابة مؤلمة: حتى لو أردت، غالباً لن يكون الدفع حلاً. نفسياً يجب التحول مباشرة إلى “إعادة بناء” وليس “فك تشفير”.

كلما انتظرت، زادت الأنظمة التي يجب إعادة بنائها. وكلما زادت، طال وضع الطوارئ. وكلما طال، زادت التكلفة.

ما الذي يؤلم حقاً

بعد ساعات، يصبح واضحاً: هذا ليس “نستعيد بعض الملفات”. بل “نعيد بناء Active Directory والأنظمة الأساسية”.

ثم تكتشف:

النسخ الاحتياطية كانت متصلة وأصيبت.
التوثيق غير محدث.
لا توجد “golden images” كافية لإعادة تهيئة سريعة.
بيانات الأدمن كانت منتشرة.
لا أحد تدرب على عزل موقع خلال 30 دقيقة.

هنا يتحول حادث IT إلى أزمة شركة.

ما الذي يفعله SOC اليوم بشكل مختلف (وأين يدخل الذكاء الاصطناعي؟)

في SOC كبير تدخل يومياً مليارات الأحداث من مصادر كثيرة. لم يعد الأمر “أدمن ينظر إلى سجل firewall”، بل عملية صناعية: حساسات، ترابط، أتمتة، وتحليل بشري.

تقسيم الأدوار مثير للاهتمام:

الذكاء الاصطناعي/الأتمتة كخط أول: يفرز ويربط ويكتشف الأنماط ويصفّي الواضح.
البشر كخط ثانٍ/ثالث: عند الحالات الحرجة أو غير الواضحة يتولى المحللون القرار والتنسيق.

قد يبدو هذا “للكبار فقط”، لكن الفكرة مهمة حتى للصغار:

لا تحتاج لبناء SOC. لكن تحتاج لنفس العقلية:

اجمع إشارات (EDR، firewall، سجلات الدخول).
عرّف ما هو “طبيعي”.
وامتلك عملية تستجيب خلال دقائق لا أيام.

NotPetya كان سريعاً جداً في 2017 لدرجة أن الإنسان لم يكن ليلحق به بمجرد بدء الانتشار. لذا قيمة الذكاء الاصطناعي ليست “أسرع” فقط، بل اكتشاف الشذوذ أبكر وسط الضوضاء (مثلاً: الساعة 03:00 فجأة 500 جهاز يريد التحدث عبر SMB). هذه الدقائق تحسم: ترى مبكراً، تحد مبكراً، تعزل مبكراً.

ويوجد أيضاً mindset أصبح شائعاً:

Assume breach.

خطط وكأن المهاجم موجود بالفعل. ليس بدافع الهلع، بل بدافع الواقعية.

ما أعتبره الحد الأدنى اليوم (بدون ميزانية Enterprise)

إن أردت أخذ فكرة واحدة من NotPetya، فلتكن هذه:

NotPetya لم يكن “ثغرة واحدة”. كان سلسلة ضعف تضاعفت معاً.

والخبر الجيد: لهذا السبب أيضاً تستطيع إزالة قدر كبير من الخطر ببعض الأساسيات.

1) إدارة التحديثات والتعرض (بجدية)

تحديثات Windows الحرجة (خصوصاً حول SMB) لا يمكن تأجيلها “لوقت لاحق”.
كل ما هو مكشوف للخارج له الأولوية.
وإن كان لديك Legacy: فعلى الأقل معزول ومقسّم بقواعد واضحة.

2) جعل Lateral Movement مؤلماً

فصل حسابات الأدمن (يومي vs أدمن).
كلمات مرور أدمن محلية فريدة لكل جهاز (LAPS).
عدم ترك WMI/PsExec مفتوحين في كل مكان.
تقييد SMB حيث لا يلزم.

3) التقسيم، لكن بواقعية

لا تحتاج Zero Trust “مثالي” فوراً. لكن:

العملاء، الخوادم، النسخ الاحتياطية، وOT/الإنتاج لا يجب أن يكونوا في شبكة مسطحة.
Domain Controller هو Tier 0 ويجب حمايته وفق ذلك.
حركة east‑west تحتاج اهتماماً مثل حركة الإنترنت.

4) النسخ الاحتياطية: offline، immutable، ومختبرة

سأقولها كما أراها كثيراً:

نسخة احتياطية متصلة وقابلة للكتابة دائماً غالباً ليست نسخة احتياطية وقت الأزمة.

3-2-1 بداية جيدة.
التخزين غير القابل للتغيير (immutable) أو الوسائط offline يغيّر اللعبة.
اختبارات الاسترجاع إلزامية.

5) Runbooks وخطة “Kill Switch” للمواقع

لا تحتاج كتيباً من 80 صفحة. لكن تحتاج وضوحاً:

من يقرر فصل موقع؟
كيف تغلق الحسابات بسرعة؟
ما الذي يعود أولاً (AD, DNS, DHCP, VPN, ERP)؟

ونعم: هذا يحتاج تدريباً.

Reality‑check: في NotPetya، أفضل إجراء في كثير من الحالات لم يكن “أداة جديدة”، بل الفصل الفيزيائي. هناك روايات أن موظفين في Maersk ركضوا عبر المكاتب وسحبوا كابلات الطاقة/الشبكة من السويتشات لإيقاف الانتشار. يبدو بدائياً، لكنه أحياناً أفضل “High‑Tech Security” عندما تحسم الثواني.

الخلاصة

بالنسبة لي، NotPetya ما زال أحد أفضل الأمثلة على أن الأمن لا يُحل بجملة “لدينا مضاد فيروسات”.

لم يكن كارثياً لأنه كان سحرياً. بل لأنه ضرب نقاط ضعف عادية جداً:

الثقة بالتحديثات
lateral movement السهل
نقص التقسيم
نسخ احتياطية قريبة جداً من شبكة الإنتاج

ولهذا هو مهم جداً للشركات “العادية”.

إذا استثمرت اليوم، فاستثمر في القدرة على الصمود: الرؤية، الاستجابة السريعة، والقدرة على الاسترجاع النظيف. هذا هو الفارق بين “يوم سيئ جداً” و“ربع سنة لا تعوضه”.

مصادر وروابط إضافية

حتى المرة القادمة، جو