Website có thể trông “sạch” ngay sau cleanup nhưng vẫn chưa được eradicated hoàn toàn. Nếu một webshell phụ, MU-plugin, cron job, hidden admin, malicious option trong database hoặc credential bị chiếm quyền còn tồn tại, attacker hoặc chính persistence mechanism có thể tái tạo payload sau vài giờ hoặc vài ngày.
CISA Incident Response Playbook yêu cầu trước recovery phải xác định và xử lý mọi phương thức persistent access, vì adversary thường dùng nhiều cơ chế backdoor cùng lúc. CISA cũng khuyến nghị tiếp tục detection sau eradication để phát hiện re-entry; nếu activity quay lại, phải quay về technical analysis thay vì coi cleanup đã thành công. WordPress khuyên giữ snapshot môi trường bị hack trước khi cleanup, thay các thành phần bằng bản sạch và đổi lại credential sau khi chắc chắn site đã sạch. Nguồn: CISA Incident Response Playbook, WordPress — FAQ My Site Was Hacked và WordPress Developer Blog — Security Checks with WP-CLI.
Bối cảnh: cleanup xong nhưng malware quay lại
Giả sử một website bị phát hiện có malicious PHP file. Đội vận hành xóa file, cập nhật plugin và chạy scanner thấy sạch. Vài giờ sau file tương tự xuất hiện lại ở đường dẫn khác. Điều này cho thấy payload ban đầu có thể chỉ là symptom; cơ chế persistence hoặc entry point thật sự vẫn còn hoạt động.
Những dấu hiệu cho thấy eradication chưa hoàn tất
- Malware tái xuất hiện sau khi file đã bị xóa.
- File mới được tạo lại với tên/path khác nhưng pattern tương tự.
- Cron event, MU-plugin hoặc drop-in lạ vẫn tồn tại.
- Hidden admin hoặc credential cũ vẫn dùng được.
- Database chứa option/post/meta bất thường có thể tái tạo payload.
- Scanner sạch nhưng access/process log vẫn có activity đáng ngờ.
Investigation: tìm persistence thay vì chỉ tìm malware file
Bước 1: dựng timeline từ lúc cleanup tới lúc tái xuất hiện
Cần ghi rõ thời điểm xóa payload, thời điểm scanner PASS, thời điểm file hoặc IOC quay lại và mọi event nằm giữa hai mốc. Nếu malicious file tái xuất hiện sau một cron execution, login lạ hoặc outbound request, correlation đó có giá trị cao hơn việc chỉ so sánh filename.
Không nên mặc định “malware tự sinh lại”. Cần xác định process, account, request hoặc scheduled task nào đã tạo lại artifact.
Bước 2: inventory các persistence mechanism có thể bị bỏ sót
CISA và MITRE ghi nhận webshell, scheduled task/cron, valid account và account manipulation đều có thể được dùng để duy trì quyền truy cập. Với WordPress, cần mở rộng scope ra ngoài plugin folder thông thường.
wp-content/mu-plugins, drop-ins nhưdb.php,advanced-cache.php.- WordPress Cron và system cron.
.htaccess,.user.ini, PHP prepend/append config.- Hidden admin trong
wp_users/wp_usermeta. - Malicious options, posts hoặc serialized payload trong database.
- Files ngoài webroot hoặc writable directory ít được scan.
- Compromised hosting, SFTP, SSH, database hoặc API credential.
Tham chiếu Persistence trong WordPress Malware và WordPress Persistence Monitoring để mở rộng scope ngoài payload hiển nhiên.
Bước 3: kiểm tra entry point vẫn còn mở không
Một cleanup tốt vẫn có thể thất bại nếu vulnerability, stolen credential hoặc exposed service ban đầu chưa được xử lý. Trong trường hợp đó, attacker chỉ đơn giản quay lại bằng đường cũ thay vì dùng persistence đã cài trước.
Vì vậy cần tách hai giả thuyết: persistence còn sót và re-compromise qua entry point chưa đóng. Cả hai có thể đồng thời tồn tại.
Khi nào có thể xác nhận cleanup trước đó thất bại?
Không nên kết luận chỉ vì một scanner báo lại cùng malware family. Evidence mạnh hơn khi có thể chứng minh artifact hoặc access mechanism tồn tại liên tục qua thời điểm cleanup.
- Persistence artifact có timestamp trước và sau cleanup.
- Same credential/session vẫn hoạt động xuyên cleanup window.
- Cron/process/log chứng minh payload được tái tạo từ cơ chế còn sót.
- Backdoor khác chưa bị xóa vẫn nhận request thành công.
- Entry point cũ chưa patch và có evidence bị khai thác lại.
Eradication: loại bỏ toàn bộ persistence và đóng entry point
Preserve evidence trước khi xóa
WordPress khuyến nghị tạo thêm snapshot của môi trường bị hack trước khi cleaning. Với incident có khả năng tái nhiễm, nên lưu raw log, file đáng ngờ, hash, timestamp và database record cần thiết trước khi quarantine/xóa để còn dữ liệu xác định root cause.
Xem thêm cách loại bỏ WordPress backdoor mà vẫn bảo toàn evidence.
Rebuild thành phần không còn đáng tin cậy
WordPress khuyến nghị thay lại các thành phần core từ nguồn sạch thay vì chỉ overwrite một phần, vì malware có thể thêm file mới mà updater không xóa. Plugin/theme nên được reinstall từ nguồn tin cậy khi integrity không thể xác minh.
- Xóa/quarantine toàn bộ backdoor và persistence đã xác nhận.
- Reinstall core/plugin/theme từ trusted source khi cần.
- Xóa cron, hidden admin, malicious option và unauthorized integration.
- Patch/remove component tạo initial access.
- Rotate WordPress, hosting, SSH/SFTP, database, API key và salts nếu có risk bị lộ.
Verification: scanner PASS chưa đủ để gọi website sạch
WordPress Developer Blog hướng dẫn dùng checksum để phát hiện core file bị thay đổi. Nhưng verification nên nhiều lớp: file integrity, account review, cron/MU-plugin, database, frontend behavior, outbound traffic và log monitoring.
Dùng quy trình xác minh WordPress sạch malware sau cleanup và root cause khi malware tái xuất hiện để tránh đóng incident quá sớm.
| Verification gate | Kết quả mong đợi |
|---|---|
| Core/file integrity | Khớp trusted source hoặc baseline |
| MU-plugin/drop-in/cron | Không còn persistence trái phép |
| Admin/account | Không còn user/privilege bất thường |
| Database | Không còn payload/option đáng ngờ đã biết |
| Credentials | Đã rotate khi có exposure risk |
| Entry point | Đã patch/remove/contain |
| Monitoring window | Không có re-entry hoặc IOC tái xuất hiện |
Recovery gate: chỉ đưa website trở lại khi persistence đã được account
CISA yêu cầu sau eradication vẫn tiếp tục detection để tìm dấu hiệu adversary re-entry. Nếu activity quay lại, quy trình phải quay về containment và technical analysis. Vì vậy recovery không nên dựa trên một snapshot “trông sạch”, mà trên confidence rằng persistence và initial access đã được xử lý.
Với website quan trọng, Incident Recovery Plan nên định nghĩa rõ clean gate, rollback và post-recovery monitoring trước khi mở lại traffic đầy đủ.
Bài học vận hành
- Xóa payload không đồng nghĩa eradication thành công.
- Attacker có thể dùng nhiều persistence mechanism cùng lúc.
- Reinfection có thể đến từ persistence còn sót hoặc entry point chưa đóng.
- Scanner PASS chỉ là một evidence layer, không phải closure gate duy nhất.
- Core/plugin/theme đáng ngờ nên được rebuild từ trusted source thay vì chỉ overwrite.
- Post-eradication monitoring là phần bắt buộc để phát hiện re-entry.