Cron, Database Persistence và Malware tái nhiễm trên WordPress

Malware tái xuất hiện sau cleanup không phải lúc nào cũng do file backdoor còn sót. Trên WordPress, cơ chế tái nhiễm có thể nằm trong WP-Cron/system cron hoặc dữ liệu trong database: scheduled hook chạy lại payload, option chứa code/config độc hại, hoặc content/database record được dùng để khôi phục script sau khi file đã bị xóa.

WP-CLI cho phép liệt kê toàn bộ scheduled events bằng wp cron event list, còn MITRE ATT&CK ghi nhận cron/scheduled task có thể bị lạm dụng để thực thi code định kỳ và duy trì persistence. Vì vậy khi malware quay lại theo chu kỳ sau cleanup, investigation phải mở rộng khỏi filesystem sang scheduled execution và database state. Nguồn: WordPress — wp cron event list, WordPress — wp cron event và MITRE ATT&CK — Scheduled Task/Job.

Bối cảnh: file malware đã xóa nhưng vài giờ sau lại xuất hiện

Giả sử đội vận hành đã quarantine một file PHP độc hại và scan lại thấy sạch. Sau vài giờ, file tương tự được tạo trở lại hoặc JavaScript injection xuất hiện lần nữa. Không có login bất thường mới và component vulnerable đã được patch. Pattern thời gian lặp lại khiến cron hoặc database persistence trở thành giả thuyết cần ưu tiên.

Signal nào làm giả thuyết persistence mạnh hơn?

• Malware quay lại theo interval tương đối ổn định.
• File mới xuất hiện ngay sau một WP-Cron/system cron event.
• Không có request exploit mới trước thời điểm tái nhiễm.
• Database option/post/meta chứa encoded script, remote URL hoặc serialized payload bất thường.
• Scheduled hook không map được về plugin/theme/business owner hợp lệ.
• Xóa file nhưng không xóa cron/database artifact thì malware tiếp tục quay lại.

Bước 1: inventory WP-Cron và system cron riêng biệt

WordPress WP-Cron là application scheduler, còn system cron là scheduler của hệ điều hành. Hai lớp này phải được kiểm tra riêng vì một site có thể dùng cả hai. wp cron event list cho biết hook, lần chạy kế tiếp và recurrence; system cron cần được kiểm tra qua crontab, timer hoặc scheduler tương ứng trên server.

Mỗi scheduled event nên được map về plugin, theme, custom code hoặc operational task có owner rõ ràng. Hook lạ không tự động là malicious; nhưng hook không có source hợp lệ, chạy ngoài baseline và correlation với thời điểm tái nhiễm là evidence quan trọng.

Bước 2: correlation thời gian giữa cron event và malware regeneration

Triage nên dựng timeline gồm: thời điểm cleanup, thời điểm scheduled event chạy, thời điểm file/database thay đổi và thời điểm IOC quay lại. Nếu malware được tạo lại ngay sau cùng một hook nhiều lần, confidence cho scheduled persistence tăng đáng kể.

Tuy nhiên correlation chưa đủ chứng minh causation. Cần xác định callback/code mà hook thực thi và kiểm tra nó có write file, fetch remote payload hoặc sửa database hay không.

Bước 3: kiểm tra database persistence

Không chỉ tìm trong wp_options

Database persistence có thể nằm trong option, post content, post meta, user meta hoặc custom table do plugin tạo. Investigation nên dựa trên baseline/schema và business context thay vì grep một chuỗi cố định.

• Option mới hoặc autoloaded option có encoded payload/remote URL.
• Post/page/widget chứa script hoặc iframe không có owner.
• User meta làm thay đổi role/capability trái phép.
• Custom table chứa task/config dùng để tái tạo payload.
• Record bị sửa đúng trước hoặc sau scheduled execution.

Tham chiếu Persistence trong WordPress Malware và case backdoor còn tồn tại sau cleanup để mở rộng scope ngoài filesystem.

Khi nào có thể xác nhận cron/database persistence là root cause?

Không nên kết luận chỉ vì có cron hook lạ hoặc database record đáng ngờ. Root cause mạnh khi có chuỗi evidence chứng minh artifact đó thực sự tái tạo malware.

• Scheduled hook hoặc database artifact tồn tại qua cleanup window.
• Execution/change timestamp khớp thời điểm malware quay lại.
• Callback/query/code có khả năng tạo lại payload.
• Disable/quarantine artifact làm chu kỳ tái nhiễm dừng lại.
• Không có alternate entry path hợp lý hơn trong cùng khoảng thời gian.

Containment: dừng recurring execution trước khi cleanup lần nữa

Nếu một scheduled task đang tái tạo malware, chỉ xóa file sẽ tạo vòng lặp cleanup–reinfection. Cần preserve evidence rồi disable/unschedule task hoặc isolate execution path trước khi tiếp tục eradication.

• Export danh sách scheduled events và metadata trước thay đổi.
• Preserve callback/source file hoặc database record liên quan.
• Disable/unschedule malicious event có kiểm soát.
• Quarantine payload và block remote endpoint nếu đã xác nhận.
• Giữ log để xác minh task không còn chạy sau containment.

Eradication: xử lý cả scheduler, database và entry point

Sau containment, remediation phải xóa toàn bộ persistence chain. Nếu cron callback nằm trong plugin/theme bị compromise, component đó cần được rebuild từ trusted source. Nếu database record là nguồn tái tạo, phải xóa hoặc sửa record sau khi preserve evidence và xác minh dependency.

• Remove malicious cron hook/system job.
• Remove unauthorized option/content/meta/custom-table record.
• Reinstall component chứa callback từ trusted source.
• Patch vulnerability hoặc rotate credential tạo initial access.
• Review adjacent cron events và database records cùng thời điểm.

Validation: chứng minh malware không còn được tái tạo

Dùng Website Security Signals để đưa cron, database change và file regeneration vào monitoring sau remediation.

Bài học vận hành

• Xóa file malware không xử lý được persistence nằm trong scheduler hoặc database.
• WP-Cron và system cron là hai lớp khác nhau, cần inventory riêng.
• Hook lạ là signal; callback và timeline mới quyết định confidence.
• Database persistence có thể nằm ngoài wp_options.
• Correlation cần được nâng thành causation bằng callback/query evidence.
• Closure chỉ nên xảy ra sau khi malware không còn tái tạo qua các chu kỳ trước đó.

Nguồn tham khảo

• WordPress — wp cron event list
• WordPress — wp cron event
• WordPress Developer Resources — wp_cron()
• MITRE ATT&CK — Scheduled Task/Job
• CISA — APT40 tradecraft and persistence techniques