Website bị hack: 10 bước xử lý trong 24 giờ đầu

7 giờ sáng thứ Hai, một khách hàng nhắn cho bạn: "Anh ơi web bên mình hiện trang cá cược, bấm vào là nhảy đi đâu đó." Bạn mở bằng máy tính của mình thì vẫn bình thường. Mở bằng 4G trên điện thoại, bấm từ kết quả Google thì đúng là nhảy thật. Website bị hack hiếm khi hiện dòng chữ "Hacked by" đỏ chót giữa màn hình như trong phim — phần lớn ca chúng tôi tiếp nhận đều âm thầm hơn nhiều: link ẩn, redirect có điều kiện, hoặc một file lạ nằm im chờ ngày được gọi.

Ở tình huống này, thứ quyết định mức thiệt hại không phải bạn giỏi kỹ thuật đến đâu, mà là 30 phút đầu bạn làm gì. Sai lầm phổ biến nhất là hoảng: xóa sạch thư mục, cài lại mã nguồn mới, đổi mật khẩu admin, thấy web chạy lại thì thở phào. Rồi một tuần sau bị lại y hệt, vì cửa hậu không nằm ở chỗ vừa bị xóa.

Bài này viết như tài liệu ứng cứu, không phải bài lý thuyết an ninh mạng. 10 bước, xếp theo mốc thời gian: 30 phút đầu, 24 giờ đầu, tuần đầu. Làm theo thứ tự, đừng nhảy cóc.

Toàn cảnh: mốc thời gian ứng cứu khi website bị hack

30 phút đầu: cô lập, chưa vội xóa gì

Bước 1 — Chụp lại hiện trường trước khi động vào

Nghe phản trực giác, nhưng đây là bước bị bỏ qua nhiều nhất và tốn kém nhất. Trước khi xóa, sửa hay restore, hãy giữ một bản nguyên trạng: nén toàn bộ thư mục web, dump database, tải access log và error log 30 ngày gần nhất về nơi lưu riêng.

Xóa file mã độc trước khi đọc log là mất luôn dấu vết thời điểm file đó được tạo — mà chính mốc thời gian ấy giúp truy ngược ra lối vào. Không có nó, bạn chỉ còn cách đoán. Đoán sai nghĩa là vá xong vẫn bị lại.

Bước 2 — Đưa site về chế độ bảo trì, đừng tắt hẳn máy chủ

Cô lập không đồng nghĩa với rút điện. Tắt hẳn VPS làm bạn mất khả năng đọc trạng thái đang chạy. Cách gọn hơn: chặn truy cập từ bên ngoài ở tầng web server hoặc firewall, chỉ cho IP của bạn vào, trả về trang bảo trì mã 503. Nếu không thể tắt vì đang phục vụ khách, ít nhất hãy chặn các đường dẫn đang bị lợi dụng và tắt chức năng đăng ký, upload, thanh toán.

Nếu site nằm chung VPS với nhiều site khác — mô hình rất phổ biến ở doanh nghiệp nhỏ — hãy cô lập cả cụm. Tình huống chúng tôi thường gặp: một website cũ không ai dùng nữa, quên cập nhật, trở thành bàn đạp lây sang bốn site còn lại trên cùng máy chủ.

Bước 3 — Cắt đường vào: đổi credential theo đúng thứ tự

Đổi mật khẩu thì ai cũng biết, nhưng thứ tự hay sai. Đổi mật khẩu admin trước mà chưa cắt phiên đăng nhập và chưa đổi khóa SSH thì kẻ tấn công vẫn đang ở trong, chỉ cần tạo lại tài khoản mới.

1. Thu hồi toàn bộ phiên đăng nhập đang mở, đổi khóa bí mật của session/cookie.
2. Đổi khóa SSH và mật khẩu root của VPS, tắt đăng nhập SSH bằng mật khẩu.
3. Đổi mật khẩu database và FTP/SFTP — FTP là nguồn rò rỉ kinh điển vì truyền không mã hóa và thường được lưu sẵn trên máy nhân viên.
4. Đổi mật khẩu control panel hosting, tài khoản tên miền, email quản trị.
5. Cuối cùng mới đến tài khoản quản trị website và các API key, token tích hợp bên thứ ba.

Đừng bỏ bước cuối. Nhiều ca bắt đầu từ một API key lộ trong repo public chứ không phải từ website.

Bước 4 — Xác định lối vào: plugin, mật khẩu, hosting hay chính code của bạn

Đây là phần tách người xử lý được với người chỉ dọn bề mặt. Bạn cần trả lời đúng một câu: kẻ tấn công vào bằng đường nào, lúc mấy giờ. Cách làm: lấy timestamp của file lạ đầu tiên hoặc file hợp lệ bị sửa, rồi mở access log đúng khung giờ đó, tìm request POST bất thường, request tới đường dẫn không tồn tại, hoặc một IP lạ dội vào trang đăng nhập ngay trước mốc đó.

Nếu sau vài giờ vẫn chưa tìm được lối vào, đừng vội dựng site lên. Dựng lên khi chưa biết cửa nào đang mở chỉ là dời lần bị hack thứ hai về sau vài ngày.

Làm sạch mã độc: bạn tự làm được đến đâu

Bước 5 — Đối chiếu file, đừng tin mắt thường

Với mã nguồn mở phổ biến, cách sạch nhất không phải "tìm và xóa file lạ" mà là so sánh với bản gốc: tải đúng phiên bản từ nguồn chính thức, so từng file phần lõi và plugin/theme. File nào khác biệt, file nào thừa ra — đó là danh sách cần xem. Với website viết riêng, dùng git để so với commit sạch gần nhất.

Những chỗ mã độc hay nằm, xếp theo tần suất chúng tôi gặp:

• File tên na ná file hệ thống, đặt trong thư mục upload — nơi đáng lẽ chỉ chứa ảnh.
• Một dòng mã nhét vào cuối file cấu hình, đẩy sang phải bằng vài trăm dấu cách để bạn không thấy khi mở lướt.
• Bản ghi trong database: script chèn vào bài viết, vào bảng cấu hình, hoặc một tài khoản quản trị mới tạo âm thầm.
• Cron job tự tải lại mã độc sau khi bạn đã dọn xong — lý do nhiều người dọn sạch buổi sáng, chiều bị lại.
• Luật redirect trong .htaccess chỉ kích hoạt khi khách đến từ Google hoặc từ điện thoại, đúng lý do bạn mở bằng máy mình thì thấy bình thường.

Bước 6 — Biết điểm dừng của việc tự xử lý

Bạn tự làm được nếu website dùng mã nguồn mở, có backup sạch, quy mô nhỏ, không lưu dữ liệu nhạy cảm và đã tìm ra lối vào rõ ràng. Nên dừng lại và gọi hỗ trợ nếu: có dấu hiệu dữ liệu khách hàng bị lấy đi; máy chủ có tiến trình lạ ăn CPU (đào tiền ảo là ca rất phổ biến); mã độc quay lại sau khi đã dọn; nhiều site cùng máy chủ cùng nhiễm; hoặc hệ thống có kết nối tới phần mềm nội bộ, ERP, cổng thanh toán.

Bước 7 — Khôi phục từ backup: lỗi kinh điển là restore luôn cửa hậu

Đây là chỗ sai nhiều nhất, và là lý do một sự cố tưởng đã xong lại kéo dài hàng tháng.

Phản xạ của hầu hết mọi người là restore bản backup gần nhất. Nhưng nếu cửa hậu được cài từ ba tuần trước và chỉ mới kích hoạt hôm qua, thì bản của tối qua, của tuần trước, có khi cả của hai tuần trước đều đã chứa cửa hậu đó. Restore xong, website sạch sẽ, kẻ tấn công vẫn giữ nguyên chìa khóa.

1. Xác định mốc xâm nhập ở bước 4 trước đã. Không có mốc này thì đừng restore.
2. Chọn bản backup có thời điểm trước mốc xâm nhập, không phải bản mới nhất.
3. Restore ra môi trường tách biệt, quét lại, đối chiếu file, kiểm tra danh sách admin và cron job. Sạch mới đưa lên production.
4. Nếu bản sạch quá cũ: lấy mã nguồn từ bản cũ sạch, còn database và thư mục upload lấy từ bản mới nhưng làm sạch riêng — mã độc trong database không đi cùng mã nguồn.
5. Vá lỗ hổng gốc trước khi mở site ra ngoài.

Nếu bạn chỉ giữ đúng một bản backup ghi đè mỗi ngày, khả năng cao không có bản nào sạch để dùng. Đây là lý do các gói vận hành của chúng tôi đặt mặc định backup hằng ngày và lưu 30 ngày — không phải để chống hỏng ổ cứng, mà để có đủ chiều sâu lịch sử cho đúng tình huống này.

Nguyên tắc giữ nhiều bản, nhiều nơi, có bản tách khỏi hệ thống chính được nói kỹ hơn trong bài phòng chống ransomware cho SME — với ransomware, chất lượng backup gần như là toàn bộ câu chuyện.

Bước 8 — Gỡ cảnh báo "trang lừa đảo" trên Google và trình duyệt

Khi website bị chèn mã độc, thiệt hại lớn nhất thường không phải file hỏng mà là dòng cảnh báo đỏ hiện ra trước mặt mọi khách hàng, kèm việc rơi khỏi kết quả tìm kiếm.

1. Mở Google Search Console, mục Security Issues, xem Google báo loại gì và lấy danh sách URL mẫu.
2. Kiểm tra từng URL mẫu, xác nhận đã sạch thật. Nhiều người trượt ở đây: gửi review khi mới dọn được một nửa, bị từ chối, mỗi lần từ chối là thêm nhiều ngày chờ.
3. Gửi yêu cầu xem xét, mô tả ngắn gọn đã tìm ra lối vào nào, vá ra sao, đổi credential gì. Mô tả cụ thể được duyệt nhanh hơn.
4. Kiểm tra thêm danh sách chặn của các trình duyệt và hãng bảo mật khác — gỡ ở Google không tự động gỡ ở nơi khác.
5. Nếu tên miền hoặc IP bị vào danh sách đen gửi mail, xử lý riêng phần đó, nếu không email đơn hàng sẽ vào spam nhiều tuần sau khi website đã sạch.

Tuần đầu: vá để không bị hack lại

Bước 9 — Checklist sau sự cố

Sự cố kết thúc khi hệ thống khác trước lúc bị tấn công, không phải khi website chạy lại.

• Cập nhật mã nguồn, plugin, theme và cả phần mềm máy chủ. Gỡ hẳn plugin không dùng thay vì chỉ tắt — file vẫn nằm đó và vẫn có thể bị gọi trực tiếp.
• Rà danh sách tài khoản admin: xóa tài khoản nhân sự đã nghỉ, của bên làm website cũ, tài khoản test.
• Bật xác thực hai lớp cho quản trị website, hosting và tên miền.
• Giới hạn số lần đăng nhập sai, đổi đường dẫn trang đăng nhập nếu nền tảng cho phép.
• Phân quyền file đúng, chặn thực thi mã trong thư mục upload.
• Bật tường lửa ứng dụng web và giám sát thay đổi file, có cảnh báo về email hoặc điện thoại.
• Chốt chính sách backup: bao lâu một lần, giữ bao nhiêu ngày, lưu ở đâu, và quan trọng nhất — đã thử restore chưa. Backup chưa từng restore thử chỉ là niềm tin, không phải phương án.
• Tách các website khỏi nhau nếu đang chung máy chủ, hoặc ít nhất tách quyền để một site nhiễm không lây sang site còn lại.

Bản đầy đủ hơn, viết cho người không rành kỹ thuật, chúng tôi đã hệ thống lại trong checklist bảo mật website cho người không biết code. Nếu website vừa bị hack đang chạy trên hạ tầng dùng chung giá rẻ, đây cũng là lúc hợp lý để xem lại dịch vụ máy chủ và tách môi trường cho gọn.

Sau khi vá xong, nếu website có giao dịch hoặc lưu dữ liệu khách hàng, việc tiếp theo là kiểm tra còn lỗ hổng nào chưa lộ ra. Bảy dấu hiệu cho thấy đã đến lúc làm việc đó nằm trong bài doanh nghiệp nhỏ có cần pentest không, còn khung chi phí thì xem báo giá pentest theo phạm vi kiểm thử.

Bước 10 — Khi nào cần gọi đơn vị ứng cứu chuyên nghiệp

Gọi ngay, không cần cân nhắc, nếu: có khả năng dữ liệu khách hàng bị lấy; website có chức năng thanh toán; hệ thống kết nối phần mềm nội bộ hoặc ERP; mã độc quay lại sau khi đã dọn; hoặc đã hơn một ngày mà vẫn chưa xác định được lối vào.

Về chi phí, đây là khoảng tham khảo thị trường tại thời điểm viết (08/2026), chưa gồm VAT. Con số thực tế phụ thuộc quy mô hệ thống, số website và máy chủ, mức độ xâm nhập và việc bạn có sẵn backup hay không — xem đây là khung dự trù, không phải báo giá cố định.

Khi chọn đơn vị, hỏi ba câu: họ đọc log để tìm lối vào hay chỉ chạy công cụ quét; có bàn giao báo cáo nêu rõ nguyên nhân gốc không; ai chịu trách nhiệm nếu bị lại trong 30 ngày.

Microads làm hạ tầng và bảo mật hệ thống từ 2015, hơn 30 kỹ sư có chứng chỉ AWS, GCP, CEH, OSCP, PMP, hỗ trợ 24/7 và cam kết phản hồi sự cố mức P1 trong 15 phút. Với ứng cứu, tốc độ phản hồi mới là thứ đáng tiền: một website bị chèn mã độc để đến ngày thứ ba mới xử lý thì phần khó nhất không còn là dọn mã độc, mà là lấy lại thứ hạng tìm kiếm đã mất.

Việc cần làm ngay bây giờ

Nếu website của bạn đang bị hack lúc này, dừng đọc ở đây, làm bước 1 đến bước 3 trước rồi quay lại. Còn nếu bạn đọc để phòng xa, hãy kiểm tra đúng một thứ trong hôm nay: bản backup gần nhất có restore được không, và bạn giữ được bao nhiêu ngày lịch sử.

Cần người rà cùng, hoặc đang trong tình huống khẩn: gọi hotline 0919 788 815 hoặc gửi thông tin qua form trên microads.vn. Chúng tôi tư vấn miễn phí phần đánh giá ban đầu — website của bạn đang bị gì, mức độ đến đâu, có cần ứng cứu đầy đủ hay không.