نتيجة عميل موثقة
القطاع: القطاع محجوب حفاظًا على سرية العميل
استعادة نظام ERP حين احتفظت الملفات المشفّرة بأسمائها
- AX 2012 R3
- SQL Server 2012
- PowerShell
- T-SQL / SqlBulkCopy
- Hyper-V
- Active Directory
- Kali Linux
- SHA-256
مدة التنفيذ: نحو خمسة أسابيع من الفحص الأولي حتى التسليم
نظرة عامة
بعد أربعة أشهر من تشفير نظام ERP الذي تدير به إحدى الشركات أعمالها في هجوم فدية، وبعد عدة محاولات إصلاح، كان النظام لا يزال متوقفًا. وكان مقاول سابق قد أنشأ نسخًا نظيفة من قواعد بياناته، لكن على إصدار أحدث من SQL Server لا يستطيع النظام استخدامه؛ فنقلنا هذه البيانات إلى الإصدار الذي تحتاجه هذه البيئة، وأعدنا بناء النظام على بنية تحتية نظيفة ومعزولة، وسلّمناه وهو يعمل بعد التحقق من بيانات الأعمال.
التحدي
لم يكن هناك مفتاح لفك التشفير، وكانت كل النسخ الاحتياطية الأصلية لقاعدة البيانات مشفّرة، وبعد محاولات الإصلاح السابقة لم يعد ممكنًا الوثوق بأي ملف على الأقراص دون فحصه. كما أن برنامج الفدية شفّر بعض الملفات دون أن يغيّر أسماءها، فظل الاسم مألوفًا بينما استُبدل المحتوى. والاعتماد على أسماء الملفات كان سيعني إعادة البناء فوق قاعدة بيانات لا تزال مشفّرة، واكتشاف ذلك بعد أيام من العمل. أما النسخ النظيفة والكاملة الوحيدة فكان مقاول سابق قد أنشأها على SQL Server 2025، في حين كانت بيئة هذا النظام مرتبطة بـ SQL Server 2012، ولا يتيح SQL Server أي طريقة مدعومة لنقل قاعدة بيانات إلى إصدار أقدم.
الحل
أبقينا الأقراص الأصلية في وضع القراءة فقط، وفحصنا كل ملف مرشّح من خلال البايتات الأولى في ترويسته لا من خلال اسمه: فلصفحة SQL Server السليمة توقيع معروف، أما الملف المشفّر هنا فكان يبدأ بالعلامة RAWR. وأثبت هذا الفحص أن قاعدة بيانات الأعمال الأصلية بحجم 23 GB مشفّرة، بينما كانت نسخة منفصلة بحجم 15.4 GB سليمة، وأن قرصًا افتراضيًا للنسخ الاحتياطي بحجم 1.09 TB مشفّر هو الآخر. ثم استخرجنا 74 GB من الملفات المستهدفة مع سجل بصمات SHA-256، وأعدنا بناء نطاق Active Directory وطبقة SQL Server وطبقة تطبيق ERP على خادم Hyper-V جديد معزول عن الشبكة. وحين تعطّلت أداة SqlPackage القياسية أمام حجم مخطط قاعدة البيانات، نقلنا البيانات إلى SQL Server 2012 عبر جسر PowerShell مخصّص يولّد المخطط بلغة T-SQL وينقل الصفوف جدولًا تلو الآخر عبر SqlBulkCopy. وقد كُتب هذا الجسر بمساعدة الذكاء الاصطناعي تحت إشراف هندسي مباشر، وأعداد السجلات الواردة في النتائج أدناه مأخوذة من البيانات التي نقلها. وكانت عملية full compile سابقة قد انهارت، فتتبّعنا السبب حتى عنصر بيانات وصفية تالف واحد، وشغّلنا AXBuild بإعدادات صحيحة ليعيد توليده بدلًا من استبداله من نسخة مرجعية، وهو ما كان سيمحو تخصيصات العميل، ثم تحققنا من تطابق النتيجة مع ذلك المرجع بايتًا ببايت. وقبل عملية full compile، ثم قبل توليد CIL، أخذنا نسخًا احتياطية مزوّدة بـ checksum وتحققنا من سلامتها. وعندما تبيّن أن ثلاثة جداول تحتوي على صفوف أعمال مكررة توقفنا، لأن إضافة المفاتيح الناقصة كانت تتطلب إزالة التكرار أو إعادة ترقيم بيانات الأعمال، وهو ما لا يسمح به نطاق العمل المكتوب. وقد نفّذنا أعمال استعادة بيانات بعد هجمات فدية لأربع مؤسسات.
النتائج
عند التسليم كانت الأجهزة الافتراضية الخمسة تعمل، وخادم تطبيق ERP في وضع التشغيل. وجرى التحقق من بيانات الأعمال داخل النظام المستعاد: بلغ عدد سندات القيد في دفتر الأستاذ العام 268,921، وعدد العملاء 432، وعدد الأصناف 1,902، وتمتد البيانات حتى آخر أمر بيع سُجّل يوم الهجوم. ونُقلت قاعدة بيانات الأعمال (6,960 جدولًا) وقاعدة بيانات model الخاصة بالتطبيق (48 جدولًا) إلى SQL Server 2012. ولإثبات أن النظام قابل للاستخدام لا للقراءة فقط، أنشأنا عميلًا وصنفًا تجريبيين من واجهة ERP ثم تأكدنا من وجودهما في قاعدة البيانات. كما قدّمنا وثائق التسليم الرسمية.
القياس والأدلة
أعداد السجلات مأخوذة من تصدير حالة النظام عند التسليم. أما أحجام الملفات وأعداد الجداول وباقي أرقام هذا المشروع فمصدرها نتائج الفحص الأولي وملاحظات التسليم وسجل استعادة مكتوب يُحيل كل نتيجة إلى دليلها، ويستند إلى 81 ملف دليل مؤرّخًا. النسخ النظيفة من قواعد البيانات على SQL Server 2025 أنشأها مقاول سابق قبل بدء هذا العمل، ومن تلك النقطة بدأ عملنا. هذا عمل استعادة بيانات وليس تحقيقًا جنائيًا رقميًا لأغراض قانونية. ولا تُثبت الأدلة الموثقة اكتمال مرحلة CIL النهائية ولا خدمات التقارير ولا لوحة Role Center، لذلك لا ندّعي أيًا منها هنا، ولا ندّعي كذلك تسليم بيئة إنتاج محصّنة. كما تُركت عمدًا دون إصلاح 12 خطأً في البيانات الوصفية ظهرت أثناء compile، وكانت قائمة مسبقًا أو تخص عناصر مخصّصة. اسم العميل وقطاعه والخوادم والتواريخ محجوبة.