Admin lạ, Plugin lạ và MU-plugin Persistence trên WordPress

Một tài khoản Admin lạ, một plugin không rõ nguồn gốc và một MU-plugin bất thường có thể xuất hiện độc lập, nhưng khi cả ba cùng xuất hiện sau một compromise thì cần xem đó như một chuỗi persistence nhiều lớp. Attacker có thể dùng account để giữ quyền truy cập tương tác, plugin để chạy code trong application lifecycle và MU-plugin để bảo đảm code tự động load ngay cả khi plugin thông thường bị disable.

WordPress xác nhận must-use plugins nằm trong wp-content/mu-plugins, tự động được load, không thể disable từ Plugins UI và có thể không xuất hiện cùng cách với plugin thông thường. MITRE ATT&CK cũng liệt kê Create Account, Valid Accounts và Server Software Component/Web Shell là các persistence technique phổ biến. Vì vậy khi admin lạ và plugin/MU-plugin cùng xuất hiện, investigation cần chứng minh từng layer có owner hợp lệ hay là unauthorized persistence. Nguồn: WordPress — Must-Use Plugins và MITRE ATT&CK — Persistence.

Bối cảnh: nhiều dấu hiệu persistence xuất hiện cùng lúc

Giả sử website đã có dấu hiệu compromise. Trong quá trình triage, đội vận hành phát hiện một Administrator không ai nhận ownership, một plugin mới không có change record và một file PHP trong wp-content/mu-plugins không map được về hosting/provider hoặc codebase hiện tại.

Vì sao ba signal này đáng chú ý khi đi cùng nhau?

• Admin account có thể cung cấp access tương tác và capability cao.
• Plugin có thể chạy code qua hooks trong WordPress lifecycle.
• MU-plugin tự động load và không disable được từ Plugins UI.
• Nếu một layer bị xóa nhưng layer khác còn tồn tại, attacker có thể tái tạo persistence.
• Ba artifact có thể cùng xuất phát từ một entry point hoặc credential compromise.

Bước 1: xác minh tài khoản Admin có thực sự trái phép không

Không nên kết luận chỉ vì tên account lạ. Cần xác minh owner, thời điểm tạo, email/recovery channel, role history, login/session và change record. Nếu account thuộc vendor hoặc automation hợp lệ nhưng documentation thiếu, đó là governance finding khác với unauthorized account.

Tham chiếu WordPress xuất hiện Admin lạ để tách việc xác minh account khỏi kết luận compromise.

Bước 2: xác minh plugin lạ theo source, code và thời điểm xuất hiện

Plugin lạ chưa chắc là malware. Cần xác định source package, vendor, version, install time và code behavior. Plugin có change record hợp lệ hoặc thuộc managed host có thể là legitimate. Ngược lại, plugin không có owner, code obfuscated hoặc xuất hiện cùng thời điểm unauthorized admin được tạo làm confidence tăng đáng kể.

• Package có khớp trusted source không?
• Plugin header có name/version/author hợp lý không?
• Code có tạo user, sửa role, fetch remote payload hoặc write file không?
• Install/modify time có trùng timeline compromise không?
• Plugin có dependency business thực sự không?

Bước 3: kiểm tra MU-plugin như một persistence layer riêng

WordPress nêu rõ MU-plugin được tự động bật, không cần activation và chỉ có thể bị vô hiệu bằng cách loại bỏ file khỏi thư mục must-use. Chúng cũng không nhận update notification theo cách plugin thông thường. Điều này làm MU-plugin hữu ích cho hosting/ops hợp lệ, nhưng cũng khiến nó trở thành vị trí cần kiểm tra kỹ khi có compromise.

Điểm cần kiểm tra ở MU-plugin

• File có owner/business purpose rõ ràng không?
• Timestamp có phù hợp deployment hoặc hosting change không?
• Code có include loader từ subdirectory hoặc external path không?
• Có logic tạo admin, sửa option, remote fetch hoặc command execution không?
• MU-plugin có được ghi nhận trong runbook/inventory hiện hành không?

Đọc thêm MU-plugin lạ có phải malware không? và WordPress Persistence Monitoring.

Bước 4: correlation để xác định các artifact có cùng persistence chain không

Ba artifact chỉ trở thành một persistence chain khi timeline và behavior liên kết được với nhau. Ví dụ: MU-plugin tạo hoặc khôi phục plugin; plugin tạo Administrator; admin account sau đó được dùng để sửa settings hoặc upload file. Nếu không có evidence nối các layer, finding nên giữ chúng thành các hypothesis riêng.

• Creation/modify timestamp có nằm cùng incident window không?
• Code của plugin/MU-plugin có gọi API tạo user hoặc role không?
• Admin account có activity sau thời điểm plugin xuất hiện không?
• Xóa một layer có làm layer khác tái xuất hiện không?
• Log/file/database evidence có cùng source account/process không?

Khi nào có thể xác nhận multi-layer persistence?

Không nên gọi multi-layer persistence chỉ vì site có một admin và một MU-plugin không quen. Confidence mạnh khi ownership không hợp lệ và các artifact có relation về code, timeline hoặc behavior.

• Admin account được xác nhận unauthorized.
• Plugin/MU-plugin không có legitimate owner hoặc package source.
• Code có behavior duy trì access hoặc tái tạo artifact khác.
• Timeline creation/modify khớp incident window.
• Disable/remove từng layer cho thấy dependency hoặc regeneration pattern.

Containment: cắt access mà không phá evidence

Trước khi xóa, nên preserve account metadata, session/log, plugin/MU-plugin files, hashes và relevant database records. Sau đó containment ưu tiên revoke privileged access và ngăn code persistence tiếp tục chạy.

• Disable/revoke unauthorized Admin account và active sessions.
• Quarantine plugin/MU-plugin đã xác nhận malicious.
• Block remote endpoint hoặc command channel nếu được xác định.
• Hạn chế write access vào plugin/MU-plugin path nếu architecture cho phép.
• Giữ copy evidence trước khi reinstall/replace component.

Eradication: xử lý toàn bộ persistence chain và entry point

Nếu chỉ xóa Admin nhưng MU-plugin vẫn có khả năng tạo lại user, incident chưa được eradicated. Nếu chỉ xóa MU-plugin nhưng credential bị lộ vẫn còn hiệu lực, attacker có thể quay lại bằng đường khác. Remediation phải xử lý đồng thời account, code persistence và root cause ban đầu.

Tham chiếu Persistence trong WordPress Malware, Root Cause Analysis sau Security Incident và case backdoor còn tồn tại sau cleanup.

Validation sau remediation

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

• Admin lạ, plugin lạ và MU-plugin lạ đều cần xác minh owner trước khi kết luận malware.
• MU-plugin là cơ chế hợp lệ của WordPress nhưng có đặc tính auto-load và khó bị disable từ UI.
• Multi-layer persistence chỉ được xác nhận khi timeline/behavior/code nối được các artifact với nhau.
• Xóa một artifact đơn lẻ có thể không đủ nếu persistence chain còn layer khác.
• Eradication phải xử lý account, code persistence và entry point cùng nhau.
• Monitoring sau remediation cần bao phủ cả account creation và plugin/MU-plugin changes.

Nguồn tham khảo

• WordPress — Must-Use Plugins
• WordPress Developer Resources — get_mu_plugins()
• WordPress — muplugins_loaded
• MITRE ATT&CK — Persistence tactic