Mã độc WordPress có thể tồn tại trong database dưới dạng script chèn, URL spam, tài khoản, capability, option hoặc payload được plugin lưu. Nếu chỉ thay tệp mà bỏ qua database, chuyển hướng và nội dung trái phép có thể tiếp tục xuất hiện dù checksum core hoàn toàn sạch.
Tạo bản export, làm việc trên bản sao và bắt đầu bằng câu lệnh chỉ đọc. Không chạy search-replace hoặc DELETE hàng loạt trên production khi chưa hiểu serialization và quan hệ dữ liệu.
Những bảng nào thường cần xem?
Tiền tố bảng không nhất thiết là `wp_`. Phạm vi thường gồm posts/postmeta cho nội dung, options cho cấu hình, users/usermeta cho tài khoản và quyền, comments nếu bị spam, cùng các bảng riêng của plugin. Trên Multisite, cấu trúc và phạm vi site cần được xác định trước.
Tìm theo chỉ báo đã biết
wp db search 'ten-mien-dang-ngo' --stats
wp db search '<script' wp_options wp_posts --format=table`wp db search` giúp xác định bảng, cột và bản ghi khớp chuỗi. Kết quả không tự động là mã độc: website hợp lệ cũng có script, iframe và URL ngoài. Hãy so sánh với cấu hình plugin, lịch sửa nội dung và domain được doanh nghiệp sử dụng.
Rà options và autoload
Options có thể chứa widget, snippet, URL, cache hoặc dữ liệu serialized. Một payload bị chèn vào option autoload có thể xuất hiện trên nhiều trang. Trước khi sửa, ghi lại option_name, kích thước, định dạng và plugin sở hữu; sửa sai serialized data có thể làm plugin hoặc site lỗi.
Kiểm tra users và capabilities
Không chỉ nhìn bảng users. Role và capability của từng tài khoản nằm trong usermeta, còn cấu hình role nằm trong options. Tài khoản hợp lệ bị nâng quyền cũng nguy hiểm như tài khoản mới. Đối chiếu ngày đăng ký, email, role, session và người sở hữu thực tế.
Nhận biết nội dung SEO spam
Tìm post ở trạng thái publish, draft, trash và custom post type; kiểm tra slug, author, ngày sửa và meta liên quan. URL spam có thể được sinh động từ option hoặc code nên không nhất thiết có một post tương ứng. Hãy đối chiếu HTML phản hồi và rewrite trước khi xóa database.
Làm sạch mà vẫn có thể rollback
- Export database và lưu checksum của bản sao.
- Ghi danh sách record nghi vấn cùng lý do.
- Thử thay đổi trên bản sao hoặc staging.
- Thực hiện thay đổi có phạm vi hẹp, lưu câu lệnh và số dòng ảnh hưởng.
- Xóa cache, kiểm thử chức năng và tìm lại chỉ báo.
Database có thể chứa email, token, đơn hàng và dữ liệu cá nhân. Việc phân tích cần diễn ra trong môi trường được kiểm soát.
Nguồn tham khảo chính thức
Tham khảo cú pháp và giới hạn của wp db search, cùng cấu trúc role/capability trong Plugin Handbook.
Database có thể giữ mã độc mà scanner file không bao giờ thấy
JavaScript chuyển hướng, admin lạ, cron option, widget và payload mã hóa có thể nằm trong options, posts hoặc usermeta. Restore source code sạch nhưng giữ database nhiễm khiến triệu chứng quay lại ngay khi cache được tạo lại.
Đừng tìm kiếm–thay thế toàn bộ khi chưa hiểu dữ liệu
Một chuỗi đáng ngờ có thể nằm trong serialized data; sửa trực tiếp làm hỏng cấu trúc. Trước thao tác, export database, ghi số bản ghi, khóa chính và giá trị gốc. Dùng công cụ hiểu serialization hoặc cập nhật qua API khi phù hợp.
Những thay đổi cần nối với timeline
- User/role được tạo hoặc nâng quyền.
- Site URL, active plugins, cron và rewrite option bị đổi.
- Post ẩn, SEO spam và script trong widget/template.
- Đơn hàng, form hoặc dữ liệu khách bị truy cập bất thường.
Câu hỏi quan trọng không chỉ là xóa record nào, mà là tài khoản hay request nào đã có quyền ghi nó và còn đường nào ghi lại hay không.
Database cũng cần bằng chứng trước và sau
Ghi checksum/export, số lượng record bị tác động và câu lệnh hoặc công cụ đã dùng. Sau làm sạch, kiểm tra cache/object cache vì payload cũ có thể còn được phục vụ dù bảng đã sửa.
Dữ liệu kinh doanh cần được bảo toàn
Không xóa hàng loạt posts, orders hoặc users theo từ khóa đơn giản. Tạo bản sao, lọc theo pattern và review mẫu với owner nghiệp vụ; một thao tác SQL vội có thể gây thiệt hại lớn hơn mã độc.
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
Mã độc có thể tồn tại chỉ trong database không?
Có. Script, URL spam, option, tài khoản và capability đều có thể nằm trong database.
Có nên tìm và xóa mọi thẻ script?
Không. Website hợp lệ có thể dùng script; cần xác định owner và ngữ cảnh từng record.
Vì sao search-replace có thể làm website lỗi?
Dữ liệu serialized chứa độ dài chuỗi; thay đổi không đúng công cụ có thể làm hỏng cấu trúc.
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ý.
