Chỉ nên mở lại website sau khi xử lý malware/hack khi đã xác minh phạm vi làm sạch, kiểm soát đường xâm nhập, tài khoản, khóa truy cập và chức năng quan trọng, đồng thời phân công người theo dõi. Trang chủ tải được hoặc máy quét báo “clean” chưa đủ. Nếu vẫn còn backdoor, tài khoản lạ hoặc khóa truy cập bị lộ chưa kiểm soát, hãy chọn NO-GO: chưa mở lại.
Một website có thể hoạt động bình thường nhưng vẫn còn tài khoản lạ, backdoor, cron độc hại, mã chèn trong database, API key bị lộ hoặc đường xâm nhập cũ chưa được đóng. Checklist này giúp kiểm tra từng lớp trước khi quyết định mở lại website.
Phạm vi bài này: dùng sau khi bước containment và cleanup đã được thực hiện. Nếu website vẫn đang bị tấn công hoặc chưa làm sạch, bắt đầu từ quy trình xử lý website bị hack.
Khi nào có thể coi website đã “đủ sạch” để vận hành lại?
Không có một dấu hiệu đơn lẻ nào chứng minh website đã an toàn. Scanner báo “clean” là tín hiệu tốt, nhưng vẫn cần kiểm tra file, tài khoản, database, cron, credential, DNS, chức năng website và log sau phục hồi.
Cách dễ hiểu nhất là trả lời 3 câu hỏi: mã độc đã được loại bỏ chưa, đường xâm nhập đã được đóng chưa và website có hoạt động bình thường sau khi xử lý không?
Checklist 10 bước trước khi mở lại website
1. Xác nhận những gì đã được kiểm tra
- Biết file, database, user, plugin, theme và hosting nào đã được rà.
- Có danh sách những thay đổi đã thực hiện trong quá trình cleanup.
- Biết phần nào chưa được kiểm tra hoặc còn nghi ngờ.
“Đã xóa file malware” không đồng nghĩa “đã kiểm tra toàn bộ website”. Phải biết rõ phạm vi đã làm sạch.
2. Kiểm tra còn backdoor hoặc file bất thường không
So sánh WordPress core, plugin và theme với nguồn tin cậy khi có thể. Rà file mới hoặc bị sửa bất thường, mu-plugin, file PHP trong uploads và các vị trí thường bị lợi dụng để duy trì truy cập.
Xem thêm cách phát hiện backdoor WordPress.
3. Kiểm tra tài khoản và quyền truy cập
- Không còn admin hoặc user không rõ nguồn gốc.
- Tài khoản hợp lệ chỉ giữ đúng quyền cần thiết.
- Rà cả WordPress, hosting, SFTP/SSH, database, CDN/DNS và dịch vụ tích hợp quan trọng.
4. Đổi những mật khẩu, API key và token có nguy cơ đã lộ
Nếu kẻ tấn công có thể đã truy cập credential trong thời gian website bị compromise, cần đổi hoặc thu hồi các khóa liên quan: mật khẩu admin, hosting, database, API key, token và webhook secret.
Trước khi thay khóa, xác định plugin, tác vụ tự động và dịch vụ đang dùng khóa đó; sau khi đổi phải thử lại chức năng phụ thuộc. Trong biên bản chỉ ghi người thực hiện, thời gian và kết quả, không lưu mật khẩu hay giá trị API key.
5. Kiểm tra database và nội dung bị chèn
Malware không chỉ nằm trong file. Cần rà user, option, nội dung chèn, JavaScript lạ, redirect, SEO spam và các thay đổi bất thường trong database.
6. Kiểm tra cron, scheduled task và automation
Một cron job hoặc webhook độc hại có thể tạo lại file, user hoặc redirect sau khi bạn vừa xóa chúng. Vì vậy cần rà WordPress cron, cron của hosting và các job tự động quan trọng.
7. Đóng đường xâm nhập đã biết
Nếu đã xác định plugin, credential hoặc cấu hình là nguyên nhân, phải xử lý đường đó trước khi mở lại: cập nhật, vô hiệu hóa, đổi credential, thu hồi quyền hoặc áp dụng biện pháp giảm thiểu phù hợp.
Nếu chưa xác định chắc nguyên nhân, không nên tuyên bố website đã an toàn hoàn toàn. Hãy ghi rõ phần còn chưa chắc chắn và tăng monitoring sau khi khôi phục.
8. Kiểm tra website có hoạt động đúng không
- Trang chủ và các trang quan trọng mở bình thường.
- Form, login, checkout hoặc chức năng chính hoạt động đúng.
- Không còn redirect ngoài ý muốn.
- Canonical, robots/noindex và nội dung SEO quan trọng không bị thay đổi lạ.
- Không còn script hoặc link lạ trong HTML render của các trang mẫu.
9. Theo dõi log và cảnh báo sau phục hồi
Sau khi mở lại, tiếp tục theo dõi login, file change, WAF/CDN, malware alert và những tín hiệu đã xuất hiện trong sự cố. Nếu dấu hiệu cũ quay lại, cần cô lập và điều tra tiếp thay vì coi cleanup đã hoàn tất.
Xem Website Security Monitoring.
10. Chốt quyết định mở lại hay chưa
Người phụ trách kỹ thuật tổng hợp bằng chứng; chủ website hoặc người được ủy quyền quyết định có mở lại hay không. Ghi thời điểm, những phần chưa kiểm tra, rủi ro tồn dư, người theo dõi và điều kiện cần cô lập lại. Đây là quyết định theo phạm vi đã xác minh, không phải chứng nhận website an toàn tuyệt đối.
Mẫu biên bản nghiệm thu 10 bước sau khi xử lý malware
Chủ doanh nghiệp có thể sao chép bảng này khi nghiệm thu với đội kỹ thuật. Ở mỗi hạng mục, đánh dấu Đạt / Chưa đạt / Chưa kiểm tra, lưu bằng chứng và tên người xác minh. Không mặc định “Chưa kiểm tra” là đã an toàn; nếu một hạng mục quan trọng còn nguy cơ xâm nhập, chưa nên mở lại website.
| Hạng mục | Bằng chứng cần lưu | Trạng thái |
|---|---|---|
| 1. Phạm vi làm sạch | Danh sách phần đã rà và phần còn chưa kiểm tra | Đạt / Chưa đạt / Chưa kiểm tra |
| 2. File và backdoor | Kết quả quét, đối chiếu file WordPress/plugin/theme và file lạ | Đạt / Chưa đạt / Chưa kiểm tra |
| 3. Tài khoản và quyền | Danh sách admin/hosting/SSH, quyền bất thường đã xử lý | Đạt / Chưa đạt / Chưa kiểm tra |
| 4. Mật khẩu và API key | Nhật ký đổi/thu hồi khóa, xác nhận tích hợp hoạt động; không ghi secret | Đạt / Chưa đạt / Chưa kiểm tra |
| 5. Database và nội dung | Kết quả kiểm tra script, chuyển hướng và trang spam | Đạt / Chưa đạt / Chưa kiểm tra |
| 6. Cron và tác vụ nền | Danh sách job, webhook và tác vụ đáng ngờ đã xử lý | Đạt / Chưa đạt / Chưa kiểm tra |
| 7. Đường xâm nhập | Bản vá, thu hồi quyền hoặc biện pháp giảm thiểu đã xác minh | Đạt / Chưa đạt / Chưa kiểm tra |
| 8. Chức năng và SEO | Kết quả thử login, form, checkout, redirect, robots và canonical | Đạt / Chưa đạt / Chưa kiểm tra |
| 9. Giám sát phục hồi | Người trực, cảnh báo, log và phương án cô lập nếu tái nhiễm | Đạt / Chưa đạt / Chưa kiểm tra |
| 10. Quyết định | Người kiểm tra, người phê duyệt, thời điểm, rủi ro còn lại | GO / GO có điều kiện / NO-GO |
Biên bản cần có: URL và môi trường kiểm tra, thời gian, người phụ trách kỹ thuật, người phê duyệt, điểm chưa đạt, thời hạn xử lý và cách liên hệ khi xuất hiện dấu hiệu tái nhiễm. Không đưa mật khẩu, token hoặc dữ liệu nhạy cảm vào bản chia sẻ.
Bảng quyết định nhanh
| Trạng thái | Khi nào áp dụng? |
|---|---|
| GO | Những kiểm tra chính đạt, đường xâm nhập đã biết được xử lý hoặc giảm thiểu có xác minh, tài khoản/khóa đã kiểm soát, các chức năng quan trọng hoạt động và có người theo dõi. |
| GO có điều kiện | Chỉ còn vấn đề không gây rủi ro xâm nhập đang hoạt động; có biện pháp kiểm soát tạm thời được xác minh, người phê duyệt chấp nhận rủi ro, thời hạn xử lý và điều kiện quay về NO-GO. |
| NO-GO | Còn backdoor, admin lạ, mã độc/redirect đang hoạt động, khóa truy cập quan trọng chưa kiểm soát, đường xâm nhập vẫn mở hoặc phạm vi cleanup chưa rõ. |
Ví dụ giả định: trang chủ đã mở lại nhưng vẫn chưa nên GO
Website đã tải bình thường và scanner không còn báo malware, nhưng vẫn phát hiện một tài khoản admin không rõ nguồn gốc và chưa đổi API key từng nằm trong file cấu hình bị truy cập. Trường hợp này vẫn nên coi là NO-GO vì quyền truy cập trái phép và credential có nguy cơ chưa được xử lý.
Kiểm tra Google Search Console sau sự cố malware
Nếu Google từng cảnh báo website có malware hoặc nội dung bị hack, vào Google Search Console → Vấn đề bảo mật (Security Issues) để xem loại cảnh báo và URL mẫu. Sau khi làm sạch, hãy đối chiếu các URL, redirect, tài nguyên chèn và kết quả kiểm tra trước khi yêu cầu Google xem xét lại (Request review). Chỉ gửi yêu cầu sau khi đã khắc phục; yêu cầu này không thay thế việc xác minh bảo mật và không bảo đảm cảnh báo được gỡ ngay. Nếu không có cảnh báo, vẫn nên rà URL lạ và trang spam có thể đã được Google phát hiện.
Hướng dẫn chính thức: Google Search Central – Malware và Security Issues.
Sau khi website hoạt động lại
Sự cố chưa kết thúc ngay khi traffic được mở lại. Cần tiếp tục monitoring, hoàn thành việc đổi credential, xử lý các điểm yếu còn lại và cập nhật quy trình để giảm nguy cơ tái diễn.
Nếu cần đưa việc này thành quy trình vận hành lặp lại, xem Website Security Operations.
Nếu website vẫn còn dấu hiệu malware, backdoor hoặc redirect, xem website nhiễm malware/backdoor và chỉ quay lại checklist này sau khi cleanup đã được thực hiện.
Cần hỗ trợ kiểm tra, làm sạch hoặc nghiệm thu sau sự cố? Xem dịch vụ xử lý website bị hack và gửi URL, thời điểm phát hiện, biểu hiện lỗi, phạm vi đã sửa và tình trạng bản sao lưu. Không gửi mật khẩu hoặc API key qua biểu mẫu công khai.
Nguồn tham khảo và cách kiểm chứng
- WordPress.org – FAQ My site was hacked: tài khoản, phần mềm, truy cập và xử lý sau xâm nhập.
- NIST SP 800-61 Rev.3 (2025): khung quản trị ứng phó và phục hồi sự cố; mẫu GO/NO-GO ở đây không phải biểu mẫu chính thức của NIST.
- Google Search Central – Malware: Security Issues và điều kiện yêu cầu xem xét lại.
Để xác minh, đối chiếu bảng kiểm với log, file, tài khoản, lịch sử thay đổi và kết quả thử các chức năng thực tế. Không có checklist chung nào bảo đảm website an toàn tuyệt đối.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.