Bài phân tích này xem xét tình huống một website WordPress xuất hiện file thay đổi bất thường và cách dùng File Integrity Monitoring để xác minh đó là update hợp lệ, false positive hay một backdoor cần xử lý. Nội dung được xây dựng từ tài liệu công khai của WordPress, NSA/CISA và OWASP; đây không phải incident, số liệu vận hành hay case khách hàng thực tế của SecureWebOps.
Backdoor trên web server thường không cần “ồn ào”. Một attacker đã có foothold có thể thêm một file PHP mới, sửa file có sẵn hoặc cài persistence vào vị trí ít được để ý để giữ quyền truy cập lâu dài. Vì vậy, thay đổi file không có change record hợp lệ là một tín hiệu cần được điều tra chứ không nên mặc định là lỗi deploy.
WordPress Developer Blog ghi nhận rằng website bị hack thường có file mới hoặc file hiện có bị sửa, và khuyến nghị dùng checksum để kiểm tra core/plugin. NSA cũng mô tả web shell là malware được đặt trên web server để thực thi lệnh từ xa và thường được attacker triển khai bằng cách thêm hoặc sửa file trong web application. Nguồn: WordPress Developer Blog — Website security checks và NSA — Detect & Prevent Web Shell Malware.
Bối cảnh và tín hiệu đầu tiên
Giả sử một website WordPress đang vận hành bình thường, không có deploy trong khung giờ gần nhất. Hệ thống monitoring bất ngờ ghi nhận một file PHP mới trong thư mục plugin hoặc một core file có checksum khác với bản phát hành chính thức.
Một file thay đổi chưa đủ để kết luận compromise. Plugin update, auto-update, cache generation, deployment script hoặc developer hotfix đều có thể tạo thay đổi hợp lệ. Việc đầu tiên là xác định thay đổi này có nằm trong một change window đã biết hay không.
Những tín hiệu làm mức độ nghi ngờ tăng lên
- File xuất hiện ngoài khung giờ deploy hoặc không có owner xác nhận.
- File nằm trong
wp-admin,wp-includeshoặc plugin nhưng không thuộc bản phát hành hợp lệ. - Checksum core/plugin không khớp với WordPress.org.
- Tên file giống core/plugin hợp lệ nhưng vị trí, timestamp hoặc nội dung khác thường.
- File PHP xuất hiện ở thư mục vốn chủ yếu chứa media hoặc static assets.
- Access log cho thấy request trực tiếp tới file mới sau thời điểm file xuất hiện.
Investigation: từ file change đến bằng chứng compromise
Bước 1: xác minh core và plugin bằng checksum
WP-CLI cung cấp wp core verify-checksums để so sánh file core với checksum chính thức của WordPress.org. Tùy chọn --include-root còn giúp phát hiện file lạ ở root. Với plugin từ WordPress.org, wp plugin verify-checksums --all --strict có thể kiểm tra các file plugin so với checksum tương ứng. Nguồn: WP-CLI core verify-checksums và WP-CLI plugin verify-checksums.
Checksum mismatch là một finding cần điều tra, không phải bằng chứng malware tuyệt đối. Plugin premium/custom có thể không có checksum trên WordPress.org; core mismatch cũng có thể do file bị chỉnh sửa thủ công hoặc sai locale/version khi đối chiếu.
Bước 2: phân biệt thay đổi hợp lệ với tampering
Đối chiếu timestamp của file với update log, deployment log, package version và người thực hiện thay đổi. Nếu monitoring ghi nhận file được tạo lúc 02:14 nhưng không có deploy, plugin update hoặc maintenance nào trong thời điểm đó, mức độ nghi ngờ tăng đáng kể.
WordPress Developer Blog cũng lưu ý rằng checksum có thể pass nhưng vẫn có file lạ mới được thêm vào; do đó chỉ dựa vào “core verifies successfully” là chưa đủ. Cần xem cả unexpected files và các thư mục không được checksum bao phủ đầy đủ.
Bước 3: correlate với access log và hành vi thực thi
Nếu một file lạ thực sự là persistence/backdoor, thường sẽ có thêm dấu vết: request trực tiếp tới file đó, outbound connection bất thường, account/plugin thay đổi sau cùng thời điểm, hoặc web server/PHP process truy cập file theo pattern không giống application bình thường.
OWASP nhấn mạnh rằng nếu thiếu logging và continuous monitoring thì breach rất khó phát hiện và phản ứng kịp thời. Vì vậy file-integrity event nên correlate với access/error log, WordPress audit log, authentication events và system telemetry thay vì được xử lý như một cảnh báo độc lập. Nguồn: OWASP A09:2025 — Security Logging and Alerting Failures.
Khi nào có thể xác nhận file là backdoor?
Không nên gắn nhãn “backdoor” chỉ vì file có tên lạ hoặc checksum mismatch. Confidence chỉ nên tăng lên mức xác nhận khi nhiều bằng chứng độc lập cùng khớp.
- File không thuộc release/deploy hợp lệ và không có owner xác nhận.
- Nội dung hoặc hành vi file cho phép thực thi chức năng không thuộc application bình thường.
- Access log cho thấy file được gọi trực tiếp hoặc được dùng trong chuỗi request đáng ngờ.
- File xuất hiện cùng thời điểm với account/plugin/config change bất thường.
- Khi isolate/remove file trong môi trường kiểm soát, hành vi đáng ngờ chấm dứt mà chức năng hợp lệ của site không bị ảnh hưởng.
NSA mô tả web shell là cơ chế giúp attacker duy trì quyền truy cập và thực thi lệnh qua HTTP/HTTPS, đồng thời cảnh báo loại malware này có thể hòa lẫn với traffic hợp lệ và né nhiều công cụ bảo mật thông thường. Điều đó giải thích vì sao file change signal cần được xem như điểm bắt đầu của investigation chứ không phải kết luận cuối cùng.
Remediation: xử lý file nhưng không phá hỏng bằng chứng
Containment trước khi cleanup
- Lưu hash, path, timestamp và copy forensic của file trước khi sửa/xóa nếu quy trình incident yêu cầu.
- Giới hạn truy cập tới file hoặc endpoint đáng ngờ ở web server/WAF trong khi điều tra.
- Revoke session và rotate credential nếu có bằng chứng account/credential liên quan.
- Kiểm tra cron, MU-plugin, plugin/theme file,
wp-config.phpvà các vị trí persistence liên quan. - Không chỉ xóa một file rồi coi incident đã hoàn tất.
Quy trình thu thập bằng chứng và log nên đi cùng investigation. Tham khảo những log cần thu thập khi điều tra sự cố website và cách thu thập Security Audit Evidence.
Cleanup phải xử lý cả entry point và persistence
Nếu chỉ xóa backdoor mà không xác định nguyên nhân ban đầu, website có thể bị tái nhiễm. Investigation cần tiếp tục tìm lỗ hổng plugin/theme, credential compromise, upload abuse, admin account lạ hoặc server-level access đã tạo điều kiện cho file được ghi vào hệ thống.
Sau cleanup, đối chiếu lại toàn bộ scope bằng File Integrity WordPress, Security Monitoring WordPress và xác định phạm vi ảnh hưởng của security incident.
Validation sau remediation
| Kiểm tra | Kết quả mong đợi |
|---|---|
| WordPress core checksum | PASS hoặc mọi deviation đều có giải thích hợp lệ |
| Plugin checksum | PASS với plugin có checksum chính thức |
| Unexpected files | Không còn file chưa xác định trong vùng critical |
| Access log | Không còn request tới backdoor/path đã xử lý |
| Account/session | Không còn admin/session/credential đáng ngờ |
| File integrity monitoring | Baseline mới sạch và alert tiếp tục hoạt động |
Nếu phải restore từ backup, chỉ nên dùng restore point đã được xác minh là known-good và không chứa cùng persistence. Xem Restore website sau malware.
Bài học vận hành và bước tiếp theo
- File change là tín hiệu điều tra, không tự động đồng nghĩa malware.
- Checksum rất hữu ích nhưng không bao phủ mọi custom/premium file và mọi persistence location.
- Baseline/change window giúp giảm false positive đáng kể.
- File-integrity event nên correlate với access log, account change và system telemetry.
- Cleanup phải xử lý entry point, persistence và credential liên quan.
- Sau remediation cần tạo baseline mới và giữ monitoring liên tục.