لقيت مستخدم مدير غير معروف في ووردبريس؟ تجربة تدقيق واحتواء
فتحت المستخدمين ولقيت مدير ما بتعرفه؟ تعامل معه كمؤشر اختراق محتمل، مش كحساب زائد وبس. حذفه ممكن يوقف دخولا مباشرا، لكنه ما بحكيلك مين انشاه ولا اذا في باب خلفي رح يرجعه بعد دقيقة.
عملنا محاكاة مضبوطة على نسخة الاختبار. سجلنا خط اساس فيه مدير معروف واحد، انشانا حسابا ثانيا بدور administrator ومسودة منسوبة له، وفحصنا تاريخ التسجيل وصف القدرات وعدد الجلسات ومصدر الانشاء. بعدها سحبنا الدور اولا، تحققنا انه فقد manage_options، ثم حذفناه مع اسناد المحتوى للحساب المعروف. اخيرا حذفنا المسودة التجريبية.
إنشاء مستخدم غير مصرح مذكور كمؤشر واضح في دليل ووردبريس للموقع المخترق. نفس المشكلة تظهر في دعم ووردبريس عن مدير مجهول وفي نقاش ريديت حديث عن حساب مدير غير معروف.
نتيجة التجربة
- قبل المحاكاة: مدير واحد وحساب المختبر غير موجود.
- بعد الانشاء: مديرين اثنين، والحساب الجديد له administrator capabilities.
- عدد جلساته صفر، وهذا يثبت ان غياب login log لا يجعل الحساب امنا.
- بعد سحب الدور: subscriber و
manage_options=false. - بعد الحذف: الحساب غير موجود، وعدد المديرين رجع واحدا.
- المسودة انتقلت للحساب المعروف قبل حذفها، فما ضاع محتوى بلا قصد.
احفظ خط الاساس والادلة
في حادث حقيقي خذ نسخة من قاعدة البيانات والملفات والسجلات قبل التغييرات اذا تقدر. سجل الوقت والمنطقة الزمنية واسم الحساب والبريد والدور. التاريخ داخل قاعدة البيانات ممكن يتعدل، لذلك قارنه بنسخ قديمة وسجلات خادم ومزود البريد.
تدقيق الحساب الجديد
فحصنا wp_users وصف capabilities في usermeta وعدد session tokens. سجل المختبر مصدر الانشاء والفاعل لاننا نتحكم بالمحاكاة. في اختراق حقيقي قد لا تلاقي هاي العلامة، او ممكن تكون مزورة، لذلك اجمع اكثر من دليل.
اسحب الصلاحية قبل الحذف
اذا الحساب غير معروف وانت تحتاج دقائق لحفظ الادلة، سحب الدور وابطال الجلسات يقلل الخطر. لكن اذا المهاجم يملك وصول ملفات او قاعدة بيانات، يقدر يرجع الدور؛ الاحتواء لازم يشمل كلمات المرور والمفاتيح والخادم.
احذف مع قرار واضح للمحتوى
واجهة ووردبريس بتسالك هل تحذف محتوى المستخدم او تسنده لغيره. لا تضغط بسرعة. افحص المقالات والصفحات والوسائط والمنتجات، لان المحتوى نفسه ممكن يكون spam او كودا ضارا، وقد تحتاج تحتفظ بنسخة كدليل.
فيديو توثيق التجربة الفعلية
هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.
اول عشر خطوات في موقع حقيقي
- لا تسجل خروجك اذا انت داخل وما عندك طريق بديل.
- وثق الحساب والوقت والدور من غير نشر البيانات.
- خذ snapshot او نسخة حادث للملفات وقاعدة البيانات.
- اسحب دور الحساب وابطل جلساته اذا هذا امن.
- غير كلمات مرور المدراء والاستضافة وSFTP وقاعدة البيانات.
- بدل WordPress salts حتى تبطل الجلسات القديمة.
- راجع المدراء ومفاتيح التطبيقات وAPI tokens.
- قارن ملفات core بمصدر رسمي واعد تنزيل الإضافات والقوالب من مصادرها.
- افحص المهام المجدولة وmu-plugins وuploads وwp-config وقواعد الخادم.
- سد سبب الدخول وحدث كل شيء ثم غير كلمات المرور مرة ثانية.
لا تفترض ان الحذف انهى الاختراق
اذا الحساب رجع، في كود او مهمة او وصول خارجي يعيد انشاءه. ابحث في سجلات الطلبات حول وقت الانشاء، الملفات المعدلة، وظائف wp_create_user وwp_insert_user المشبوهة، Cron، وإضافات غير معروفة. راجع حساب الاستضافة كله اذا مواقع متعددة تشترك بنفس المستخدم.
شو تفحص في قاعدة البيانات؟
- صف المستخدم والبريد والتاريخ.
- صف capabilities ودوره الحقيقي.
- session_tokens ومفاتيح التطبيقات.
- محتوى منسوب للحساب.
- خيارات active_plugins وcron.
- مستخدمون اخرون تغير دورهم او بريدهم بنفس الفترة.
الجلسات صفر مش براءة
الحساب ممكن ينشأ وما يستخدم، او تنظف جلساته، او يدخل بطريقة ما تترك السجل المتوقع. غياب جلسة واحدة لا يلغي مؤشر الانشاء غير المصرح. نفس الشيء لتاريخ التسجيل: هو خيط، مش حقيقة مستقلة.
بعد التنظيف
راقب انشاء المستخدمين وتغير الادوار والملفات عدة ايام. فعل 2FA للمديرين، قلل عددهم، واحذف الحسابات غير المستخدمة. احتفظ بنسخ خارج حساب الاستضافة حتى ما يحذفها المهاجم.
حدود تجربتنا
الحساب في التجربة انشأناه نحن وسجلنا مصدره، لذلك ما بنسمي الموقع مخترقا. الهدف توثيق تدفق التدقيق والاحتواء والحذف والاسناد من غير مخاطرة. في موقع حقيقي لازم تضيف سجلات الخادم وفحص ملفات وسبب جذري.
الخلاصة
عدد المديرين ارتفع من واحد لاثنين، ثم رجع بعد سحب الدور والحذف، واسندنا المحتوى قبل التنظيف. الدرس الاهم: المدير الغريب مؤشر حادث. احفظ الادلة، احتو الحساب، وابحث عن الباب الذي انشاه قبل ما تعتبر المشكلة منتهية.
