كيف تتبعتُ حقنًا خفيًا وقمتُ بتحصين البيئة
تقوم بإجراء فحص للبرامج الضارة. تستبدل الملفات الأساسية. تُحدث الإضافات وتغير كلمات المرور. يبدو الموقع نظيفًا.
بعد يومين، يتصل العميل. عادت حسابات المسؤولين الجديدة. يتم إعادة توجيه الزوار إلى مواقع ضارة.
هذا هو كابوس الاستمرارية (persistence).
غالبًا ما تفشل إضافات الأمان القياسية. المهاجمون المتمرسون لا يكتفون بإسقاط حمولة (payload) واحدة فقط، بل يبنون أبوابًا خلفية (backdoors) متداخلة تختبئ داخل ملفات مشروعة.
تعاملتُ مؤخرًا مع حالة فشلت فيها ثلاث محاولات للتنظيف. كانت الأعراض محددة:
• المسؤولون الأشباح (Ghost Admins): تظهر حسابات جديدة بأسماء عشوائية كل 48 ساعة. • إعادة التوجيه المشروط: الزوار الجدد القادمون من محركات البحث فقط هم من يرون الموقع الضار، بينما لا يرى المطورون شيئًا.
كان الفريق قد استبدل بالفعل نواة WordPress وحدّث الإضافات. لم تظهر الماسحات الضوئية أي شيء. كانت البرمجية الضارة تتجدد مثل وحش الهيدرا.
كان لدى المهاجم آلية استمرارية في قاعدة البيانات أو عبر وظيفة cron job. فاتتها الماسحات الضوئية الآلية لأن الكود كان مخصصًا.
استخدمتُ سطر الأوامر (command line) للوصول إلى الحقيقة.
أولاً، تحققتُ من الملفات الأساسية باستخدام الـ checksums:
wp core verify-checksums
كانت النواة نظيفة. كان الباب الخلفي موجودًا في wp-content أو في قاعدة البيانات.
بحثتُ عن الملفات التي تم تعديلها في آخر 7 أيام:
find . -type f -mtime -7 -name "*.php"
ثم بحثتُ عن دوال مشبوهة مثل eval() أو base64_decode():
grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('
وجدتُ ملفًا مدفونًا في إضافة مدفوعة (premium plugin) قديمة. لكن حذف الإضافة لم يوقف العدوى.
ترك المهاجم محفزًا (trigger) في جدول wp_options تحت خيار cron. في كل مرة يتم فيها تشغيل WordPress cron، كان يجلب حمولة (payload) جديدة. كان يعيد إصابة الملفات الأساسية بعد دقائق من تنظيفها.
لإصلاح ذلك، يجب عليك اتباع ترتيب صارم:
- تنظيف قاعدة البيانات (Database Scrubbing)
- ابحث في
wp_optionsعن بيانات autoload ضارة. - افحص
wp_cronبحثًا عن روابط (URLs) غير معروفة. - استخدم SQL لحذف المستخدمين غير المصرح لهم مباشرة.
- تطهير نظام الملفات (File System Purge)
- احذف كل شيء باستثناء
wp-config.phpوwp-content/uploads/. - استبدل كل شيء بملفات جديدة من المستودع الرسمي.
- احذف أي ملفات PHP داخل مجلد
uploads.
- تدوير بيانات الاعتماد (Credential Rotation)
- أعد إنشاء جميع أملاح المصادقة (authentication salts) في
wp-config.php. - أعد تعيين جميع كلمات مرور قاعدة البيانات، وSSH، والاستضافة.
قمتُ أيضًا بتنفيذ ثلاث ضمانات (guardrails) لمنع تكرار ذلك:
• حماية الحواف: استخدمت Cloudflare WAF لحظر طلبات POST المشبوهة الموجهة إلى المجلدات الحساسة. • أذونات الملفات: قمت بإغلاق هيكل المجلدات؛ حيث أصبحت المجلدات 755 والملفات 644، كما ضبطت wp-config.php ليكون للقراءة فقط. • تعطيل التحرير: أضفت DISALLOW_FILE_EDIT و DISALLOW_FILE_MODS إلى wp-config.php. هذا يمنع أي شخص من تغيير الكود عبر لوحة التحكم.
لا تثق بعلامة الصح الخضراء التي تظهرها الإضافات. افترض حدوث اختراق بالفعل. احمِ موقعك من الداخل إلى الخارج.
المصدر: https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm