Phát hiện website bị hack luôn gây căng thẳng, nhất là khi khách hàng thấy cảnh báo, redirect lạ hoặc trang bị lỗi. Nhưng vài hành động đầu tiên rất quan trọng.
Mục tiêu là khoanh vùng thiệt hại, giữ đủ thông tin để hiểu điều gì đã xảy ra, và đưa website trở lại trạng thái sạch.
Đừng xem giờ đầu tiên là cuộc đua làm cho homepage nhìn bình thường lại. Cleanup vội có thể xóa mất bằng chứng hữu ích, restore nhầm file đã nhiễm hoặc để nguyên entry point ban đầu.
1. Đừng vội khôi phục backup mới nhất
Khôi phục backup có thể hữu ích, nhưng cũng có thể đưa mã độc quay lại nếu backup được tạo sau thời điểm bị tấn công.
Trước khi khôi phục, hãy xác định thời điểm sự cố có khả năng bắt đầu. Kiểm tra ngày sửa file, đăng nhập admin bất thường, cảnh báo hosting, Search Console và phản ánh từ khách hàng.
Nếu có nhiều bản backup, hãy so sánh chúng. Backup hôm qua có thể đã chứa backdoor, trong khi backup cũ hơn có thể sạch nhưng thiếu order, form submission hoặc content update gần đây. Restore point đúng phải cân bằng cả security lẫn business data.
2. Đưa website về trạng thái có kiểm soát
Nếu website đang redirect người truy cập, phát mã độc hoặc rò rỉ dữ liệu, hãy tạm thời hạn chế truy cập công khai trong khi xử lý. Việc này bảo vệ khách truy cập và giảm thiệt hại uy tín.
Với website ecommerce hoặc thành viên, cần cẩn thận với chế độ bảo trì để không làm mất đơn hàng, form submit hoặc dữ liệu khách hàng.
Nếu site đang gây hại cho người truy cập, containment phải đi trước. Điều đó có thể là chặn public access, disable plugin bị compromise, tạm dừng checkout hoặc đưa một static holding page sạch lên live trong lúc điều tra site thật.
Nếu incident có thể liên quan customer data, payment data hoặc thông tin có yêu cầu compliance, hãy ghi lại timeline và đưa đúng người phụ trách pháp lý hoặc compliance vào trước khi xóa log.
3. Đổi thông tin truy cập
Hãy đổi mật khẩu hosting, tài khoản quản trị CMS, FTP/SFTP, SSH, database, email liên quan đến website và các dịch vụ triển khai.
Nếu có thể, bật xác thực nhiều lớp. Xóa ngay các tài khoản quản trị không quen thuộc.
Credential rotation nên thực hiện từ thiết bị sạch và network đáng tin. Nếu attacker vẫn có quyền vào email, hosting hoặc password manager, chỉ đổi mật khẩu CMS có thể không đủ.
Cũng cần revoke API key cũ, deployment token, application password, OAuth app và SSH key không dùng. Nhiều lần reinfection xảy ra vì một đường truy cập ít rõ ràng vẫn mở.
4. Làm sạch file và database
Mã độc có thể ẩn trong theme, plugin, thư mục uploads, cron job, database, mu-plugin, cache và file cấu hình server.
Một lần làm sạch đúng nghĩa cần kiểm tra tất cả các vị trí này. Chỉ xóa phần bị phá giao diện thường sẽ để lại backdoor.
Hãy tìm file mới sửa gần đây, file PHP lạ trong upload folder, encoded payload, cron task không rõ, JavaScript bị inject, hidden admin user và option đáng nghi trong database.
Với WordPress, cần chú ý wp-content/uploads, mu-plugins, theme file, plugin folder, wp-config.php, .htaccess, scheduled action và administrator account bất thường.
5. Vá nguyên nhân xâm nhập
Website đã sạch vẫn có thể bị nhiễm lại nếu điểm yếu ban đầu còn đó. Nguyên nhân phổ biến gồm plugin lỗi thời, mật khẩu yếu, admin panel bị lộ, theme/plugin nulled, form handler có lỗ hổng và phân quyền file sai.
Khôi phục nên luôn đi kèm phân tích nguyên nhân và gia cố bảo mật.
Root cause không phải lúc nào cũng là một câu trả lời hoàn hảo, nhưng đội recovery nên giải thích được đường vào có khả năng cao nhất: plugin vulnerable, credential yếu, panel bị lộ, file permission sai, theme bỏ quên, hosting account bị compromise hoặc custom code không an toàn.
Sau khi đóng đường vào có khả năng cao, hãy update software, xóa component không dùng, siết permission, bật MFA, review admin user và xác nhận backup đang chạy.
6. Yêu cầu review sau khi đã sạch
Nếu trình duyệt, Google, nhà cung cấp bảo mật hoặc hosting đã gắn cờ website, hãy gửi yêu cầu review sau khi chắc chắn website đã sạch. Gửi quá sớm có thể làm quá trình gỡ cảnh báo chậm hơn.
Trước khi request review, hãy scan lại site, kiểm tra thủ công các page quan trọng, clear cache layer bị nhiễm và xác nhận redirect đã biến mất trên cả desktop lẫn mobile user agent. Search engine và security vendor có thể cache kết quả cũ, nhưng họ kỳ vọng live site sạch khi re-check.
7. Monitor kỹ sau khi website quay lại
Website đã recover nên được theo dõi kỹ hơn trong một thời gian. Reinfection có thể xảy ra nếu còn hidden backdoor, stolen credential hoặc scheduled task bị bỏ sót.
Trong vài tuần đầu, hãy monitor file change, admin login, malware scan, Search Console warning, uptime và form behavior. Giữ maintenance log cập nhật để so sánh activity đáng nghi với các fix hợp lệ.
Nên chuẩn bị gì trước incident?
Response tốt nhất bắt đầu trước khi bị hack. Hãy giữ danh sách access cho hosting, DNS, CMS, registrar, email, analytics và deployment. Biết backup nằm ở đâu. Biết ai có quyền duyệt maintenance mode. Biết ai sẽ giao tiếp với khách hàng nếu cảnh báo xuất hiện.
Sự chuẩn bị đó biến emergency từ đoán mò thành checklist. Nó cũng giúp đội recovery hỗ trợ nhanh hơn nhiều.
Khôi phục không chỉ là mở lại website
Đích đến thực sự không phải là “trang chủ tải được lại”. Đích đến là website sạch, điểm yếu đã được vá, backup đã xác minh, và giám sát có thể phát hiện dấu hiệu bất thường sớm.
Nếu website đang bị compromise, dịch vụ website recovery của ViWeb có thể hỗ trợ làm sạch, đóng các entry point rõ ràng và thiết lập monitoring để giảm khả năng lặp lại.