Persistence Monitoring là việc theo dõi những cơ chế có thể giúp một thay đổi tồn tại hoặc tự quay lại sau khi người quản trị nghĩ rằng website đã được xử lý. Với WordPress, các điểm cần chú ý gồm WP-Cron, MU-plugin, plugin/theme, tài khoản đặc quyền, scheduled task ở server, file cấu hình và các thay đổi có khả năng tái tạo mã hoặc quyền truy cập.
Mục tiêu không phải là gắn nhãn mọi cron job hay MU-plugin là độc hại. Cả hai đều là cơ chế hợp lệ của WordPress. Điều cần phát hiện là thành phần mới, callback lạ, thay đổi ngoài baseline hoặc cơ chế xuất hiện lại sau cleanup.
Persistence trong WordPress cần được theo dõi ở đâu?
WP-Cron và scheduled task
WordPress dùng WP-Cron để xử lý tác vụ theo lịch. Monitoring nên ghi nhận hook, callback, schedule, interval, arguments và component sở hữu event. Một event mới không có owner rõ ràng hoặc callback thay đổi ngoài deployment cần được review.
- Scheduled event mới xuất hiện ngoài change window.
- Callback không map được tới plugin/theme/core đã biết.
- Tần suất chạy tăng bất thường.
- Event đã được loại bỏ nhưng xuất hiện lại.
- Cron change đi cùng plugin mới, file change hoặc login Admin bất thường.
Không nên alert chỉ vì event chạy trễ; WP-Cron phụ thuộc vào page load nên thời điểm thực thi có thể dao động. Để xem góc hardening, tham khảo bảo mật WP-Cron WordPress.
MU-plugin và component tự nạp
Must-use plugins được WordPress tự động nạp từ wp-content/mu-plugins. Vì không vận hành giống plugin thông thường, chúng cần inventory riêng: filename, hash, owner, chức năng, thời điểm deploy và source.
Plugin và theme cũng có thể trở thành điểm persistence nếu component đã gỡ quay lại hoặc plugin inactive bỗng được active sau login bất thường. Liên kết với component monitoring để kiểm tra version, source và change context.
Tài khoản đặc quyền và server-level scheduler
Một Administrator mới, custom role có capability mạnh hoặc account đã offboard nhưng hoạt động trở lại có thể duy trì quyền truy cập. Vì vậy persistence monitoring nên correlation cron và file với account activity.
WP-Cron chỉ là scheduler ở lớp WordPress. System cron, timer hoặc automation ở hosting/control panel cũng nên nằm trong inventory nếu có quyền truy cập.
Xây baseline persistence
Baseline nên ghi nhận:
- Danh sách WP-Cron event hợp lệ.
- MU-plugin hợp lệ và hash kỳ vọng.
- Plugin/theme active hợp lệ.
- Administrator và role/capability kỳ vọng.
- System scheduled task liên quan website.
- File cấu hình và startup/deployment mechanism quan trọng.
Mỗi entry nên có owner và lý do tồn tại. Để đồng bộ baseline với toàn bộ hệ thống monitoring, xem Security Monitoring Baseline.
Thiết kế rule và correlation cho persistence
Rule ban đầu
- MU-plugin mới hoặc thay đổi ngoài deployment.
- WP-Cron event mới không có owner.
- Cron callback thay đổi hoặc tần suất tăng mạnh.
- Plugin đã gỡ xuất hiện lại.
- Administrator mới + cron hoặc file change trong cùng time window.
- File đã cleanup xuất hiện lại.
Rule cần được xây theo Security Alerting và correlation nhiều signal thay vì alert từng artifact riêng lẻ.
File Integrity Monitoring là lớp xác minh quan trọng
FIM giúp phát hiện MU-plugin, file cấu hình hoặc artifact đã cleanup quay lại. Khi persistence signal xuất hiện, kết hợp với File Integrity Monitoring để xác định file nào thay đổi và khi nào.
Monitoring sau cleanup và tái nhiễm
Sau khi xử lý malware hoặc backdoor, cần tạo last-known-good baseline mới rồi theo dõi sát các điểm persistence. Nếu cùng file, cron, MU-plugin hoặc account quay lại, root cause có thể chưa được xử lý hoàn toàn.
Đừng chỉ lặp lại cleanup. Hãy điều tra nguồn tái tạo: account, component, scheduled task, deployment pipeline hoặc server-level mechanism. Nếu website có dấu hiệu tái nhiễm, xem thêm malware tái xuất hiện sau cleanup.
Triage một persistence signal
Trước hết, bảo toàn timeline và evidence cần thiết: event nào xuất hiện, lúc nào, process/account nào liên quan và có thay đổi gì trước đó. Sau đó xác minh owner và change context.
Nếu signal có khả năng liên quan compromise, chuyển sang Incident Response thay vì chỉ xóa từng artifact. Để phân loại alert và quyết định escalation, dùng Security Alert Triage.
Checklist Persistence Monitoring
- Inventory WP-Cron.
- Inventory MU-plugin.
- Component và account baseline.
- Server scheduler inventory nếu có quyền truy cập.
- FIM cho vùng persistence quan trọng.
- Correlation account → component → cron → file.
- Review sau mỗi deployment.
- Tăng cường monitoring sau incident cleanup.
Kết luận
WordPress Persistence Monitoring hiệu quả khi nhìn xuyên nhiều lớp: WP-Cron, MU-plugin, component, account và server scheduler. Thay vì coi từng artifact là nguyên nhân, hãy theo dõi chúng như một chuỗi quan hệ và ưu tiên những thay đổi lệch baseline, tái xuất hiện hoặc đi cùng các tín hiệu compromise khác.