Website vừa được báo sạch nhưng vài giờ hoặc vài ngày sau lại chuyển hướng, sinh tài khoản lạ hoặc xuất hiện tệp mã độc. Đây không hẳn là một cuộc tấn công mới. Phổ biến hơn là điểm vào chưa được vá, backdoor còn sót, credential vẫn bị lộ hoặc một website khác trong cùng hosting tiếp tục lây chéo.
Bảy nguyên nhân tái nhiễm thường gặp
- Chỉ xóa tệp bị cảnh báo mà không tìm backdoor hoặc persistence.
- Plugin, theme hoặc core dễ tổn thương chưa được cập nhật hay thay thế.
- Mật khẩu hosting, SFTP, WordPress, email hoặc database vẫn bị lộ.
- Thiết bị quản trị có malware và lấy lại credential mới.
- Website khác trong cùng tài khoản hosting vẫn nhiễm.
- Cron, mu-plugin, database hoặc tài khoản quản trị lạ chưa được rà.
- Khôi phục từ backup đã chứa mã độc hoặc chưa đóng lỗ hổng.
Phân biệt tái nhiễm với cache cũ
CDN, page cache, cache trình duyệt hoặc kết quả Google có thể tiếp tục hiển thị nội dung cũ sau khi origin đã sạch. Hãy so sánh phản hồi từ origin và CDN, xóa cache có kiểm soát, kiểm tra ở chế độ riêng tư và xác minh tệp/database có thực sự thay đổi trở lại hay không. Nếu timestamp mới xuất hiện, đó là hoạt động tiếp diễn chứ không chỉ là cache.
Dựng timeline để tìm đường quay lại
Ghi thời điểm hoàn tất làm sạch, đổi từng credential, mở website và lần đầu dấu hiệu quay lại. Đối chiếu access log, auth log, cron và tệp mới sửa trong khoảng đó. Nếu một backdoor được tạo lại theo chu kỳ cố định, cron là giả thuyết đáng ưu tiên; nếu xuất hiện sau đăng nhập, cần rà tài khoản và thiết bị.
Quy trình làm sạch lần hai phải khác gì?
- Tạm ngừng thay đổi nội dung và chụp snapshot lần tái nhiễm.
- So sánh hai snapshot để tìm tệp, bảng hoặc tài khoản được tái tạo.
- Mở rộng phạm vi sang toàn bộ hosting, DNS, CDN, email và thiết bị quản trị.
- Thay thế mã nguồn từ nguồn sạch, xóa thành phần không còn tin cậy.
- Vá điểm vào trước khi mở lại và xoay toàn bộ credential liên quan.
- Bật giám sát thay đổi, đăng nhập và request bất thường sau phục hồi.
Nếu bản backup sạch được đưa lên đúng môi trường vẫn còn lỗ hổng hoặc credential lộ, website có thể nhiễm lại ngay. Restore và remediation là hai công việc khác nhau.
Tiêu chí kết thúc theo dõi
Không có mốc thời gian duy nhất phù hợp mọi website. Đội xử lý nên xác nhận checksum/tệp ổn định, không có tài khoản hoặc cron mới, log không còn request khai thác, các luồng nghiệp vụ hoạt động và cảnh báo bên ngoài đã được xử lý. Website quan trọng cần thời gian theo dõi dài hơn và người chịu trách nhiệm rõ ràng.
Nguồn tham khảo chính thức
WordPress nhấn mạnh việc thay toàn bộ điểm truy cập, thay secret keys, làm sạch và đổi mật khẩu lại sau khi sạch trong hướng dẫn hậu xâm nhập. Các biện pháp cập nhật, nguồn tin cậy và containment được mô tả trong Hardening WordPress.
Tái nhiễm là bằng chứng quy trình trước còn thiếu
Website sạch rồi lại xuất hiện mã không nhất thiết do “virus quá mạnh”. Thường là điểm vào chưa vá, credential vẫn lộ, cron/backdoor còn sót, backup nhiễm được restore hoặc website khác cùng hosting lây lại.
Dựng lại timeline giữa hai lần nhiễm
So sánh hash, vị trí và thời gian file trở lại. Nếu cùng mẫu xuất hiện đúng lịch cron, tập trung persistence; nếu theo sau login lạ, rà danh tính; nếu ngay sau deploy/restore, kiểm tra artifact nguồn.
Đừng lặp lại đúng thao tác cũ
Mỗi lần tái nhiễm cần mở rộng phạm vi và thay giả thuyết. Giữ monitoring file, outbound, user và cron trong giai đoạn quan sát. Chỉ đóng sự cố khi đã giải thích được cơ chế quay lại và kiểm soát ngăn nó tái diễn.
Tái nhiễm không phải lúc dọn nhanh hơn; đó là lúc điều tra sâu hơn.
Tiếp tục theo quy trình ứng cứu
Các bài trong cụm này đi từ nhận biết đến xử lý và phòng tái nhiễm.
Câu hỏi thường gặp
Website hiện lại nội dung cũ có phải tái nhiễm không?
Chưa chắc. Cần loại trừ cache CDN, cache trang và kết quả tìm kiếm cũ, sau đó kiểm tra timestamp và dữ liệu origin.
Khôi phục backup sạch có ngăn tái nhiễm không?
Không nếu lỗ hổng, credential bị lộ hoặc website khác cùng hosting chưa được xử lý.
Cần theo dõi bao lâu sau khi làm sạch?
Tùy mức độ và chu kỳ hoạt động; quan trọng là theo dõi đủ để xác nhận tệp, tài khoản, cron và log ổn định.
Cần kiểm tra website theo hiện trạng thực tế?
WebAnToan có thể rà dấu hiệu, khoanh vùng phạm vi và đề xuất thứ tự xử lý phù hợp với website của bạn.
Kết nối access log, tệp, database, cron và tài khoản thành một timeline có thể kiểm chứng.
Gia cố cấu hình, vùng ghi, danh tính, endpoint, WAF và monitoring thành bảy lớp có thể kiểm thử.
