بالأمس وصلتنا رسالة بريد إلكتروني من أحد العملاء. كان موقعه يعرض كازينو إندونيسي بدلاً من صفحة شركته اللوجستية. تلت ذلك 6 ساعات من العمل المكثف في مواجهة منظومة هجوم منظّمة بإحكام. هذه هي قصة ما اكتشفناه، وكيف نظّفنا الموقع، وما تعلّمناه من التجربة.
ماذا حدث
تعرّض أحد مواقع WordPress الخاصة بعملائنا للاختراق في 3 يوليو 2026. دخل المهاجمون عبر ماسح آلي استغل ثغرة معروفة علناً (CVE-2026-63030) في إصدار قديم من WordPress. كان العميل قد تلقّى تذكيراتنا بضرورة التحديث، لكنها بقيت دون ردّ. غير أن الجزء الأكثر إثارة للاهتمام ليس الاختراق نفسه، بل ما فعلوه بعده.
على مدى الأيام الـ66 التالية، بنى المهاجمون بعناية بنية تحتية للبقاء داخل الموقع: عدة منافذ خلفية مستقلة، وتعمية (obfuscation) متقنة، وبنية قيادة وتحكم عبر GitLab وTelegram. وحين أصبح كل شيء جاهزاً فقط، نشروا الحمولة النهائية: استُبدلت الصفحة الرئيسية للموقع بنسخة ثابتة من العلامة التجارية للكازينو الإندونيسي RUBY8000 بهدف التلاعب بمحركات البحث (SEO).
لماذا يهم ذلك
لو تمكّن Google من فهرسة الموقع بحالة الكازينو قبل أن ننظّفه، لتضررت سمعة العميل في محركات البحث لأشهر. يُدرج Google مثل هذه المواقع في القائمة السوداء بسرعة، والعودة إلى الترتيب الطبيعي تتطلب وقتاً طويلاً وطلباً يدوياً عبر Google Search Console.
تشريح الهجوم
عندما بدأنا التحليل الجنائي، أدركنا أننا لا نتعامل مع هاوٍ من فئة script kiddie. كان للهجوم 8 مراحل واضحة يمكن تحديدها، وكانت كل مرحلة مخططاً لها كنسخة احتياطية للمرحلة السابقة:
المرحلة 1 – موطئ القدم الأولي (foothold)
رفع PHP webshell عبر نقطة ضعيفة.
المرحلة 2 – تصعيد الصلاحيات (escalation)
أُنشئ 22 حساب مسؤول في WordPress بأنماط مولَّدة بالجملة (admin_wp2, wpadmin, root_admin…).
المرحلة 3 – الاستمرارية عبر الإضافات (plugins)
زُرعت 4 إضافات خلفية مخفية: core-helper-f6003adcd7, wp2shell_badba2c3, wp2shell-f38e02fa54f1, WP-Compact، بالإضافة إلى إضافة مزيفة لتحسين WebP هي wtec-webp تحتوي على غلاف ALFA_TEAMSHELL مدمج.
المرحلة 4 – باب خلفي عبر Auto_prepend_file
أُدرجت في الملفين .htaccess و.user.ini توجيهات أجبرت على تنفيذ default.php قبل معالجة كل طلب PHP. وحتى لو حُذفت جميع الإضافات، لظلّ الباب الخلفي يعمل.
المرحلة 5 – ملفات index.php مخفية بعمق
أكثر من 15 ملف index.php موزعة في أعماق بنية WordPress (مثلاً wp-includes/theme-compat/plugins/, wp-admin/network/pomo/) مع تعمية قائمة على goto وحمولات base64 تُنفَّذ بـ eval.
المرحلة 6 – نسخة mu-plugins-old الاحتياطية
مجلد mu-plugins بديل يحوي باباً خلفياً من نوع l10n. وقد تنكّر اسمه في هيئة نسخة احتياطية قديمة.
المرحلة 7 – اتصالات C&C
ثلاث قنوات قيادة وتحكم مستقلة: GitLab snippet لتنزيل الحمولة ديناميكياً، وTelegram bot للإشعارات، واتصال HTTP مباشر بخادم المشغّل.
المرحلة 8 – نشر الحمولة (Payload deploy)
استُبدل ملف index.php الخاص بالموقع بالملف index.html الذي يحتوي على نسخة كاملة من كازينو RUBY8000.
أكثر التفاصيل التقنية إثارة للاهتمام – التعمية بالمسافات البيضاء (whitespace obfuscation)
في الملف default.php (77 KB) وجدنا هذه العجيبة:
$dispatcher = ‘ \t \t\t \t\t \t \t \t \t\t\t\t\t\t …’;
$binary = str_replace([‘ ‘, “\t”], [‘0’, ‘1’], $dispatcher);
// كل 8 بتات تُحوَّل إلى رمز:
$decoded = ”;
for ($i = 0; $i < strlen($binary); $i += 8) {
$decoded .= chr(bindec(substr($binary, $i, 8)));
}
eval($decoded); // تشغيل كود PHP بعد فك ترميزه
استخدم المهاجم المسافات وعلامات التبويب كبيانات ثنائية. كل مسافة تمثل 0 وكل علامة تبويب تمثل 1. وكل 8 رموز تشكّل بايتاً واحداً. إنه حل ذكي، لأن:
- عادةً ما تفحص ماسحات مكافحة الفيروسات الآلية الأحرف القابلة للطباعة (printable characters)
- يبدو الملف للعين المجردة كتعليقات فارغة ومنسّقة
- يعثر البحث بـ Grep عن “eval” على موضع واحد فقط في أسفل الشيفرة، وليس على حمولة مشوَّشة (obfuscated payload) بحجم 77 KB
كيف نظّفنا الموقع
كان النهج المعتاد هو الاستعادة من النسخة الاحتياطية. لكن آخر نسخة احتياطية نظيفة لدى العميل كانت أقدم من 66 يوماً، وخلال تلك الفترة تلقّى الموقع الكثير من تحديثات المحتوى المشروعة. لم يكن بإمكاننا ببساطة “إعادة الموقع إلى الوراء” وخسارة كل ذلك العمل.
لذلك اخترنا النهج الجراحي: تحديد كل أثر تركه المهاجم وإزالته بدقة، مع الحفاظ على كل المحتوى المشروع. وذلك على ثلاث جولات:
الجولة 1: التطهير الأولي
باستخدام Bash + wp-cli عبر SSH. عطّلنا وحذفنا 4 إضافات خلفية (backdoor)، وحذفنا default.php وملف .htaccess الذي يحتوي على auto_prepend_file وملف .user.ini. وبواسطة wp-cli حذفنا 22 حساب مسؤول وأزلنا جميع رموز الجلسات (session tokens). وقبل أي تعديل – أخذنا نسخة احتياطية كاملة من قاعدة البيانات كشبكة أمان.
الجولة 2: الفحص العميق
فحص تكراري لملفات PHP في كامل تثبيت WordPress بحثاً عن التواقيع والشذوذات. على سبيل المثال: ملف index.php يتجاوز حجمه 20 KB في عمق WordPress أمر مشبوه. عثرنا على 10 ملفات backdoor مخفية أخرى لم تكن ظاهرة في الجولة الأولى. كما حذفنا مجلد ALFA_DATA مع CGI wrappers و15 ملف .htaccess تابعاً للمهاجم.
الجولة 3: التنظيف عبر WordPress نفسه
استخدمنا تكامل Novamira MCP للوصول المباشر إلى واجهة WordPress API. تحققنا من ملفات نواة WordPress مقابل checksums الرسمية (كلها نظيفة). نظّفنا سجلات قاعدة بيانات TranslatePress من محتوى RUBY8000. ومسحنا ذاكرة التخزين المؤقت لـ Elementor و Varnish HTTP.
تحصين الخادم بعد التنظيف
الموقع النظيف الذي يبقى دون تغيير يشبه باباً مغلقاً بالمفتاح نفسه الذي جرى اختراقه. لذلك عزّزنا الإعدادات:
// إضافات wp-config.php
define(‘DISALLOW_FILE_EDIT’, true); // منع تعديل الإضافات/القوالب من لوحة الإدارة
define(‘AUTOMATIC_UPDATER_DISABLED’, false);
define(‘WP_AUTO_UPDATE_CORE’, ‘minor’); // تحديثات تلقائية لرقع الأمان
define(‘FORCE_SSL_ADMIN’, true); // فرض HTTPS على wp-admin
بالإضافة إلى ذلك، غيّرنا جميع مفاتيح salts في WordPress: AUTH_KEY وSECURE_AUTH_KEY وLOGGED_IN_KEY وNONCE_KEY (ما أجبر أي جلسة متبقية للمهاجم على تسجيل الخروج)، وحظرنا xmlrpc.php، وحميّنا wp-config.php من طلبات HTTP، وفعّلنا حظر تنفيذ PHP في المجلدين wp-content/uploads/ وwp-includes/.
4 دروس خرجنا بها من هذه الحالة
1. تحديثات WordPress ليست “عندما يتوفر الوقت”، بل هي أمر حاسم
كان السبب الأصلي في هذه الحالة بسيطاً: إصدار WordPress قديم. أرسلنا إلى العميل تذكيرات بضرورة التحديث، لكنها بقيت دون رد. فعندما يُعلَن علناً عن ثغرة أمنية في أحد مكوّنات WordPress، تبدأ الماسحات الآلية عملها خلال ساعات قليلة. لذلك يجب إجراء التحديثات خلال أسابيع لا أشهر.
توصية عملية: وقّعوا عقد صيانة مع شريككم في WordPress ينص بوضوح على أن الشريك التقني ينفّذ التحديثات بنفسه دون طلب الموافقة في كل مرة. بهذه الطريقة تتجنبون أن يبقى بريد إلكتروني عن تحديث حرج غير مفتوح لأسابيع.
2. تدوير النسخ الاحتياطية أمر حاسم
كانت لدى العميل نسخ احتياطية، لكنها كانت أقدم من الهجوم. فترة الكمون التي بلغت 66 يوماً تعني أن البرمجية الخبيثة كانت قد دخلت بالفعل جميع النسخ “الحديثة”. ننصح بالاحتفاظ بسجل نسخ احتياطية لا يقل عن 90 يوماً، مع تخزين خارج الموقع (off-site) ونسخ احتياطية غير قابلة للتعديل (immutable).
3. الاحتفاظ بالسجلات (logs) لمدة 7 أيام قصير جداً
لم نتمكن من تحديد نقطة الدخول الأولى بدقة 100%، لأن سجلات الوصول في Nginx كانت تُحفظ 7 أيام فقط. إن الاحتفاظ بالسجلات لمدة 180 يوماً على الأقل ينبغي أن يكون إلزامياً لأي موقع يعالج بيانات شخصية.
4. جدار WAF ليس رفاهية، بل حدٌّ أدنى
كانت على الموقع إضافة أمنية مثبتة، لكن كثيراً من ميزاتها لم تكن مفعّلة. ولربما كان جدار حماية تطبيقات الويب (Web Application Firewall) العامل في الوقت الفعلي، مع تواقيع تهديدات محدّثة ومفعّلة، قد أوقف الماسح الأولي. وإضافة إلى ذلك، فإن المصادقة الثنائية (2FA) لجميع حسابات المسؤولين حدٌّ أدنى إلزامي وليست خياراً.
ماذا تفعل إذا تعرّضت أنت أيضاً لهجوم مشابه
- لا تستعد النسخة الاحتياطية إلا إذا كنت متأكداً من أنها نظيفة. احتفظ أولاً بنسخة من الموقع المخترق كدليل.
- لا تغيّر كلمات المرور من جهاز مخترق. إذا كان على حاسوبك برنامج keylogger، فسيتم اعتراض كلمات المرور الجديدة أيضاً.
- غيّر كلمات المرور من جهاز آخر: لوحة إدارة WordPress، لوحة تحكم الاستضافة، MySQL، FTP/SSH.
- أنهِ جميع الجلسات النشطة وفرض المصادقة الثنائية (2FA) على جميع حسابات المسؤولين.
- تواصل مع متخصص في الأمن. التنظيف اليدوي دون خبرة يترك عادةً جزءاً من الأبواب الخلفية (backdoor) دون معالجة، ويعود الهجوم خلال 2-4 أسابيع.
CERT.LV الإبلاغ الطوعيإذا تعرّض موقعك لحادث سيبراني، يمكنك الإبلاغ طوعاً إلى CERT.LV ([email protected]). ولا يترتب على ذلك أي التزامات إضافية، وقد تساعد مؤشرات الاختراق (IoC) التي تقدمها في تحذير مؤسسات لاتفيّة أخرى من الحملة نفسها.
هل موقع WordPress الخاص بك محمي؟
يقدم قسم الأمن في EvoEX تدقيقاً أمنياً، ومراقبة على مدار الساعة طوال أيام الأسبوع (24/7)، واستجابة طارئة للحوادث. تكلّف الحماية الاستباقية نحو 10% فقط من تكلفة حادث واحد.
تذكّر!
منع الهجمات السيبرانية ليس عملية سريعة أو بسيطة، فهو يتطلب معرفة تقنية عميقة، وزمن استجابة طارئاً، وتوثيقاً للجهات المسؤولة. لذلك ننصحك باختيار خدمة الصيانة التي يقدمها مطوّر WordPress الخاص بك. وإذا لم يكن لديك شريك تقني – تواصل معنا.