Một file PHP thay đổi checksum, timestamp hoặc nội dung không tự động đồng nghĩa website đã bị malware. Trong WordPress, file có thể thay đổi do core/plugin/theme update, hotfix của developer, deployment automation hoặc corruption. Triage tốt phải xác định ai thay đổi, thay đổi khi nào, có change record không và file đó khác baseline ở điểm nào trước khi nâng finding thành security incident.
WordPress WP-CLI hỗ trợ wp core verify-checksums để so sánh core với checksum chính thức; WordPress Developer Blog cũng lưu ý checksum mismatch có thể do corruption hoặc dùng sai version/locale, và plugin premium/custom có thể không có checksum trên WordPress.org. Vì vậy file-integrity alert là signal cần điều tra, không phải verdict. Nguồn: WordPress — wp core verify-checksums, WordPress Developer Blog — Website security checks và WordPress — wp plugin verify-checksums.
Bối cảnh: một file PHP đổi bất thường ngoài maintenance window
Giả sử monitoring phát hiện một file PHP trong plugin hoặc theme thay đổi lúc 03:17 UTC. Không có deployment được ghi nhận trong maintenance window, checksum hiện tại khác baseline, nhưng website vẫn hoạt động bình thường và chưa có IOC rõ ràng.
Những signal cần thu thập ngay
- Path, owner, permission, size, mtime/ctime và hash trước/sau.
- Package/version hiện tại của core, plugin hoặc theme chứa file.
- Deployment/update log quanh thời điểm file đổi.
- Process/user/account nào có quyền ghi vào path.
- Web access, admin activity, SSH/SFTP hoặc control-panel log liên quan.
- Nội dung diff có obfuscation, eval/base64, external domain, credential access hoặc file-write behavior hay không.
Bước 1: xác minh đây có phải thay đổi hợp lệ không
Trước tiên cần map file về component owner và phiên bản. Nếu file thuộc WordPress core, wp core verify-checksums có thể so sánh với checksum chính thức của đúng version/locale. Với plugin WordPress.org, wp plugin verify-checksums hỗ trợ kiểm tra tương tự.
Tuy nhiên checksum không bao phủ mọi trường hợp. Plugin custom hoặc premium có thể không có checksum công khai; hotfix hợp lệ cũng tạo mismatch. Vì vậy cần đối chiếu với package từ nguồn tin cậy, Git commit/deployment artifact hoặc bản backup gần nhất.
Tham chiếu File Integrity WordPress và giám sát plugin, theme và WordPress Core thay đổi bất thường để xây baseline trước khi triage.
Bước 2: đọc diff để phân biệt update với tampering
Dấu hiệu nghiêng về legitimate change
- File khớp package chính thức của version vừa deploy.
- Timestamp trùng deployment/update window đã được phê duyệt.
- Diff phù hợp changelog hoặc commit được xác minh.
- Không có code obfuscated, external loader hoặc privilege escalation mới.
Dấu hiệu cần nâng confidence security finding
- Code bị chèn ngoài function/class structure bình thường.
- Có obfuscation, dynamic execution, remote fetch hoặc command execution.
- File được sửa ngoài deployment window bởi account/process không có owner.
- Xuất hiện thêm file lạ ở cùng directory hoặc writable path.
- Access/auth log cho thấy activity bất thường ngay trước thời điểm file đổi.
Bước 3: tìm process hoặc account đã tạo thay đổi
File diff cho biết cái gì thay đổi, nhưng root cause cần biết ai hoặc process nào đã ghi file. Cần correlate filesystem metadata với deployment agent, web/PHP process, SSH/SFTP account, control panel, WordPress admin action và scheduled task.
Nếu không có log đủ để attribution chính xác, finding nên ghi giới hạn evidence thay vì suy diễn attacker path. Ví dụ: “unauthorized PHP modification confirmed; write origin not attributable with available logs”.
Khi nào có thể xác nhận file PHP bị tamper trái phép?
Checksum mismatch đơn lẻ chưa đủ. Confidence mạnh hơn khi nhiều lớp evidence khớp nhau.
- File không khớp trusted package/baseline.
- Không có deployment/change record hợp lệ.
- Diff chứa behavior không thuộc chức năng dự kiến.
- Writer/process/account không được authorize hoặc không giải thích được.
- Có related IOC như file lạ, login bất thường, outbound request hoặc persistence.
Containment và remediation
Trước khi overwrite file, nên lưu bản sao hiện tại, hash và metadata nếu incident cần RCA. Sau đó remediation phụ thuộc scope: một file core/plugin bị sửa có thể được thay bằng bản trusted, nhưng nếu có dấu hiệu compromise rộng hơn thì cần mở rộng sang account, persistence, credential và entry point.
- Quarantine hoặc preserve file đáng ngờ trước khi replace.
- Reinstall core/plugin/theme từ trusted source nếu integrity không còn đủ confidence.
- Review writable permissions và account/process có quyền ghi.
- Patch/remove vulnerability hoặc credential issue nếu xác định được entry point.
- Scan/review các file lân cận và persistence mechanism liên quan.
Nếu evidence cho thấy backdoor, tham chiếu case phát hiện Backdoor bằng File Integrity Monitoring để mở rộng scope điều tra.
Validation sau remediation
| Gate | Điều kiện PASS |
|---|---|
| Trusted comparison | File khớp package/baseline được xác minh |
| Unexpected files | Không còn file lạ đã biết trong path liên quan |
| Permissions | Chỉ process/account cần thiết có quyền ghi |
| Deployment | Change path có owner và audit trail rõ |
| Monitoring | Không tái xuất hiện modification ngoài window |
| Business flow | Website/plugin/theme vẫn hoạt động bình thường |
Bài học vận hành
- File-integrity alert là signal, không phải kết luận malware.
- Checksum phải so với đúng version/locale/package.
- Custom/premium plugin cần trusted baseline riêng nếu không có checksum công khai.
- Diff nên được correlation với deployment, account và process evidence.
- Không overwrite file đáng ngờ trước khi preserve evidence nếu cần RCA.
- Closure chỉ nên xảy ra khi integrity và write path đều được xác minh.