Điều tra mã độc WordPress không phải là chạy một máy quét rồi xóa file đỏ. Mục tiêu là dựng timeline, xác định phạm vi, tìm cơ chế persistence, loại bỏ mã độc từ mọi lớp và thu thập đủ bằng chứng để chứng minh website ổn định sau làm sạch.
Quy trình này nối access log, tính toàn vẹn tệp, database, cron và danh tính thành một cuộc điều tra thống nhất. Mọi thao tác phá hủy cần diễn ra sau snapshot và có đường rollback.
Bước 1: định nghĩa câu hỏi điều tra
Website đang biểu hiện gì? Sự kiện đầu tiên được biết lúc nào? Dữ liệu hoặc chức năng nào bị ảnh hưởng? Những thay đổi nào diễn ra gần đó? Việc đặt câu hỏi cụ thể giúp tránh thu thập mọi thứ nhưng không trả lời được nguyên nhân.
Bước 2: bảo toàn dữ liệu và chuẩn hóa thời gian
Tạo snapshot tệp, database, access/error log, cấu hình, cron và user. Ghi timezone, thời điểm lấy mẫu, người thực hiện và checksum của bản sao khi có thể. Không phân tích tệp nghi vấn theo cách có thể thực thi nó.
Bước 3: dựng timeline từ access log
Bắt đầu từ timestamp của file/user/nội dung lạ rồi tìm request trước và sau. Nhóm theo phiên tương đối và nối với hậu quả. Lưu ý proxy/CDN, log rotation, timezone và khả năng user-agent/IP bị thay đổi.
Bước 4: so sánh tệp với nguồn sạch
Xác minh core và plugin có checksum, rà package premium/tùy biến bằng nguồn phát hành hoặc repository. Tìm file mới trong core, PHP trong uploads, mu-plugin/drop-in và cấu hình rewrite. Không dừng khi checksum core đạt.
Bước 5: rà database có kiểm soát
Trên bản sao, tìm IoC trong posts, options, users/usermeta và bảng plugin. Ghi record, owner, ngữ cảnh trước khi sửa. Cẩn trọng với serialized data và dữ liệu cá nhân; tránh search-replace rộng trên production.
Bước 6: kiểm tra cron và persistence
Liệt kê WP-Cron cùng system cron, tìm callback và thành phần sở hữu. Nối nhịp tái tạo file với lịch chạy nhưng phải xác minh code thực tế. Không chạy thử callback nghi vấn trên website thật.
Bước 7: điều tra user, session và credential
Rà Administrator, capability trực tiếp, Super Admin, session, application password và tài khoản hạ tầng. Xác định người sở hữu, thu hồi quyền trái phép và xoay credential sau khi thiết bị quản trị được kiểm tra.
Bước 8: làm sạch và đóng đường vào
- Thay code từ nguồn sạch, xử lý database có phạm vi.
- Gỡ cron, account và persistence đã xác minh.
- Vá hoặc loại bỏ thành phần dễ tổn thương.
- Xoay credential, salts và khóa liên quan.
- Kiểm tra website khác cùng hosting và thiết bị quản trị.
Bước 9: xác minh và theo dõi
Quét nhiều lớp, tìm lại IoC, kiểm thử nghiệp vụ và theo dõi đủ chu kỳ. Nếu file, cron hoặc user quay lại, mở lại điều tra với snapshot mới. Báo cáo cần phân biệt điều đã chứng minh, giả thuyết có bằng chứng và khoảng trống dữ liệu.
Đầu ra của một cuộc điều tra tốt
- Timeline sự cố và phạm vi ảnh hưởng.
- Danh sách IoC: URL, tệp, record, hook và tài khoản.
- Root cause hoặc giả thuyết được xếp hạng theo bằng chứng.
- Thay đổi đã thực hiện cùng đường rollback.
- Kết quả xác minh và kế hoạch giám sát.
Nếu nhiều website cùng nhiễm, system account lạ, binary/process đáng ngờ hoặc log cho thấy quyền vượt ngoài WordPress, phạm vi phải chuyển sang điều tra hệ điều hành/hosting.
Nguồn tham khảo chính thức
Quy trình dựa trên hướng dẫn My site was hacked, Hardening WordPress, tài liệu WP-CLI về checksum, database search và cron events.
Điều tra bắt đầu khi đội ngũ ngừng hỏi “file độc nằm ở đâu?”
Mã độc chỉ là một phần của câu chuyện. Điều cần biết là attacker vào lúc nào, bằng đường nào, đã làm gì và còn giữ quyền ở đâu. Nếu chỉ tìm một file có chuỗi đáng ngờ rồi xóa, website có thể sạch trong vài giờ nhưng bằng chứng về điểm xâm nhập đã mất.
Một timeline tốt nối được nhiều nguồn
Access log cho biết request, file metadata cho biết thời điểm thay đổi, database ghi user và option, cron cho thấy persistence, còn Search Console phản ánh lúc nội dung lạ được crawl. Mỗi nguồn có thể thiếu, nhưng ghép chúng lại sẽ thu hẹp cửa sổ xâm nhập.
Ba câu hỏi WebAnToan dùng để giữ cuộc điều tra đúng hướng
- Phạm vi nào đã bị chạm tới, kể cả tài khoản và hạ tầng ngoài WordPress?
- Bằng chứng nào chứng minh nguyên nhân thay vì chỉ là triệu chứng?
- Sau khi làm sạch, kiểm soát nào xác nhận attacker không thể quay lại?
Điều tra tốt không nhất thiết tạo một báo cáo thật dài. Nó tạo ra quyết định đúng: khoanh vùng ở đâu, credential nào phải xoay và bản backup nào đủ tin cậy để phục hồi.
Cụm điều tra mã độc WordPress
Đi từ dấu vết kỹ thuật đến kết luận có thể kiểm chứng.
Câu hỏi thường gặp
Điều tra mã độc khác quét mã độc thế nào?
Quét tìm chỉ báo; điều tra còn dựng timeline, xác định phạm vi, persistence và đường xâm nhập.
Có cần giữ bản website bị nhiễm không?
Có, nên giữ snapshot cách ly để đối chiếu và điều tra, không dùng trực tiếp để phục hồi.
Nếu không tìm được root cause thì sao?
Cần ghi rõ giới hạn, mở rộng phạm vi và tăng giám sát thay vì tuyên bố đã xử lý triệt để.
Khi nào phải điều tra cả máy chủ?
Khi nhiều website cùng nhiễm hoặc xuất hiện process, system account hay thay đổi vượt ngoài WordPress.
Cần điều tra website theo dữ liệu thực tế?
WebAnToan có thể rà log, file, database, cron và tài khoản để xác định phạm vi cùng thứ tự xử lý.
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ử.
Thiết lập baseline, theo dõi file và log, ưu tiên cảnh báo rồi kiểm thử khả năng phục hồi.
