حذف بدافزار از سایت

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

بدافزار سایت ممکن است خود را به شکل ریدایرکت کاربران، صفحات اسپم، تبلیغات ناخواسته، فایل‌های PHP ناشناس، اسکریپت‌های مخرب JavaScript، حساب Administrator جدید، تغییر فایل‌های اصلی یا حتی کاهش ناگهانی ترافیک گوگل نشان دهد. در برخی حملات نیز هیچ علامت ظاهری مشخصی وجود ندارد و سایت در ظاهر کاملاً طبیعی کار می‌کند.

Google Search Console می‌تواند برخی صفحات هک‌شده یا فایل‌های مشکوک را در بخش Security Issues گزارش کند. گوگل همچنین توصیه می‌کند مدیران سایت به‌صورت دوره‌ای نتایج دامنه خود را بررسی کنند؛ زیرا صفحات ناشناخته یا محتوایی که مدیر سایت ایجاد نکرده ممکن است نشانه هک باشد.

در این مقاله بررسی می‌کنیم بدافزار سایت چیست، چگونه متوجه آلودگی شویم، چه قسمت‌هایی باید بررسی شوند، حذف بدافزار از وردپرس چگونه انجام می‌شود، چرا بعضی سایت‌ها پس از پاک‌سازی دوباره آلوده می‌شوند و بعد از برطرف شدن مشکل چه اقداماتی برای امنیت و سئو ضروری هستند.

---

بدافزار سایت چیست؟

Malware کوتاه‌شده عبارت Malicious Software است و به کد یا نرم‌افزاری گفته می‌شود که با هدف انجام فعالیت ناخواسته یا آسیب‌زا اجرا می‌شود.

در یک وب‌سایت، بدافزار الزاماً شبیه ویروس کامپیوتر نیست. ممکن است فقط چند خط PHP یا JavaScript باشد که به فایل قانونی سایت اضافه شده است.

برای مثال بدافزار می‌تواند باعث شود:

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

گوگل نیز میان Malware اجراشونده در وب و Harmful Downloads تفاوت قائل می‌شود و موارد شناسایی‌شده را می‌تواند در Security Issues نمایش دهد.

در نتیجه، اصطلاح «سایت آلوده» می‌تواند طیف بزرگی از مشکلات امنیتی را شامل شود.

---

تفاوت هک شدن سایت و آلوده شدن به بدافزار

هک شدن و آلودگی به Malware دو مفهوم مرتبط اما متفاوت‌اند.

نفوذ زمانی اتفاق می‌افتد که شخص یا برنامه‌ای بدون مجوز بتواند به بخشی از سایت یا زیرساخت آن دسترسی پیدا کند.

Malware یکی از چیزهایی است که مهاجم ممکن است بعد از نفوذ روی سایت قرار دهد.

برای مثال ممکن است مهاجم با استفاده از یک افزونه آسیب‌پذیر وارد سایت شود و سپس فایل مخربی ایجاد کند. در این سناریو آسیب‌پذیری افزونه نقطه ورود است و فایل مخرب بخشی از Payload یا Persistence محسوب می‌شود.

از طرف دیگر ممکن است مهاجم فقط حساب Administrator جدیدی بسازد و هیچ Malware مشخصی روی سایت قرار ندهد.

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

مستندات رسمی WordPress نیز تأکید می‌کند که پس از Incident باید مشخص شود مهاجم چگونه وارد شده است تا همان Attack Vector دوباره قابل استفاده نباشد.

---

بدافزار چگونه وارد سایت می‌شود؟

راه ورود به نوع سایت و زیرساخت بستگی دارد، اما در بسیاری از وب‌سایت‌ها چند عامل بیشتر دیده می‌شوند.

افزونه یا قالب آسیب‌پذیر

یک افزونه دارای Vulnerability ممکن است به مهاجم اجازه دهد فایل ایجاد کند، کد اجرا کند یا تنظیمات سایت را تغییر دهد.

به همین دلیل به‌روزرسانی WordPress، Plugins و Themes یک اقدام امنیتی پایه محسوب می‌شود. مستندات رسمی WordPress توصیه می‌کند نسخه‌های قدیمی به‌روز شوند و نسخه‌های WordPress فقط از منابع رسمی دریافت شوند.

قالب یا افزونه نامعتبر

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

نسخه‌های Nulled مخصوصاً ریسک بالایی دارند؛ زیرا مدیر سایت دقیقاً نمی‌داند چه تغییراتی روی PHP و JavaScript آن‌ها انجام شده است.

راهنمای Hardening وردپرس نیز توصیه می‌کند قالب و افزونه فقط از WordPress.org یا منابع شناخته‌شده و قابل اعتماد دریافت شوند.

رمز عبور سرقت‌شده

گاهی هیچ آسیب‌پذیری نرم‌افزاری وجود ندارد.

مهاجم Password مربوط به WordPress، Hosting، FTP یا Email را به دست می‌آورد و مانند یک کاربر قانونی وارد می‌شود.

در چنین حالتی Malware Scanner ممکن است Payload را پیدا کند، اما علت واقعی Incident سرقت Credential است.

آلودگی کامپیوتر مدیر سایت

کامپیوتری که برای مدیریت Hosting یا WordPress استفاده می‌شود نیز بخشی از زنجیره امنیت است.

اگر سیستم مدیر به Keylogger یا Malware آلوده باشد، رمزهای جدید نیز ممکن است دوباره سرقت شوند. WordPress و Google هر دو بر سالم و به‌روز بودن سیستمی که برای مدیریت سایت استفاده می‌شود تأکید می‌کنند.

تنظیمات ناامن سرور

Permissionهای بسیار باز، سرویس‌های قدیمی، FTP ساده یا نرم‌افزارهای Patch نشده می‌توانند سطح حمله را افزایش دهند.

Google توصیه می‌کند نرم‌افزارهای سرور مرتب Patch شوند و برای انتقال فایل به‌جای پروتکل‌های Plain-text از SSH یا SFTP استفاده شود.

---

مهم‌ترین نشانه‌های وجود بدافزار در سایت

آلودگی همیشه با یک Warning بزرگ روی صفحه اصلی مشخص نمی‌شود.

بعضی Malwareها عمداً طوری طراحی می‌شوند که فقط در شرایط خاص اجرا شوند.

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

Google نیز در سیاست‌های Spam خود توضیح می‌دهد که سایت هک‌شده می‌تواند محتوای تزریق‌شده یا Redirectهایی داشته باشد که فقط برای بعضی User-Agentها، Deviceها یا Referrerها فعال می‌شوند.

نشانه‌های مهم شامل تغییر فایل‌ها، صفحات ناشناس در Google، هشدار Search Console، کاربر Administrator ناشناس، ریدایرکت، Popup غیرعادی، مصرف منابع نامعمول، ارسال Spam و فایل‌های PHP ناشناخته هستند.

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

---

اولین اقدام بعد از شناسایی بدافزار چیست؟

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

این کار گاهی باعث از بین رفتن شواهدی می‌شود که برای پیدا کردن مسیر نفوذ ضروری هستند.

اگر Incident جدی است، ابتدا باید وضعیت فعلی حفظ و دامنه خسارت مشخص شود.

WordPress در راهنمای سایت هک‌شده توصیه می‌کند پس از شناسایی نفوذ ابتدا شرایط محدود شود، حساب‌ها و Sessionهای فعال بررسی شوند و Backup تهیه شود.

هدف مرحله اول پاسخ به سه سؤال است:

مهاجم چه زمانی وارد شده است؟

از چه روشی وارد شده است؟

چه بخش‌هایی را تغییر داده است؟

اگر پاسخ سؤال سوم فقط «یک فایل» باشد اما در واقع Backdoor دیگری وجود داشته باشد، آلودگی دوباره برمی‌گردد.

---

آیا از سایت آلوده بکاپ بگیریم؟

بله، در بسیاری از Incidentها منطقی است که قبل از شروع پاک‌سازی یک Snapshot یا Backup از وضعیت آلوده تهیه شود.

این Backup نباید به‌عنوان نسخه سالم شناخته شود.

هدف آن حفظ شواهد و امکان بررسی بعدی است.

WordPress نیز تهیه Backup را حتی پس از شناسایی Hack توصیه می‌کند؛ زیرا Backup بخشی از فرآیند Continuity و Recovery محسوب می‌شود.

نسخه آلوده را کاملاً از Backupهای سالم جدا کنید و نام یا Tag مشخصی برای آن در نظر بگیرید.

---

سایت آلوده را آنلاین نگه داریم یا موقتاً محدود کنیم؟

پاسخ به نوع Malware بستگی دارد.

اگر سایت در حال:

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

در چنین شرایطی ممکن است محدود کردن موقت سایت، فعال کردن Maintenance Mode یا ایزوله کردن قسمت آسیب‌دیده منطقی باشد.

اما اگر قصد تحلیل Incident دارید، تغییرات باید کنترل‌شده انجام شوند تا Log و Evidence از بین نروند.

در پروژه‌های حساس بهتر است Cleanup ابتدا روی یک محیط جداگانه انجام شود.

---

حذف بدافزار از سایت وردپرسی چگونه انجام می‌شود؟

پاک‌سازی حرفه‌ای وردپرس را بهتر است به چند مرحله تقسیم کنیم.

اول باید مشخص شود چه چیزی آلوده است؛ سپس فایل‌های قانونی با نسخه سالم مقایسه شوند، Database بررسی شود، Accessها بازبینی شوند و در پایان Vulnerability اصلی Patch شود.

تنها اجرای یک Malware Scan و کلیک روی Delete برای Incidentهای جدی کافی نیست.

مرحله اول: بررسی Google Search Console

اگر سایت در Search Console ثبت شده است، یکی از اولین بخش‌هایی که باید بررسی شود:

Security & Manual Actions → Security Issues

است.

Google در این گزارش می‌تواند نمونه URLهایی را نشان دهد که Hacked Content، Malware، Social Engineering یا Harmful Download در آن‌ها شناسایی شده است.

URLهای نمونه همیشه تمام فایل‌های آلوده نیستند؛ آن‌ها فقط می‌توانند نقطه شروع بررسی باشند.

اگر یک URL آلوده گزارش شده است، باید مشخص شود کدام فایل یا رکورد Database آن را تولید می‌کند.

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

جستجوی زیر یکی از روش‌های ساده برای پیدا کردن صفحات مشکوک است:

site:yourdomain.com

اگر سایت شما مثلاً ۵۰۰ صفحه قانونی دارد اما هزاران URL درباره دارو، قمار یا موضوعات کاملاً نامرتبط مشاهده می‌کنید، احتمال SEO Spam مطرح می‌شود.

Google نیز بررسی دوره‌ای دامنه با اپراتور site: را برای پیدا کردن صفحات یا Contentهای ناشناخته توصیه می‌کند.

البته افزایش URLها همیشه Malware نیست؛ پارامترها، Filterها و مشکلات فنی SEO نیز می‌توانند URL اضافی ایجاد کنند.

مرحله سوم: فایل‌های تغییرکرده را پیدا کنید

در WordPress مهم است مشخص کنید کدام فایل‌ها نسبت به نسخه رسمی تغییر کرده‌اند.

اگر Version Control دارید، مقایسه فایل‌ها با نسخه قبلی بسیار ارزشمند است.

راهنمای رسمی WordPress نیز استفاده از Version Control یا مقایسه فایل‌ها با نسخه رسمی WordPress را برای شناسایی تغییرات مفید می‌داند.

به‌خصوص فایل‌هایی که اخیراً تغییر کرده‌اند، در مسیر غیرعادی ایجاد شده‌اند یا پسوند PHP دارند اما در Upload Directory قرار گرفته‌اند، باید بررسی شوند.

اما Modified Time نیز مدرک قطعی نیست؛ مهاجم می‌تواند زمان فایل را تغییر دهد.

فایل‌های حساس وردپرس که باید بررسی شوند

برخی فایل‌ها به دلیل اجرا شدن در تعداد زیادی Request برای مهاجمان جذاب هستند.

WordPress در راهنمای رسمی خود به بررسی فایل‌هایی مانند .htaccess، index.php، header.php، footer.php و فایل‌های Function اشاره می‌کند؛ زیرا تغییر آن‌ها می‌تواند روی بخش بزرگی از سایت اثر بگذارد.

همچنین باید مسیرهای:

wp-admin

wp-includes

wp-content/plugins

wp-content/themes

wp-content/uploads

و Root سایت بررسی شوند.

وجود فایل PHP در Uploads همیشه Malware نیست، اما در بسیاری از سایت‌ها دلیل قانونی مشخصی برای اجرای PHP در این مسیر وجود ندارد و چنین فایل‌هایی نیاز به بررسی دارند.

فایل‌های wp-admin و wp-includes را چگونه پاک‌سازی کنیم؟

یکی از روش‌های امن‌تر نسبت به ویرایش خط‌به‌خط صدها فایل این است که فایل‌های Core با نسخه رسمی WordPress جایگزین شوند.

WordPress در راهنمای Recovery خود اشاره می‌کند که پوشه‌های wp-admin و wp-includes را می‌توان با نسخه مناسب و سالم جایگزین کرد، درحالی‌که wp-content به دلیل داشتن Theme، Plugin و محتوای سفارشی نیازمند دقت بیشتری است.

نکته مهم این است که صرف Overwrite کردن فایل‌ها ممکن است فایل جدیدی را که مهاجم ایجاد کرده پاک نکند.

به همین دلیل باید فایل‌های اضافی نیز شناسایی شوند.

WP-CLI و بررسی Integrity وردپرس

اگر دسترسی SSH و WP-CLI دارید، ابزارهای Integrity Check می‌توانند در تشخیص تغییر فایل‌های Core و افزونه‌ها کمک کنند.

هدف این بررسی مقایسه فایل‌های موجود با Checksum نسخه رسمی است.

اما نتیجه باید تحلیل شود.

فایل سفارشی همیشه Malware نیست و Malware نیز الزاماً فقط داخل Core قرار ندارد.

این ابزار یک Signal تشخیصی است، نه حکم نهایی.

بررسی wp-config.php

فایل wp-config.php بسیار حساس است، زیرا اطلاعات اتصال Database و Security Keys را در خود نگه می‌دارد.

هر خط ناشناخته یا Include مشکوک باید بررسی شود.

WordPress برای Hardening توصیه می‌کند دسترسی این فایل محدود باشد و فقط Web Server و Owner موردنیاز بتوانند آن را بخوانند.

در Incident جدی ممکن است لازم باشد Database Credential نیز Rotate شود.

اما ابتدا مطمئن شوید محیطی که Password جدید را در آن وارد می‌کنید سالم است.

بررسی فایل .htaccess

.htaccess یکی از فایل‌های مهم در Serverهای Apache است و برای Rewrite، Redirect و Access Control استفاده می‌شود.

Malware می‌تواند Ruleهایی به آن اضافه کند تا کاربران گوگل به دامنه دیگری هدایت شوند، Botها رفتار متفاوتی ببینند یا دسترسی به فایل مخرب پنهان شود.

WordPress نیز .htaccess را یکی از فایل‌هایی می‌داند که در Incidentهای امنیتی ارزش بررسی ویژه دارد.

اگر نسخه سالم قبلی دارید، مقایسه تغییرات بسیار مفید است.

فقط فایل‌ها را Scan نکنید؛ دیتابیس هم مهم است

یکی از دلایل شکست فرآیند حذف بدافزار از سایت این است که فقط File System بررسی می‌شود.

بعضی Payloadها داخل Database ذخیره می‌شوند.

برای مثال ممکن است JavaScript مخرب در Widget، Post، Option، Theme Setting یا سایر Metadataها قرار گرفته باشد.

اگر فایل‌ها پاک شوند اما Injection داخل Database باقی بماند، Malware دوباره در Front-end ظاهر خواهد شد.

بنابراین بررسی Database بخش ضروری Cleanup است.

کدام قسمت‌های دیتابیس وردپرس مهم‌ترند؟

در WordPress باید بسته به نوع Incident بخش‌هایی مانند Users، Options، Posts و Metadata بررسی شوند.

اگر حساب Administrator ناشناس مشاهده شد، فقط آن را حذف نکنید.

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

همچنین مقادیر غیرعادی در Options ممکن است مربوط به Plugin قانونی باشند، بنابراین پاک کردن رکوردهای ناشناس بدون شناخت می‌تواند سایت را خراب کند.

بررسی کاربران Administrator

یکی از روش‌های ساده برای حفظ Persistence ایجاد حساب مدیر است.

تمام Administratorهای WordPress باید Owner مشخص داشته باشند.

اگر حسابی را نمی‌شناسید، فعالیت آن را بررسی و دسترسی را لغو کنید.

راهنمای WordPress نیز در فرآیند Recovery بر Reset کردن Password کاربران و خاتمه Sessionهای فعال تأکید می‌کند.

برای سایت سازمانی بهتر است علاوه بر WordPress، کاربران Hosting، FTP/SFTP و Database نیز بررسی شوند.

Sessionهای فعال را قطع کنید

اگر مهاجم Session معتبر داشته باشد، تغییر Password همیشه فوراً Session را بی‌اثر نمی‌کند.

WordPress پیشنهاد می‌کند در Incident امنیتی Security Keys داخل wp-config.php به‌روزرسانی شوند تا Sessionهای فعال WordPress از اعتبار خارج شوند.

پس از این کار کاربران باید دوباره Login کنند.

این کار مخصوصاً زمانی مهم است که Administrator Account در اختیار مهاجم بوده باشد.

آیا Passwordها را همان ابتدا تغییر دهیم؟

در ابتدای Incident معمولاً لازم است Accessهای در معرض خطر محدود شوند، اما یک نکته وجود دارد.

اگر سیستم مدیر یا خود Server هنوز آلوده باشد، Password جدید ممکن است دوباره سرقت شود.

WordPress پیشنهاد می‌کند Credentialها پس از پاک‌سازی نیز دوباره تغییر کنند.

در عمل می‌توان در مرحله مهار Accessهای حساس را Rotate کرد و بعد از اطمینان از سلامت سیستم، Rotation نهایی انجام داد.

---

Backdoor چیست؟

Backdoor روشی است که مهاجم برای ورود دوباره به سیستم باقی می‌گذارد.

این Backdoor ممکن است یک فایل PHP کوچک، حساب Admin، Scheduled Task یا کد مخفی داخل فایل قانونی باشد.

Web Shell نیز نوعی ابزار است که می‌تواند پس از Compromise روی Web Server قرار گیرد و برای حفظ دسترسی غیرمجاز استفاده شود. CISA در راهنمای خود درباره Web Shellها هشدار داده که وجود آن‌ها می‌تواند به دسترسی غیرمجاز و گسترش Compromise منجر شود.

به همین دلیل پیدا کردن فقط Malware قابل مشاهده کافی نیست.

چرا Malware بعد از حذف دوباره برمی‌گردد؟

Reinfection معمولاً یکی از این معنی‌ها را دارد:

Payload دیگری پیدا نشده است، Backdoor باقی مانده، Credential هنوز در اختیار مهاجم است یا Vulnerability اولیه همچنان Patch نشده است.

برای مثال اگر Plugin آسیب‌پذیر عامل ورود بوده و همان نسخه دوباره روی سایت فعال شود، حتی یک Cleanup کامل نیز جلوی نفوذ بعدی را نمی‌گیرد.

همین موضوع یکی از مهم‌ترین تفاوت‌ها میان «پاک کردن فایل آلوده» و «Incident Response» است.

آیا Restore کردن بکاپ بهترین راه حذف بدافزار است؟

اگر یک Backup سالم و مربوط به قبل از نفوذ دارید، Restore می‌تواند یکی از سریع‌ترین روش‌های Recovery باشد.

اما سه شرط مهم وجود دارد.

نسخه باید واقعاً قبل از Compromise باشد، آسیب‌پذیری اولیه باید اصلاح شود و Credentialهای در معرض خطر باید Rotate شوند.

Google نیز در راهنمای Security Issues اشاره می‌کند که در Cleanup می‌توان فایل‌های آسیب‌دیده را با آخرین Backup سالم جایگزین کرد یا محتوای مخرب را مستقیماً حذف کرد.

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

ممکن است Backup دیروز نیز حاوی Backdoor باشد.

چگونه Backup سالم را انتخاب کنیم؟

فقط تاریخ Backup را نگاه نکنید.

Timeline Incident را با Logها، زمان تغییر فایل‌ها، اولین Alert امنیتی، تاریخ ایجاد User ناشناس و اولین URL اسپم در Search Console مقایسه کنید.

هرچه Backup قدیمی‌تر باشد احتمال سالم بودن بیشتر می‌شود، اما در مقابل اطلاعات جدید بیشتری از دست می‌رود.

در فروشگاه اینترنتی این تصمیم بسیار حساس است؛ زیرا Restore Database قدیمی می‌تواند سفارش‌های جدید را حذف کند.

Malware Scanner چه کاری انجام می‌دهد؟

Security Scannerها معمولاً به دنبال Signature شناخته‌شده، فایل تغییرکرده، URL مشکوک، Patternهای غیرعادی یا تفاوت با فایل‌های رسمی هستند.

این ابزارها برای تشخیص سریع بسیار مفیدند.

اما Scanner کامل و بی‌خطا وجود ندارد.

ممکن است False Positive ایجاد شود یا Malware جدید از Signature Detection عبور کند.

بنابراین در Incident مهم، نتیجه Scanner باید همراه با بررسی فایل، Database و Logs تحلیل شود.

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

گاهی بله و گاهی نه.

اگر Malware شناخته‌شده و محدود باشد، ابزارهای Cleanup می‌توانند بسیار مؤثر باشند.

اما در Compromise عمیق، ممکن است Database، Server Account، Cron، چند سایت روی Hosting یا حتی خود Workstation مدیر درگیر شده باشند.

در چنین شرایطی Plugin داخل همان WordPress فقط بخشی از تصویر را می‌بیند.

اگر سایت پس از چند بار Cleanup دوباره آلوده می‌شود، احتمالاً بررسی در سطح گسترده‌تری لازم است.

چند سایت روی یک هاست دارید؟ همه را بررسی کنید

در Shared Account یا VPS ممکن است چند Domain کنار یکدیگر باشند.

اگر فقط سایت A را پاک کنید ولی سایت B آلوده باقی بماند، امکان آلودگی مجدد وجود دارد؛ به‌خصوص اگر Permission و Ownership به‌درستی ایزوله نشده باشند.

پس Scope Incident باید شامل کل Account مربوطه باشد.

همچنین فایل‌های قدیمی مانند old-site، backup، test یا نسخه Staging فراموش‌شده می‌توانند نرم‌افزار آسیب‌پذیر داشته باشند.

Logها چه کمکی به حذف بدافزار می‌کنند؟

Logها کمک می‌کنند Timeline Incident مشخص شود.

می‌توانید بررسی کنید چه Requestهایی قبل از ایجاد فایل آلوده ارسال شده‌اند، چه IPهایی Login داشته‌اند، چه Endpointهایی غیرعادی فراخوانی شده‌اند و آیا تعداد زیادی Request به یک Plugin خاص وجود داشته است.

Google توصیه می‌کند مدیران سایت Logها را مرتب بررسی کنند، و OWASP نیز Logging و Monitoring را بخش مهمی از Detection و Incident Response می‌داند.

اگر Log فقط روی همان Server ذخیره شود، مهاجم دارای دسترسی بالا ممکن است بتواند آن را حذف یا تغییر دهد.

تاریخ تغییر فایل‌ها را چگونه استفاده کنیم؟

فرض کنید یک فایل مشکوک در ساعت 02:15 ایجاد شده است.

می‌توان Logهای اطراف همان زمان را بررسی کرد تا Request یا Login مرتبط پیدا شود.

این روش می‌تواند Attack Vector را محدود کند.

اما Timestamp به‌تنهایی قابل اعتماد کامل نیست.

در تحلیل حرفه‌ای باید چند Evidence مستقل با هم مقایسه شوند.

بدافزار SEO Spam چیست؟

یکی از انواع رایج آلودگی، ایجاد محتوای Spam روی یک دامنه معتبر است.

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

Google این رفتار را Content Injection می‌نامد و توضیح می‌دهد که مهاجمان ممکن است Text یا Linkهایی را به شکل مخفی داخل صفحه قرار دهند یا حتی محتوای متفاوتی به موتور جستجو نشان دهند.

این نوع آلودگی ممکن است مدت زیادی از دید صاحب سایت پنهان بماند.

Redirect Malware چیست؟

در این حمله کد مخرب کاربران را به URL دیگری هدایت می‌کند.

Redirect ممکن است فقط برای Mobile User، Search Visitor یا اولین Visit فعال شود.

Google اشاره می‌کند Redirectهای هک‌شده ممکن است بر اساس Referrer، User-Agent یا Device رفتار متفاوتی داشته باشند.

بنابراین اگر کاربران درباره Redirect شکایت دارند ولی مدیر سایت آن را مشاهده نمی‌کند، مشکل را رد نکنید.

JavaScript Malware

همه Malwareهای سایت PHP نیستند.

کد مخرب ممکن است داخل JavaScript قرار گیرد و در Browser کاربر اجرا شود.

در چنین شرایطی ممکن است Popup، Redirect، Fake Login Form یا Resource خارجی بارگذاری شود.

منبع JavaScript می‌تواند فایل Theme، Plugin، Database یا سرویس Third-party باشد.

Malware در فایل‌های تصویری؟

وجود .jpg یا .png در نام فایل تضمین نمی‌کند فایل بی‌خطر است.

Server Configuration و Content واقعی اهمیت دارند.

از سوی دیگر، هر فایل با نام عجیب نیز Malware نیست.

تشخیص باید براساس محتوا، محل، رفتار و Context انجام شود.

Permission فایل‌ها را بعد از پاک‌سازی بررسی کنید

Permissionهای بیش‌ازحد باز می‌توانند ریسک را افزایش دهند.

در راهنمای Hardening رسمی WordPress، مقادیر عمومی 755 برای Directoryها و 644 برای Files به‌عنوان نمونه مطرح شده‌اند؛ اما تنظیم دقیق باید با Hosting و Ownership سیستم سازگار باشد.

هیچ‌گاه Permission کل سایت را بدون نیاز روی 777 قرار ندهید.

بعد از حذف بدافزار همه چیز را به‌روز کنید

بعد از پاک‌سازی باید WordPress Core، Plugins، Themes و در صورت مدیریت Server، نرم‌افزارهای زیرساختی به نسخه امن پشتیبانی‌شده منتقل شوند.

WordPress صراحتاً توصیه می‌کند بعد از Cleanup نصب به آخرین نسخه مناسب Update شود.

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

Plugin غیرفعال را نگه داریم؟

اگر Plugin واقعاً استفاده نمی‌شود، نگه داشتن کد اضافی روی Server مزیت چندانی ندارد.

هر Component اضافه بخشی از سطح حمله است.

این موضوع مخصوصاً درباره Pluginها و Themeهای قدیمی اهمیت بیشتری دارد.

فایل‌های اصلی را از منبع معتبر دریافت کنید

بعد از Hack ممکن است تصمیم بگیرید Theme یا Plugin را دوباره نصب کنید.

فایل جایگزین را از منبع رسمی و مطمئن دریافت کنید.

اگر همان ZIP ناشناخته‌ای را که قبلاً استفاده شده دوباره نصب کنید، ممکن است Backdoor را نیز دوباره وارد سایت کنید.

WordPress نیز تأکید می‌کند نسخه اصلی Core از وب‌سایت رسمی آن دریافت شود.

سیستم مدیر سایت را Scan کنید

اگر نقطه ورود مشخص نیست، Workstation مدیر را نادیده نگیرید.

Browser، Password Manager، FTP Client یا Credential ذخیره‌شده روی یک سیستم آلوده می‌توانند منبع Leak باشند.

Google توصیه می‌کند کامپیوترهایی که برای مدیریت Website استفاده می‌شوند به‌روز و عاری از Malware باشند.

Passwordهای مهم را تغییر دهید

پس از پاک‌سازی نهایی Credentialهای حساس را Rotate کنید.

این شامل WordPress Administrator، Hosting، SSH/SFTP، Database، Email Admin، CDN و سایر سرویس‌هایی است که احتمال دسترسی مهاجم به آن‌ها وجود دارد.

WordPress نیز تغییر دوباره Passwordها پس از پاک شدن سایت و استفاده از Passwordهای طولانی و منحصربه‌فرد را توصیه می‌کند.

اگر API Key یا Token داخل فایل آلوده یا Repository در معرض خطر بوده است، آن‌ها نیز باید Rotate شوند.

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

2FA احتمال سوءاستفاده مستقیم از Password سرقت‌شده را کاهش می‌دهد.

بهتر است حداقل روی WordPress Administrator، Hosting، Registrar، Email اصلی و CDN فعال باشد.

امنیت Email اهمیت ویژه‌ای دارد؛ زیرا معمولاً مسیر Password Reset سایر حساب‌ها است.

بعد از حذف بدافزار Search Console چه کنیم؟

اگر Google برای سایت Security Issue ثبت کرده است، ابتدا مطمئن شوید تمام موارد پاک شده‌اند و Vulnerability اصلی نیز برطرف شده است.

سپس از Security Issues درخواست Review ارسال کنید.

Google می‌گوید پس از تأیید رفع مشکل می‌توان Security Review درخواست کرد؛ بررسی Malware ممکن است چند روز طول بکشد و بعضی Reviewهای مربوط به Hacked Spam مدت بیشتری نیاز داشته باشند.

ارسال Request Review قبل از پاک‌سازی کامل می‌تواند زمان رفع Warning را طولانی‌تر کند.

در درخواست Review گوگل چه بنویسیم؟

توضیح کوتاه اما دقیق بهتر از جمله «مشکل را حل کردم» است.

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

Google نیز در راهنمای خود توصیه می‌کند هنگام Review توضیح داده شود مشکل چگونه پاک و Vulnerability چگونه اصلاح شده است.

صفحات اسپم را از گوگل حذف کنیم؟

ابتدا باید خود صفحات از سایت حذف یا اصلاح شوند.

برای بعضی URLهای حساس می‌توان از Removals Tool نیز برای پنهان کردن موقت نتیجه استفاده کرد، اما Google تأکید می‌کند حذف دائمی نیازمند Remove یا Update شدن Content، محدود شدن دسترسی یا استفاده درست از روش‌های Index Control است.

Removals Tool جای Cleanup سایت را نمی‌گیرد.

آیا حذف URLهای هک‌شده به سئو آسیب می‌زند؟

URLهایی که توسط مهاجم ایجاد شده‌اند معمولاً نباید به‌عنوان محتوای واقعی سایت باقی بمانند.

بعد از حذف Malware، وضعیت Response آن‌ها باید منطقی باشد.

برای URL جعلی که جایگزین قانونی ندارد، معمولاً برگشت 404 یا 410 طبیعی‌تر از Redirect کردن هزاران صفحه Spam به Homepage است.

مهم است Sitemap، Internal Link و Canonicalهای سایت نیز پس از Recovery بررسی شوند.

تأثیر Malware بر سئو

آلودگی ممکن است باعث هشدار Browser، کاهش Click، ایجاد URLهای Spam، تغییر Titleها، Redirect، Link Injection یا مصرف Crawl Budget شود.

Google Safe Browsing می‌تواند هنگام شناسایی محتوای خطرناک به کاربران Warning نمایش دهد و Search Console نیز درباره برخی مشکلات به Owner اطلاع می‌دهد.

به همین دلیل سرعت Detection و Recovery علاوه بر امنیت، برای SEO نیز اهمیت دارد.

بعد از Cleanup چه چیزهایی را تست کنیم؟

ظاهر سالم Homepage کافی نیست.

صفحات مهم سایت، Login، Search، فرم‌ها، Checkout، API، Cron، Sitemap، Robots.txt و Redirectها باید تست شوند.

اگر فروشگاه اینترنتی دارید، Cart، Payment و Order Flow نیز بررسی شوند.

همچنین سایت را با Mobile و Browser Incognito آزمایش کنید؛ زیرا بعضی Malwareها براساس Cookie یا Device رفتار متفاوتی دارند.

آیا کش سایت می‌تواند Malware قدیمی را نمایش دهد؟

بله.

پس از Cleanup ممکن است CDN، Page Cache یا Browser Cache هنوز نسخه قدیمی را نمایش دهد.

بعد از اطمینان از حذف آلودگی، Cacheهای مربوطه را Purge کنید.

اما قبل از پاک کردن همه Cache و Logها در مرحله اولیه Incident، مطمئن شوید Evidence موردنیاز برای تحلیل حفظ شده است.

CDN و Malware

CDN خودش معمولاً منشأ Malware اپلیکیشن نیست، اما می‌تواند نسخه Cache‌شده صفحه آلوده را نگه دارد.

از طرف دیگر WAF روی CDN می‌تواند بخشی از حملات Web را قبل از رسیدن به Origin مسدود کند.

پس از Recovery Ruleها و Origin Security را بازبینی کنید.

WAF بعد از حذف بدافزار چه کمکی می‌کند؟

Web Application Firewall می‌تواند بعضی Requestهای مشکوک را براساس Rule مسدود کند.

اما WAF جای Update را نمی‌گیرد.

اگر Plugin دارای Vulnerability شناخته‌شده است، راه‌حل اصلی Patch یا حذف آن است.

Security در WordPress نیز به‌عنوان کاهش Risk از طریق مجموعه Controls معرفی می‌شود، نه یک ابزار جادویی واحد.

Backup بعد از پاک‌سازی

وقتی مطمئن شدید سایت پاک و پایدار است، یک Backup جدید با برچسب «Clean Baseline» ایجاد کنید.

این نسخه در Incident آینده بسیار ارزشمند خواهد بود.

WordPress داشتن Backup و آگاهی از وضعیت سالم Installation را بخشی از آمادگی امنیتی می‌داند.

بهتر است حداقل یک نسخه Backup خارج از Server اصلی قرار داشته باشد.

Monitoring بعد از Incident

چند روز و هفته بعد از Cleanup اهمیت زیادی دارند.

اگر Malware دوباره ظاهر شود، باید سریعاً متوجه شوید.

مواردی مانند File Change، Login Administrator، Creation User، Security Alert، Server Resource و Search Console باید مانیتور شوند.

OWASP توصیه می‌کند Log و Monitoring به شکلی طراحی شوند که فعالیت مشکوک سریع تشخیص داده و برای آن Response مناسب تعریف شود.

چرا فقط نصب افزونه امنیتی کافی نیست؟

فرض کنید Scanner بسیار خوبی نصب کرده‌اید ولی Password هاست لو رفته است.

مهاجم اصلاً نیازی به Exploit کردن WordPress ندارد.

یا ممکن است Server قدیمی باشد یا Theme از منبع نامعتبر نصب شده باشد.

بنابراین دفاع باید چندلایه باشد.

Security Plugin یکی از Layers است، نه کل Security Architecture.

مدل صحیح برای جلوگیری از آلودگی مجدد

یک سایت سالم بعد از Incident بهتر است چند لایه دفاع داشته باشد: Hosting امن و نرم‌افزار به‌روز، WordPress و Pluginهای Patch شده، Access Control و 2FA، Backup مستقل، WAF در صورت نیاز، Logging و Monitoring.

راهنمای WordPress نیز امنیت را Risk Reduction می‌داند و تأکید می‌کند Limiting Access، Containment، Backup و Monitoring باید در کنار هم استفاده شوند.

اشتباهات رایج هنگام حذف بدافزار از سایت

حذف اولین فایل مشکوک و اعلام پایان مشکل یکی از بزرگ‌ترین اشتباهات است.

Restore کردن Backup بدون رفع Vulnerability نیز معمولاً به Reinfection منجر می‌شود.

اشتباه دیگر نصب چندین Security Plugin به‌صورت هم‌زمان و تصور این است که تعداد ابزار بیشتر الزاماً امنیت را افزایش می‌دهد.

همچنین حذف کورکورانه فایل‌های ناشناس خطرناک است؛ زیرا برخی فایل‌ها ممکن است متعلق به Application باشند.

Cleanup باید براساس مقایسه، Evidence و شناخت ساختار سایت انجام شود.

آیا حذف کامل سایت و نصب مجدد بهتر است؟

در بعضی پروژه‌ها بازسازی از یک Baseline سالم بهترین گزینه است.

اگر Application ساده است و Source Code، Database سالم و Assets معتبر دارید، Rebuild می‌تواند اطمینان بیشتری ایجاد کند.

اما این روش همیشه ممکن نیست.

سایت‌های بزرگ ممکن است Customization، User-generated Data، Orderها و فایل‌های مهم زیادی داشته باشند.

در WordPress نیز راهنمای رسمی توصیه می‌کند بعضی Components مانند Core را می‌توان جایگزین کرد، اما wp-content نیازمند بررسی دقیق‌تر است.

---

چه زمانی باید از متخصص امنیت کمک بگیریم؟

اگر سایت چند بار بعد از Cleanup دوباره آلوده می‌شود، اطلاعات مالی یا شخصی حساس درگیر شده، Server Root Access احتمالاً Compromise شده یا نمی‌توانید نقطه ورود را مشخص کنید، بررسی تخصصی منطقی است.

همچنین سازمان‌هایی که الزامات قانونی درباره Data Breach دارند ممکن است نیازمند Incident Response رسمی و حفظ Evidence باشند.

در چنین شرایطی حذف سریع فایل‌ها بدون مستندسازی می‌تواند تصمیم مناسبی نباشد.

---

پاک‌سازی بدافزار در سایت غیروردپرسی

اصول کلی تقریباً یکسان هستند.

باید Source Code با Baseline سالم مقایسه شود، Dependencies بررسی شوند، Database کنترل شود، Credentialها Rotate شوند، Logها تحلیل شوند و Vulnerability اصلی Patch شود.

تفاوت اصلی در ابزارها و معماری Application است.

برای Laravel، Node.js، Django یا CMSهای دیگر نباید روش مخصوص WordPress را بدون تطبیق اجرا کرد.

---

بدافزار و Upload Vulnerability

اگر Application اجازه Upload فایل می‌دهد، باید Extension، MIME Type، محل ذخیره و امکان Execution کنترل شود.

ضعف در File Upload می‌تواند مسیر مهمی برای قرار دادن فایل مخرب روی Server باشد.

این مشکل باید در Source Application اصلاح شود، نه اینکه فقط فایل آپلودشده حذف شود.

---

SQL Injection و Malware

در بعضی Incidentها آسیب‌پذیری SQL Injection ممکن است امکان تغییر Database را فراهم کند.

در این صورت حذف Script از Front-end کافی نیست.

Application باید از نظر Vulnerability نیز بررسی شود.

Google نیز در توصیه‌های امنیتی خود بررسی XSS و SQL Injection را برای صاحبان Server مطرح می‌کند.

---

XSS و تزریق کد

Cross-Site Scripting باعث می‌شود Script مخرب در Context صفحه معتبر به کاربر تحویل داده شود.

OWASP، XSS را نوعی Injection معرفی می‌کند که در آن Script مخرب از طریق Application به کاربران نمایش داده می‌شود.

اگر عامل آلودگی XSS است، پاک کردن Payload بدون اصلاح Output Encoding یا Input Handling باعث می‌شود مشکل دوباره قابل سوءاستفاده باشد.

---

چک‌لیست حذف بدافزار از سایت

• [ ] وضعیت فعلی سایت و زمان تقریبی شروع Incident ثبت شود.
• [ ] از نسخه آلوده Backup جداگانه تهیه شود.
• [ ] در صورت خطر برای کاربران، سایت یا بخش آلوده موقتاً محدود شود.
• [ ] Google Search Console و Security Issues بررسی شود.
• [ ] فایل‌های Core با نسخه رسمی مقایسه شوند.
• [ ] فایل‌ها و مسیرهای تازه یا غیرعادی بررسی شوند.
• [ ] .htaccess و فایل‌های Configuration کنترل شوند.
• [ ] Database برای Injection و کاربران ناشناس بررسی شود.
• [ ] تمام Administratorها و Accountهای Hosting بازبینی شوند.
• [ ] Sessionهای مشکوک خاتمه داده شوند.
• [ ] Backdoor و Persistence جستجو شود.
• [ ] همه سایت‌های موجود روی همان Hosting Account بررسی شوند.
• [ ] Logها برای پیدا کردن مسیر ورود تحلیل شوند.
• [ ] Vulnerability یا Credential اولیه شناسایی و اصلاح شود.
• [ ] Core، Theme، Plugin و Server Software به‌روزرسانی شوند.
• [ ] افزونه‌ها و فایل‌های غیرضروری حذف شوند.
• [ ] Credentialهای حساس پس از Cleanup نهایی Rotate شوند.
• [ ] 2FA برای حساب‌های مهم فعال شود.
• [ ] Backup سالم جدید تهیه و خارج از Server نگهداری شود.
• [ ] Cache و CDN پس از تأیید Cleanup پاک شوند.
• [ ] صفحات مهم سایت و Workflowهای حیاتی تست شوند.
• [ ] در صورت وجود Warning گوگل، Security Review درخواست شود.
• [ ] File Monitoring و Security Alert برای جلوگیری از آلودگی مجدد فعال شود.

---

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

در ۲۴ ساعت اول، Logs و Loginها را با حساسیت بیشتری بررسی کنید.

در چند روز بعد، File Change، Search Console، منابع Server و Administratorها را کنترل کنید.

پس از اطمینان از ثبات، یک Backup سالم جدید تهیه کنید.

در هفته‌های بعد Updateها و Security Alertها را به‌صورت منظم بررسی کنید.

هدف این است که Cleanup به یک اقدام یک‌باره تبدیل نشود، بلکه Incident باعث بهبود Security Baseline سایت شود.

---

سوالات متداول درباره حذف بدافزار از سایت

چگونه بفهمیم سایت بدافزار دارد؟

ریدایرکت ناخواسته، صفحات ناشناس در Google، Warning مرورگر، Security Issues در Search Console، فایل‌های تغییرکرده، حساب Administrator ناشناس و Popupهای مشکوک از نشانه‌های مهم هستند. Google نیز Security Issues و بررسی دوره‌ای نتایج site: را برای شناسایی بعضی مشکلات پیشنهاد می‌کند.

آیا حذف فایل آلوده برای پاک‌سازی سایت کافی است؟

معمولاً نباید چنین فرضی کرد. اگر Backdoor، Credential سرقت‌شده یا Vulnerability اولیه باقی مانده باشد، سایت می‌تواند دوباره آلوده شود.

بهترین روش حذف بدافزار وردپرس چیست؟

باید Core با نسخه رسمی مقایسه یا جایگزین شود، wp-content دقیق بررسی شود، Database و کاربران کنترل شوند و مسیر نفوذ نیز Patch شود. WordPress توصیه می‌کند Coreهای قابل جایگزینی با نسخه سالم جایگزین و فایل‌هایی مانند .htaccess نیز بررسی شوند.

آیا Restore بکاپ سایت هک‌شده را پاک می‌کند؟

اگر Backup مربوط به قبل از نفوذ باشد، می‌تواند Recovery را بسیار سریع کند؛ اما اگر Vulnerability اولیه همچنان وجود داشته باشد، Reinfection ممکن است رخ دهد.

چگونه بفهمیم Backup آلوده نیست؟

Timeline نفوذ را با تاریخ Backup مقایسه کنید و نسخه را قبل از Production در محیط جداگانه Scan و Test کنید. جدیدترین Backup الزاماً سالم‌ترین نسخه نیست.

اگر سایت پس از پاک‌سازی دوباره آلوده شود مشکل چیست؟

معمولاً Persistence، Backdoor، Credential لو رفته، سایت آلوده دیگر روی همان Account یا Vulnerability رفع‌نشده وجود دارد.

آیا Malware Scanner به‌تنهایی کافی است؟

برای Infection ساده ممکن است بسیار کمک‌کننده باشد، اما در Incident جدی باید Files، Database، Users، Logs و Server Scope نیز بررسی شوند.

بعد از حذف بدافزار رمزها را تغییر دهیم؟

بله. Credentialهای در معرض خطر باید Rotate شوند و WordPress نیز توصیه می‌کند پس از پاک شدن سایت Passwordها دوباره تغییر داده شوند.

آیا حذف بدافزار روی سئو تأثیر دارد؟

پاک‌سازی سریع می‌تواند جلوی گسترش صفحات Spam، Redirect و Warningهای امنیتی را بگیرد. بعد از Cleanup باید Indexing، Sitemap، Canonical و Security Issues نیز بررسی شوند.

چطور هشدار قرمز گوگل را برداریم؟

ابتدا آلودگی و Vulnerability باید کاملاً برطرف شود. سپس از بخش Security Issues در Search Console درخواست Review ارسال کنید. Google اعلام می‌کند بررسی سایت‌های آلوده به Malware معمولاً چند روز زمان نیاز دارد.

آیا WordPress بعد از هک باید دوباره نصب شود؟

در بسیاری از موارد جایگزینی فایل‌های Core با نسخه رسمی سالم اقدام مناسبی است، اما wp-content و Database باید با دقت بررسی شوند؛ زیرا اطلاعات سفارشی سایت در آن‌ها قرار دارد.

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

خیر. مهاجم ممکن است Web Shell، Backdoor، User دوم یا دسترسی Hosting داشته باشد. Password Reset فقط یکی از مراحل Incident Response است.

آیا سایت دارای SSL هم می‌تواند بدافزار داشته باشد؟

بله. HTTPS ارتباط Browser و Server را رمزنگاری می‌کند و هیچ تضمینی درباره سالم بودن کد Server ارائه نمی‌دهد.

آیا پاک‌سازی سایت بدون Downtime ممکن است؟

گاهی بله، به‌خصوص اگر Staging، Load Balancer یا امکان Deploy سریع داشته باشید. اما اگر سایت فعالانه به کاربران آسیب می‌رساند، Security کاربران باید نسبت به Uptime اولویت داشته باشد.

---

جمع‌بندی

حذف بدافزار از سایت یک فرآیند چندمرحله‌ای است، نه عملیات حذف چند فایل مشکوک.

یک Cleanup موفق باید بتواند به چهار سؤال پاسخ دهد:

چه چیزی آلوده شده است؟

مهاجم چگونه وارد شده است؟

چه راه‌هایی برای بازگشت باقی گذاشته است؟

چگونه جلوی تکرار همان Incident را بگیریم؟

اگر فقط پاسخ سؤال اول مشخص باشد، هنوز نمی‌توان سایت را کاملاً پاک‌شده دانست.

در سایت وردپرسی، فایل‌های Core، Theme، Plugin، .htaccess، wp-config.php، Database و Administratorها باید بررسی شوند. فایل‌های اصلی را می‌توان با نسخه رسمی مقایسه یا در بخش‌های مناسب جایگزین کرد، اما محتوای wp-content و Database نیازمند دقت بیشتری هستند. WordPress نیز پس از Cleanup روی Update، تغییر Password و پیدا کردن Attack Vector تأکید دارد.

Google Search Console نیز یکی از ابزارهای مهم بعد از Incident است. Security Issues می‌تواند برخی صفحات یا فایل‌های آلوده را گزارش کند و پس از پاک‌سازی می‌توان Security Review درخواست کرد.

مهم‌ترین اشتباه پس از هک این است که سایت را فقط از نظر ظاهری بررسی کنیم. اینکه صفحه اصلی باز می‌شود یا Redirect ناپدید شده به معنی حذف کامل Malware نیست.

Backdoor می‌تواند همچنان روی Server باقی مانده باشد.

Credential مهاجم ممکن است هنوز فعال باشد.

Database ممکن است Injection داشته باشد.

یا Plugin آسیب‌پذیر همچنان نصب باشد.

بنابراین آخرین مرحله Cleanup همیشه باید Hardening و Monitoring باشد.

WordPress امنیت را به‌عنوان کاهش Risk تعریف می‌کند، نه حذف کامل تمام خطرها. استفاده هم‌زمان از Update، Access Control، Backup، Monitoring، Hosting امن و ابزارهای دفاعی مناسب باعث می‌شود احتمال آلودگی مجدد به شکل قابل‌توجهی کاهش پیدا کند.

یک سایت واقعاً پاک‌شده سایتی نیست که فقط Malware از آن حذف شده باشد؛ سایتی است که علت آلودگی آن نیز پیدا و برطرف شده باشد.