بدافزار سایت؛ تشخیص، پاک‌سازی و جلوگیری از آلودگی وردپرس

پاک‌کردن یک فایل ناشناس به معنی پاک‌شدن بدافزار نیست. مهاجم ممکن است هم‌زمان Admin پنهان، Cron job، Web shell، کلید API و کد تزریق‌شده در Database ساخته باشد. اگر فقط Symptom را حذف کنید و بردار ورود یا Persistence باقی بماند، سایت چند ساعت یا چند روز بعد دوباره آلوده می‌شود.

این راهنما برای WordPress و وب‌سایت‌های ایرانی نوشته شده و پیشگیری، تشخیص، Containment، پاک‌سازی، بازیابی و Recovery سئو را به‌صورت یک Runbook عملی پوشش می‌دهد.

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

Website malware کد یا تغییری است که بدون مجوز برای سرقت، کنترل، Redirect، Spam، مصرف منابع یا ایجاد دسترسی پایدار وارد سایت/سرور می‌شود. «ویروس» فقط یکی از اصطلاحات عمومی است؛ در وب بیشتر با Backdoor، Web shell، JavaScript injection و SEO spam روبه‌رو می‌شویم.

انواع آلودگی رایج

آلودگی از چه راهی وارد می‌شود؟

• Plugin، Theme، CMS یا Server patch‌نشده؛
• افزونه/قالب نال‌شده یا منبع نامعتبر؛
• Password سرقت‌شده و نبود MFA؛
• Application Password/API key لو‌رفته؛
• آسیب‌پذیری Upload، SQLi، XSS یا RCE؛
• دستگاه مدیر آلوده؛
• هاست اشتراکی با Isolation ضعیف؛
• Third-party JavaScript یا Tag manager تصاحب‌شده؛
• Secret داخل Repository/Backup عمومی؛
• دسترسی پیمانکار یا حساب فراموش‌شده؛
• پیکربندی فایل/Directory و Credential نامناسب.

نشانه با اثبات فرق دارد

کندی، افت ترافیک یا خطای ۵۰۰ می‌تواند Bug هم باشد. Indicatorها را Correlate کنید:

• فایل جدید/تغییرکرده خارج از Release؛
• Admin/Role/Email ناشناس؛
• Cron، Scheduled task یا Service تازه؛
• Process و Network connection غیرعادی؛
• Redirect شرطی بر Mobile، Cookie یا Referrer؛
• URL/Title نامرتبط در Search؛
• هشدار Search Console/Safe Browsing/Hosting؛
• Spike در CPU، PHP worker، Email یا Egress؛
• تغییر DNS، htaccess، web.config یا Nginx config؛
• JavaScript مبهم در Header/Footer/Database؛
• Login موفق از Device/موقعیت غیرعادی؛
• Checksum mismatch.

شدت Incident را تعیین کنید

اگر داده کاربر، Credential یا پرداخت ممکن است افشا شده باشد، موضوع فقط «پاک‌سازی سایت» نیست؛ Privacy و Incident response سازمانی لازم است.

مسئولیت مشترک امنیت

• Hosting/Cloud: طبق مدل سرویس، زیرساخت، Hypervisor، شبکه یا بخشی از Patch؛
• تیم سایت: CMS، Plugin/Theme، Account، Code، Secret، Backup و Monitoring؛
• Vendor: Patch و اعلان آسیب‌پذیری محصول؛
• پرداخت/Third party: Scope قراردادی خود، نه کل سایت؛
• مدیر کسب‌وکار: Risk، Budget، Owner و Incident plan.

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

پیشگیری: Inventory و مالکیت

نمی‌توان چیزی را که نمی‌شناسید Patch یا حذف کنید:

• WordPress/Core/PHP/Database/Web server؛
• Plugin و Theme فعال/غیرفعال؛
• Composer/NPM و Library؛
• Admin، Editor، Service account و API credential؛
• Domain/DNS/CDN/Hosting/Email؛
• Scheduled task و Integration؛
• Backup و Storage؛
• Owner، نسخه، منبع، آخرین استفاده و EOL.

Patch و Update امن

• Security advisory و Release source رسمی؛
• Staging یا Test متناسب؛
• Backup قابل‌بازگشت؛
• اولویت بر اساس Exploitability و Exposure؛
• Update Core/Plugin/Theme/PHP/OS؛
• حذف Component بلااستفاده، نه فقط Disable؛
• Changelog و Compatibility؛
• Rollout و Monitor؛
• Emergency patch/virtual patch با Expiry؛
• ثبت نسخه و نتیجه.

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

منبع قابل‌اعتماد Plugin و Theme

راهنمای رسمی Hardening وردپرس نصب Core و افزونه/قالب را از منابع معتبر، محدودکردن دسترسی، آمادگی Backup و دانستن وضعیت سالم سیستم توصیه می‌کند.

• نسخه نال‌شده/کرک‌شده ممنوع؛
• ناشر، دامنه و Signature/Checksum در صورت وجود؛
• Changelog، Maintenance و Security contact؛
• حداقل Permission؛
• عدم نصب Pluginهای هم‌پوشان و رهاشده؛
• مرور کد/Behavior برای Component حساس؛
• SBOM/Dependency lock برای توسعه اختصاصی.

هویت و دسترسی

• Passkey/MFA برای Admin، Hosting، DNS و Email؛
• حساب شخصی به‌جای Shared admin؛
• Least privilege و Review دوره‌ای Role؛
• Offboarding فوری؛
• Password manager و breached-password blocklist؛
• Application Password محدود و قابل Revoke؛
• SSH/SFTP key و حذف Protocol ناامن؛
• Session و دستگاه‌های فعال قابل مشاهده؛
• Alert برای Admin/Factor/Email change.

Rollout را با راهنمای MFA پنل مدیریت و دفاع Login را با راهنمای Brute Force و Credential Stuffing تکمیل کنید.

File permission و اجرای کد

• Owner/group درست؛
• Write فقط برای مسیرهای لازم؛
• Upload directory بدون اجرای Script در صورت معماری؛
• عدم ۷۷۷ عمومی؛
• Editor فایل از پنل در Production محدود؛
• Config و Secret خارج از Web root در صورت امکان؛
• Directory listing خاموش؛
• Temp و Cache با Permission مناسب؛
• Deploy user جدا از Web process؛
• Container/image غیرقابل‌تغییر در معماری مناسب.

Upload امن

• Allowlist نوع واقعی و Extension؛
• نام تصادفی و خارج از مسیر اجرایی؛
• Size/Dimension limit؛
• Decode/Re-encode تصویر در صورت نیاز؛
• Archive extraction امن و محدود؛
• Malware scan به‌عنوان لایه، نه تضمین؛
• عدم اعتماد به MIME اعلامی Browser؛
• Access control فایل خصوصی؛
• Log و Rate limit؛
• حذف Metadata حساس در سناریوی لازم.

WAF و Origin protection

WAF می‌تواند Exploitهای شناخته‌شده و Bot را کاهش دهد، اما Backdoor موجود یا Credential معتبر را پاک نمی‌کند. Network/Host firewall، WAF، Rule tuning و Origin را طبق راهنمای فایروال سایت طراحی کنید.

• Origin مستقیم بسته؛
• Rule set به‌روز و Tune؛
• Upload/Login/API Policy جدا؛
• Virtual patch زمان‌دار؛
• Log بدون Secret؛
• Rule bypass دارای Owner و Expiry.

Backup مقاوم در برابر مهاجم

Backup روی همان Account/Server ممکن است همراه سایت حذف یا آلوده شود.

• کپی جدا از Production و Credential جدا؛
• نسخه Immutable/Object lock در صورت امکان؛
• چند Retention برای کشف دیرهنگام؛
• Database، Upload، Config و Infrastructure definition؛
• Encryption و دسترسی محدود؛
• Log دسترسی/حذف؛
• Restore test دوره‌ای؛
• Checksum/Integrity و تاریخ Known-good؛
• Backup آلوده برای Forensic حفظ، نه Restore کور.

File integrity monitoring

Baseline سالم و Change context لازم است:

• Checksum Core/Plugin/Theme منبع رسمی؛
• تغییر خارج از Deployment window؛
• فایل اجرایی در Upload/Cache؛
• htaccess، config، mu-plugins و bootstrap؛
• مالک/Permission تغییرکرده؛
• Rule برای فایل جدید و حذف‌شده؛
• Agent/Monitor خارج از کنترل Web user در صورت امکان؛
• Alert با Release ID برای کاهش Noise.

Mismatch نشانه بررسی است؛ Custom code و Update قانونی هم فایل را تغییر می‌دهند.

اسکن خارجی و داخلی

نتیجه «پاک» یک ابزار اثبات قطعی نیست؛ چند منبع و Baseline را ترکیب کنید.

Search Console و Search monitoring

راهنمای جاری Google برای پیشگیری از Malware بررسی Security Issues، پیام‌های Search Console و جست‌وجوی دوره‌ای site: برای URL/موضوع ناشناس را پیشنهاد می‌کند.

• همه Propertyها و Ownerها را Audit کنید؛
• Security Issues و Messages؛
• Indexing/Pages برای URL نامرتبط؛
• Query و Country غیرعادی؛
• Sitemap ناشناس؛
• تغییر robots/canonical؛
• Manual action را با Security issue یکی ندانید.

Logging و Detection

برای Timeline حداقل این منابع را Correlate کنید:

• Web access/error و Reverse proxy/WAF؛
• WordPress login/user/plugin/theme change؛
• OS auth/sudo/process/service/cron؛
• Database audit در سطح لازم؛
• DNS/CDN/Hosting control-plane؛
• Git/CI/CD/deployment؛
• Email/API/payment؛
• File integrity و backup access.

Correlation ID، زمان UTC و Asia/Tehran، Retention و دسترسی امن لازم است. طراحی را با راهنمای Observability هماهنگ کنید.

Alertهای باارزش

• Admin/Role/Email یا MFA تغییر کرد؛
• Plugin/Theme/Core خارج از Deploy تغییر کرد؛
• فایل PHP در Upload/Cache ساخته شد؛
• Cron/Service/Scheduled task جدید؛
• Egress به مقصد/Port جدید؛
• Spike در Email، CPU یا PHP worker؛
• Redirect/Content خارجی از چند Probe؛
• Security issue یا Safe Browsing warning؛
• Backup delete/disable؛
• Logging/Scanner agent خاموش شد؛
• Config/DNS/Origin تغییر کرد.

اگر شک کردید: اول شواهد را خراب نکنید

حذف فایل، Restore فوری یا نصب چند Scanner می‌تواند Timestamp و Evidence را تغییر دهد. ابتدا:

1. Incident ID، زمان و تصمیم‌گیر مشخص کنید.
2. Snapshot/Disk/DB و Logهای لازم را با دسترسی محدود حفظ کنید.
3. Hash و Chain of custody متناسب ثبت کنید.
4. فهرست Process/Connection/User/Task و نسخه‌ها را Capture کنید.
5. از دستگاه/حساب امن برای Response استفاده کنید.
6. Scope و خطر کاربر را تعیین کنید.

در Incident کوچک هم حداقل Timeline و فایل مشکوک را قبل از حذف نگه دارید.

Containment بدون نابودی شواهد

Maintenance page باید از زیرساخت تمیز Serve شود؛ همان WordPress آلوده را با Plugin Maintenance اجرا نکنید.

رمزها را چه زمانی عوض کنیم؟

Rotation از دستگاه یا سایت هنوز آلوده ممکن است Secret جدید را هم لو بدهد. ترتیب:

1. Control channel و دستگاه Response سالم؛
2. Contain دسترسی مهاجم؛
3. Revoke Session/Token فوری؛
4. پاک‌سازی/بازسازی؛
5. Rotate بر اساس Scope: WordPress، DB، salts، Hosting، SSH، API، Payment، Email، DNS؛
6. Update Secret در Consumerها؛
7. مانیتور استفاده از Secret قدیمی؛
8. ابطال قطعی و ثبت نتیجه.

Scope را پیدا کنید

• اولین Indicator چه زمانی است؟
• کدام Host/Tenant/Site؟
• چه حساب و IP/Device؟
• کدام فایل/DB row/Task؟
• آیا Plugin/Theme مشترک است؟
• آیا دیگر سایت‌های همان Hosting account آلوده‌اند؟
• آیا Backup، Git یا CI/CD تغییر کرده؟
• آیا داده خوانده/خارج شده؟
• آیا Credential برای سرویس دیگر استفاده می‌شود؟
• آیا مهاجم Persistence چندگانه دارد؟

Persistenceهای رایج در WordPress

• Admin یا Application Password ناشناس؛
• mu-plugin یا Plugin با نام شبیه سیستمی؛
• Theme functions/header/footer؛
• wp-config و salts؛
• htaccess/user.ini/php.ini؛
• PHP در uploads/cache/tmp؛
• wp_options autoloaded payload؛
• Post/Widget/Customizer/Tag manager injection؛
• WP-Cron یا OS cron؛
• SSH key/FTP account؛
• Database trigger/user؛
• DNS/CDN worker/page rule.

بردار ورود را ببندید

پیش از بازگشت سایت:

• نسخه آسیب‌پذیر Patch/حذف؛
• Credential و Session Revoke؛
• Upload/RCE/SQLi fix؛
• Rule موقت WAF با Expiry تا Patch؛
• Plugin نال‌شده حذف و از منبع سالم جایگزین؛
• دستگاه مدیر بررسی/پاک؛
• Shared hosting isolation با Provider؛
• Third-party Script/Account revoke؛
• Secret repository پاک و Rotate؛
• Account/Role غیرلازم حذف.

برای ورودی‌های برنامه، راهنمای SQL Injection و XSS را اجرا کنید.

پاک‌سازی یا Rebuild؟

وقتی کنترل سرور/ادمین یا Persistence ناشناخته است، Rebuild از Image/Source سالم معمولاً قابل‌اعتمادتر از جست‌وجوی دستی همه Backdoorهاست.

Rebuild امن WordPress

1. محیط تمیز با OS/PHP/Web/DB پشتیبانی‌شده بسازید.
2. WordPress Core را از منبع رسمی نصب کنید.
3. Plugin/Theme لازم را از منابع رسمی و نسخه امن نصب کنید.
4. Config را از Template سالم بازسازی کنید، نه Copy کور.
5. Upload را Scan و نوع فایل/اجرا را کنترل کنید.
6. Database را برای User، Option، Post، Script و URL مشکوک Review کنید.
7. Credential/Salts/Keyها را Rotate کنید.
8. Permission، WAF و Monitoring را اعمال کنید.
9. Regression، Security و Business flow را تست کنید.
10. DNS/Traffic را تدریجی به محیط تمیز منتقل کنید.

Restore از Backup؛ چهار سؤال

• Backup مربوط به قبل از اولین Compromise است؟
• Root cause پس از Restore بسته می‌شود؟
• Backup Integrity و Restore واقعاً تست شده؟
• داده قانونی بعد از Backup چگونه امن Reconcile می‌شود؟

Restore یک Backup ناشناخته ممکن است Backdoor را برگرداند؛ Restore بدون Patch، آلودگی دوباره را دعوت می‌کند.

Database را فراموش نکنید

• wp_users و wp_usermeta Role/Email؛
• wp_options، active_plugins، siteurl/home، cron و autoload؛
• Post/Page/Widget/Block با Script/iframe؛
• SEO title/canonical و Sitemap؛
• WooCommerce webhook/API key؛
• Redirect و Ad/tag configuration؛
• Database user/permission؛
• Trigger/Event در DBهای پشتیبان؛
• Serialized data با ابزار امن، نه Replace خام.

اعتبارسنجی قبل از بازگشت

• Core/Plugin/Theme checksum یا Build manifest؛
• هیچ Admin/Key/Task ناشناس؛
• File integrity baseline جدید؛
• External crawl از Desktop/Mobile و Referrerهای مختلف؛
• Search/Checkout/Login/Upload/Email؛
• WAF/Rate limit و Origin؛
• Egress و Process baseline؛
• چند Scanner مستقل بدون اتکا به یک نتیجه؛
• Log/Alert/Backup فعال؛
• Secret قدیمی غیرقابل‌استفاده؛
• Pen test هدفمند بردار ورود؛
• Owner و Hypercare.

Recovery سئو بعد از هک

1. آلودگی و Root cause را کامل رفع کنید.
2. Security Issues و نمونه URLها را دوباره بررسی کنید.
3. Spam URLها را ۴۰۴/۴۱۰ یا به محتوای واقعاً مرتبط برگردانید؛ Redirect همه به Home ندهید.
4. Sitemap تمیز و canonical/robots درست شوند.
5. صفحات قانونی و مهم ۲۰۰ بمانند.
6. Request review را فقط پس از پاک‌سازی و توضیح اقدامات بفرستید.
7. Indexing، Query، Crawl و Warning را Monitor کنید.
8. Backlink/Spam campaign و Search resultهای جعلی را جدا بررسی کنید.

Robots.txt برای پنهان‌کردن URL هک‌شده از Google کافی نیست و ممکن است بررسی Removal را سخت کند.

درخواست Review به Google

اگر Search Console/Safe Browsing هشدار دارد، پس از پاک‌سازی:

• همه نمونه‌ها و Patternها را پوشش دهید، نه فقط URL گزارش‌شده؛
• بردار ورود و Component آسیب‌پذیر را رفع کنید؛
• Persistence و حساب‌ها را پاک کنید؛
• سایت از بیرون و با Mobile/Crawler تست شود؛
• در Review کوتاه و دقیق بگویید چه یافت و چه اصلاح شد؛
• درخواست مکرر قبل از Cleanup نفرستید؛
• Monitoring پس از رفع هشدار ادامه یابد.

ارتباط با کاربران و ذی‌نفعان

پنهان‌کاری یا ادعای زودهنگام «هیچ داده‌ای نرفته» خطرناک است. پیام Incident باید:

• واقعیت تأییدشده و Unknownها را جدا کند؛
• زمان و سرویس‌های متاثر؛
• اقدام انجام‌شده؛
• کاری که کاربر باید انجام دهد؛
• کانال پشتیبانی معتبر؛
• زمان Update بعدی؛
• الزام قانونی/قراردادی با مشاور مناسب؛
• عدم افشای جزئیات کمک‌کننده به مهاجم.

Post-incident review

• Timeline از Initial access تا Detection/Containment؛
• Root cause و عوامل کمک‌کننده؛
• چرا Prevention/Detection قبلی نگرفت؟
• چه چیزی خوب/بد عمل کرد؟
• اثر کاربر، داده، مالی و SEO؛
• Action با Owner و Deadline؛
• Control و Test جدید؛
• به‌روزرسانی Runbook/Training؛
• پیگیری تا بسته‌شدن Actionها.

KPIهای امنیت بدافزار

برنامه ۲۴ ساعت اول

1. Incident commander و کانال امن؛
2. حفظ Snapshot/Log؛
3. Contain اثر فعال؛
4. Scope اولیه و داده/پرداخت؛
5. Revoke Session/Token بحرانی؛
6. مسیر تمیز برای Maintenance/Service؛
7. اطلاع داخلی و Provider؛
8. برنامه Rebuild/Cleanup؛
9. Update زمان‌دار وضعیت.

برنامه هفت روز

• Root cause و Persistence کامل؛
• Rebuild/Restore امن؛
• Rotation همه Credentialهای Scope؛
• Validation و Hypercare؛
• Search Console/SEO cleanup؛
• ارتباط لازم؛
• Post-incident اولیه؛
• Actionهای فوری Patch/MFA/WAF/Backup.

برنامه ۳۰روزه پیشگیری

هفته اول

Inventory، Admin/Secret، Backup و Patchهای بحرانی.

هفته دوم

MFA، Permission، Upload، WAF/Origin و حذف Component بلااستفاده.

هفته سوم

File integrity، External scan، Log/Alert و Search monitoring.

هفته چهارم

Restore drill، Malware/Account takeover tabletop و اصلاح Runbook.

چک‌لیست جلوگیری و پاک‌سازی بدافزار

• Asset/Plugin/Theme/Account inventory و Owner دارد.
• Patch بر اساس Risk و Test منتشر می‌شود.
• هیچ نرم‌افزار نال‌شده یا رهاشده وجود ندارد.
• MFA و Least privilege برای همه Control planeها فعال است.
• Upload، Permission و اجرای فایل محدود است.
• WAF/Origin و Login defense مکمل‌اند.
• Backup جدا، Immutable و Restore-tested است.
• File/DB/Host/External monitoring ترکیب شده‌اند.
• Search Console و site: پایش می‌شوند.
• در Incident شواهد پیش از حذف حفظ می‌شوند.
• Root cause و Persistence قبل از بازگشت بسته‌اند.
• Secret از کانال سالم و پس از Containment Rotate می‌شود.
• Rebuild/Restore از منبع Known-good است.
• Spam URL، Sitemap و Review گوگل درست مدیریت می‌شوند.
• Post-incident Action دارای Owner/Deadline است.

سؤالات متداول بدافزار سایت

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

File integrity، حساب/Task، Log، Process/Egress، External crawl و Search Console را ترکیب کنید. نتیجه پاک یک Scanner به‌تنهایی سلامت را ثابت نمی‌کند.

آیا حذف فایل آلوده کافی است؟

معمولاً نه. باید بردار ورود، Backdoorها، Admin/Key، Cron، Database injection و دیگر Persistenceها را پیدا و Secretها را امن Rotate کنید.

Restore Backup بهترین راه است؟

فقط اگر Backup قبل از Compromise، سالم و تست‌شده باشد و Root cause نیز بسته شود. در غیر این صورت Backdoor دوباره برمی‌گردد.

آیا SSL یا WAF جلوی بدافزار را می‌گیرد؟

SSL انتقال را رمز می‌کند و WAF بخشی از Exploitها را کاهش می‌دهد؛ هیچ‌کدام Plugin آسیب‌پذیر، Credential معتبر یا Backdoor موجود را به‌تنهایی حل نمی‌کنند.

بعد از پاک‌سازی چگونه هشدار Google را برداریم؟

همه Patternهای آلودگی و Root cause را رفع، سایت را از بیرون تست و سپس در Security Issues درخواست Review دقیق ثبت کنید؛ قبل از Cleanup درخواست تکراری نفرستید.

جمع‌بندی

پاسخ درست به بدافزار «اسکن و حذف» نیست؛ یک Incident lifecycle است: شواهد، Containment، Scope، Root cause، حذف Persistence، Rebuild/Restore سالم، Rotation، Validation و Recovery سئو. پیشگیری نیز به Inventory، Patch، MFA، Backup و Monitoring وابسته است.

برای Triage آلودگی، Rebuild امن یا بازیابی Search Console، از فرم مشاوره امنیت مایندیو استفاده کنید و نوع هشدار، زمان اولین نشانه و اطلاعات حساس‌زدایی‌شده را بنویسید.