Website bị redirect sang trang lạ: nguyên nhân, cách điều tra và xử lý an toàn

Website tự chuyển người dùng sang một domain không mong muốn có thể do cấu hình redirect sai, cache, JavaScript, plugin hoặc một sự cố bảo mật. Nếu redirect chỉ xuất hiện trên mobile, chỉ với người đến từ Google hoặc chỉ thỉnh thoảng xảy ra, việc chẩn đoán càng khó.

Điều quan trọng là không sửa hàng loạt trước khi ghi nhận bằng chứng và xác định lớp gây redirect.

Bài này tập trung vào triệu chứng redirect bất thường và cách chẩn đoán theo lớp. Nếu đã xác nhận website nhiễm mã độc hoặc có backdoor, chuyển sang quy trình làm sạch malware/backdoor và chống tái nhiễm thay vì coi mọi redirect là một bài toán redirect riêng.

Trước hết: redirect đó có hợp lệ không?

Website có nhiều redirect bình thường; việc đầu tiên là xác định hành vi có nằm trong cấu hình mong đợi hay không.

• HTTP → HTTPS;
• www ↔ non-www;
• URL cũ → URL mới;
• trailing slash;
• chuyển ngôn ngữ/khu vực;
• redirect sau đăng nhập.

Redirect đáng nghi khi đích không thuộc hệ thống mong đợi, xuất hiện không có change record hoặc chỉ kích hoạt với một nhóm người dùng.

Ghi nhận bằng chứng trước khi sửa

Nên lưu:

• URL nguồn;
• URL đích;
• thời điểm;
• thiết bị/trình duyệt;
• referrer;
• network;
• chuỗi redirect;
• header;
• screenshot/video nếu cần;
• thay đổi gần nhất;
• log liên quan.

Nếu nghi compromise, tránh xóa file hoặc reset hệ thống ngay lập tức nếu việc đó làm mất dấu vết cần cho điều tra.

Redirect có thể phát sinh ở những lớp nào?

Redirect có thể được tạo trước khi request tới WordPress, trong ứng dụng hoặc thậm chí phía trình duyệt, nên cần điều tra theo lớp:

DNS hoặc proxy/CDN

Domain có thể trỏ sai, rule edge bị thay đổi hoặc tài khoản CDN bị compromise.

Web server

.htaccess, Nginx config, reverse proxy hoặc rule trên hosting có thể tạo redirect.

WordPress

Plugin redirect, SEO plugin, cache plugin, theme hoặc custom code có thể can thiệp.

Database

URL hoặc script độc hại có thể được chèn vào option, widget, post content hoặc cấu hình plugin.

JavaScript

Script frontend có thể kiểm tra user-agent/referrer rồi redirect có điều kiện.

Trình duyệt/máy người dùng

Extension, DNS cục bộ hoặc malware phía client cũng có thể tạo biểu hiện giống website bị nhiễm.

Vì sao redirect độc hại thường chỉ xuất hiện thỉnh thoảng?

Kẻ tấn công có thể cố tình tránh bị chủ website phát hiện bằng cách kích hoạt theo:

• user-agent mobile;
• referrer từ search;
• cookie;
• IP;
• số lần truy cập;
• thời gian;
• vị trí;
• URL cụ thể.

Vì vậy thử một lần trên máy quản trị rồi kết luận “hết lỗi” là chưa đủ.

Khi redirect là dấu hiệu compromise: khoanh vùng trước, làm sạch theo quy trình malware

1. ghi nhận evidence;
2. giới hạn thay đổi không cần thiết;
3. cô lập nếu redirect gây hại nghiêm trọng;
4. xác định scope: account, server, WordPress, database, DNS/CDN;
5. tìm persistence, không chỉ file hiện ra đầu tiên;
6. làm sạch hoặc phục hồi từ bản sạch đã xác minh;
7. rotate credential/secrets có nguy cơ lộ;
8. cập nhật dependency liên quan;
9. verify từ nhiều môi trường;
10. theo dõi tái diễn.

Nếu đã xác nhận malware/backdoor hoặc persistence, quy trình owner là xử lý website nhiễm malware/backdoor. Bài website bị hack hoặc tấn công là incident hub phù hợp khi scope sự cố rộng hơn redirect.

Có nên restore backup ngay?

Restore có thể là lựa chọn tốt nếu biết mốc sạch và hiểu vector xâm nhập. Nhưng nếu lỗ hổng, credential hoặc backdoor vẫn tồn tại, website có thể bị tái nhiễm sau restore.

Trước khi dùng backup, xem lại backup website, RPO/RTO và restore test.

Kiểm tra sau khi xử lý

• redirect chain đúng;
• DNS/CDN không có rule lạ;
• admin/role hợp lệ;
• file integrity;
• plugin/theme;
• database;
• cron;
• server config;
• log;
• mobile/referrer-specific behavior;
• Search Console/security warning nếu có;
• monitoring vài ngày/chu kỳ phù hợp.

Nếu redirect làm người dùng đến trang độc hại, ưu tiên an toàn người dùng trước tối ưu SEO. Sau phục hồi mới rà canonical, sitemap, internal link và indexation nếu chúng bị ảnh hưởng.

Khi nào không nên tự xử lý?

Nếu website chứa dữ liệu nhạy cảm, có payment, nhiều site dùng chung hosting, không có backup tin cậy hoặc có dấu hiệu lateral movement, nên chuyển sang quy trình incident có người đủ năng lực. Việc sửa thử từng plugin trên production có thể vừa làm mất evidence vừa kéo dài downtime.

Redirect lạ là triệu chứng, không phải nguyên nhân. Xử lý tốt phải trả lời được: redirect được tạo ở đâu, bằng cách nào, scope bao nhiêu và điều gì ngăn nó quay lại.

Đọc thêm trong cụm Managed Website: Website Security Monitoring; Website nhiễm malware/backdoor; Dịch vụ quản trị và vận hành website.

Nếu redirect là một phần của sự cố rộng hơn cần severity, containment, recovery và verify có điều phối, xem Website Incident Response.

Khi redirect là dấu hiệu website đã bị compromise

Bài này tiếp tục sở hữu intent website bị redirect sang trang lạ và chẩn đoán theo lớp. Nếu đã xác nhận malware, backdoor, admin lạ hoặc redirect độc hại và cần containment, cleanup, recovery cùng verification có owner, xem dịch vụ xử lý website bị hack.