Website bị hack hoặc tấn công: quy trình xử lý và khôi phục an toàn

Khi website xuất hiện redirect lạ, tài khoản quản trị không rõ nguồn gốc, nội dung bị chèn, cảnh báo mã độc hoặc dữ liệu bị thay đổi, mục tiêu đầu tiên không phải là “sửa cho trang chạy lại”. Doanh nghiệp cần giảm tác động, giữ bằng chứng, xác định phạm vi và ngăn kẻ tấn công duy trì quyền truy cập. Xóa file, cài thêm plugin hoặc restore vội có thể làm mất log, ghi đè dữ liệu mới và khiến sự cố tái diễn.

Tóm tắt: Hãy kích hoạt đầu mối xử lý sự cố; ghi timeline và phạm vi; bảo toàn log, file và bản sao hiện trạng; cô lập tài khoản hoặc dịch vụ bị ảnh hưởng; xác định cơ chế xâm nhập; làm sạch hoặc xây lại từ nguồn tin cậy; khôi phục dữ liệu theo điểm sạch đã xác minh; xoay vòng credential và secret; kiểm thử trước khi mở lại; sau đó theo dõi, báo cáo và sửa quy trình. Không chọn backup chỉ theo số ngày và không gửi yêu cầu Google review trước khi toàn bộ vấn đề được xử lý.

1. Phân loại: lỗi kỹ thuật, dấu hiệu xâm nhập hay tấn công đang diễn ra?

Một lỗi 500 sau cập nhật có thể là lỗi kỹ thuật; redirect chỉ xuất hiện với người dùng từ Google có thể là mã độc; request tăng đột biến có thể là bot hợp lệ, chiến dịch thành công hoặc DDoS. Cần phân loại bằng bằng chứng thay vì dựa vào một triệu chứng.

Tình huống	Dấu hiệu cần kiểm tra	Hướng xử lý đầu tiên
Lỗi kỹ thuật	Lỗi xuất hiện sau deploy/update, không có admin/file/redirect lạ, log chỉ ra lỗi ứng dụng	Dừng thay đổi, đọc log, kiểm thử và rollback có kiểm soát
Nghi ngờ bị xâm nhập	Admin lạ, file hoặc cron lạ, spam SEO, nội dung bị sửa, credential bị đổi	Kích hoạt xử lý sự cố, bảo toàn bằng chứng và cô lập
Tấn công đang diễn ra	Request bất thường, brute force, bot abuse, DDoS, form spam hoặc khai thác lặp lại	Phối hợp hosting/CDN/WAF, giảm bề mặt và bảo vệ dịch vụ quan trọng
Cảnh báo từ Google hoặc trình duyệt	Security Issues, phishing, harmful download hoặc interstitial cảnh báo	Xem báo cáo như nguồn điều tra, sửa toàn bộ vấn đề rồi mới request review

Nếu không có dấu hiệu xâm nhập và lỗi gắn rõ với thay đổi kỹ thuật, dùng quy trình chẩn đoán lỗi website. Nếu có một dấu hiệu nghiêm trọng liên quan tài khoản đặc quyền, mã độc, dữ liệu hoặc nội dung giả mạo, hãy xử lý như sự cố cho tới khi có đủ cơ sở loại trừ.

Dấu hiệu	Rủi ro cần xem xét	Bằng chứng cần giữ
Mất quyền admin hoặc xuất hiện user đặc quyền lạ	Chiếm tài khoản, persistence hoặc email quản trị bị xâm nhập	Audit log, email thông báo, session, user metadata và timeline
Redirect, popup hoặc nội dung lạ	Code/database bị chèn, DNS/proxy bị thay đổi hoặc script bên thứ ba	HTTP response, HTML, file, database, DNS và log thay đổi
File, cron hoặc scheduled task không rõ nguồn gốc	Backdoor, web shell hoặc cơ chế tái nhiễm	Bản sao file, hash, timestamp, owner và log thực thi
Đơn hàng, lead hoặc dữ liệu bị thay đổi	Ảnh hưởng tính toàn vẹn hoặc khả năng rò rỉ dữ liệu	Database snapshot, log ứng dụng, payment/CRM log và đối chiếu nghiệp vụ
Traffic hoặc tài nguyên tăng khác baseline	DDoS, bot abuse, khai thác endpoint hoặc tác vụ độc hại	Access log, WAF/CDN log, CPU/RAM/I/O và mã phản hồi
Security Issues trong Search Console	Hacked content, malware, phishing hoặc harmful behavior	Loại vấn đề, URL mẫu, ảnh chụp và thời điểm phát hiện

2. Hành động ban đầu: giảm tác động nhưng không phá bằng chứng

NIST SP 800-61 Rev. 3 xem ứng cứu sự cố là một phần của quản trị rủi ro liên tục, trong đó Detect, Respond và Recover phải phối hợp với vai trò, trách nhiệm và hoạt động cải tiến. Không có mốc “60 phút” áp dụng cho mọi tổ chức; hành động phải dựa trên mức độ, dữ liệu và khả năng phục hồi.

Nguồn tham khảo: NIST SP 800-61 Rev. 3.

1. Chỉ định đầu mối sự cố: một người điều phối quyết định, giao tiếp và ghi timeline; tránh nhiều người cùng thay đổi production.
2. Dùng kênh liên lạc tin cậy: nếu email hoặc tài khoản chính có thể bị chiếm, dùng kênh ngoài băng và thiết bị sạch để phối hợp.
3. Ghi hiện trạng: URL, thời điểm, múi giờ, tài khoản, mã lỗi, ảnh chụp, request ID, thay đổi gần nhất và người phát hiện.
4. Bảo toàn bằng chứng: sao chép log, file đáng ngờ, cấu hình, database và snapshot hiện trạng với quyền truy cập hạn chế. Bản này có thể nhiễm và không dùng trực tiếp để phục hồi.
5. Cô lập theo mức cần thiết: khóa tài khoản đáng ngờ, chặn endpoint, chuyển maintenance, giới hạn origin hoặc tạm dừng chức năng có thể gây hại. Tránh xóa mù.
6. Giảm tác động tới người dùng: tạm dừng quảng cáo hoặc form nếu có redirect, phishing, đánh cắp dữ liệu hay giao dịch sai; hiển thị thông báo trung thực khi phù hợp.
7. Phối hợp nhà cung cấp: yêu cầu hosting, CDN, WAF, registrar, email hoặc payment giữ log và hỗ trợ containment theo phạm vi họ quản lý.
8. Bảo vệ danh tính: từ thiết bị tin cậy, thu hồi session/token, khóa tài khoản lạ và xoay credential ưu tiên. Không chỉ đổi mật khẩu WordPress nếu hosting, email hoặc DNS cũng có thể bị ảnh hưởng.

Không restore trước khi hiểu dữ liệu nào sẽ bị ghi đè. Không bật debug hiển thị công khai. Không xóa file đáng ngờ trước khi lưu bản sao và metadata. Không thông báo “đã an toàn” khi mới chỉ đưa trang hoạt động trở lại.

3. Điều tra, làm sạch và chọn điểm khôi phục

Khôi phục an toàn cần trả lời ba câu hỏi: sự cố bắt đầu từ khi nào, kẻ tấn công đã có quyền gì và cơ chế duy trì truy cập nằm ở đâu. Chỉ xóa file được scanner báo hoặc cài lại plugin không đủ nếu email, API key, cron, database hoặc DNS vẫn bị chiếm.

Giai đoạn	Việc cần làm	Đầu ra
Xây timeline	Đối chiếu log đăng nhập, file, deploy, plugin, email, WAF/CDN, DNS và dữ liệu nghiệp vụ	Khoảng thời gian nghi ngờ và sự kiện then chốt
Xác định phạm vi	Website, subdomain, hosting, email, DNS, API, CRM, payment và tài khoản liên quan	Danh sách tài sản và dữ liệu có thể bị ảnh hưởng
Xác định vector	Credential, plugin/theme, custom code, file upload, cấu hình, bên thứ ba hoặc chuỗi cung ứng	Nguyên nhân đã xác minh hoặc giả thuyết có bằng chứng
Loại bỏ persistence	Rà admin, session, token, cron, web shell, rule, database injection và tài khoản dịch vụ	Danh sách hạng mục đã làm sạch hoặc xây lại
Chọn điểm sạch	So backup với timeline, hash, log và dữ liệu; restore vào môi trường tách biệt để kiểm tra	Điểm khôi phục được chấp nhận và dữ liệu cần hòa giải
Vá nguyên nhân	Cập nhật, thay thế, sửa code, giới hạn quyền, WAF/rate limit hoặc thay đổi kiến trúc	Kiểm soát gốc và biện pháp tạm thời

Không chọn backup theo công thức “1–7 ngày trước”

Thời điểm phát hiện không phải thời điểm xâm nhập. Một bản backup cũ hơn vẫn có thể chứa backdoor; một bản quá cũ có thể làm mất đơn hàng, lead hoặc tài khoản. Hãy chọn điểm sạch dựa trên timeline và kiểm tra restore, sau đó hòa giải dữ liệu phát sinh bằng nguồn đáng tin như hệ thống thanh toán, CRM, email hoặc log giao dịch.

Bài backup website, RPO/RTO và kiểm tra khôi phục trình bày cách quản lý các điểm phục hồi.

Ưu tiên xây lại thành phần từ nguồn tin cậy

• Cài lại core, plugin và theme từ nguồn có thể xác minh thay vì tin mọi file hiện có.
• Review custom code, file upload, mu-plugin, cấu hình server và database.
• Gỡ thành phần nulled, không còn hỗ trợ hoặc không xác định được nguồn.
• Thu hồi và tạo lại secret, API key, application password, salt và token sau khi persistence đã được loại bỏ.
• Tạo tài khoản riêng, áp dụng quyền tối thiểu và MFA cho tài khoản đặc quyền.
• Không đưa bản sao nhiễm hoặc secret cũ trở lại production.

4. Nghiệm thu trước khi mở lại và xử lý cảnh báo Google

Website “mở được” chưa đủ để kết thúc sự cố. Phải xác nhận mã độc hoặc persistence đã được loại bỏ, nguyên nhân đã được vá hoặc giảm thiểu, dữ liệu đã được đối chiếu và monitoring đang hoạt động.

• Kiểm tra trang chính, admin, form, email, login, upload, checkout, booking, API và cron.
• Đối chiếu user, role, session, token, database, media và dữ liệu giao dịch.
• Kiểm tra DNS, SSL, redirect, WAF/CDN, origin và cấu hình email.
• Rà status code, sitemap, robots, canonical, noindex và URL có traffic.
• Xác nhận backup mới, quyền restore và monitoring/log sau phục hồi.
• Thực hiện kiểm thử từ thiết bị hoặc tài khoản không dùng trong quá trình xử lý.
• Ghi rủi ro còn lại, người chấp nhận rủi ro và điều kiện rollback.

Google cho biết Security Issues report có thể liệt kê hacked content, phishing, malware hoặc hành vi gây hại; URL mẫu không nhất thiết là danh sách đầy đủ. Chỉ Request Review sau khi đã sửa tất cả vấn đề trên toàn bộ site và kiểm thử. Yêu cầu nên mô tả vấn đề, bước khắc phục và kết quả; thời gian review có thể từ vài ngày tới vài tuần tùy trường hợp.

Nguồn tham khảo: Google Search Console — Security issues report.

5. Khi nào cần đội chuyên môn và cách phòng tái diễn

Cần chuyển cấp sớm khi	Lý do
Không xác định được phạm vi hoặc thời điểm xâm nhập	Khó chọn bản sạch và dễ bỏ sót persistence
Email, DNS, hosting, repository hoặc nhiều tài khoản cùng bị ảnh hưởng	Sự cố vượt ngoài WordPress và có thể tiếp tục tái nhiễm
Có dữ liệu cá nhân, thanh toán hoặc dữ liệu nghiệp vụ bị truy cập/thay đổi	Cần điều tra, đối chiếu, pháp lý và truyền thông phù hợp
Log bị xóa, mã độc quay lại hoặc có nhiều web shell	Cần năng lực điều tra và rebuild sâu hơn
DDoS hoặc khai thác đang tiếp diễn	Cần phối hợp upstream, CDN/WAF và hosting
Không có backup sạch hoặc restore không thành công	Cần kế hoạch phục hồi và hòa giải dữ liệu riêng
Website là kênh doanh thu chính hoặc có yêu cầu SLA cao	Quyết định containment và recovery có tác động kinh doanh lớn

Nếu nghi có vi phạm dữ liệu hoặc nghĩa vụ thông báo, cần tham vấn người phụ trách pháp lý và bảo vệ dữ liệu theo quy định áp dụng; không công bố nguyên nhân hoặc phạm vi khi chưa có bằng chứng đủ.

Theo dõi sau sự cố theo rủi ro, không theo lịch 30 ngày cố định

• Theo dõi tài khoản, session, file, cron, outbound connection và traffic khác baseline.
• Rà bản vá, thành phần không dùng, quyền tạm và secret đã xoay vòng.
• Kiểm tra backup mới và diễn tập restore theo RPO/RTO.
• Kiểm tra form, giao dịch, API, tracking và dữ liệu cần xử lý lại.
• Cập nhật WAF/rate limit và alert dựa trên hành vi đã quan sát.
• Hoàn thiện báo cáo: timeline, phạm vi, nguyên nhân, tác động, quyết định và bài học.
• Cập nhật kiểm soát bảo mật trong gói bảo trì để ngăn tái diễn.

Để biến bài học sau sự cố thành hardening dài hạn, ưu tiên MFA cho tài khoản đặc quyền, chạy lại checklist bảo mật website có cổng web công và dùng quy trình triển khai bảo mật hệ thống A–Z để đưa tài khoản, WAF, backup, log, monitoring và incident response vào operating model thay vì chỉ khắc phục từng sự cố.

Kết luận: Ứng cứu website bị hack là quá trình quản lý rủi ro, không phải thao tác xóa mã độc. Cần giữ bằng chứng, giành lại quyền kiểm soát, xác định phạm vi, khôi phục từ nguồn đã xác minh, vá nguyên nhân và theo dõi bằng dữ liệu. Website hoạt động lại chỉ là một mốc trong quá trình phục hồi.