Khi đã xác định một thành phần có dấu hiệu là WordPress backdoor, mục tiêu không chỉ là xóa nó càng nhanh càng tốt. Cần cân bằng containment với việc bảo toàn evidence đủ để hiểu phạm vi compromise, persistence và entry point trước khi dấu vết quan trọng bị thay đổi.
Containment hay evidence: ưu tiên thế nào?
| Tình huống | Ưu tiên | Hành động |
|---|---|---|
| Site đang redirect/phát tán nội dung nguy hiểm | Containment cao | Giảm impact trước, đồng thời lưu tối thiểu path/hash/log/timestamp nếu có thể |
| Backdoor đã xác minh nhưng activity chưa thấy tiếp diễn | Evidence + controlled removal | Chụp trạng thái, copy artifact, ghi hash, sau đó thay sạch |
| Nhiều host/account bị ảnh hưởng | Incident response | Không xử lý cục bộ từng file; cần scope/coordination/forensics |
Evidence manifest tối thiểu
| Field | Nội dung cần ghi |
|---|---|
| Artifact ID | Mã nội bộ duy nhất |
| Path / object | Đường dẫn file, user, cron, DB row hoặc config |
| Hash / state | Hash file hoặc mô tả state |
| Timestamp | mtime/ctime khi có + thời điểm thu thập |
| Collector | Người/đội thực hiện |
| Source | Production, backup, log, snapshot |
| Action | Copied / quarantined / replaced / removed |
| Reason | Finding và evidence hỗ trợ |
Manifest không cần biến thành quy trình pháp y phức tạp cho mọi website nhỏ, nhưng phải đủ để phân biệt artifact ban đầu với thay đổi do đội remediation tạo ra.
Chain-of-custody tối thiểu cho incident cần truy vết
- Không chỉnh trực tiếp artifact gốc trước khi đã lưu bản sao phù hợp.
- Ghi ai thu thập, lúc nào, từ đâu và hash/state trước thay đổi.
- Lưu bản working copy riêng nếu cần static review.
- Ghi mọi thao tác remediation sau đó để timeline không bị trộn với attacker activity.
CISA nhấn mạnh incident response có cấu trúc và duy trì artifact phục vụ containment, eradication và recovery. Tham khảo CISA Incident & Vulnerability Response Playbooks.
Không chạy backdoor trên production để “xác minh”
Không cần kích hoạt hoặc gửi input cho code nghi vấn trên website thật để chứng minh nó nguy hiểm. Ưu tiên provenance, diff, static review, log và hành vi đã quan sát. Nếu cần đánh giá file PHP, dùng workflow phát hiện PHP backdoor.
Clean replacement thay vì sửa thủ công khi có nguồn tin cậy
Với WordPress core hoặc component có nguồn phát hành đáng tin cậy, thường nên đối chiếu đúng version rồi thay file compromised bằng clean source thay vì cố gỡ từng đoạn code. Với core, có thể dùng:
wp core verify-checksums
Tài liệu chính thức: WP-CLI — Verify core checksums. Custom code cần baseline/repository riêng; không xóa chỉ vì không có checksum công khai.
Loại bỏ file có đủ không?
Không. Sau khi containment và thu evidence phù hợp, cần kiểm tra persistence và entry point. Nếu chỉ xóa file nhưng bỏ sót cron, MU-plugin, account, credential hoặc loader khác, backdoor/payload có thể quay lại. Xem persistence trong WordPress malware.
Remediation record mẫu
| Action | Before | After | Rollback | Verification |
|---|---|---|---|---|
| Replace compromised file | Hash/path bản nghi vấn | Hash/source bản sạch | Snapshot/backup trước thay đổi | Checksum/diff PASS |
| Disable/remove account | User/role/activity | Không còn quyền trái phép | Owner confirmation + account record | Auth log/user list |
| Remove persistence | Cron/plugin/MU-plugin finding | Mechanism bị xử lý | Config snapshot | Không tái tạo payload |
Verification artifact phải chứng minh gì?
- Artifact độc hại đã được loại bỏ hoặc thay sạch.
- Persistence không còn tái tạo file/user/payload.
- Credential/entry point liên quan đã được xử lý.
- Frontend không còn triệu chứng trong điều kiện tái hiện.
- Timeline remediation được ghi lại để phân biệt với activity trước đó.
Checklist verification chi tiết: xác minh WordPress sạch malware sau cleanup.
Khi nào nên escalation?
Nếu nhiều host/account liên quan, activity còn tiếp diễn, cần preservation/forensics sâu hơn hoặc không thể containment mà không phá evidence quan trọng, nên chuyển sang Incident Response. WordPress đơn lẻ cần cleanup + recovery + verification có thể theo Malware Removal.
Nguồn kỹ thuật tham khảo
- CISA — Incident Response Playbooks
- WP-CLI — Verify core checksums
- WordPress.org — FAQ: My site was hacked
Kết luận
Loại bỏ WordPress backdoor an toàn là quá trình có kiểm soát: containment khi cần, evidence manifest đủ dùng, clean replacement, xử lý persistence/entry point/credential và verification bằng artifact. Mục tiêu là phục hồi website mà không làm mất khả năng hiểu nguyên nhân và chứng minh trạng thái sau remediation.
