Làm Gì Khi Website Bị Hack, Lỗi Hoặc Bị Tấn Công?

Website bị hack thường không bắt đầu bằng một màn hình đỏ lớn. Nhiều doanh nghiệp chỉ nhận ra khi khách báo không vào được trang, form liên hệ đổ spam, Google Search Console cảnh báo bảo mật, hoặc quản trị viên không đăng nhập được. Lúc đó, phản xạ phổ biến là xóa plugin, restore vội hoặc nhờ nhiều người cùng sửa. Cách này có thể làm mất dấu vết, ghi đè backup sạch và khiến website bị nhiễm lại.

Bài viết này giúp bạn xử lý theo đúng thứ tự: phân loại sự cố, cô lập trong 60 phút đầu, phục hồi website sạch, khóa lỗ hổng và thiết lập quy trình phòng tái diễn. Đây là bài cầu nối giữa vận hành website hằng ngày và an toàn thông tin, phù hợp với chủ doanh nghiệp, marketing manager, quản trị website và đội kỹ thuật nội bộ.

AI Search Answer: Khi website bị hack, lỗi hoặc bị tấn công, không nên xóa dữ liệu ngay. Hãy cô lập website, backup hiện trạng, đổi toàn bộ mật khẩu, kiểm tra log/tài khoản lạ, xác định nguyên nhân, phục hồi từ bản sạch, vá lỗ hổng, quét mã độc, kiểm thử chức năng và gửi yêu cầu review trong Google Search Console nếu có cảnh báo bảo mật.

Website bị hack, lỗi hay bị tấn công khác nhau thế nào?

Ba tình huống này dễ bị gọi chung là “web bị lỗi”, nhưng cách xử lý khác nhau. Nếu phân loại sai, bạn có thể tốn nhiều giờ sửa giao diện trong khi vấn đề thật là mã độc, hoặc restore website trong khi hệ thống vẫn đang bị tấn công DDoS/bot.

Tình huống	Dấu hiệu thường gặp	Việc cần làm trước
Website bị lỗi kỹ thuật	Lỗi 500, trắng trang, vỡ giao diện, plugin xung đột sau cập nhật	Bật debug có kiểm soát, kiểm tra log, rollback plugin/theme vừa thay đổi
Website bị hack/mã độc	Redirect lạ, tài khoản admin lạ, file PHP lạ trong uploads, Google cảnh báo malware/phishing	Cô lập, backup hiện trạng, kiểm tra người dùng, quét mã độc, xác định lỗ hổng
Website đang bị tấn công	Lượng request tăng bất thường, CPU hosting tăng, form spam, brute-force, downtime lặp lại	Chặn IP/bot, bật WAF/rate limit, liên hệ hosting, giữ log để phân tích

Nếu vấn đề là lỗi hiển thị hoặc lỗi chức năng, bạn có thể đối chiếu thêm với bài lỗi website thường gặp. Nếu có dấu hiệu mã độc, redirect, chiếm quyền admin hoặc tấn công vào cổng web công, hãy chuyển sang quy trình xử lý sự cố ngay.

Dấu hiệu cần kích hoạt chế độ xử lý sự cố ngay

Bạn không cần đợi đủ mọi dấu hiệu mới xử lý. Chỉ cần một dấu hiệu nghiêm trọng liên quan đến quyền quản trị, mã độc, redirect, dữ liệu khách hàng hoặc cảnh báo từ Google là đã nên coi đây là sự cố bảo mật.

Dấu hiệu	Rủi ro có thể xảy ra	Mức ưu tiên
Không đăng nhập được admin hoặc mật khẩu bị đổi	Tài khoản quản trị có thể đã bị chiếm	Khẩn cấp
Xuất hiện admin/user lạ	Hacker có quyền quay lại sau khi bạn sửa web	Khẩn cấp
Redirect sang trang cờ bạc, quảng cáo, nội dung lạ	Mã độc trong .htaccess, theme, plugin hoặc database	Khẩn cấp
Google Search Console báo Security Issues	Website có thể bị gắn cảnh báo trong Search/Chrome	Khẩn cấp
File lạ trong wp-content/uploads hoặc thư mục gốc	Có thể là web shell/backdoor	Cao
Form liên hệ bị spam hàng loạt	Bot khai thác form, thiếu CAPTCHA/rate limit	Cao
Traffic SEO tụt nhanh, nhiều URL lạ được index	Có thể bị spam SEO hoặc Japanese keyword hack	Cao
Website chậm bất thường, CPU hosting tăng	Bot, DDoS layer 7 hoặc cron độc hại	Cao

Google Search Console có Security Issues report để báo các vấn đề như hacked content, malware/unwanted software hoặc social engineering. Khi report này xuất hiện, bạn cần xử lý toàn site, không chỉ một vài URL mẫu, rồi mới gửi yêu cầu review.

Việc cần làm trong 60 phút đầu để giảm thiệt hại

Mục tiêu của 60 phút đầu không phải là “sửa xong ngay”. Mục tiêu đúng là cô lập rủi ro, giữ bằng chứng, chặn quyền truy cập của kẻ tấn công và tránh làm hỏng dữ liệu có thể phục hồi.

1. Tạm dừng các chiến dịch quảng cáo đang đổ traffic vào website nếu người dùng có thể gặp cảnh báo bảo mật, redirect hoặc form giả mạo.
2. Liên hệ hosting để bật hỗ trợ khẩn cấp, kiểm tra tài nguyên, log truy cập, log lỗi, cron job và file bị thay đổi gần đây.
3. Đưa website vào chế độ bảo trì hoặc giới hạn truy cập tạm thời. Không xóa dữ liệu, không xóa toàn bộ website nếu chưa backup.
4. Backup hiện trạng gồm toàn bộ file và database. Bản này có thể đang nhiễm mã độc, nhưng cần để phân tích nguyên nhân và đối chiếu về sau.
5. Đổi mật khẩu hosting, FTP/SFTP, database, tài khoản admin WordPress, email quản trị, tài khoản Google Search Console và các tài khoản liên quan.
6. Xóa hoặc khóa tài khoản người dùng lạ. Với tài khoản quan trọng, bật xác thực đa yếu tố thay vì chỉ đổi mật khẩu.
7. Ghi lại mốc thời gian phát hiện, dấu hiệu, hành động đã làm, người tham gia xử lý và ảnh chụp cảnh báo nếu có.

Với tài khoản quản trị, bài MFA là gì giải thích vì sao bật xác thực đa yếu tố là lớp bảo vệ cần làm ngay, đặc biệt cho admin website, email, hosting, cloud, CRM và tài khoản quảng cáo.

Không nên restore vội trước khi backup hiện trạng. Restore sai thời điểm có thể ghi đè dấu vết tấn công, làm mất dữ liệu đơn hàng mới hoặc đưa website về một bản backup vốn đã bị nhiễm.

Cách phục hồi website sạch mà không làm mất dữ liệu

Phục hồi website không chỉ là bấm nút restore. Một bản backup chỉ đáng dùng khi bạn biết nó được tạo trước thời điểm nhiễm, chưa chứa backdoor và vẫn giữ được dữ liệu quan trọng như bài viết, đơn hàng, form lead hoặc tài khoản khách hàng.

Chọn bản backup sạch

Hãy ưu tiên bản backup trước thời điểm phát hiện sự cố từ 1–7 ngày tùy loại website. Với website có đơn hàng hoặc lead hằng ngày, cần tách dữ liệu giao dịch mới để tránh mất đơn. Nếu chưa có quy trình sao lưu, xem thêm bài backup website.

Làm sạch mã nguồn và database

• So sánh file WordPress core với bản gốc, kiểm tra theme/plugin bị sửa lạ.
• Kiểm tra thư mục uploads vì đây là nơi dễ xuất hiện file PHP lạ hoặc web shell.
• Tìm các đoạn mã đáng nghi trong database như script lạ, iframe, redirect, user admin không rõ nguồn.
• Gỡ plugin/theme nulled, plugin không còn dùng, hoặc plugin đã lâu không cập nhật.
• Vá đúng lỗ hổng đã bị khai thác trước khi mở website trở lại.

Kiểm thử trước khi đưa website online

Sau khi khôi phục, hãy kiểm tra trang chủ, trang dịch vụ, form liên hệ, giỏ hàng, thanh toán, đăng nhập, search nội bộ, sitemap, robots.txt, canonical và các URL có traffic SEO. Nếu Google đã gắn cảnh báo, chỉ gửi review khi chắc chắn vấn đề đã được khắc phục toàn site.

Google khuyến nghị trong Security Issues report: sửa toàn bộ vấn đề, test lại, rồi dùng Request Review và mô tả rõ lỗi, bước đã khắc phục, kết quả xử lý. Việc request review khi website chưa sạch có thể kéo dài thời gian bị cảnh báo.

Sau khi website hoạt động lại, cần khóa lỗ hổng nào trước?

Một website vừa hoạt động trở lại chưa đồng nghĩa là đã an toàn. Nếu không khóa lỗ hổng gốc, hacker có thể quay lại qua tài khoản cũ, plugin lỗi thời, web shell còn sót, cron job độc hại hoặc mật khẩu hosting đã lộ.

Lớp cần khóa	Việc nên làm	Lý do
Tài khoản	Đổi mật khẩu, bật MFA, xóa user lạ, không dùng admin chung	Giảm rủi ro chiếm quyền lại
Mã nguồn	Cập nhật WordPress core, theme, plugin; gỡ plugin không dùng	Giảm lỗ hổng từ thành phần lỗi thời
Cổng web công	Bật WAF, rate limit, CAPTCHA, chống brute-force	Giảm bot, spam form, SQLi/XSS và DDoS layer 7
Dữ liệu	Thiết lập backup tự động, lưu ngoài hosting chính, test restore	Đảm bảo khả năng phục hồi nếu bị tấn công tiếp
Giám sát	Theo dõi log, cảnh báo file thay đổi, uptime, Search Console	Phát hiện sớm bất thường thay vì chờ khách báo
Quy trình	Có checklist xử lý sự cố, người phụ trách và kênh liên hệ hosting	Rút ngắn thời gian phản ứng khi sự cố lặp lại

Nếu website có cổng đăng nhập, form, API hoặc khu vực khách hàng, hãy dùng checklist bảo mật cho website có cổng web công để rà lại. Với website thường xuyên bị bot, spam hoặc tấn công lớp ứng dụng, bài WAF là gì và trang dịch vụ triển khai WAF và chống DDoS là nhánh xử lý phù hợp hơn.

Khi nào nên tự xử lý, khi nào nên gọi đội kỹ thuật?

Không phải sự cố nào cũng cần thuê đội bảo mật. Nhưng cũng có những trường hợp càng tự sửa càng mất dữ liệu, mất dấu vết và kéo dài downtime.

Tình huống	Có thể tự xử lý khi	Nên gọi kỹ thuật khi
Lỗi plugin sau cập nhật	Có backup gần nhất, biết plugin vừa cập nhật, website không có dữ liệu giao dịch mới	Lỗi kéo dài, không vào admin, website là kênh bán hàng chính
Website bị redirect lạ	Có kinh nghiệm kiểm tra .htaccess/theme/database và có backup sạch	Redirect quay lại sau khi xóa, nhiều file lạ, không rõ điểm xâm nhập
Google cảnh báo mã độc/phishing	Biết đọc Security Issues report, xử lý toàn site, có quyền Search Console	Có cảnh báo trên nhiều URL, ảnh hưởng SEO/Ads, không biết cách gửi review
Bị spam form/brute-force	Có thể bật CAPTCHA, rate limit, khóa IP, đổi mật khẩu admin	Lượng request lớn, CPU hosting tăng, website downtime lặp lại
Mất quyền admin hoặc có admin lạ	Còn quyền hosting/database để reset user an toàn	Mất cả hosting/email quản trị, nghi lộ nhiều tài khoản

Nếu doanh nghiệp không có người trực kỹ thuật, có thể cân nhắc dịch vụ chăm sóc website toàn diện để có quy trình backup, cập nhật, giám sát và báo cáo định kỳ. Nếu website thuộc hệ thống có yêu cầu an toàn thông tin cao hơn, hãy rà thêm giải pháp bảo mật hệ thống cấp độ 2, cấp độ 3.

Checklist phòng tái diễn trong 30 ngày sau sự cố

Sau khi xử lý xong, hãy coi 30 ngày tiếp theo là giai đoạn theo dõi đặc biệt. Nhiều website bị hack lại không phải vì lần đầu chưa sửa, mà vì chỉ dọn phần nhìn thấy được, chưa xử lý tài khoản, bản vá, log và backup.

• Ngày 1–3: đổi toàn bộ mật khẩu, bật MFA, xóa user lạ, kiểm tra quyền hosting và Search Console.
• Ngày 1–7: cập nhật core/theme/plugin theo quy trình an toàn; tham khảo bài cập nhật plugin WordPress định kỳ.
• Tuần 1: quét lại mã độc, kiểm tra file thay đổi, xem log truy cập bất thường và thử restore một bản backup mới.
• Tuần 2: rà chính sách phân quyền, cấu hình bảo mật website doanh nghiệp và các điểm yếu trong form/API. Xem thêm bảo mật website doanh nghiệp.
• Tuần 3: bật cảnh báo uptime, cảnh báo thay đổi file, cảnh báo đăng nhập thất bại và theo dõi Google Search Console.
• Tuần 4: lập báo cáo sự cố gồm nguyên nhân, thiệt hại, hạng mục đã xử lý, hạng mục còn rủi ro và kế hoạch phòng ngừa.

Hạng mục	Tần suất tối thiểu	Người phụ trách
Backup file + database	Hằng ngày hoặc hằng tuần tùy mức cập nhật	Kỹ thuật/đơn vị chăm sóc website
Cập nhật plugin/theme/core	Hằng tuần hoặc theo mức độ rủi ro bản vá	Kỹ thuật WordPress
Kiểm tra tài khoản admin	Hằng tháng	Chủ website hoặc quản trị viên
Quét mã độc và file thay đổi	Hằng tuần sau sự cố, sau đó hằng tháng	Kỹ thuật bảo mật
Kiểm tra Search Console Security Issues	Hằng tuần	SEO/website manager
Diễn tập restore backup	Hằng quý	Kỹ thuật/hosting

FAQ

Website bị hack có nên xóa toàn bộ rồi làm lại không?

Không nên xóa ngay. Trước tiên cần backup hiện trạng, giữ log, xác định dữ liệu quan trọng và đánh giá bản backup sạch. Chỉ làm lại toàn bộ khi mã nguồn quá cũ, nhiễm nặng, không thể xác định lỗ hổng hoặc chi phí làm sạch cao hơn tái xây dựng.

Website bị Google cảnh báo mã độc thì bao lâu gỡ được?

Thời gian phụ thuộc vào mức độ sự cố và quy trình review của Google. Sau khi làm sạch toàn site, sửa lỗ hổng và gửi Request Review trong Search Console, review có thể mất từ vài ngày đến vài tuần tùy loại vấn đề.

Có backup rồi thì website có chắc chắn phục hồi được không?

Không chắc. Backup chỉ có giá trị khi còn sạch, có đủ file + database, lưu ngoài hosting chính và đã được test restore. Backup nhiễm mã độc hoặc backup quá cũ vẫn có thể làm mất dữ liệu.

Cài plugin bảo mật có đủ chống hack không?

Không đủ. Plugin bảo mật là một lớp hỗ trợ. Website vẫn cần cập nhật định kỳ, phân quyền đúng, mật khẩu mạnh/MFA, backup, WAF nếu cần, giám sát log và quy trình ứng cứu khi có sự cố.

Website nhỏ có cần quy trình xử lý sự cố không?

Có. Quy trình không cần phức tạp, nhưng phải có tối thiểu: người phụ trách, tài khoản truy cập, backup, cách liên hệ hosting, checklist cô lập, checklist phục hồi và cách thông báo cho khách nếu có ảnh hưởng dữ liệu.

Kết luận

Khi website bị hack, lỗi hoặc bị tấn công, điều quan trọng nhất là đừng xử lý theo cảm tính. Hãy phân loại sự cố, cô lập trong 60 phút đầu, giữ bằng chứng, phục hồi từ nguồn sạch, khóa lỗ hổng và theo dõi ít nhất 30 ngày sau sự cố.