اگر نشانهای از هک شدن وردپرس میبینید، هدف اول «حذف سریع یک فایل مشکوک» نیست؛ باید همزمان آلودگی را مهار کنید، شواهد را حفظ کنید، مسیر نفوذ را پیدا کنید و فقط بعد از رفع علت اصلی سایت را به حالت عادی برگردانید. پاکسازی ناقص معمولاً باعث میشود Backdoor، کاربر ادمین ناشناس، Cron مخرب یا کد تزریقشده در دیتابیس باقی بماند و سایت دوباره آلوده شود. در این راهنما یک مسیر عملی برای شناسایی Malware، پاکسازی، بازیابی و سختسازی وردپرس ارائه میکنیم.
از کجا بفهمیم سایت وردپرس هک شده است؟
نشانههای آلودگی همیشه واضح نیستند. بعضی حملات با Redirect کردن بازدیدکننده، ساخت صفحه Spam یا نمایش تبلیغات ناشناس خودشان را نشان میدهند؛ بعضی دیگر فقط یک Backdoor مخفی میگذارند تا مهاجم بعداً برگردد. این موارد را جدی بگیرید:
- Redirect ناخواسته به دامنههای ناشناس یا صفحات تبلیغاتی.
- ایجاد کاربر Administrator که شما آن را نساختهاید.
- تغییر فایلهای PHP، JavaScript،
.htaccessیاwp-config.phpبدون دلیل مشخص. - وجود فایلهای PHP در مسیرهایی که معمولاً محل آپلود رسانه هستند.
- ارسال Spam، مصرف غیرعادی CPU یا افزایش ناگهانی درخواستهای خروجی.
- صفحات SEO Spam یا URLهای عجیب که در Search Console ظاهر میشوند.
- هشدار مرورگر، سرویس امنیتی یا افزونهای مثل Wordfence درباره فایل یا کد مشکوک.
یک علامت بهتنهایی دلیل قطعی آلودگی نیست، اما وجود چند نشانه همزمان باید مثل Incident امنیتی بررسی شود.
مرحله اول: قبل از پاکسازی، آلودگی را مهار کنید
در یک سایت آلوده، ادامه فعالیت عادی میتواند باعث سرقت Session، تغییر بیشتر فایلها یا آسیب به کاربران شود. اگر نشانههای نفوذ فعال است، دسترسی عمومی را محدود کنید یا سایت را موقتاً پشت Maintenance/Access Control قرار دهید. اگر فروشگاه یا سرویس حیاتی دارید، محدودسازی را طوری انجام دهید که لاگها و شواهد حذف نشوند.
قبل از هر حذف یا بازنویسی، یک Snapshot یا Backup کامل از فایلها، دیتابیس و لاگهای مرتبط بگیرید. برای طراحی یک روند بازیابی مطمئن، راهنمای بکاپ و بازیابی اطلاعات سرور را هم ببینید. این نسخه را برای بازگردانی مستقیم استفاده نکنید مگر اینکه بعداً پاک بودن آن تأیید شود؛ نقش اصلی آن در این مرحله حفظ شواهد و امکان مقایسه است.
مرحله دوم: همه دسترسیهای حساس را بازبینی کنید
اگر مهاجم هنوز Credential معتبر داشته باشد، حتی پاکترین نسخه وردپرس هم دوباره آلوده میشود. بنابراین فهرست دسترسیها را از پنل وردپرس فراتر ببرید:
- رمز همه حسابهای Administrator وردپرس.
- حساب هاست، cPanel/DirectAdmin یا پنل مدیریت سرور.
- SFTP/FTP و SSH.
- رمز دیتابیس در صورت احتمال افشای
wp-config.php. - کلیدهای API، SMTP، سرویسهای پرداخت و سرویسهای شخص ثالث.
کاربران ادمین ناشناس را حذف یا غیرفعال کنید و Sessionهای فعال را با تعویض Authentication Keys و Salts وردپرس باطل کنید. بهتر است تغییر رمزها از دستگاهی انجام شود که از سالم بودن آن مطمئن هستید.
مرحله سوم: فایلهای هسته وردپرس را با نسخه رسمی مقایسه کنید
یکی از بهترین روشها این است که فایلهای Core را با نسخه رسمی مقایسه کنید. اگر WP-CLI روی هاست یا سرور شما فعال است، دستور زیر برای بررسی Checksum هسته وردپرس مفید است:
wp core verify-checksumsوجود خطا به معنی «حتماً Malware» نیست؛ ممکن است فایل عمداً تغییر کرده باشد. اما در یک Incident امنیتی، فایل Core تغییریافته باید بررسی شود. بهجای ترمیم دستی کد ناشناس، معمولاً امنتر است هسته وردپرس را از منبع رسمی مجدداً نصب کنید و فقط فایلهای اختصاصی مثل wp-config.php و محتوای wp-content را با بررسی دقیق نگه دارید.
مرحله چهارم: افزونهها و قالبها را منبع اصلی آلودگی در نظر بگیرید
بخش بزرگی از نفوذهای وردپرس از افزونه یا قالب آسیبپذیر، نسخه قدیمی یا کد Nulled شروع میشود. فهرست افزونهها را با تاریخ آخرین بروزرسانی و نیاز واقعی آنها مقایسه کنید. هر افزونه یا قالبی که استفاده نمیشود باید حذف شود، نه اینکه فقط غیرفعال بماند.
برای افزونههای مخزن رسمی وردپرس میتوان از WP-CLI برای مقایسه فایلها استفاده کرد:
wp plugin verify-checksums --allاین بررسی برای همه محصولات تجاری یا افزونههای خارج از WordPress.org نتیجه قطعی نمیدهد. در چنین مواردی فایل نصب سالم را مستقیماً از فروشنده یا مخزن رسمی دریافت و جایگزین کنید.
اگر میخواهید با الگوهای رایج ریسک در افزونهها آشنا شوید، مقاله آسیبپذیرترین افزونههای وردپرس در آکادمی وانسرور مکمل خوبی برای این مرحله است.
مرحله پنجم: مسیرهای حساس wp-content را بررسی کنید
مهاجم معمولاً جایی را انتخاب میکند که در بروزرسانیهای عادی پاک نشود. مسیرهای زیر را با دقت بررسی کنید:
wp-content/uploadsبرای فایلهای PHP یا نامهای غیرعادی.wp-content/mu-pluginsبرای افزونههای Must-Use ناشناس.- قالب فعال، مخصوصاً
functions.phpو فایلهای تازه ایجادشده. - پوشههای Cache یا Temp که امکان اجرای PHP در آنها وجود دارد.
- فایلهای
.htaccessدر ریشه و زیرپوشهها.
برای پیدا کردن فایل PHP در پوشه Uploads میتوانید فقط بهعنوان مرحله شناسایی از دستور زیر استفاده کنید:
find wp-content/uploads -type f -name "*.php" -printوجود فایل PHP در Uploads در بسیاری از سایتها غیرعادی است، اما حذف کورکورانه توصیه نمیشود؛ ابتدا محتوا، تاریخ تغییر و وابستگی آن به افزونههای معتبر را بررسی کنید.
مرحله ششم: دیتابیس وردپرس را فراموش نکنید
پاکسازی فایلها کافی نیست. مهاجم میتواند Payload را داخل wp_options، محتوای نوشتهها، Widgetها، Templateها یا حسابهای کاربری ذخیره کند. این موارد را بررسی کنید:
- کاربران Administrator و ایمیلهای آنها.
- مقادیر مشکوک در Options، مخصوصاً مواردی که Autoload میشوند.
- JavaScript یا iframe ناشناس در نوشتهها، برگهها و ابزارکها.
- URLهای خارجی غیرعادی در تنظیمات قالب و افزونهها.
- Scheduled Eventها و Cronهای ناشناخته.
در دیتابیس Production از Replace گسترده روی رشتههای ناشناس خودداری کنید. ابتدا Backup بگیرید و هر تغییر را روی یک کپی یا Staging بررسی کنید.
مرحله هفتم: با Wordfence اسکن کنید، اما فقط به یک اسکن تکیه نکنید
راهنمای رسمی Wordfence برای پاکسازی سایت هکشده بر اسکن، شناسایی فایلهای تغییرکرده و ترمیم یا حذف موارد آلوده تأکید دارد. اسکن Wordfence میتواند فایلهای مشکوک، تغییرات هسته و بعضی الگوهای Malware را پیدا کند؛ اما نتیجه «No issues found» بهتنهایی تضمین نمیکند که هیچ Backdoor سفارشی یا دسترسی سرقتشدهای باقی نمانده است.
بهتر است نتیجه اسکن را با Checksum، بررسی کاربران، لاگها، Cronها و فایلهای حساس ترکیب کنید. اگر به ابزار خط فرمان علاقه دارید، راهنمای نصب WPScan برای بررسی امنیتی وردپرس نیز میتواند برای ارزیابی آسیبپذیریهای شناختهشده مفید باشد.
مرحله هشتم: علت اصلی نفوذ را پیدا کنید
اگر فقط Malware را حذف کنید ولی Root Cause را نبندید، احتمال آلودگی مجدد بالاست. برای پیدا کردن علت، این سؤالها را پاسخ دهید:
- کدام افزونه، قالب یا نسخه WordPress در زمان حادثه قدیمی بوده است؟
- آیا حساب ادمین با رمز ضعیف یا بدون MFA وجود داشته است؟
- آیا ورود غیرعادی از IP یا کشور ناشناس در لاگها دیده میشود؟
- آیا FTP قدیمی یا Credential مشترک بین چند کاربر استفاده شده است؟
- آیا هاست یا سرور سیستمعامل و PHP پشتیبانیشده دارد؟
- آیا فایل Nulled یا افزونه دانلودشده از منبع غیررسمی روی سایت نصب شده است؟
زمان ایجاد اولین فایل مشکوک را با Access Log، Error Log و Login Log مقایسه کنید. این Timeline معمولاً سرنخ بهتری از حدس زدن نام Malware میدهد.
مرحله نهم: نسخه سالم را بازسازی یا Restore کنید
اگر Backup سالم از قبل از Incident دارید، Restore میتواند سریعترین مسیر باشد؛ اما فقط وقتی که تاریخ آلودگی و Root Cause را میدانید. بازگردانی یک Backup آلوده یا Restore کردن بدون Patch کردن افزونه آسیبپذیر، سایت را دوباره در همان وضعیت قبلی قرار میدهد.
در پروژههای حساس، روش مطمئنتر این است که WordPress Core، افزونهها و قالبها را از منابع رسمی دوباره Deploy کنید و فقط Uploadها و دادههای لازم را بعد از بررسی به محیط جدید منتقل کنید.
مرحله دهم: بعد از پاکسازی وردپرس را Hardening کنید
پس از بازیابی، سایت باید از حالت «پاکشده» به حالت «مقاومتر» برسد. حداقل اقدامات پیشنهادی:
- WordPress Core، افزونهها و قالبها را به نسخههای پشتیبانیشده ارتقا دهید.
- افزونه و قالب بلااستفاده را حذف کنید.
- برای حسابهای مدیریتی MFA فعال کنید.
- سطح دسترسی کاربران را بر اساس Least Privilege تنظیم کنید.
- برای دسترسی فایل از SFTP/SSH بهجای FTP ناامن استفاده کنید.
- ویرایش فایل از داخل پنل WordPress را در صورت عدم نیاز غیرفعال کنید.
- Backup منظم خارج از همان هاست داشته باشید و Restore آن را دورهای تست کنید.
- لاگ ورود، تغییر فایل و درخواستهای مشکوک را مانیتور کنید.
برای تکمیل Hardening در لایه وبسرور، راهنمای تنظیم هدرهای امنیتی HTTP روی NGINX و Apache نیز میتواند به کاهش بخشی از ریسکهای سمت مرورگر کمک کند. برای جلوگیری از ویرایش مستقیم فایلهای قالب و افزونه از داخل داشبورد میتوانید در wp-config.php از تنظیم زیر استفاده کنید:
define('DISALLOW_FILE_EDIT', true);این گزینه بهتنهایی جلوی نفوذ را نمیگیرد، اما در کنار MFA، بروزرسانی منظم و محدودسازی دسترسیها سطح حمله را کاهش میدهد.
آیا تعویض هاست بعد از هک ضروری است؟
خیر، همیشه لازم نیست. اگر Root Cause یک افزونه آسیبپذیر بوده و سرور سالم، بهروز و قابل مدیریت است، تعویض هاست راهحل اصلی نیست. اما اگر محیط میزبانی قدیمی، بدون Patch، فاقد Backup قابل اتکا یا محدود در کنترل امنیتی است، انتقال به زیرساخت بهتر میتواند بخشی از Recovery باشد. اگر برای بررسی لاگها، فایروال و تنظیمات سطح سیستمعامل به کنترل بیشتری نیاز دارید، یک سرور مجازی با دسترسی کامل برای مدیریت امنیتی گزینه مناسبتری از هاست اشتراکی است.
برای سایتی که به محیط بهروز، Backup و منابع مناسب WordPress نیاز دارد، انتخاب یک هاست مناسب برای وردپرس با زیرساخت قابل مدیریت میتواند نگهداری بعد از Incident را سادهتر کند؛ با این حال، هیچ هاستی جای بروزرسانی، MFA و مدیریت صحیح افزونهها را نمیگیرد.
چکلیست نهایی قبل از بازگرداندن سایت به حالت عادی
- Backup شواهد و نسخه قبل از پاکسازی نگهداری شده است.
- همه حسابها و Sessionهای حساس بازبینی و Credentialهای لازم تعویض شدهاند.
- Core، افزونهها و قالبها از منبع معتبر نصب یا Verify شدهاند.
- فایلهای Uploads، MU Plugins،
.htaccessوwp-config.phpبررسی شدهاند. - کاربران، Cronها و دادههای مشکوک در دیتابیس بررسی شدهاند.
- Root Cause شناسایی و Patch یا حذف شده است.
- اسکن امنیتی نهایی و کنترل Checksum انجام شده است.
- MFA، Backup، Hardening و مانیتورینگ بعد از Incident فعال شدهاند.
جمعبندی
پاکسازی سایت وردپرس هکشده یک فرآیند Incident Response است، نه فقط حذف چند فایل آلوده. مهار حمله، حفظ Backup و شواهد، تعویض Credentialها، بررسی Core و افزونهها، پاکسازی دیتابیس، شناسایی Root Cause و Hardening بعد از Recovery باید بهصورت یک زنجیره انجام شوند. اگر یکی از این حلقهها حذف شود، احتمال بازگشت Malware یا Backdoor بالا میماند.