کالبدشکافی یک نفوذ واقعی به وردپرس؛ از فایل‌های ناشناس تا Backdoor و Browser Miner

بررسی یک پروژه واقعی امنیتی در WordPress و مسیر شناسایی، تحلیل و پاک‌سازی سایت آلوده

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

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

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

در این فرآیند با موارد مختلفی مواجه شدیم:

• فایل‌های PHP ناشناس در مسیر wp-content/uploads
• فایل‌هایی با نام‌های تصادفی که با ساختار معمول وردپرس هماهنگ نبودند
• احتمال وجود Webshell و Backdoor
• کدهای JavaScript رمزگذاری‌شده با Base64
• Scriptهای قانونی که در نگاه اول مشکوک به نظر می‌رسیدند
• رفتارهایی مشابه Browser Mining
• ارتباط‌های WebSocket ناشناس
• بررسی Pluginها، Theme، Database و مسیرهای مخفی دسترسی مجدد

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

یک Script با فرمت Base64 لزوماً Malware نیست. یک فایل ناشناس لزوماً Backdoor نیست. و از طرف دیگر، یک فایل کوچک و ساده می‌تواند مسیر اصلی ورود مهاجم به کل سایت باشد.

کار یک متخصص امنیت فقط پیدا کردن فایل خراب و حذف کردن آن نیست؛ بلکه باید بفهمد:

• چه اتفاقی افتاده؟
• مهاجم از چه مسیری وارد شده؟
• چه دسترسی‌ای ایجاد کرده؟
• آیا راه برگشتی برای خود باقی گذاشته؟
• و مهم‌تر از همه، چطور باید جلوی تکرار این اتفاق را گرفت؟

شروع بررسی؛ وقتی سایت ظاهراً سالم بود

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

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

اولین قانون در بررسی یک سایت هک شده: قبل از حذف، تحلیل کنید

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

فرض کنید در سایت با فایلی مانند:

wp-content/uploads/2025/05/wp/bMdBrd.php

مواجه می‌شویم. واکنش طبیعی این است که بگوییم:

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

چرا؟

چون همین فایل ممکن است اطلاعات مهمی درباره مسیر نفوذ در اختیار ما قرار دهد.

برای مثال ممکن است داخل آن مواردی وجود داشته باشد مانند:

• نام یک Function خاص
• آدرس یک سرور خارجی
• اطلاعات مربوط به نحوه اجرای کد
• مسیر فایل‌های دیگری که توسط مهاجم ایجاد شده‌اند
• نشانه‌هایی از Persistence یا دسترسی دائمی

به همین دلیل، در یک سایت آلوده معمولاً ابتدا شواهد ثبت می‌شوند و بعد فرآیند پاک‌سازی انجام می‌شود.

یعنی روند درست بیشتر شبیه این است:

مشاهده
   ↓
ثبت شواهد
   ↓
تحلیل
   ↓
تشخیص
   ↓
پاک‌سازی

نه اینکه:

مشاهده فایل مشکوک
   ↓
Delete

اولین نشانه جدی؛ پیدا شدن فایل PHP در پوشه uploads

یکی از مهم‌ترین سرنخ‌های این بررسی، پیدا شدن فایل‌های PHP در مسیر زیر بود:

wp-content/uploads/

در ساختار استاندارد وردپرس، این مسیر برای نگهداری فایل‌های رسانه‌ای استفاده می‌شود. تصاویر، فایل‌های PDF، ویدئوها و سایر فایل‌هایی که کاربران یا مدیر سایت آپلود می‌کنند معمولاً در این بخش قرار می‌گیرند.

یک ساختار معمولی می‌تواند چیزی شبیه این باشد:

uploads/

├── 2025/
│
├── 01/
│   ├── image.jpg
│   └── document.pdf
│
└── 02/
    └── product.webp

اما در این پروژه فایل‌هایی با پسوند PHP در این مسیر مشاهده شد:

wp-content/uploads/2023/03/wp/YJjtEXyRZU.php

و:

wp-content/uploads/2025/05/wp/bMdBrd.php

وجود فایل PHP در uploads به‌تنهایی نمی‌تواند صددرصد ثابت کند که سایت هک شده است. گاهی بعضی پلاگین ها یا سیستم‌های خاص ممکن است فایل‌هایی در این مسیر ایجاد کنند. اما وقتی چند نشانه کنار هم قرار می‌گیرند، موضوع جدی‌تر می‌شود:

• فایل PHP
• مسیر uploads
• نام تصادفی فایل
• نبود ارتباط مشخص با Plugin یا Theme

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

چرا فایل PHP در uploads خطرناک است؟

دلیل اصلی ساده است. پوشه uploads معمولاً محلی برای نگهداری فایل است، نه اجرای کد. اگر تنظیمات سرور اجازه اجرای PHP در این مسیر را بدهد، مهاجم ممکن است بتواند یک فایل PHP را در آن قرار دهد و سپس مستقیماً آن را اجرا کند.

برای مثال:

example.com/wp-content/uploads/2025/05/wp/random.php

اگر این فایل شامل کد مخرب باشد، مهاجم می‌تواند بدون نیاز به ورود دوباره به پیشخوان وردپرس، دسترسی خود را حفظ کند. به همین دلیل یکی از اقدامات مهم در Hardening وردپرس این است که اجرای PHP در مسیرهایی مانند uploads محدود شود.

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

دو فایل اصلی که در این بررسی توجه ما را جلب کردند:

YJjtEXyRZU.php

و:

bMdBrd.php

بودند.

نام‌هایی از این جنس معمولاً با فایل‌های استاندارد وردپرس یا فایل‌های Media شباهت ندارند. اما یک نکته مهم وجود دارد:

نام تصادفی به‌تنهایی دلیل Malware بودن نیست. یک Plugin می‌تواند فایل موقت با نام تصادفی ایجاد کند. یک سیستم Cache ممکن است فایل‌هایی با نام غیرقابل خواندن بسازد اما وقتی این موارد کنار هم قرار می‌گیرند:

نام تصادفی
+
پسوند PHP
+
مسیر uploads

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

• محتوای فایل
• زمان ایجاد یا تغییر
• مالک فایل
• Permission
• ارتباط با فایل‌های دیگر
• و اینکه چه چیزی باعث ایجاد آن شده است

وقتی مهاجم فقط یک فایل روی سایت نمی‌گذارد

پیدا شدن یک فایل PHP ناشناس معمولاً اولین سؤال را ایجاد می‌کند:

«این فایل دقیقاً چه کاری انجام می‌دهد؟»

چون هر فایل PHP ناشناسی الزاماً یک تهدید نیست. برای اینکه بفهمیم با یک فایل معمولی، یک ابزار مدیریتی یا یک کد مخرب روبه‌رو هستیم، باید رفتار آن را بررسی کنیم. در بسیاری از حملات وردپرسی، مهاجم صرفاً یک فایل مخرب ایجاد نمی‌کند؛ بلکه تلاش می‌کند یک مسیر دسترسی دائمی برای خودش بسازد.

اینجا دو مفهوم مهم مطرح می‌شود:

• Webshell
• Backdoor

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

Webshell چیست و چرا خطرناک است؟

Webshell معمولاً یک Script است که روی سرور قرار می‌گیرد و به مهاجم اجازه می‌دهد از طریق مرورگر یا درخواست‌های HTTP، دستورات یا عملیات خاصی را اجرا کند. به زبان ساده، مهاجم یک «پنل مخفی» روی سایت ایجاد می‌کند. این پنل ممکن است امکاناتی مثل موارد زیر داشته باشد:

• مشاهده فایل‌های سرور
• ایجاد فایل جدید
• حذف یا تغییر فایل‌ها
• اجرای دستورات خاص
• مشاهده اطلاعات Server
• بررسی تنظیمات هاست

برای مثال، یک مهاجم ممکن است بعد از پیدا کردن یک آسیب‌پذیری در یک Plugin، فایلی مانند:

shell.php

را روی سایت قرار دهد.

بعد از آن بتواند با باز کردن یک آدرس مانند:

example.com/wp-content/uploads/shell.php

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

Backdoor چیست؟

Backdoor مفهوم گسترده‌تری دارد. Backdoor یعنی یک مسیر مخفی که به مهاجم اجازه می‌دهد در آینده دوباره به سیستم دسترسی پیدا کند. این مسیر ممکن است یک فایل PHP باشد، اما محدود به فایل نیست. یک Backdoor می‌تواند در بخش‌های مختلف وردپرس پنهان شود:

• Plugin
• Theme
• Database
• mu-plugins
• Cron Job
• فایل‌های Core وردپرس
• تنظیمات سرور

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

چرا حذف سریع فایل مشکوک همیشه تصمیم درستی نیست؟

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

• زمان حمله
• روش ورود مهاجم
• نام فایل‌های دیگر
• آدرس‌های خارجی
• کلیدها یا Tokenها
• اطلاعات مربوط به Persistence

به همین دلیل در یک پروژه آلوده واقعی، فایل مشکوک ابتدا باید:

1. کپی شود
2. Hash گرفته شود
3. تحلیل شود
4. ارتباط آن با سایر فایل‌ها بررسی شود
5. سپس حذف شود

یک سناریوی رایج؛ چرا یک فایل حذف‌شده دوباره برمی‌گردد؟

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

در این حالت معمولاً سؤال اشتباه این است:

«چرا این فایل دوباره ساخته شد؟»

سؤال درست این است:

«چه چیزی آن را دوباره ساخته است؟»

چون احتمالاً یک مسیر دیگر هنوز فعال است.

مثلاً:

Backdoor اصلی
        ↓
ایجاد فایل جدید
        ↓
اجرای دوباره کد مخرب

در این شرایط، فایل حذف‌شده فقط یک نشانه بوده، نه منبع اصلی مشکل.

پیدا کردن Root Cause مهم‌تر از حذف Malware است

در یک بررسی امنیتی حرفه‌ای، هدف فقط پیدا کردن فایل آلوده نیست. هدف اصلی پیدا کردن Root Cause است.

یعنی باید بفهمیم:

• مهاجم از کجا وارد شد؟
• چه دسترسی‌ای گرفت؟
• چه فایلی ایجاد کرد؟
• آیا کاربر جدید ساخته شد؟
• آیا Database تغییر کرده؟
• آیا Plugin یا Theme آلوده شده؟
• آیا راه برگشتی باقی مانده؟

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

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

بعد از پیدا شدن فایل‌هایی مانند:

YJjtEXyRZU.php
bMdBrd.php

بررسی ما باید چند سؤال اصلی را پاسخ دهد:

این فایل چه زمانی ایجاد شده؟

زمان ایجاد فایل می‌تواند با زمان شروع مشکل ارتباط داشته باشد.

چه کسی مالک فایل است؟

در بعضی شرایط Permission و Owner فایل می‌تواند سرنخ خوبی باشد.

داخل فایل چه چیزی وجود دارد؟

باید بررسی شود که آیا فایل شامل مواردی مانند:

• eval
• base64_decode
• shell_exec
• exec
• system
• passthru

یا الگوهای غیرمعمول دیگر است یا خیر.

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

مرحله بعدی بررسی؛ چیزی که داخل صفحه سایت اجرا می‌شد

بعد از بررسی فایل‌های سمت سرور، مرحله بعدی تحلیل رفتار Frontend بود.

چون یک سؤال مهم باقی مانده بود:

اگر فایل‌های PHP مشکوک وجود داشتند، آیا کدی هم در صفحات سایت تزریق شده بود؟

برای پاسخ به این سؤال، بررسی HTML، JavaScript و درخواست‌های Network شروع شد.

در این مرحله با Scriptهایی مواجه شدیم که در نگاه اول بسیار مشکوک به نظر می‌رسیدند؛ Scriptهایی که به صورت:

<script src="data:text/javascript;base64,..."></script>

در صفحات قرار گرفته بودند.

اما همان‌طور که در ادامه خواهیم دید، یکی از مهم‌ترین نکات این پروژه آلوده این بود که:

هر چیزی که شبیه Malware به نظر می‌رسد، الزاماً Malware نیست.

تحلیل JavaScriptهای ناشناس؛ وقتی یک کد قانونی شبیه Malware به نظر می‌رسد

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

دو روش اصلی برای این کار وجود دارد:

• مشاهده Source صفحه
• بررسی DOM با DevTools مرورگر

اما نکته مهم اینجاست که این دو همیشه یک نتیجه یکسان نشان نمی‌دهند.

مشاهده Scriptهای ناشناس در HTML

در بررسی این سایت، Scriptهایی مشاهده شدند که ساختار آن‌ها شبیه این بود:

<script src="data:text/javascript;base64,..."></script>

در نگاه اول، این نوع کد بسیار مشکوک به نظر می‌رسد. چون معمولاً وقتی توسعه‌دهندگان یا متخصصان امنیت با عبارت‌هایی مانند:

base64

یا:

data:text/javascript

مواجه می‌شوند، احتمال وجود Obfuscation یا مخفی کردن کد را بررسی می‌کنند.

اما اینجا باید یک نکته مهم را در نظر گرفت:

رمزگذاری یا Encode شدن کد، به معنی مخرب بودن آن نیست.

data:text/javascript;base64 چیست؟

ساختاری مانند:

data:text/javascript;base64,XXXXX

به مرورگر می‌گوید:

«کدی که قرار است اجرا شود داخل همین آدرس قرار دارد و بخش بعد از Base64 را Decode کن.»

به این روش Data URL گفته می‌شود. این تکنیک می‌تواند کاربردهای کاملاً قانونی داشته باشد.

برای مثال:

• قرار دادن فایل‌های کوچک بدون درخواست جداگانه
• کاهش تعداد Requestهای مرورگر
• بعضی کتابخانه‌های Frontend
• ابزارهای Build و Minify

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

اشتباه رایج؛ Base64 یعنی ویروس؟

یکی از رایج‌ترین اشتباهاتی که هنگام بررسی Malware اتفاق می‌افتد این است:

کد Base64 پیدا شد
        ↓
پس Malware است

این نتیجه‌گیری درست نیست. Base64 فقط یک روش Encoding است. برای اینکه بفهمیم یک Script چه کاری انجام می‌دهد، باید آن را Decode کنیم و رفتار واقعی آن را ببینیم. در این پروژه آلوده نیز دقیقاً همین اتفاق افتاد. اگر فقط بر اساس ظاهر تصمیم می‌گرفتیم، احتمال داشت یک بخش کاملاً قانونی سایت را حذف کنیم.

نتیجه بررسی این Script چه بود؟

در پایان تحلیل، مشخص شد این Script با وجود اینکه در ابتدا مشکوک به نظر می‌رسید، رفتار مخربی ندارد.

دلایل:

• فقط روی فیلد مشخصی از فرم کار می‌کرد.
• از کتابخانه شناخته‌شده استفاده می‌کرد.
• منطق مشخص برای Validation داشت.
• رفتار آن با عملکرد فرم سایت هماهنگ بود.
• هیچ نشانه‌ای از سرقت اطلاعات، اجرای Command یا فعالیت مخفی مشاهده نشد.

بنابراین نتیجه این نبود که:

«هر کد Base64 یک Malware است.»

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

«کد باید Decode شود و بر اساس رفتار آن قضاوت شود.»

اما همه Scriptها قانونی نبودند…

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

• اجرای محاسبات سنگین
• استفاده از Web Worker
• ارتباط WebSocket
• استفاده از WebAssembly

را نشان می‌دادند. این بخش مسیر بررسی را به سمت یک احتمال جدی‌تر برد:

کشف Browser Miner؛ وقتی سایت شما از منابع کاربران استفاده می‌کند

بعد از اینکه بخشی از Scriptهای سایت بررسی شد و مشخص شد بعضی از آن‌ها کاملاً قانونی هستند، بررسی ادامه پیدا کرد. در این مرحله سؤال اصلی این بود:

آیا تمام Scriptهای ناشناس فقط مربوط به عملکردهای عادی سایت هستند یا چیزی خارج از انتظار هم در حال اجراست؟

با بررسی دقیق‌تر رفتار JavaScriptها، چند نشانه متفاوت مشاهده شد:

• استفاده از Web Worker
• اجرای محاسبات سنگین در مرورگر
• ارتباط‌های WebSocket
• استفاده از WebAssembly
• درخواست‌هایی که با عملکرد معمول سایت ارتباطی نداشتند

ترکیب این موارد باعث شد احتمال وجود یک Browser Miner بررسی شود.

Browser Miner چیست؟

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

به زبان ساده:

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

روند کلی معمولاً شبیه این است:

باز شدن صفحه سایت
        ↓
اجرای JavaScript مخرب
        ↓
فعال شدن Workerها
        ↓
انجام محاسبات سنگین
        ↓
ارسال نتیجه به سرور خارجی

نتیجه این اتفاق می‌تواند مواردی مانند:

• افزایش مصرف CPU
• کاهش سرعت سیستم
• افزایش مصرف باتری لپ‌تاپ
• گرم شدن دستگاه
• کند شدن مرورگر

باشد.

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

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

Web Worker چه نقشی در Browser Miner دارد؟

یکی از مواردی که در بررسی این پروژه آلوده اهمیت داشت، استفاده از Web Worker بود. Web Worker یک قابلیت استاندارد JavaScript است که اجازه می‌دهد بخشی از کد در یک Thread جداگانه اجرا شود. این قابلیت کاملاً قانونی است.

برای مثال سایت‌ها از Web Worker برای مواردی مانند:

• پردازش تصویر
• اجرای محاسبات پیچیده
• بازی‌های تحت وب
• پردازش فایل‌ها

استفاده می‌کنند.

بنابراین:

وجود Web Worker = Malware

یک نتیجه‌گیری اشتباه است.

اما وقتی Web Worker در کنار موارد دیگری دیده شود، اهمیت پیدا می‌کند.

برای مثال:

Web Worker
+
Hash Calculation
+
WebSocket
+
Mining Infrastructure

ترکیبی است که باید با دقت بررسی شود.

چگونه Browser Miner را تشخیص دهیم؟

یکی از اشتباهات رایج این است که فقط دنبال اسم فایل بگردیم.

مثلاً:

miner.js

اما مهاجم می‌تواند نام فایل را هر چیزی بگذارد.

ممکن است:

app.js
main.js
loader.js

نام‌گذاری شده باشد.

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

نشانه‌های مهم:

۱. افزایش غیرعادی مصرف CPU

۲. وجود Workerهای متعدد

۳. محاسبات Hash

۴. ارتباط با مقصدهای ناشناس

۵. اجرای WebAssembly بدون دلیل مشخص

بررسی Network و پیدا کردن منبع واقعی Script

بعد از مشاهده رفتار مشکوک، مرحله بعد این بود که بفهمیم این Script چگونه وارد صفحه شده است.

چون یک سؤال مهم وجود داشت:

آیا این Script مستقیماً در فایل قالب قرار گرفته؟

یا:

• یک Plugin آن را اضافه کرده؟
• از Database خوانده شده؟
• توسط Cache تزریق شده؟
• از طریق یک فایل دیگر Load شده؟

برای پاسخ به این سؤال، یکی از مهم‌ترین ابزارها DevTools مرورگر است.

پیدا کردن منبع آلودگی؛ فایل مخرب از کجا وارد سایت شده است؟

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

در وردپرس معمولاً مسیرهای رایج نفوذ شامل موارد زیر هستند:

• Plugin آسیب‌پذیر یا قدیمی
• Theme آلوده یا Null شده
• رمز عبور ضعیف برای پنل مدیریت
• دسترسی FTP یا هاست دزدیده‌شده
• آسیب‌پذیری در فرم‌های Upload
• تغییرات غیرمجاز در Database

برای همین بعد از پیدا کردن Malware باید تمام نقاطی که امکان ایجاد دسترسی دارند بررسی شوند.

مراحل پاک‌سازی یک سایت وردپرسی آلوده

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

۱. گرفتن Backup قبل از پاک‌سازی

قبل از هر تغییری:

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

این کار باعث می‌شود اگر در بررسی اشتباهی رخ داد، امکان بازگشت وجود داشته باشد.

۲. حذف فایل‌های مشکوک

فایل‌هایی مانند:

wp-content/uploads/random.php

یا فایل‌هایی که:

• نام تصادفی دارند.
• ارتباطی با وردپرس ندارند.
• اخیراً ایجاد شده‌اند.
• داخل مسیرهای غیرمعمول قرار گرفته‌اند.

باید بررسی و در صورت تأیید حذف شوند.

اما همیشه قبل از حذف باید مطمئن شوید فایل مربوط به یک Plugin یا قابلیت واقعی سایت نیست.

۳. بررسی Pluginها

یکی از رایج‌ترین دلایل هک وردپرس، Pluginهای آسیب‌پذیر هستند.

موارد زیر را بررسی کنید:

• Pluginهای قدیمی را حذف یا آپدیت کنید.
• Pluginهای Null شده را پاک کنید.
• Pluginهای غیرضروری را حذف کنید.
• فقط Pluginهای معتبر نصب کنید.

همچنین فقط غیرفعال کردن Plugin کافی نیست؛ چون فایل‌های آن همچنان روی سرور باقی می‌مانند.

---

۴. بررسی قالب سایت

قالب وردپرس نیز باید بررسی شود. فایل‌هایی که معمولاً بررسی می‌شوند:

functions.php
header.php
footer.php
index.php
404.php

همچنین:

• کدهای Custom اضافه‌شده
• فایل‌های ناشناس داخل Theme
• تغییرات اخیر

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

گاهی مهاجم هیچ فایل جدیدی ایجاد نمی‌کند و کد مخرب را داخل Database قرار می‌دهد.

۵. بررسی Database وردپرس

بخش‌های مهم:

wp_options

و تنظیمات Pluginها هستند.

عبارت‌هایی که ارزش بررسی دارند:

<script
iframe
base64
javascript:
eval(

اما باید دقت کرد که وجود این کلمات به تنهایی به معنی آلودگی نیست و باید Context بررسی شود.

۶. بررسی کاربران سایت

تمام کاربران Administrator باید بررسی شوند.

موارد مهم:

• کاربر ناشناس وجود نداشته باشد.
• ایمیل مدیر تغییر نکرده باشد.
• کاربران قدیمی غیرضروری حذف شوند.
• رمز تمام کاربران مهم تغییر کند.

۷. تغییر تمام رمزهای عبور

بعد از یک نفوذ احتمالی، تغییر رمز فقط برای وردپرس کافی نیست.

رمزهای زیر باید تغییر کنند:

• WordPress Admin
• Hosting Panel
• FTP / SFTP
• Database
• Emailهای مرتبط
• Cloudflare
• API Keyها

چون ممکن است مهاجم از یکی از این مسیرها دوباره وارد شود.

۸. جلوگیری از اجرای PHP در uploads

یکی از مهم‌ترین اقدامات امنیتی وردپرس این است که اجازه اجرای PHP در پوشه Uploads داده نشود.

هدف این است:

مهاجم اگر بتواند فایل PHP آپلود کند، نتواند آن را اجرا کند. Apache معمولاً با تنظیمات .htaccess و در Nginx با تنظیمات Server انجام می‌شود.

۹. فعال کردن لایه‌های امنیتی

بعد از پاک‌سازی بهتر است:

• WordPress همیشه به‌روز باشد.
• Pluginها مرتب آپدیت شوند.
• ورود مدیران با Two Factor Authentication محافظت شود.
• Backup منظم گرفته شود.
• دسترسی فایل‌ها بررسی شود.
• Monitoring فعال شود.

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

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

۱. چه چیزی باعث ورود مهاجم شد؟

۲. چه دسترسی‌هایی برای برگشت ایجاد شده است؟

۳. چه تغییراتی باید انجام شود که دوباره تکرار نشود؟

چک‌لیست نهایی امنیت وردپرس بعد از هک

✅ حذف فایل‌های PHP مشکوک در uploads
✅ بررسی Pluginها و Theme
✅ حذف Pluginهای Null
✅ بررسی Database
✅ بررسی کاربران Administrator
✅ تغییر تمام رمزها
✅ فعال کردن 2FA
✅ جلوگیری از اجرای PHP در uploads
✅ بررسی Cron Jobها
✅ بررسی فایل‌های تغییرکرده اخیر
✅ پاک‌سازی Cache و CDN
✅ فعال کردن سیستم مانیتورینگ

جمع‌بندی

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

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

امنیت وردپرس فقط نصب یک Plugin امنیتی نیست؛ امنیت یعنی:

• شناخت ساختار سایت
• بررسی رفتارهای غیرعادی
• پیدا کردن مسیر ورود
• حذف کامل دسترسی مهاجم
• و جلوگیری از تکرار دوباره مشکل

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

«چه فایلی را حذف کنیم؟»

بلکه این است:

«چه چیزی باعث شد این فایل اصلاً بتواند وارد سایت شود؟»

بعد از هک وردپرس چه کارهایی انجام دهیم تا دوباره آلوده نشود؟

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

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

وردپرس و افزونه‌ها را همیشه به‌روز نگه دارید

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

بهتر است:

• Pluginهای بدون استفاده حذف شوند.
• Pluginهای ناشناس استفاده نشوند.
• Themeهای قدیمی روی سایت باقی نمانند.
• نسخه PHP سرور نیز به‌روز باشد.

دسترسی مدیران را محدود کنید

هر کاربری نباید دسترسی Administrator داشته باشد.

بهتر است:

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

گاهی یک نفوذ از پیچیده‌ترین آسیب‌پذیری‌ها اتفاق نمی‌افتد؛ فقط یک رمز ضعیف کافی است.

Backup منظم داشته باشید

Backup زمانی ارزشمند است که قبل از مشکل وجود داشته باشد.

یک سیستم Backup استاندارد باید:

• زمان‌بندی مشخص داشته باشد.
• خارج از همان سرور نگهداری شود.
• امکان Restore سریع داشته باشد.

داشتن Backup باعث می‌شود در زمان بحران مجبور نباشید بین «پاک‌سازی سخت» و «از دست دادن سایت» یکی را انتخاب کنید.

لاگ‌ها و رفتار سایت را بررسی کنید

یکی از تفاوت‌های سایت امن و ناامن، این است که رفتارهای غیرعادی سریع‌تر شناسایی می‌شوند.

مواردی که باید زیر نظر باشند:

• ایجاد فایل‌های جدید
• تغییر فایل‌های PHP
• افزایش غیرعادی مصرف CPU
• ایجاد کاربر جدید
• درخواست‌های مشکوک به سرورهای خارجی
• تغییرات غیرمنتظره Database

چه زمانی بهتر است سایت هک‌ شده را کامل بازسازی کنیم؟

گاهی میزان آلودگی آن‌قدر زیاد است که پاک‌سازی دستی بهترین گزینه نیست.

برای مثال:

• تعداد زیادی فایل تغییر کرده باشد.
• Core وردپرس آلوده شده باشد.
• منبع نفوذ مشخص نباشد.
• Backdoorهای متعدد وجود داشته باشد.
• مدت زیادی از نفوذ گذشته باشد.

در این شرایط معمولاً روش امن‌تر این است:

1. تهیه Backup از اطلاعات ضروری
2. نصب یک نسخه سالم وردپرس
3. نصب Theme و Pluginهای معتبر
4. انتقال کنترل‌شده محتوا
5. بررسی Database قبل از انتقال
6. تغییر تمام دسترسی‌ها

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