آموزش پاک‌سازی سایت هک‌شده وردپرس؛ حذف بدافزار، بازیابی و جلوگیری از نفوذ مجدد

ارسال توسط Dev Source

24 مهر 1405

منتشرشده در 6 مرداد 1405

🗓 آخرین به‌روزرسانی: 24 مهر 1405

📚 این آموزش بخشی از آموزش جامع وردپرس از صفر تا حرفه‌ای است؛ مسیر کامل یادگیری را آنجا ببینید.

پاک‌سازی سایت هک‌شده وردپرس فقط به حذف یک فایل مشکوک یا نصب افزونه اسکنر محدود نمی‌شود. اگر مسیر ورود مهاجم، حساب‌های در معرض خطر، دسترسی‌های API، فایل‌های آلوده، تغییرات دیتابیس و تنظیمات سرور هم‌زمان بررسی نشوند، سایت ممکن است چند ساعت یا چند روز بعد دوباره آلوده شود. پاک‌سازی حرفه‌ای یک فرایند Incident Response است: تشخیص، حفظ شواهد، مهار، حذف عامل نفوذ، بازیابی از منابع سالم، اعتبارسنجی و جلوگیری از تکرار.

نشانه‌های نفوذ نیز همیشه واضح نیستند. گاهی سایت به دامنه‌ای ناشناس Redirect می‌شود؛ گاهی صفحه‌های اسپم فقط برای Googlebot نمایش داده می‌شوند؛ گاهی یک Administrator جدید، فایل PHP در Uploads، Cron Job ناشناس، تغییر درگاه پرداخت یا ارسال ایمیل‌های Spam تنها علامت حادثه است. بنابراین باید به‌جای حدس، علائم و تغییرات را مستند و با داده‌های قابل اعتماد مقایسه کرد.

در این آموزش، نشانه‌های هک، اقدام‌های فوری، Snapshot آلوده، مهار بدون نابودکردن شواهد، بررسی حساب‌ها، Core، افزونه‌ها، قالب، MU Pluginها، Uploads، دیتابیس، Cron، WooCommerce، Search Console، تعویض رمز و کلیدها، بازسازی تمیز و مانیتورینگ پس از حادثه را مرحله‌به‌مرحله بررسی می‌کنیم.

نکته درباره سایت فعلی: انتشار این مقاله به معنی هک‌شدن dev-source.ir نیست. در این مرحله اسکن فایل، دیتابیس یا لاگ سرور انجام نشده است. روی سایت افزونه امنیتی یا اسکنر بدافزار اختصاصی فعالی مشاهده نمی‌شود؛ بنابراین برای ارزیابی واقعی باید دسترسی هاست، لاگ‌ها و فایل‌سیستم در اختیار متخصص قرار گیرد.

از کجا بفهمیم وردپرس هک شده است؟

یک علامت می‌تواند خطای فنی عادی باشد؛ چند نشانه مرتبط احتمال نفوذ را افزایش می‌دهد. WordPress در راهنمای رسمی خود توصیه می‌کند ابتدا Indicators of Compromise یا نشانه‌های قابل مشاهده را دقیق ثبت کنید.

نشانه‌های واضح

Redirect به سایت ناشناس، تبلیغ یا صفحه شرط‌بندی
هشدار مرورگر درباره Malware یا Phishing
ثبت Security Issue در Google Search Console
ایجاد Administrator بدون مجوز
تغییر متن، لینک یا شماره حساب
ارسال ایمیل Spam از دامنه
تعلیق سایت توسط هاست
وجود فایل‌های ناشناس با نام تصادفی

نشانه‌های پنهان‌تر

صفحه‌های ژاپنی، دارویی یا قمار در نتایج گوگل
افزایش ناگهانی مصرف CPU و I/O
تغییر زمان آخرین ویرایش فایل‌های Core
خطاهای ۵۰۰ یا ۴۰۳ بدون تغییر برنامه‌ریزی‌شده
Cron Job یا Scheduled Action ناشناس
درخواست‌های غیرعادی به REST API
تغییر آدرس ایمیل مدیر
سفارش، Refund یا کوپن غیرمجاز

مرحله اول: آرام بمانید و همه چیز را مستند کنید

پاک‌کردن فوری فایل مشکوک ممکن است شواهد مسیر نفوذ را از بین ببرد. قبل از تغییر، این موارد را ثبت کنید:

زمان کشف و منطقه زمانی
نخستین علامت مشاهده‌شده
URLها و Screenshotها
پیام هاست، مرورگر یا Search Console
حساب‌های جدید یا تغییرکرده
فایل‌های دارای زمان ویرایش مشکوک
IP، User Agent و Request ID در Log
تغییرهای اخیر قالب، افزونه و کد سفارشی

یک Timeline ساده بسازید. دانستن اینکه نخستین رفتار مشکوک پیش یا پس از نصب یک افزونه رخ داده، محدوده بررسی را کوچک می‌کند.

مرحله دوم: از وضعیت آلوده Snapshot بگیرید

حتی نسخه آلوده ارزش بررسی دارد. قبل از پاک‌سازی، در صورت امکان این موارد را خارج از Web Root ذخیره کنید:

آرشیو کامل فایل‌ها
Export دیتابیس
Access Log و Error Log
فهرست فایل با زمان، اندازه و Hash
فهرست Userها، Roleها و Sessionها
فهرست افزونه و قالب همراه نسخه
Cron و Scheduled Actions

نسخه آلوده را با نام واضح قرنطینه کنید و هرگز مستقیماً روی سایت دیگری Restore نکنید. راهنمای WordPress نیز توصیه می‌کند پیش از Clean-up یک Snapshot از وضعیت موجود داشته باشید.

برای ساخت نسخه سالم و قابل بازیابی، مقاله آموزش بکاپ و بازیابی وردپرس را مطالعه کنید.

مرحله سوم: حادثه را مهار کنید

هدف Containment جلوگیری از آسیب بیشتر است، بدون اینکه شواهد نابود شوند.

اقدام‌های ممکن

فعال‌کردن Maintenance محدود
محدودکردن wp-admin با WAF یا IP
مسدودکردن Endpoint مخرب شناخته‌شده
تعلیق موقت Upload یا ثبت‌نام عمومی
غیرفعال‌کردن درگاه یا Checkout در صورت خطر مالی
محدودکردن ارسال ایمیل در صورت Spam
قطع Integration آلوده

اگر سایت در حال سرقت اطلاعات، تغییر پرداخت یا توزیع Malware است، حفظ فروش کوتاه‌مدت نباید بر ایمنی مشتری اولویت داشته باشد.

آیا باید سایت را فوراً خاموش کنیم؟

به دامنه حادثه بستگی دارد:

تغییر ظاهری محدود: دسترسی مدیریت را ببندید و بررسی کنید.
Redirect یا Malware فعال: سایت را از دسترس عمومی خارج کنید.
تغییر درگاه یا سفارش: Checkout را فوراً متوقف نمایید.
نفوذ سرور یا چند سایت: با هاست هماهنگ و همه حساب‌ها را مهار کنید.

صفحه Maintenance نباید از همان وردپرس آلوده کد اجرا کند. در حادثه جدی، پاسخ ثابت در سطح Proxy یا وب‌سرور امن‌تر است.

مرحله چهارم: رمزها را چه زمانی تغییر دهیم؟

در آغاز حادثه می‌توان برای مهار، دسترسی‌های فوری را تغییر یا لغو کرد؛ اما بعد از پاک‌سازی باید همه رمزها دوباره Rotate شوند. دلیل این است که Keylogger یا Backdoor ممکن است رمز اولیه جدید را نیز دیده باشد.

دسترسی‌هایی که باید بررسی شوند

Administrator و Shop Manager
ایمیل مدیر
cPanel، Plesk یا پنل هاست
SFTP، SSH و FTP
دیتابیس
Cloudflare و DNS Registrar
SMTP
درگاه پرداخت و Webhook
Git، CI/CD و فضای بکاپ
Application Passwordها و API Keyها

رمزها را از یک دستگاه سالم تغییر دهید. اگر لپ‌تاپ مدیر آلوده باشد، Rotation روی همان دستگاه بی‌اثر می‌شود.

Security Saltهای وردپرس

تغییر Authentication Keys و Salts باعث نامعتبرشدن Cookieهای ورود می‌شود و کاربران باید دوباره وارد شوند. کلیدهای جدید را از Generator رسمی WordPress دریافت و در wp-config.php جایگزین کنید.

این کار Backdoor را حذف نمی‌کند؛ فقط Sessionهای موجود را می‌بندد. Application Passwordها نیز باید جداگانه Revoke شوند.

مرحله پنجم: حساب‌های کاربری را بررسی کنید

تمام Administratorها و Shop Managerها را فهرست کنید.
تاریخ ایجاد و ایمیل را بررسی نمایید.
Display Name را با Login اشتباه نگیرید.
کاربر ناشناس را ابتدا مستند و سپس حذف کنید.
محتوای User حذف‌شده را به حساب سالم منتقل نمایید.
Sessionهای همه مدیران را لغو کنید.
2FA را پس از پاک‌سازی اجباری نمایید.

حسابی با نقش Subscriber نیز ممکن است Meta یا Capability غیرعادی داشته باشد. بررسی فقط ستون Role در صفحه Users کافی نیست.

بررسی Session با WP-CLI

wp user session list USER_ID
wp user session destroy USER_ID --all

شناسه حساب را متناسب با سایت تغییر دهید. پس از حادثه بهتر است Sessionهای همه کاربران حساس بسته شوند.

مرحله ششم: سلامت فایل‌های Core را بررسی کنید

فایل‌های هسته نباید دستی ویرایش شوند. WP-CLI می‌تواند آن‌ها را با Checksum رسمی نسخه نصب‌شده مقایسه کند:

wp core verify-checksums --include-root

گزینه --include-root فایل‌های اضافی Root را نیز گزارش می‌کند. خروجی ناموفق الزاماً اثبات Malware نیست؛ فایل سفارشی یا نسخه Locale اشتباه نیز ممکن است هشدار بسازد. هر مورد باید بررسی شود.

بازسازی امن Core

به‌جای اصلاح دستی فایل‌های آلوده، Core را از بسته رسمی همان نسخه یا نسخه پشتیبانی‌شده جایگزین کنید. پوشه wp-content و فایل تنظیمات را کورکورانه بازنویسی نکنید.

فایل‌های حساس برای بررسی

index.php
wp-config.php
.htaccess
wp-settings.php
wp-load.php
فایل‌های Header، Footer و Functions قالب
فایل‌های PHP داخل Uploads
فایل‌های جدید در Root

WordPress در راهنمای رسمی نیز فایل‌های عمومی مانند index، header، footer و functions را از اهداف رایج تغییر معرفی می‌کند.

پیداکردن فایل‌های تازه تغییرکرده

در SSH می‌توان برای بررسی اولیه فایل‌های PHP تغییرکرده در چند روز اخیر از دستور زیر استفاده کرد:

find public_html -type f -name "*.php" -mtime -14 -print

عدد ۱۴ را با Timeline حادثه هماهنگ کنید. این دستور فایل را حذف نمی‌کند و فقط فهرست می‌سازد. آپدیت قانونی نیز زمان فایل‌ها را تغییر می‌دهد.

بررسی PHP در Uploads

در نصب معمول وردپرس، پوشه Uploads عمدتاً برای تصویر و فایل رسانه‌ای است. وجود PHP در آن نیازمند بررسی فوری است:

find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" \) -print

بعضی افزونه‌های خاص ممکن است فایل قانونی داشته باشند، اما هیچ موردی را بدون شناخت اجرا یا حذف نکنید.

مرحله هفتم: افزونه‌ها را از منابع سالم بازسازی کنید

فایل افزونه عمومی را از مخزن رسمی یا فروشنده معتبر دوباره دریافت کنید. اصلاح یک یا دو فایل تضمین نمی‌کند Backdoor دیگری باقی نمانده باشد.

بررسی Checksum افزونه‌های مخزن

wp plugin verify-checksums --all

این بررسی برای افزونه‌های موجود در WordPress.org مفید است. افزونه تجاری یا سفارشی ممکن است Checksum عمومی نداشته باشد و هشدار دریافت کند.

برای افزونه سفارشی

با Release سالم Git مقایسه کنید.
فایل‌های ناشناخته را بررسی نمایید.
Capability، Nonce و Upload را Audit کنید.
Secretها را Rotate نمایید.
نسخه تمیز را از Source کنترل‌شده Deploy کنید.

سایت فعلی چند افزونه سفارشی دارد؛ بنابراین نسخه سالم و تاریخچه تغییر آن‌ها برای هر Incident ضروری است.

قالب و Child Theme

قالب رسمی یا تجاری را از بسته معتبر جایگزین کنید. Child Theme را با Git یا نسخه پشتیبان سالم مقایسه نمایید.

مکان‌های پرریسک:

functions.php
header.php
footer.php
Template Overrideهای WooCommerce
فایل JavaScript سفارشی
کدهای قرارگرفته در Custom CSS/JS

کد مخرب ممکن است در Theme Option دیتابیس ذخیره شده باشد؛ پاک‌کردن فایل قالب به‌تنهایی کافی نیست.

MU Plugins و Drop-inها را فراموش نکنید

افزونه‌های Must-Use در wp-content/mu-plugins بدون نمایش معمول در صفحه Plugins اجرا می‌شوند. Drop-inهایی مانند این موارد نیز باید بررسی شوند:

advanced-cache.php
object-cache.php
db.php
sunrise.php

LiteSpeed Cache یا ابزار Cache ممکن است Drop-in قانونی بسازند؛ فایل را با منبع افزونه و Hash سالم مقایسه کنید.

مرحله هشتم: wp-config.php و .htaccess را بررسی کنید

در wp-config.php به‌دنبال این موارد باشید:

Include یا Require ناشناس
URL یا دامنه خارجی
کد Obfuscated
User دیتابیس تغییرکرده
کلید API ناشناس
تعریف Cron یا Proxy غیرمجاز

در .htaccess Redirect، Rewrite و Handlerهای PHP را بررسی کنید. محتوای میان # BEGIN WordPress و # END WordPress ممکن است توسط وردپرس بازنویسی شود؛ Rule سفارشی قانونی باید مستند باشد.

نشانه‌های Obfuscation

وجود توابع یا رشته‌های رمزگذاری‌شده به‌تنهایی اثبات Malware نیست، اما در فایل غیرمنتظره مشکوک است:

رشته‌های Base64 بسیار طولانی
ترکیب بی‌دلیل eval و Decode
متغیرهای تصادفی و کد یک‌خطی بسیار بلند
ساخت تابع از رشته
ارتباط با دامنه ناشناس

جست‌وجوی الگو باید با مقایسه Source سالم انجام شود؛ حذف کورکورانه رشته Base64 ممکن است افزونه قانونی را خراب کند.

مرحله نهم: دیتابیس را پاک‌سازی کنید

بدافزار ممکن است هیچ فایل آشکاری باقی نگذارد و Payload را در دیتابیس ذخیره کند.

بخش‌های مهم

محتوای نوشته و برگه
Widget و Menu
Theme Mod و Optionها
Snippetهای سفارشی
Redirectهای SEO
User Meta و Capability
Cron Option
Template و Email Setting
محصول، Checkout و درگاه

قبل از هر Query، Export کامل دیتابیس بگیرید. حذف با SQL مستقیم بدون شناخت Serialized Data می‌تواند سایت را خراب کند.

جست‌وجوی URL ناشناس در دیتابیس

اگر دامنه مخرب مشخص است، از ابزار Search سازگار با Serialization یا WP-CLI استفاده کنید:

wp db search 'malicious-example.invalid' --all-tables

دامنه نمونه را با Indicator واقعی جایگزین کنید. ابتدا فقط Search انجام دهید و Replace خودکار را پس از بررسی نوع داده اجرا نمایید.

بررسی Cron وردپرس

Backdoor می‌تواند پس از حذف، با Cron دوباره فایل بسازد.

wp cron event list

نام Hook، زمان اجرا و Interval را بررسی کنید. Hook ناشناس را به افزونه یا کد مشخص نسبت دهید. حذف Event بدون حذف کد ثبت‌کننده ممکن است موقت باشد.

Action Scheduler ووکامرس

WooCommerce و افزونه‌های آن از Scheduled Actions استفاده می‌کنند. موارد Failed یا ناشناس را در WooCommerce → Status → Scheduled Actions بررسی کنید.

Jobهای قانونی ارسال ایمیل، وب‌هوک، Analytics و پاک‌سازی را حذف نکنید. ابتدا Hook و افزونه مالک را شناسایی نمایید.

مرحله دهم: WooCommerce را جداگانه بررسی کنید

در فروشگاه، نفوذ می‌تواند آسیب مالی مستقیم ایجاد کند.

موارد ضروری

آدرس درگاه و Merchant ID
شماره حساب و متن BACS
Callback و Webhook
وضعیت سفارش و Refund
کوپن‌های جدید
قیمت محصولات
Administrator و Shop Manager
فایل‌های دانلودی و URL آن‌ها
ایمیل فرستنده و گیرنده مدیر
API Keyهای WooCommerce

مهاجم ممکن است بدون Defaceکردن سایت، فقط مقصد پرداخت یا ایمیل سفارش را تغییر دهد.

بررسی سفارش‌ها و تراکنش‌ها

Order Noteهای غیرعادی
سفارش‌های Completed بدون تراکنش معتبر
Refundهای بدون مجوز
تغییر ناگهانی موجودی
Customer Note یا لینک ناشناس
Transaction ID تکراری

برای اختلاف مالی، پنل درگاه، دیتابیس سفارش و Log سرور را تطبیق دهید. تغییر دستی وضعیت بدون تأیید مالی شواهد را مخدوش می‌کند.

فایل‌های دانلودی فروشگاه

در سایت فروش PDF یا نرم‌افزار بررسی کنید:

فایل اصلی جایگزین نشده باشد.
Hash فایل با نسخه سالم مطابقت داشته باشد.
لینک مستقیم عمومی ایجاد نشده باشد.
مجوزهای دانلود غیرعادی نباشند.
فایل اجرایی ناشناس اضافه نشده باشد.

Google ممکن است برای دانلود آلوده یا ناشناخته هشدار نمایش دهد. فایل‌های فروشگاهی باید از Source سالم بازسازی و دوباره بررسی شوند.

مرحله یازدهم: بازسازی تمیز بهتر است یا پاک‌سازی دستی؟

بازسازی تمیز

در حادثه گسترده معمولاً قابل اعتمادتر است:

سرور یا محیط تمیز آماده کنید.
WordPress را از منبع رسمی نصب نمایید.
قالب و افزونه‌ها را از منابع سالم نصب کنید.
Child Theme و افزونه سفارشی را از Git سالم Deploy نمایید.
Uploads را اسکن و منتقل کنید.
دیتابیس را پاک‌سازی یا داده‌های لازم را مهاجرت دهید.
رمزها و کلیدها را Rotate کنید.

پاک‌سازی دستی

برای Incident محدود و تیم باتجربه ممکن است سریع‌تر باشد، اما خطر باقی‌ماندن Persistence بالاتر است. اگر Source سالم برای مقایسه ندارید، بازسازی انتخاب مطمئن‌تری است.

Restore از بکاپ چه زمانی مناسب است؟

Restore فقط وقتی مؤثر است که:

تاریخ نفوذ را تقریباً بدانید.
نسخه انتخابی قبل از آلودگی باشد.
مسیر ورود بسته شده باشد.
Credentialها Rotate شده باشند.
سفارش‌ها و داده‌های پس از Backup مدیریت شوند.

جدیدترین Backup ممکن است آلوده باشد. Restore بدون Patchکردن افزونه آسیب‌پذیر باعث نفوذ مجدد می‌شود.

مرحله دوازدهم: Search Console و هشدارهای گوگل

در Google Search Console گزارش Security Issues را بررسی کنید. Google ممکن است موارد زیر را گزارش کند:

Hacked Content
Code Injection
URL Injection
Malware
Phishing یا Social Engineering
Harmful Downloads

نمونه URLهای گزارش کامل نیستند؛ باید کل سایت بررسی شود. پس از پاک‌سازی، Request Review ارسال کنید و دقیق توضیح دهید چه چیزی آلوده بوده، چه اقدام‌هایی انجام شده و چگونه از تکرار جلوگیری کرده‌اید.

ارسال درخواست بازبینی پیش از رفع کامل می‌تواند فرایند را طولانی کند.

پاک‌سازی SEO Spam

در Google با site:domain.example جست‌وجو کنید.
Sitemap را بررسی نمایید.
صفحه‌ها و Taxonomyهای ناشناس را حذف کنید.
Redirectها را بررسی نمایید.
Canonical و Meta Robots را کنترل کنید.
Cache، CDN و Sitemap را Purge کنید.
URLهای پاک‌شده را 404 یا 410 منطقی برگردانید.

ممکن است نتایج اسپم مدتی پس از پاک‌سازی باقی بمانند. پاک‌شدن از ایندکس به Crawl مجدد نیاز دارد.

مرحله سیزدهم: همه دسترسی‌ها را دوباره Rotate کنید

پس از اطمینان از پاکی سایت:

رمزهای WordPress
Salts
دیتابیس
SFTP و SSH
پنل هاست
DNS و CDN
SMTP
درگاه پرداخت
WooCommerce REST API
Application Passwordها
Git Deploy Key و CI Secret

برای هر Integration یک Credential مستقل بسازید. رمز Administrator نباید در ابزار ثالث ذخیره شود.

مرحله چهاردهم: کنترل‌های پیشگیرانه را فعال کنید

2FA یا Passkey برای مدیران
WAF و Rate Limit
آپدیت منظم
حذف افزونه بلااستفاده
File Integrity Monitoring
Audit Log
بکاپ خارج از هاست
محدودیت Upload
حداقل دسترسی
مانیتورینگ Search Console

راهنمای کامل در مقاله افزایش امنیت وردپرس، امنیت ورود و فایروال وردپرس موجود است.

اعتبارسنجی پس از پاک‌سازی

قبل از بازکردن سایت، فقط صفحه اصلی را تست نکنید.

WordPress

ورود مدیر و 2FA
ایجاد و ویرایش نوشته
آپلود رسانه
REST API
Cron
ایمیل بازیابی رمز

WooCommerce

محصول و جست‌وجو
سبد و Checkout
درگاه در حالت تست
سفارش و ایمیل
Refund
My Account
دانلود فایل

امنیت

Core Checksum
Plugin Checksum
عدم وجود User ناشناس
عدم وجود PHP غیرمجاز در Uploads
عدم وجود Cron ناشناس
Log بدون تکرار Indicatorها

مانیتورینگ ۷۲ ساعت اول

پس از بازگشایی، Log را با دقت بیشتر بررسی کنید:

تلاش ورود
درخواست به فایل حذف‌شده
ایجاد دوباره فایل
ترافیک POST غیرعادی
خطاهای WAF
ایمیل Spam
تغییر User و Option
سفارش یا Refund غیرعادی

درخواست مکرر به Backdoor حذف‌شده می‌تواند نشان دهد مهاجم هنوز تلاش می‌کند، اما اگر فایل دوباره ساخته شود Persistence باقی مانده است.

آیا باید مشتریان را مطلع کنیم؟

اگر احتمال دسترسی غیرمجاز به اطلاعات شخصی، سفارش، ایمیل، تلفن یا داده پرداخت وجود دارد، با مشاور حقوقی و الزامات محل فعالیت بررسی کنید. تصمیم باید براساس نوع داده، دامنه حادثه، ریسک افراد و قوانین قابل اجرا باشد.

هیچ‌گاه بدون بررسی فنی ادعا نکنید داده‌ای سرقت نشده است. گزارش حادثه باید دقیق، مستند و بدون حدس باشد.

اشتباهات رایج در پاک‌سازی

حذف اولین فایل مشکوک و پایان کار
Restore آخرین Backup بدون تعیین زمان نفوذ
تغییر رمز روی کامپیوتر آلوده
نصب چند اسکنر بدون تحلیل
حذف همه فایل‌های Base64
نادیده‌گرفتن دیتابیس و Cron
فراموش‌کردن MU Plugin و Drop-in
بازکردن Checkout پیش از بررسی درگاه
ارسال درخواست Review گوگل پیش از Clean-up کامل
حذف Log و شواهد

خطا: بدافزار بعد از حذف برمی‌گردد

Persistence هنوز فعال است. Cron، MU Plugin، User، دیتابیس، فایل خارج از Root، حساب هاست و سایت‌های دیگر همان Account را بررسی کنید.

خطا: Checksum Core ناموفق است

نسخه، Locale، فایل سفارشی Root و تغییر قانونی را بررسی کنید. فایل Core تغییرکرده را از بسته رسمی جایگزین نمایید؛ از گزینه ناامن TLS برای دورزدن خطا استفاده نکنید.

خطا: سایت تمیز است اما گوگل هشدار می‌دهد

Security Issues، Cache، نمونه URLها و منابع خارجی را دوباره بررسی کنید. پس از تأیید کامل، Review درخواست دهید. ارزیابی ممکن است چند روز یا بیشتر زمان ببرد.

خطا: سایت بعد از بازسازی ۵۰۰ می‌دهد

نسخه PHP، Permission، wp-config.php، افزونه سفارشی، Object Cache و Error Log را بررسی کنید. فایل‌ها و دیتابیس ممکن است متعلق به نسخه‌های ناسازگار باشند.

خطا: سفارش‌های جدید بعد از Restore از بین رفته‌اند

Backup قدیمی روی دیتابیس زنده بازنویسی شده است. بازیابی Delta سفارش‌ها نیازمند تطبیق شناسه، HPOS، تراکنش و موجودی است و باید توسط متخصص انجام شود.

چک‌لیست پاک‌سازی سایت هک‌شده

Incident Timeline ساخته شده است.
Snapshot آلوده خارج از Web Root ذخیره شده است.
حادثه مهار شده است.
دستگاه مدیر بررسی شده است.
حساب‌ها و Sessionها بازبینی شده‌اند.
Core با Checksum رسمی کنترل شده است.
افزونه و قالب از Source سالم بازسازی شده‌اند.
MU Plugin و Drop-in بررسی شده‌اند.
Uploads برای PHP و فایل ناشناس بررسی شده است.
wp-config و htaccess کنترل شده‌اند.
دیتابیس، Option، User Meta و Cron پاک‌اند.
درگاه، سفارش و فایل دانلودی بررسی شده‌اند.
Credentialها بعد از Clean-up Rotate شده‌اند.
2FA، WAF و مانیتورینگ فعال شده‌اند.
Search Console بررسی و Review ارسال شده است.
Restore و Checkout آزمایش شده‌اند.
گزارش Incident و اقدامات پیشگیرانه ثبت شده است.

📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و انتقال وردپرس به هاست جدید

پرسش‌های متداول

آیا نصب افزونه اسکنر سایت را کاملاً پاک می‌کند؟

خیر. اسکنر ابزار تشخیص است و ممکن است دیتابیس، Credential، سرور یا Backdoor پیچیده را کامل پوشش ندهد. پاک‌سازی به تحلیل و بازسازی نیاز دارد.

آیا می‌توان فقط Core را دوباره نصب کرد؟

بازسازی Core مفید است، اما آلودگی می‌تواند در wp-content، دیتابیس، MU Plugin، Cron یا حساب هاست باشد.

آیا آخرین Backup همیشه بهترین نسخه است؟

خیر. ممکن است آلودگی مدت‌ها قبل آغاز شده باشد. نسخه باید مربوط به پیش از نفوذ و پس از بستن مسیر آسیب‌پذیری باشد.

آیا تغییر رمز کافی است؟

خیر. رمز، Session، Salt، API Key و Application Password باید همراه با حذف Backdoor و اصلاح آسیب‌پذیری مدیریت شوند.

چرا Google صفحه‌های اسپم را هنوز نشان می‌دهد؟

ایندکس با Crawl مجدد به‌روز می‌شود. صفحه آلوده باید حذف، پاسخ درست داده و Search Console Review تکمیل شود.

آیا WP-CLI Checksum همه Malwareها را پیدا می‌کند؟

خیر. Core و بعضی افزونه‌های مخزن را با نسخه رسمی مقایسه می‌کند، اما فایل سفارشی، دیتابیس، Uploads و افزونه تجاری به بررسی جدا نیاز دارند.

جمع‌بندی

پاک‌سازی وردپرس هک‌شده با حذف علامت ظاهری پایان نمی‌یابد. ابتدا باید حادثه مستند و مهار شود، سپس فایل، دیتابیس، حساب، Cron، Credential، درگاه و زیرساخت با Source سالم مقایسه شوند.

در حادثه گسترده، بازسازی محیط تمیز معمولاً قابل اعتمادتر از اصلاح دستی تک‌تک فایل‌هاست. Backup فقط زمانی مفید است که پیش از نفوذ ساخته شده باشد و مسیر ورود مهاجم نیز بسته شود.

پس از بازگشایی، 2FA، WAF، File Integrity، Audit Log، بکاپ خارج از هاست و Search Console باید به برنامه دائمی نگهداری تبدیل شوند. هدف نهایی فقط آنلاین‌کردن دوباره سایت نیست؛ باید بتوان با شواهد قابل اتکا نشان داد عامل نفوذ حذف و احتمال تکرار کاهش یافته است.

منابع رسمی

آموزش‌های تازه، کد آماده و رفع خطاهر هفته در کانال Dev Source؛ رایگان.

✈️ کانال تلگرام 🟣 کانال روبیکا