Malware tái xuất hiện sau cleanup cho thấy remediation trước có thể bỏ sót persistence, entry point, credential bị lộ hoặc nguồn tái nhiễm khác. Khi đó không nên tiếp tục xóa cùng payload; cần dựng timeline, tạo hypothesis và kiểm chứng bằng evidence.
Phân biệt recurrence với cleanup chưa hoàn tất
| Tình huống | Khả năng | Hướng điều tra |
|---|---|---|
| Payload chưa từng biến mất hoàn toàn | Cleanup chưa đầy đủ | Quay lại scope/persistence trước khi gọi là reinfection |
| Đã verify sạch rồi payload xuất hiện mới | Entry point/persistence/credential còn mở hoặc compromise mới | Dựng timeline từ thời điểm verify sạch đến recurrence |
| Cùng file/hash/path quay lại theo chu kỳ | Cơ chế tái tạo có tính lặp | Đối chiếu cron, process, request và account trước thời điểm xuất hiện |
Timeline worksheet
| Thời điểm | Event | Evidence | Layer | Ghi chú |
|---|---|---|---|---|
| T0 | Cleanup/removal | Hash/path/remediation log | Filesystem | Payload nào đã xử lý? |
| T1 | Credential rotation/update/deploy | Change record | Account/config | Phạm vi đã đủ chưa? |
| T2 | Request/job/login đáng chú ý | Access/auth/cron log | Network/account/cron | Có xảy ra trước recurrence? |
| T3 | Payload tái xuất hiện | Hash/path/URL/screenshot | File/DB/frontend | Giống hay khác lần trước? |
Hypothesis/evidence table
| Hypothesis | Evidence ủng hộ | Evidence phản bác | Test an toàn | State |
|---|---|---|---|---|
| Cron tái tạo payload | Hook chạy ngay trước T3 | Không có correlation | Inventory callback/owner; không chạy payload | OPEN/CONFIRM/REJECT |
| Credential bị lộ | Login/action sau rotation chưa đủ phạm vi | Không có auth activity | Đối chiếu auth log và owner | … |
| Backdoor còn tồn tại | File/request liên quan xuất hiện trước T3 | Integrity sạch, không behavior | Static review/diff/log correlation | … |
Đọc access log theo timeline, không theo một IP đơn lẻ
Ưu tiên endpoint, timestamp, method, status và chuỗi request quanh lúc payload quay lại; IP/user-agent chỉ là một phần context và có thể bị proxy/CDN làm thay đổi. Dùng workflow đọc access log khi WordPress bị hack để correlation request với file/account change.
Kiểm tra persistence và entry point
Rà soát file, plugin/MU-plugin, cron, account, database và credential theo evidence. Persistence trả lời “cái gì khiến payload/quyền quay lại”; entry point trả lời “bên xâm nhập vào bằng cách nào”. Hai câu hỏi này không nên gộp thành một.
So sánh payload giữa các lần xuất hiện
- Hash và nội dung có giống nhau không?
- Path/URL có giữ nguyên không?
- Timestamp có đi theo chu kỳ job hoặc request cụ thể không?
- Owner/process nào xuất hiện ngay trước mỗi lần tái tạo?
Sự giống nhau là evidence cho correlation, không tự chứng minh cùng attacker hay cùng entry point.
Scope boundary: khi nào không còn là một site đơn lẻ?
Nếu recurrence xuất hiện trên nhiều website, dùng chung credential/infrastructure, liên quan privileged account hoặc activity đang tiếp diễn, cần mở rộng scope và cân nhắc Incident Response. Không nên tiếp tục xử lý từng payload riêng lẻ.
Verification sau remediation tiếp theo
Recurrence chỉ được coi là xử lý khi hypothesis đã được kiểm chứng, mechanism/root cause đã có mitigation và IOC không quay lại trong observation window phù hợp với risk. Dùng PASS/FAIL verification sau cleanup.
Nguồn kỹ thuật tham khảo
Kết luận
Khi malware quay lại, câu hỏi cần trả lời là “event nào tái tạo nó?” và “entry point nào vẫn mở?”. Timeline + hypothesis/evidence + log correlation giúp chuyển từ xóa triệu chứng sang root-cause remediation có thể kiểm chứng.