Phát hiện PHP backdoor trong WordPress không nên dựa vào một filename, một chuỗi obfuscation hay một regex duy nhất. Mục tiêu là xác định thay đổi ngoài baseline, đánh giá behavior theo static review và ghép file evidence với timeline/log — không chạy file nghi vấn trên production để thử.
Workflow phát hiện an toàn
- Khóa baseline. Xác định version WordPress/plugin/theme và nguồn tin cậy để so sánh.
- Inventory thay đổi. Ghi path, size, hash, mtime và owner của file mới/sửa.
- Integrity check. Dùng checksum/diff ở component có source chính thức.
- Static review. Đọc luồng input → authorization → action/output; không kích hoạt code.
- Correlation. Đối chiếu timestamp với access/auth/deploy log.
- Classify. Xác định file hợp lệ, suspicious finding, confirmed backdoor hay chưa đủ evidence.
- Preserve rồi remediate. Lưu evidence phù hợp trước clean replacement/removal.
Integrity checks chỉ đọc
Với WordPress core:
wp core verify-checksumsVới plugin có checksum trên WordPress.org:
wp plugin verify-checksums --allCác lệnh này giúp phát hiện file khác checksum nhưng mismatch không tự động chứng minh malware; cần kiểm tra version, source và custom code. Tài liệu: WP-CLI core verify-checksums và WP-CLI plugin verify-checksums.
Static review: đọc behavior, không săn “từ khóa xấu”
| Câu hỏi | Evidence cần xem | Không nên kết luận từ |
|---|---|---|
| Input đến từ đâu? | Request, hook, file, DB, cron | Chỉ thấy biến request |
| Có authorization/validation không? | Capability/nonce/logic kiểm soát | Một hàm nhạy cảm đứng riêng lẻ |
| Code thực hiện gì? | File write, include, account/config change, outbound request | Obfuscation đơn thuần |
| Behavior có đúng chức năng component? | Docs/repo/baseline/change record | Tên file “lạ” |
Expected output của investigation
| Finding | State | Next action |
|---|---|---|
| File khớp clean source | PASS cho integrity | Không xóa; tiếp tục layer khác nếu IOC còn |
| File khác baseline nhưng có owner/change record | EXPLAINED_CHANGE | Document và review code theo nhu cầu |
| File khác baseline, không owner, behavior đáng ngờ | SUSPICIOUS | Preserve evidence + correlation + scope |
| Behavior truy cập trái phép đã được xác minh | CONFIRMED_BACKDOOR | Contain/remediate + persistence/entry point + verify |
Đối chiếu log và timeline
Gắn mtime/file creation với request, login, deploy/update và cron gần cùng thời điểm. Một IP hoặc user-agent đơn lẻ không đủ để attribution; ưu tiên chuỗi sự kiện. Nếu cần, dùng workflow đọc access log.
MU-plugin và plugin lạ
MU-plugin được WordPress tự động nạp và có use case hợp lệ; plugin lạ cũng có thể thuộc hosting/agency. Xác minh owner/provenance trước khi coi là backdoor. Xem MU-plugin lạ có phải malware?.
Nếu xác định được backdoor
Không chỉ xóa file. Lưu path/hash/timestamp/log phù hợp, đánh giá persistence và entry point, rồi clean replacement/removal có rollback. Workflow tiếp theo: loại bỏ backdoor và bảo toàn evidence → verify sau cleanup.
Khi nào nên escalation?
Nếu backdoor liên quan nhiều host/account, activity còn tiếp diễn, chưa xác định được scope hoặc cần preservation/forensics sâu hơ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
- WP-CLI — Verify core checksums
- WP-CLI — Verify plugin checksums
- WordPress.org — FAQ: My site was hacked
Kết luận
PHP backdoor detection đáng tin cậy là baseline + integrity + static behavior + timeline/log correlation. Không chạy suspect trên production và không kết luận chỉ từ obfuscation; output phải là finding có state, evidence và next action rõ ràng.