التحقيق الجنائي الرقمي وتطهير ووردبريس صغرة كلمة المرور

التحقيق الجنائي الرقمي وتطهير ووردبريس صغرة كلمة المرور

📅 August 27, 2026⏱️

التحقيق الجنائي الرقمي وتطهير ووردبريس: الدليل العملي الكامل لعلاج اختراق حقن روابط الكازينو والسيو الخبيث (SEO Spam Injection)

تُعد هجمات السيو الخبيث (SEO Spam Injection أو ما يُعرف بـ Parasite SEO) من أخطر وأخبث التهديدات الأمنية التي تواجه المواقع الإلكترونية المبنية على منصة ووردبريس (WordPress). على عكس الهجمات التخريبية التقليدية (Defacement) التي يسعى المهاجم من خلالها إلى إسقاط الموقع أو تغيير صفحته الرئيسية لإثبات وجوده، يتسم هجوم الـ SEO Spam بطابعه الاستغلالي الصامت؛ إذ يحرص المخترقون على إبقاء الموقع يعمل بكفاءة وسرعة ظاهرية لأسابيع وربما لأشهر، مستغلين سمعة النطاق وقوته لدى محركات البحث لضخ مئات أو آلاف الصفحات والمقالات التي تروج لمواقع المراهنات والكازينوهات عبر الإنترنت وروابط الاحتيال المالي.
يستعرض هذا الدليل الشامل مسار تحقيق جنائي رقمي واقعي ومكتمل الأركان، يوثق بالتفصيل كيفية اكتشاف حقن المقالات الخبيثة، وتتبع سجلات الخادم (Server Access Logs) خطوة بخطوة، والوصول إلى الباب الخلفي (Backdoor)، وفهم آلية زرع التطبيقات المصرح بها (Application Passwords)، ثم تنفيذ خطة استئصال جذرية تسد الثغرات وتمنع تكرار الهجوم على مستوى نظام إدارة المحتوى والخادم وخوادم البروكسي العكسي (Nginx / Cloudflare).

1. التشريح التقني لهجمات SEO Spam و Parasite SEO

لفهم خطورة الهجوم، يجب أولاً إدراك العقلية الاقتصادية للمهاجم؛ فالمخترق هنا ليس هاوياً يسعى للتخريب، بل جزء من شبكة ترويج تجارية غير قانونية تسعى لتخطي خوارزميات مكافحة السبام في Google و Bing عبر استغلال النطاقات القديمة والموثوقة (High Domain Authority).
[ شبكة المهاجم C2 Server ] 
         │
         ▼ (استغلال ثغرة أو تخمين بيانات دخول)
[ تسجيل دخول ناجح إلى ووردبريس ] 
         │
         ├───► رفع إضافة ملغومة (Webshell / Backdoor)
         ├───► إنشاء حسابات مدراء خفية (Service Bots)
         └───► توليد كلمات مرور التطبيقات (Application Passwords)
         │
         ▼ (أتمتة دورية مجدولة)
[ ضخ مئات مقالات الكازينو برمجياً عبر REST API / Backdoor ]
         │
         ▼
[ فهرسة الروابط الخبيثة في جوجل واستغلال سمعة النطاق ]

لماذا يتجنب المهاجم إتلاف الموقع؟

  • الحفاظ على التخفي (Stealth Persistence): عند تعطل الموقع، يهرع المدير التقني فوراً لاسترجاع نسخة احتياطية (Backup) أو فحص السيرفر، مما يغلق وصول المهاجم سريعاً. أما عند بقاء الموقع حياً، فإن المقالات الخبيثة تُنشر في مسارات فرعية غير معروضة في القوائم الرئيسية.
  • تمرير قوة الروابط (Link Juice Flow): يتطلب رفع ترتيب مواقع القمار في نتائج البحث بقاء الروابط المنشورة على موقعك مفهرسة ومستقرة في خوادم Googlebot لأطول فترة ممكنة.
  • الأتمتة الشاملة (Botnets): بمجرد تثبيت نقطة الوصول، يتم نقل بيانات الاتصال إلى منصات أتمتة مركزية تتولى النشر المجدول وإعادة بناء الأبواب الخلفية تلقائياً في حال حذفها يدوياً بشكل غير مكتمل.

2. العلامات والمؤشرات الأولية للاختراق (Indicators of Compromise – IoC)

بدأت مؤشرات الهجوم بملاحظة نشر مقالات بلغات متعددة (التشيكية، الروسية، السلوفاكية، الفرنسية وغيرها) تتعلق بمراجعات الكازينوهات وتطبيقات الرهانات الرياضية.

أبرز مؤشرات الاشتباه التي تم رصدها:

  1. ظهور مقالات مجهولة في لوحة التحكم: مقالات منشورة بحالة Published دون أي تسجيل لمؤلف محدد، حيث كانت خانة الكاتب تحمل القيمة Author = 0 بدلاً من أسماء المدراء المشروعة.
  2. تطبيقات مجهولة في الملف الشخصي (Application Passwords): وجود مفاتيح REST API بأسماء بوتات مثل sentinel، و auto-bootstrap، و auto-job-a41d50 مقترنة بعناوين IP خارجية مشبوهة استُخدمت لضخ المحتوى عبر الـ API.
  3. وجود إضافات غير مألوفة في النظام: رصد إضافات مريبة في قائمة الإضافات البرمجية أو ملفات في مسار المحتوى لم يتم تثبيتها بواسطة مالك الموقع، مثل إضافة باسم easypost برقم إصدار غير قياسي.

3. منهجية التحقيق الجنائي الرقمي (Server Forensics)

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

الخطوة الأولى: تحديد المسار الحقيقي لسجلات الخادم (Access Logs)

في بيئات الاستضافة المدارة مثل Virtualmin أو Nginx vhosts، لا تكون السجلات مخزنة في المسار الافتراضي العام /var/log/nginx/access.log، بل في ملفات خاصة بكل نطاق فرعي (Virtual Host).
يمكن تحديد المسار الدقيق لملف السجل عبر فحص إعدادات Nginx:

Bash

grep -rn "access_log" /etc/nginx/sites-available/
أظهر الفحص أن سجلات النطاق المستهدف (wp.3wda.net) تُكتب داخل المسار المخصص:
/var/log/virtualmin/wp.3wda.net_access_log

الخطوة الثانية: فحص المؤلف في قاعدة البيانات عبر WP-CLI

باستخدام أداة سطر الأوامر الخاصة بووردبريس (WP-CLI)، تم استخراج قائمة المنشورات المشبوهة للتعرف على هوية المستخدم المسؤول عن النشر:

Bash

wp post list --post_status=publish --fields=ID,post_title,post_author,post_date --allow-root | grep -E "Casino|1win" | head -n 10
نتيجة الفحص:

Plaintext

226   Hotel Algarve Casino – análise completa, bônus e jogos   0    2026-08-09 05:34:22
225   Пин Ап Казино - Официальный сайт Pin Up Casino           0    2026-08-09 03:35:37
223   Pin Up Casino - Azərbaycanda Onlayn Kazino               0    2026-08-09 03:35:36
تحليل جنائي: ظهور المعرف 0 ككاتب للمقال يؤكد أن المنشورات لم تكن تُنشر عبر حساب مستخدم عادي مسجل الدخول، بل تم إنشاؤها إما عبر تجاوز صلاحيات (Unauthenticated Endpoint) أو عبر سكربت داخلي يستدعي دالة wp_insert_post() مباشرة من داخل نظام الملفات دون تحديد $post_author.

الخطوة الثالثة: تتبع طلبات الـ POST في سجلات الوصول

بالبحث داخل سجلات الوصول المؤرشفة (.gz) في تواريخ وأوقات النشر المسجلة للمقالات (أوائل شهر أغسطس):

Bash

zgrep "POST" /var/log/virtualmin/wp.3wda.net_access_log* | grep -E "31/Jul/2026|08/Aug/2026|09/Aug/2026" | head -n 30
الأثر الجنائي الحاسم الذي تم اكتشافه:

Plaintext

172.70.248.135 - - [09/Aug/2026:03:35:36 +0000] "POST /wp-content/easypost/easypost.php?action=create_post HTTP/1.1" 201 321 "-" "Mozilla/5.0..."
172.70.248.135 - - [09/Aug/2026:03:35:37 +0000] "POST /wp-content/easypost/easypost.php?action=create_post HTTP/1.1" 201 336 "-" "Mozilla/5.0..."
أثبتت السجلات دون أدنى شك وجود ملف باب خلفي باسم easypost.php يستقبل طلبات خارجية تؤدي إلى إنشاء المنشورات بنجاح وبرمز استجابة HTTP 201 Created.

4. الفحص المعمق لشيفرة الباب الخلفي (Backdoor Analysis)

عند قراءة وتحليل ملف wp-content/easypost/easypost.php، تبيّن أنه ليس مجرد كود شيل بسيط (Webshell)، بل هو حزمة برمجية معقدة وشديدة التنظيم طُورت خصيصاً للتحكم بمواقع ووردبريس عن بُعد.

PHP

<?php
define('EASYPOST_ENDPOINT_CONFIG', '{"endpoint_version":"2026.06.10","token_id":"ep_e3fcea3ec05744d691373dd268ef1ad7","token_verifier":"v1:...","ota_release_public_key_pem":"-----BEGIN PUBLIC KEY-----\n..."}');

الخصائص الهجومية المكتشفة داخل الكود:

  1. المصادقة المشفرة (HMAC Authentication): لا يقبل السكربت أي طلب عشوائي؛ بل يفرض وجود ترويسات أمان مشفرة (x-easypost-token-id, x-easypost-signature) مع التحقق من فارق التوقيت (Timestamp) لمنع هجمات إعادة الإرسال (Replay Attacks).
  2. التكامل مع قوالب Elementor: يضم الكود دوال مخصصة (easypost_endpoint_insert_elementor_widget) تقوم بالبحث في قاعدة بيانات الصفحات المصممة بـ Elementor وحقن أدوات نصوص وروابط مخفية داخل هياكل الـ JSON التابعة لها.
  3. تقنيات الإخفاء المتعددة (Cloaking & CSS Tricks): يتيح السكربت للمهاجم حقن الروابط بسبعة أساليب إخفاء مختلفة لحجبها عن زوار الموقع وإظهارها فقط لعناكب محركات البحث:
    • White Link: جعل لون النص أبيض ليختفي فوق الخلفية البيضاء.
    • Class Hide: استخدام فئات CSS مثل display:none.
    • Invisible Zone: نقل النص خارج حدود الشاشة عبر إحداثيات سلبية (left:-11407px; top:-10560px; position:absolute;).
    • No Opacity & No Visibility: ضبط الشفافية على الصفر تقريباً (opacity:0.001).
  4. تثبيت البقاء التلقائي (Self-Persistence via mu-plugins): في حال حذف مجلد الإضافة، يقوم السكربت تلقائياً بإنشاء ملف تشغيل تنفيذي إجباري في مسار wp-content/mu-plugins/easypost-runtime.php ليظل يعمل مع كل تحميل لصفحات الموقع دون الحاجة لتفعيله كإضافة عادية.
  5. التحديث الهوائي التلقائي (OTA Updates): يدعم السكربت استقبال تحديثات برمجية جديدة مشفرة بالمفتاح العام عبر بيئة Bun، حيث يتم التحقق من توقيع الشيفرة (OpenSSL Verification) وتحديث الملف تلقائياً على القرص الصلب.

5. تحديد نقطة الدخول الأولى والتسلسل الزمني للاختراق

للإجابة عن السؤال الجوهري: “كيف تم رفع هذا الملف وإنشاء الإضافات في المقام الأول؟”، تم الرجوع بسجلات الوصول إلى تاريخ إنشاء أول ملف في السيرفر وتاريخ أول مستخدم مجهول.
تم تنفيذ أمر البحث في تاريخ 28 يوليو 2026:

Bash

zgrep -E "28/Jul/2026" /var/log/virtualmin/wp.3wda.net_access_log* | grep "POST" | head -n 30

خط الدفاع الزمني لاختراق الخادم (Attack Timeline)

التاريخ والوقت (UTC) الطلب والمسار رمز الاستجابة الأثر الجنائي
28 يوليو – 03:09:02 POST /xmlrpc.php & /wp-login.php 405 / 200 بدء هجوم التخمين (Brute Force) وتجربة كلمات المرور.
28 يوليو – 03:24:49 POST /wp-login.php 302 Found نجاح تسجيل الدخول بحساب المسؤول بعد تخمين كلمة المرور.
28 يوليو – 03:24:51 POST /wp-admin/update.php?action=upload-plugin 200 OK رفع وتثبيت حزمة الإضافة الملغومة مباشرة من لوحة التحكم.
28 يوليو – 07:57:38 POST /wp-json/wp/v2/users 201 Created إنشاء حساب مسؤول خفي جديد باسم Service Bot (المعرف: 3).
28 يوليو – 07:57:39 POST /wp-json/wp/v2/users/3/application-passwords 201 Created توليد كلمات مرور التطبيقات (REST API Passwords) للبوت.
28 يوليو – 21:18:06 POST /wp-json/wp/v2/users 201 Created إنشاء حساب مسؤول خفي ثانٍ باسم admfha9c3 (المعرف: 4).
30 يوليو – 18:44:25 POST /wp-content/easypost/easypost.php?action=create_post 201 Created بدء ضخ مقالات الكازينو عبر الباب الخلفي.
15 أغسطس – 01:13:40 POST /wp-content/easypost/easypost.php?action=update_endpoint 200 OK تحديث كود الباب الخلفي عبر خادم تحكم خارجي مشفر.

6. إجراءات التطهير والاستئصال الشامل (Step-by-Step Remediation)

بناءً على الأدلة الجنائية، نُفذت خطة تطهير كاملة استهدفت الملفات، الحسابات، قواعد البيانات، ومستويات الخادم.

1. حذف الحسابات الخادعة وإلغاء مفاتيح الـ API

من خلال لوحة التحكم أو عبر WP-CLI، تم فحص المستخدمين وحذف الحسابات المزروعة فوراً:

Bash

# استعراض قائمة المستخدمين
wp user list --allow-root

# حذف الحسابات الخبيثة وتعيين أي محتوى للحساب الأصلي (ID 1)
wp user delete 3 --reassign=1 --yes --allow-root
wp user delete 4 --reassign=1 --yes --allow-root

# تغيير كلمات المرور لكافة الحسابات الشرعية
wp user update 1 --user_pass='Super_Strong_Random_Password_Here!' --allow-root
wp user update 2 --user_pass='Another_Super_Strong_Password_Here!' --allow-root

2. حذف كافة منشورات الاختراق دفعة واحدة

لحذف مئات المقالات التي تم حقنها بصفة Author = 0 دفعة واحدة دون إتلاف المقالات الأصلية:

Bash

wp post delete $(wp post list --post_status=publish --author=0 --format=ids --allow-root) --force --allow-root

# تفريغ سلة المهملات نهائياً
wp post empty-trash --allow-root

3. استئصال الإضافات الخبيثة والأبواب الخلفية

تم حذف الإضافات المزروعة التي تم الكشف عنها أثناء الفحص الزمني (wp-core-util و wp-security-helper و easypost):

Bash

cd /home/threewda.net/domains/wp.3wda.net
rm -rf wp-content/easypost
rm -rf wp-content/plugins/easypost
rm -rf wp-content/plugins/wp-core-util
rm -rf wp-content/plugins/wp-security-helper
rm -f wp-content/mu-plugins/easypost-runtime.php

4. تنظيف خيارات قاعدة البيانات (Options Table)

قام الباب الخلفي بحفظ مصفوفات الروابط داخل جدول الخيارات، فتم حذفها برمجياً:

Bash

wp option delete easypost_homepage_placements --allow-root

5. تجديد مفاتيح الأمان وجلسات تسجيل الدخول (Salts)

لإسقاط كافة الجلسات المفتوحة وملفات تعريف الارتباط (Cookies) التي قد يحتفظ بها المخترقون، تم فتح ملف wp-config.php وتوليد مفاتيح تشفير جديدة تماماً:

PHP

define('AUTH_KEY',         'put-your-unique-phrase-here');
define('SECURE_AUTH_KEY',  'put-your-unique-phrase-here');
define('LOGGED_IN_KEY',    'put-your-unique-phrase-here');
define('NONCE_KEY',        'put-your-unique-phrase-here');
define('AUTH_SALT',        'put-your-unique-phrase-here');
define('SECURE_AUTH_SALT', 'put-your-unique-phrase-here');
define('LOGGED_IN_SALT',   'put-your-unique-phrase-here');
define('NONCE_SALT',       'put-your-unique-phrase-here');

7. تأمين الخادم وإغلاق الثغرات نهائياً (Hardening & Protection)

حتى لا يتكرر الاختراق مستقبلاً، تم بناء سياج أمني على ثلاث طبقات: مستوى ووردبريس، ومستوى خادم الويب (Nginx)، ومستوى جدار الحماية (Cloudflare WAF).
                 [ حركة المرور الواردة ]
                           │
                           ▼
 ┌──────────────────────────────────────────────────┐
 │  الطبقة الأولى: Cloudflare WAF                  │
 │  • حظر الـ REST API لغير الـ IPs المعتمدة       │
 └─────────────────────────┬────────────────────────┘
                           │
                           ▼
 ┌──────────────────────────────────────────────────┐
 │  الطبقة الثانية: Nginx Web Server                │
 │  • حظر تنفيذ ملفات PHP داخل مجلد uploads        │
 │  • إغلاق ملف xmlrpc.php كلياً                    │
 └─────────────────────────┬────────────────────────┘
                           │
                           ▼
 ┌──────────────────────────────────────────────────┐
 │  الطبقة الثالثة: WordPress Core (wp-config.php)  │
 │  • تعطيل تعديل وتثبيت الإضافات عبر المتصفح      │
 │  • قفل التسجيل المفتوح وتجديد الـ Salts          │
 └──────────────────────────────────────────────────┘

أولاً: التحصين على مستوى ووردبريس (wp-config.php)

لمنع أي مستخدم (حتى لو كان مديراً) من تثبيت أي إضافات جديدة أو تعديل الملفات عبر المتصفح:

PHP

// منع تعديل الملفات البرمجية من لوحة التحكم
define( 'DISALLOW_FILE_EDIT', true );

// منع تثبيت وتحديث الإضافات والقوالب من المتصفح (التثبيت يتم عبر سطر الأوامر فقط)
define( 'DISALLOW_FILE_MODS', true );
تعطيل التسجيل المفتوح نهائياً:

Bash

wp option set users_can_register 0 --allow-root

ثانياً: التحصين على مستوى خادم Nginx

تم تعديل ملف التكوين الخاص بالنطاق (/etc/nginx/sites-available/wp.3wda.net.conf) وإضافة قواعد الحماية الصارمة:

Nginx

# 1. إغلاق xmlrpc.php نهائياً لمنع هجمات التخمين
location = /xmlrpc.php {
    deny all;
    return 403;
}

# 2. منع تشغيل وتنفيذ أي ملفات PHP داخل مجلدات الرفع والملفات الثابتة
location ~* ^/wp-content/(uploads|mu-plugins)/.*\.php$ {
    deny all;
    return 403;
}

# 3. منع تنفيذ ملفات PHP العشوائية الموضوعة مباشرة في جذر wp-content
location ~* ^/wp-content/[^/]+\.php$ {
    deny all;
    return 403;
}

# 4. تقييد عمليات النشر عبر REST API لسيرفرات الأتمتة المعتمدة فقط (مثل n8n)
location ~ ^/wp-json/wp/v2/(posts|pages|users) {
    limit_except GET HEAD {
        allow 198.51.100.45; # استبدله بعنوان IP الخاص بسيرفر الأتمتة
        deny all;
    }
    try_files $uri $uri/ /index.php?$args;
}
تطبيق التعديلات:

Bash

sudo nginx -t && sudo systemctl reload nginx

ثالثاً: التحصين على مستوى جدار حماية Cloudflare WAF

لحظر أي محاولات تلاعب بالـ REST API من خارج السيرفرات المصرح لها:
  1. التوجه إلى Security ثم WAF ثم Custom Rules.
  2. إنشاء قاعدة جديدة: Restrict WP API Modifications.
  3. ضبط المعايير:
    • URI Path starts with /wp-json/wp/v2/
    • AND Request Method in {"POST", "PUT", "DELETE", "PATCH"}
    • AND IP Source Address ne YOUR_N8N_SERVER_IP
  4. تحديد الإجراء (Action): Block.

8. التعامل مع تبعات محركات البحث (Google Search Console & SEO Recovery)

بعد حذف الروابط الخبيثة، تأتي مرحلة تنظيف السمعة الرقمية للموقع لتفادي العقوبات اليدوية (Manual Actions) من محركات البحث:
  • رمز الاستجابة السليم (404 / 410): عند حذف المنشورات، تعود خوادم الموقع بإرجاع رمز 404 Not Found أو 410 Gone لطلبات تلك الصفحات. هذا الرمز يُعد إشارة صريحة لخوارزميات Googlebot بأن المحتوى تم حذفه نهائياً، مما يؤدي إلى إزالته تدريجياً من الفهرس.
  • فحص لوحة Search Console: الدخول إلى قسم Security & Manual Actions للتأكد من عدم تصنيف الموقع كـ “موقع مخترق بحقن روابط سبام”.
  • إعادة إرسال خريطة الموقع (Sitemap): تحديث ملف sitemap.xml وإعادة إرساله عبر Search Console لتسريع عملية إعادة زحف محركات البحث إلى الصفحات النظيفة فقط.

9. إدارة المستودعات (Git Best Practices) للإنتاج

لتجنب تعارض الملفات أثناء سحب التحديثات البرمجية (git pull) ولمنع رفع وسائط الموقع إلى المستودع المصدري:
  1. عزل مجلد الوسائط: يجب إضافة مجلد الرفع uploads/ إلى ملف .gitignore:

    Code snippet

    wp-content/uploads/
    wp-content/upgrade/
    *.log
    
  2. إلغاء التتبع التلقائي للتغييرات المحلية: إذا تم تعديل ملفات نواة أو إضافات تلقائياً عبر ووردبريس، يُفضل تثبيت بيئة الإنتاج على فرع مستقر ومنع التعديل المباشر عليها.
  3. تنظيف الكاش فور نشر التحديثات:

    Bash

    # مسح كاش ووردبريس الداخلي
    wp cache flush --allow-root
    
    # إعادة تشغيل معالج PHP لقراءة ملفات الذاكرة المخبأة (OPcache)
    systemctl reload php*-fpm
    
    # تحديث قواعد إعادة التوجيه
    wp rewrite flush --allow-root
    

الخلاصة وقائمة التحقق الأمنية السريعة (Security Checklist)

عنصر التحقق الإجراء الأمني المطبق الحالة بعد التحقيق
حسابات المستخدمين حذف حسابات Service Bot و admfha9c3 وتعيين كلمات مرور معقدة مؤمّن بالكامل
مفاتيح التطبيقات إبطال كافة مفاتيح الـ API غير المعروفة وإبقائها فقط لسيرفر n8n مؤمّن بالكامل
ملفات النواة والإضافات حذف easypost و wp-core-util و wp-security-helper نظيف 100%
تنفيذ PHP حظر تنفيذ لغة PHP داخل مجلدات uploads و mu-plugins في Nginx محمي تماماً
واجهة XML-RPC حظر مسار /xmlrpc.php كلياً على مستوى خادم الويب معطل نهائياً
إدارة الملفات البرمجية تفعيل DISALLOW_FILE_MODS و DISALLOW_FILE_EDIT في wp-config.php مغلق عن المتصفح
التحكم بالـ API تقييد صلاحيات التعديل في REST API بـ IP خادم الأتمتة فقط محصن عبر WAF
باتباع هذه الإجراءات الممنهجة، يتحول الموقع من حالة التعرض لاختراق نشط ومعقد إلى بيئة إنتاجية عالية الأمان ومحصنة ضد محاولات الحقن والتسلل المستقبلية.

 فحص الملفات وتنظيف الـ Backdoors
حذف المنشورات وحده لا يكفي لأن المخترق يترك عادةً ملفات خفية (Webshells / Backdoors) لإعادة الحقن:
  • عبر الـ Terminal أو مدير الملفات في السيرفر:
    • افحص مسار wp-content/uploads/ وتأكد من عدم وجود أي ملفات بامتداد .php بداخله (الملفات داخل هذا المجلد يجب أن تكون صور ومستندات فقط):
      Bash

      find /path/to/wordpress/wp-content/uploads/ -type f -name "*.php"
      
    • افحص ملفات index.php، wp-config.php، وملف .htaccess للتأكد من عدم وجود أكواد غريبة أو عمليات إعادة توجيه (Redirection rules).
تأكد من وجود هذه الأسطر في wp-config.php:
PHP

// منع تعديل وتثبيت الإضافات والقوالب من لوحة التحكم نهائياً
define( 'DISALLOW_FILE_MODS', true );
define( 'DISALLOW_FILE_EDIT', true );
حظر التسجيل المفتوح عبر سطر الأوامر
تأكد من غلق باب تسجيل الأعضاء تلقائياً:
Bash

wp option set users_can_register 0 --allow-root

 

الملف الفعلي لسجلات الموقع هو:
/var/log/virtualmin/wp.3wda.net_access_log
في ووردبريس، لا يمكن لـ Application Passwords أو مستخدم عادي أن ينشر بمؤلف رقم 0؛ النشر كـ author = 0 أو مجهول يعني أن المنشورات تم حقنها مباشرة عبر ثغرة REST API غير مصرح بها (Unauthenticated REST API Vulnerability) في قالب أو إضافة معينة، أو عبر SQL Injection / Backdoor كتب مباشرة في قاعدة البيانات.
1. فحص ملف السجل الحقيقي للدومين
قم بالبحث داخل المسار الفعلي لسجلات Virtualmin في تاريخ أول منشور خبيث (يوليو / أغسطس):
Bash

# فحص كل طلبات POST في تاريخ 31 يوليو و 8 و 9 أغسطس
zgrep "POST" /var/log/virtualmin/wp.3wda.net_access_log* | grep -E "31/Jul/2026|08/Aug/2026|09/Aug/2026" | head -n 30
2. البحث عن استغلال مسارات الإضافات (Plugins)
للبحث عن الـ endpoint أو الإضافة التي استغلها المهاجم:
Bash

zgrep -E "wp-json|admin-ajax\.php" /var/log/virtualmin/wp.3wda.net_access_log* | grep "POST" | head -n 30
3. فحص قائمة الإضافات المنصبة وحالتها
اعرض قائمة الإضافات المثبتة في ووردبريس لمعرفة ما إذا كان هناك إضافة بها ثغرة معروفة:
Bash

wp plugin list --allow-root
4. البحث عن أي ملفات PHP مزروعة داخل مجلد uploads
تأكد من عدم وجود سكربتات خفية (Webshells) تم رفعها:
Bash

find /home/threewda.net/domains/wp.3wda.net/public_html/wp-content/uploads/ -type f -name "*.php"
نفّذ هذه الأوامر لنرى مسار الـ POST الدقيق واسم الإضافة المصابة.

نعم، هذا وارد ومحتمل جداً، لأن المهاجم امتلك صلاحيات كاملة عبر الواجهة الإدارية وملف الـ Backdoor لفترة امتدت قرابة شهر.
للتأكد بشكل قاطع من عدم وجود أي ملفات أخرى مزروعة في ملفات الموقع، نفّذ عمليات الفحص الجنائي التالية:
1. التحقق من سلامة ملفات ووردبريس الأساسية (Core & Plugins Checksums)
تعتمد هذه الأوامر على مقارنة تجزئة (Hashes) ملفاتك بالنسخ الأصلية النظيفة من مستودع WordPress.org لاكتشاف أي ملف تم تعديله أو حقنه:
Bash

# فحص ملفات نواة ووردبريس الأساسية
wp core verify-checksums --allow-root

# فحص الإضافات المثبتة من المستودع الرسمي
wp plugin verify-checksums --all --allow-root
(إذا كانت كل الملفات سليمة سيعطيك Success: WordPress installation verifies against checksums.)
2. البحث عن أي ملفات PHP تم إنشاؤها أو تعديلها حديثاً
ابحث عن أي ملف PHP تم إنشاؤه أو التعديل عليه خلال آخر 35 يوماً (منذ تاريخ الاختراق في 28 يوليو):
Bash

find /home/threewda.net/domains/wp.3wda.net/ -type f -name "*.php" -mtime -35 -ls
  • راجع قائمة الملفات الناتجة؛ يجب ألا تجد فيها سوى التعديلات التي قمت بها بنفسك مؤخراً (مثل wp-config.php).
3. البحث عن الدوال البرمجية المشبوهة في كامل مسار الموقع
ابحث عن أي استخدام لأكواد التشفير أو تنفيذ الأوامر الخفية في أي ملف PHP:
Bash

grep -rnE "(eval\(|base64_decode\(|gzinflate\(|str_rot13\(|assert\(|passthru\(|shell_exec\()" /home/threewda.net/domains/wp.3wda.net/wp-content/ --exclude-dir={plugins,themes}
4. فحص الملفات المخفية ونقاط الدخول الأساسية
تأكد من نظافة الملفات التي يفضل المخترقون زرع أكوادهم بداخلها لضمان تشغيلها مع كل زيارة:
Bash

# فحص أول 20 سطراً في ملفات التشغيل الأساسية
head -n 20 /home/threewda.net/domains/wp.3wda.net/index.php
head -n 20 /home/threewda.net/domains/wp.3wda.net/wp-blog-header.php
head -n 20 /home/threewda.net/domains/wp.3wda.net/wp-load.php

# فحص ملفات التكوين وقواعد التوجيه المخفية
cat /home/threewda.net/domains/wp.3wda.net/.htaccess 2>/dev/null

التعليقات (0)

أضف تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني.

لا توجد تعليقات بعد. كُن أول من يشارك رأيه!

جاهز لتحويل عملك؟

دعنا نناقش كيف يمكن لحلولنا التقنية مساعدتك في تحقيق أهدافك.