Sau khi xử lý malware, việc bàn giao website không nên chỉ dừng ở thông báo “đã sạch”. Một checklist bàn giao sau xử lý malware cần biến kết quả incident response thành baseline vận hành mới: trạng thái verification, thay đổi đã thực hiện, credential, backup, hardening, monitoring, owner và rollback. Mục tiêu là để đội vận hành biết rõ điều gì đã được xác minh, điều gì còn mở và ai chịu trách nhiệm theo dõi sau recovery. Một case end-to-end để đối chiếu các gate này là Cleanup, Restore, Verification và Bàn giao Website sau Malware. Với recovery ở phạm vi incident rộng hơn, xem thêm case khôi phục Website sau Security Incident mà không tái nhiễm.
Checklist bàn giao tổng hợp
| Hạng mục | Trạng thái | Evidence | Owner | Due date | Rollback / fallback |
|---|---|---|---|---|---|
| Scope & remediation summary | ☐ OPEN ☐ PASS ☐ N/A | Timeline, finding, change log | Incident owner | … | Khôi phục snapshot/change đã ghi |
| Verification sau cleanup | ☐ OPEN ☐ PASS ☐ FAIL | IOC, integrity, account, persistence, frontend | Technical reviewer | … | Re-open incident nếu FAIL |
| Credential review/rotation | ☐ OPEN ☐ PASS ☐ N/A | Account list, rotation record | System owner | … | Không lưu secret trong biên bản |
| Backup & restore test | ☐ OPEN ☐ PASS ☐ FAIL | Backup ID, restore test result | Operations | … | Giữ restore point trước thay đổi |
| Hardening theo root cause | ☐ OPEN ☐ PASS ☐ N/A | Patch/config/plugin change | Platform owner | … | Rollback từng change có kiểm soát |
| Monitoring & alerting | ☐ OPEN ☐ PASS ☐ FAIL | Alert rule, recipient, escalation path | Operations/SOC | … | Manual check nếu automation lỗi |
| Persistence review | ☐ OPEN ☐ PASS ☐ N/A | Cron, plugin, MU-plugin, account inventory | Technical reviewer | … | Re-open investigation khi IOC tái xuất hiện |
1. Phạm vi sự cố và remediation phải được ghi rõ
- Triệu chứng ban đầu và incident window.
- Phạm vi đã kiểm tra: file, database, account, cron, plugin/MU-plugin, frontend, log.
- Finding nào đã xác minh và finding nào chỉ là hypothesis.
- Thành phần đã thay thế, xóa, cấu hình lại hoặc giữ nguyên.
- Entry point/root cause đã xác minh hay vẫn còn mở.
Không biến một giả thuyết chưa có evidence thành kết luận chắc chắn. Nếu root cause chưa xác minh, trạng thái bàn giao phải ghi rõ là OPEN hoặc PARTIAL.
2. Verification phải có PASS/FAIL theo từng lớp
Không dùng một câu “scanner sạch” làm kết luận duy nhất. Verification nên bám các Indicators of Compromise ban đầu, integrity, account, persistence và frontend khi phù hợp. Dùng workflow xác minh WordPress sạch malware sau cleanup để ghi PASS/FAIL theo evidence.
| Layer | PASS khi | FAIL khi |
|---|---|---|
| Filesystem | Khớp baseline hoặc khác biệt có owner | File suspect còn hoặc quay lại |
| Accounts | Không còn user/quyền trái phép | Admin lạ hoặc quyền trái phép tái xuất hiện |
| Persistence | Cron/plugin/MU-plugin/account có owner hợp lệ | Cơ chế tái tạo chưa giải thích |
| Frontend | Không còn redirect/spam/injected behavior | IOC vẫn tái hiện |
3. Credential: ghi trạng thái, không ghi secret
- Xác minh account trái phép đã được xử lý.
- Ghi phạm vi credential đã rotate: WordPress, hosting, database, deployment, API key nếu thuộc incident scope.
- Ghi thời điểm rotate và owner chịu trách nhiệm.
- Không chép password, salt, token hoặc secret thật vào biên bản bàn giao thông thường.
4. Backup phải có khả năng phục hồi
Mỗi backup nên có phạm vi, lịch chạy, retention và kết quả restore test. Một backup chỉ “tồn tại” nhưng chưa từng được kiểm tra restore không nên được coi là control đã hoàn chỉnh. Nếu backup, log hoặc file tạm còn nằm ở public path, đối chiếu cách bảo vệ file backup, log và file tạm khỏi truy cập công khai.
| Check | Owner | Evidence | Status |
|---|---|---|---|
| Backup file + database đầy đủ | Operations | Backup ID/location | ☐ PASS ☐ FAIL |
| Retention phù hợp | Operations | Policy/config | ☐ PASS ☐ FAIL |
| Restore test thành công | Technical owner | Restore log/screenshot | ☐ PASS ☐ FAIL |
5. Hardening phải gắn với root cause và rollback
Ưu tiên cập nhật thành phần, loại bỏ plugin/theme không dùng, giảm quyền không cần thiết và sửa cấu hình liên quan đến incident. Mỗi thay đổi cần có mục tiêu, owner, evidence và rollback. Trước khi áp dụng thay đổi hardening trên production, dùng Website Hardening Checklist trước khi triển khai; sau bàn giao, đưa các control vào checklist duy trì Website Hardening định kỳ. WordPress cung cấp hướng dẫn hardening chính thức tại Hardening WordPress.
6. Monitoring phải có người nhận và cách escalation
| Tín hiệu | Owner | Ngưỡng/điều kiện | Escalation |
|---|---|---|---|
| File change quan trọng | Operations | Ngoài maintenance/deploy window | Technical review |
| Admin/user mới | Site owner | Không có change record | Incident triage |
| Redirect/spam tái xuất hiện | Operations | Bất kỳ IOC cũ quay lại | Re-open incident |
| Cron/MU-plugin bất thường | Technical owner | Không owner hoặc khác baseline | Persistence review |
Nếu malware quay lại, dùng workflow tìm root cause khi malware tái xuất hiện thay vì chỉ xóa payload lần nữa.
7. Persistence review phải nêu rõ đã kiểm tra gì
Nếu incident liên quan cron, plugin, MU-plugin, backdoor hoặc account, biên bản phải ghi rõ layer đã kiểm tra và evidence tương ứng. Không tuyên bố “không còn persistence” nếu scope kỹ thuật chưa đủ để xác minh. Có thể đối chiếu thêm Persistence trong WordPress Malware.
8. Change log và rollback record
| Change | Before | After | Owner | Rollback | Verified |
|---|---|---|---|---|---|
| File/plugin/config/account | Version/hash/state cũ | Version/hash/state mới | … | Snapshot/clean source | ☐ YES ☐ NO |
Với thay đổi có khả năng ảnh hưởng vận hành, rollback phải khả thi trước khi đóng ticket bàn giao.
9. RACI tối thiểu sau recovery
| Task | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Review alert | Operations | Site owner | Security/Dev | Stakeholder |
| Apply security update | Dev/Platform | Technical owner | Security | Site owner |
| Re-open incident | Incident responder | Incident owner | Platform/Hosting | Stakeholder |
RACI là khung phân trách nhiệm; tên thật của owner chỉ nên điền khi đã được tổ chức xác nhận.
10. Glossary Việt–Anh dùng trong bàn giao
| Thuật ngữ | Giải thích ngắn |
|---|---|
| Payload | Phần mã hoặc hành vi gây tác động trực tiếp như redirect, spam, injected code. |
| Persistence | Cơ chế giúp quyền truy cập hoặc payload tồn tại/tái xuất hiện. |
| Entry point | Con đường hoặc điều kiện ban đầu dẫn tới compromise. |
| Baseline | Trạng thái tin cậy dùng để so sánh file, config, account hoặc behavior. |
| IOC — Indicator of Compromise | Dấu hiệu có thể liên quan compromise và cần được xác minh bằng context/evidence. |
| Containment | Giảm impact hoặc phạm vi sự cố trong khi vẫn bảo toàn khả năng điều tra. |
| Remediation | Thay đổi nhằm loại bỏ finding đã xác minh và xử lý nguyên nhân liên quan. |
| Verification | Kiểm tra sau remediation để xác nhận trạng thái PASS/FAIL. |
| Rollback | Khôi phục về state trước thay đổi khi remediation gây lỗi hoặc không đạt validation. |
11. Điều kiện đóng bàn giao
- Không còn hạng mục critical ở trạng thái FAIL mà không có owner/plan.
- Verification có evidence và phạm vi rõ.
- Backup/restore path đã được xác nhận phù hợp.
- Monitoring có owner và escalation path.
- Change log + rollback được ghi lại.
- Risk còn lại được nêu rõ, không dùng cam kết “không bao giờ bị hack lại”.
Nếu incident từng kích hoạt cảnh báo từ Google/Search Console, xác minh trạng thái theo quy trình xử lý cảnh báo website bị hack hoặc chứa nội dung độc hại trước khi đóng bàn giao. Khi đóng bàn giao, nên lưu outcome, residual risk và action còn mở trong Security Incident Report để giữ traceability giữa incident, recovery và vận hành sau sự cố.
Nguồn kỹ thuật tham khảo
Kết luận
Checklist bàn giao sau xử lý malware nên là một artifact vận hành có thể dùng thật, không chỉ là chuỗi đoạn mô tả. Mỗi hạng mục cần status, evidence, owner, due date và rollback; glossary giúp đội kỹ thuật và chủ website hiểu cùng một ngôn ngữ, còn RACI và monitoring giúp recovery tiếp tục được duy trì sau khi incident chính đã đóng.
Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem dịch vụ Malware Removal.