Redirect lạ, JavaScript injection và SEO spam trên WordPress thường không xuất hiện như ba sự cố độc lập. Trong nhiều compromise, cùng một entry point có thể cho phép attacker chèn script, tạo hidden links hoặc spam pages và chỉ redirect một số user theo referrer, user-agent hoặc device để giảm khả năng bị chủ website phát hiện.
Google định nghĩa hacked content gồm code injection, malicious JavaScript, page/content injection và redirects; redirect có thể chỉ kích hoạt với người dùng đến từ Google Search hoặc một số user-agent. Search Console Security Issues cũng khuyến nghị dùng URL Inspection, cURL hoặc Wget với referrer/user-agent khác nhau để tái hiện hành vi bị cloaking. WordPress khuyên coi các triệu chứng như blacklist, malware warning hoặc nội dung bất thường là Indicators of Compromise và xử lý theo quy trình incident thay vì chỉ xóa symptom. Nguồn: Google Search Spam Policies, Google Search Console — Security Issues và WordPress — FAQ My Site Was Hacked.
Bối cảnh: owner mở website bình thường nhưng user từ Google bị redirect
Giả sử website nhìn bình thường khi admin mở trực tiếp homepage. Nhưng một số user báo khi click từ Google Search thì bị chuyển sang casino/pharma page, trong khi Search Console bắt đầu hiển thị URL lạ hoặc Security Issues. Source code chỉ thỉnh thoảng xuất hiện JavaScript obfuscated hoặc link spam khó thấy.
Những signal cần gom ngay
- Redirect chỉ xảy ra khi referrer là Google/Bing hoặc trên mobile.
- HTML/rendered DOM có JavaScript lạ, iframe, encoded payload hoặc external domain không rõ owner.
- Google index xuất hiện casino, pharma, Japanese keyword hoặc URL không do team tạo.
.htaccess, theme/plugin file hoặc database option có code redirect.- Search Console báo hacked content, code injection hoặc URL injection.
- Access log cho thấy request tới spam URL hoặc redirect destination ngoài baseline.
Investigation: tái hiện hành vi theo referrer và user-agent
Bước 1: so sánh direct visit với search-referrer visit
Google lưu ý hacker thường dùng cloaking để chỉ phục vụ redirect hoặc spam cho một số user-agent/referrer. Vì vậy chỉ mở URL bằng browser của admin chưa đủ. Cần so sánh response khi truy cập trực tiếp, khi giả lập referrer từ search engine, mobile user-agent và khi fetch bằng URL Inspection nếu có quyền Search Console.
Nếu redirect chỉ xuất hiện trong một context cụ thể, evidence cần ghi rõ điều kiện kích hoạt thay vì nói chung rằng “website luôn redirect”.
Bước 2: xác định injection nằm ở file, database hay third-party
Redirect hoặc JavaScript lạ có thể nằm trực tiếp trong PHP/theme file, .htaccess, database option/post content, widget, tag manager hoặc third-party script. Google Security Issues nêu các ví dụ như header redirect từ server config, JavaScript redirect hoặc malicious external script.
Tham chiếu WordPress bị chèn JavaScript lạ và mã độc trong wp-config.php, .htaccess hoặc index.php để tách client-side injection khỏi server-side persistence.
Bước 3: inventory spam URL và search footprint
SEO spam có thể tạo page mới, hidden links hoặc sửa nội dung hiện có để search engine thấy khác người dùng. Cần inventory URL lạ từ Search Console, sitemap, database, web logs và tìm kiếm site: hỗ trợ discovery; tuy nhiên site: không phải nguồn đầy đủ để kết luận toàn bộ index state.
Đọc thêm SEO Spam Malware WordPress để phân loại Japanese keyword hack, pharma spam và hidden links.
Khi nào có thể xác nhận đây là hacked redirect/SEO spam?
Không nên gọi mọi redirect hoặc script bên thứ ba là malware. Confidence mạnh khi có evidence rằng code/content được thêm ngoài authorization và tạo hành vi không thuộc business flow.
- Code, script, link hoặc page không có owner/change record hợp lệ.
- Redirect destination không thuộc business requirement.
- Behavior thay đổi theo referrer/user-agent nhằm che giấu.
- Spam URL/content xuất hiện trong index hoặc Search Console ngoài ý muốn.
- File/database diff cho thấy unauthorized modification.
Containment và cleanup: xử lý cả symptom lẫn persistence
Preserve evidence trước khi xóa
Trước cleanup, nên giữ bản sao file/DB/log liên quan, timestamp và hash khi phù hợp. Việc xóa JavaScript hoặc spam page quá sớm có thể làm mất evidence về entry point hoặc persistence.
Dùng quy trình bảo toàn evidence nếu incident cần RCA hoặc có khả năng tái nhiễm.
Loại bỏ injection và đóng entry point
- Remove malicious JavaScript, spam content, redirect rule và unauthorized page.
- Reinstall component bị sửa từ trusted source nếu integrity không còn đủ.
- Patch/remove plugin/theme hoặc credential tạo initial access.
- Review admin, scheduled task, MU-plugin, database option và file ngoài webroot để tìm persistence.
- Rotate credential/session/token nếu compromise có thể đã lộ secret.
Cleanup chỉ được coi là hoàn tất khi root cause và persistence được xử lý, không phải khi redirect tạm thời biến mất.
Search recovery: xác minh site sạch trước khi request review
Google khuyến nghị chỉ request security review khi đã xác nhận vấn đề thực sự được sửa. Với hacked spam, cần kiểm tra toàn bộ loại issue được liệt kê trong Security Issues, không chỉ một URL mẫu. URL Inspection giúp so sánh cách Google thấy trang với browser thông thường.
Không nên cam kết thời gian gỡ warning hoặc phục hồi ranking/index. Sau cleanup, Google cần recrawl/re-evaluate; thời gian phụ thuộc loại security issue và quá trình review.
Dùng quy trình xác minh WordPress sạch malware sau cleanup trước khi request review hoặc đóng incident.
Validation matrix sau remediation
| Gate | Điều kiện PASS |
|---|---|
| Direct visit | Không còn redirect/spam ngoài business flow |
| Search referrer/mobile UA | Không tái hiện conditional redirect |
| Rendered HTML/DOM | Không còn malicious script/link đã biết |
| Files/database | Unauthorized modification đã được xử lý |
| Persistence | Không còn account/task/plugin/option trái phép đã biết |
| Search Console | Security issue được xử lý trước khi request review |
| Monitoring | Không xuất hiện lại IOC hoặc spam URL mới |
Bài học vận hành
- Redirect malware có thể chỉ kích hoạt với referrer, user-agent hoặc device nhất định.
- JavaScript injection, SEO spam và redirects có thể cùng xuất phát từ một compromise.
- Owner mở website bình thường không chứng minh site không bị hacked cloaking.
- Spam URL phải được điều tra cùng file/database/persistence, không chỉ xóa khỏi index.
- Security review chỉ nên request sau khi cleanup và verification thực sự hoàn tất.
- Không nên cam kết ranking/index phục hồi theo một mốc thời gian cố định.