Persistence WordPress Malware: Backdoor, Cron, MU-plugin

Persistence trong WordPress malware là tập hợp cơ chế giúp bên xâm nhập duy trì hoặc lấy lại quyền truy cập, hoặc khiến payload xuất hiện trở lại sau remediation. Đây là lý do cleanup chỉ xóa phần nhìn thấy được có thể thất bại: payload có thể biến mất trong vài giờ nhưng cơ chế tái tạo vẫn còn.

Payload, persistence và entry point khác nhau thế nào?

Khái niệm	Vai trò	Ví dụ	Câu hỏi điều tra
Payload	Biểu hiện hoặc hành vi gây hại	SEO spam, redirect, injected JS	Cái gì đang tác động tới site/user?
Persistence	Duy trì hoặc tái tạo quyền/payload	Backdoor, cron, MU-plugin, account, loader	Cái gì khiến thay đổi quay lại?
Entry point	Con đường ban đầu dẫn đến compromise	Credential bị lộ, lỗ hổng, cấu hình sai	Làm sao attacker vào được lần đầu?

Nếu nghi entry point là component có lỗ hổng, đối chiếu case Plugin WordPress có lỗ hổng dẫn tới Website bị xâm nhập để tách bằng chứng exploitation khỏi việc chỉ biết component có CVE.

Điều tra persistence theo từng layer

Layer matrix: nên kiểm tra persistence ở đâu?

Layer	Finding thường gặp	Evidence nên thu	False positive cần loại trừ
Filesystem	Backdoor, loader, file PHP bị sửa; xem case PHP Backdoor trong file cấu hình WordPress	Path, hash, diff, mtime, owner/deploy history	Update/plugin/theme hợp lệ
Database	Code/URL/config bị chèn	Row/revision/options, timestamp, source	Automation hoặc plugin hợp lệ
Cron / scheduled task	Job tái tạo file/post/config; xem case Cron, Database Persistence và Malware tái nhiễm	Hook, callback, args, schedule, owner	Backup/cache/maintenance job
Plugin / MU-plugin	Code tự nạp hoặc plugin không owner; xem case Admin lạ, Plugin lạ và MU-plugin Persistence	Path, provenance, repo/ticket, callback	Hosting/agency feature hợp lệ
Account / credential	Admin lạ, API key, secret bị lộ; xem case Credential Leak khiến Website bị tái xâm nhập	User/role, auth log, rotation history	Account vận hành hợp lệ

Cron: inventory trước khi xóa

Scheduled task là chức năng hợp lệ. Không nên xóa toàn bộ cron chỉ vì site từng nhiễm malware. Với WP-CLI, có thể liệt kê event:

wp cron event list

Kết quả mặc định gồm hook, thời điểm chạy tiếp theo và recurrence; mục tiêu là xác định hook/callback nào không có owner hoặc không khớp chức năng đã biết. Tài liệu: WP-CLI — wp cron event list.

MU-plugin: tự động nạp nhưng không mặc nhiên độc hại

WordPress mô tả must-use plugins là plugin trong thư mục đặc biệt, được tự động bật và không tắt theo cách plugin thông thường. Chính đặc tính này khiến wp-content/mu-plugins đáng kiểm tra trong incident, nhưng hosting hoặc agency cũng thường dùng MU-plugin hợp lệ. Xem WordPress — Must-use plugins và workflow kiểm tra MU-plugin lạ.

Flow điều tra persistence

Dựng timeline. Khi nào payload bị phát hiện, xóa, rồi quay lại?
Gắn mỗi lần tái xuất hiện với layer. File nào được tạo lại, user nào xuất hiện, cron nào chạy, request nào xảy ra?
Tìm common predecessor. Event nào luôn xảy ra trước khi payload quay lại?
Xác minh owner. Với plugin/MU-plugin/cron/account, tìm repo, ticket, hosting feature hoặc người chịu trách nhiệm.
Contain và bảo toàn evidence. Tránh chạy code nghi vấn; lưu hash/path/log trước thay đổi lớn nếu cần.
Loại bỏ persistence + entry point. Không chỉ xóa payload.
Verify qua observation window. Theo dõi xem file/user/redirect/spam có quay lại trong điều kiện tương tự không.

Evidence table mẫu

Thời điểm	Event	Layer	Evidence	Hypothesis	Kết quả
T0	Payload bị xóa	Filesystem	Hash/path	Cleanup hoàn tất?	Pending
T1	Hook chạy	Cron	Hook/callback	Job tái tạo payload?	Verify
T2	File quay lại	Filesystem	mtime/hash	Correlation với T1	Confirm/Reject

Backdoor và tài khoản đặc quyền

Backdoor có thể là một persistence mechanism quan trọng, nhưng không phải mọi persistence đều là backdoor. Nếu có PHP đáng ngờ, dùng workflow phát hiện PHP backdoor. Nếu Admin lạ xuất hiện hoặc quay lại, dùng workflow xác minh tài khoản Admin lạ.

Remediation và verification

Expected result sau remediation

Payload đã bị loại bỏ.
Persistence mechanism đã được xác định và xử lý.
Entry point/credential liên quan đã được xử lý hoặc có owner/mitigation rõ ràng.
Không có file/account/job/plugin bất thường quay lại trong observation window phù hợp với risk.
Verification sau cleanup có evidence, không chỉ dựa vào “scan sạch một lần”.

Khi nào nên escalation?

Nếu chưa xác định được layer tái tạo payload, persistence liên quan nhiều hệ thống/account, hoạt động trái phép vẫn tiếp diễn hoặc cần containment/forensics phối hợp, nê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

Kết luận

Persistence giải thích vì sao WordPress có thể tái nhiễm dù payload đã bị xóa. Điều tra tốt phải tách payload, persistence và entry point; kiểm tra file, database, cron, plugin/MU-plugin và account theo evidence; sau đó verify qua timeline thay vì dựa vào một lần scan.