Website WordPress bị chèn mã độc: dấu hiệu, cách xử lý an toàn và nghiệm thu sạch

Website vẫn mở bình thường không có nghĩa là không bị chèn mã độc. Tài liệu xử lý của Halo ghi nhận trường hợp người xem nhận nội dung tiếng Việt, còn công cụ tìm kiếm lại nhận trang spam. Có trường hợp tệp vừa sửa bị ghi lại ngay bởi một tiến trình chạy nền. Vì vậy, xử lý cần bắt đầu bằng đo hiện trạng và giữ bằng chứng, sau đó mới chặn, làm sạch và nghiệm thu.

Tóm tắt nhanh

• Nội dung lạ, tài khoản quản trị không rõ nguồn gốc, tệp bất thường và thay đổi tự quay lại đều cần được kiểm chứng.
• Không xoá vội: cần giữ nhật ký, sao lưu dữ liệu và bằng chứng trước khi xử lý để còn điều tra và khôi phục.
• Phải kiểm cả WordPress, ứng dụng liên quan, tiến trình và cơ chế tự chạy lại trên máy chủ.
• Nghiệm thu cần có số đo, giới hạn phạm vi và lịch kiểm lại; không hứa website an toàn tuyệt đối.

Những dấu hiệu cần kiểm tra

Dấu hiệu dễ thấy là website xuất hiện nội dung spam không thuộc hoạt động của doanh nghiệp. Tuy nhiên, nội dung đó có thể chỉ hiện với một nhóm lượt truy cập. Cloaking là cách trả nội dung khác nhau theo đối tượng truy cập; trong ca được Halo ghi lại, trình duyệt và công cụ tìm kiếm nhận hai nội dung khác nhau trên cùng đường dẫn.

Ở bên trong, dấu hiệu có thể là tài khoản quản trị lạ, tệp PHP nằm ở vị trí bất thường, tệp lõi bị thay đổi hoặc quyền tệp tự quay về trạng thái cũ. PHP là mã được máy chủ thực thi để chạy WordPress. Một tệp mang tên giống thành phần WordPress nhưng đặt sai chỗ cũng cần được đối chiếu.

Những dấu hiệu này chưa tự động là kết luận. Tài liệu Halo ghi nhận cả tệp PHP hợp lệ trong thư mục tải lên và tệp rỗng vô hại. Dương tính giả là trường hợp phép kiểm báo nghi ngờ nhưng đối tượng thực tế hợp lệ. Xoá theo tên tệp hoặc một từ khoá có thể làm hỏng thành phần đang dùng.

Dấu vết lịch sử cũng cần phân biệt với mã độc đang hoạt động. Ghi chú do phần mềm bảo vệ để lại có thể cho thấy website từng bị nhiễm, nhưng chưa trả lời hiện tại còn mã độc thực thi hay không. Báo cáo cần tách hai trạng thái này thay vì gộp thành một nhãn chung.

Vì sao không nên xoá ngay tệp đáng ngờ?

Nhật ký máy chủ, còn gọi là log, ghi lại hoạt động giúp truy đường vào và thời điểm xảy ra sự cố. Log có thể bị xoay vòng, tức bản cũ được thay theo lịch. Quy trình Halo yêu cầu kéo log về trước khi quét sâu để tránh mất phần bằng chứng này.

Xoá một tệp cũng chưa chắc dừng được hoạt động của nó. Tiến trình là chương trình đang chạy trên máy chủ; có trường hợp tệp đã bị xoá khỏi đĩa nhưng tiến trình vẫn hoạt động. Ngược lại, dừng tiến trình quá sớm có thể làm mất cơ hội thu lại nội dung còn được nó giữ. Phần này cần người quản trị xử lý theo đúng thứ tự.

Một cơ chế chạy nền còn có thể ghi lại tệp vừa dọn. Khi đó, việc xoá lặp đi lặp lại chỉ xử lý phần xuất hiện trước mắt. Tài liệu ghi nhận chính tiến trình canh tệp khiến những lần sửa trước không giữ được kết quả. Cần tìm và vô hiệu cơ chế đó trước khi hoàn tất việc làm sạch.

Trước khi thay đổi, phải có bản sao lưu và gói bằng chứng, bao gồm dữ liệu, cấu hình, nhật ký và các tệp liên quan. Phạm vi điều tra có thể rộng hơn thư mục website. Dung lượng trống cũng phải được đo trước khi đóng gói để tránh làm đầy ổ trong lúc xử lý.

Quy trình xử lý theo thứ tự

1. Đo hiện trạng và xác định đúng phạm vi

Hồ sơ cũ chỉ là điểm tham chiếu. Người xử lý cần ghi thời điểm mở ca, xác định đúng thư mục website và kiểm tra ai đang thao tác trên máy. Nếu quét nhầm thư mục rồi nhận kết quả rỗng, không được coi đó là bằng chứng không có mã độc.

Phạm vi phải bao gồm các ứng dụng liên quan. Trong một ca của Halo, WordPress là nơi bị lây sang từ ứng dụng khác trên cùng hệ thống. Chỉ quét WordPress sẽ bỏ qua đường vào. Các website dùng chung tài khoản hệ thống cũng cần được rà soát để đánh giá khả năng ảnh hưởng chéo.

2. Giữ bằng chứng rồi chặn đường vào

Sau khi lưu nhật ký và bằng chứng, đội kỹ thuật mới triển khai biện pháp chặn phù hợp. Gói bằng chứng cần có mã kiểm tra toàn vẹn và bản ở ngoài máy chủ. Tài liệu yêu cầu bảo toàn thông tin phiên đăng nhập trước khi thu hồi tài khoản hoặc thay khoá xác thực.

Chặn đường vào phải tính tới cơ chế đang tự ghi lại tệp. Nếu cấu hình vừa sửa bị hoàn nguyên, cần tìm nguyên nhân thay vì tiếp tục sửa cùng một chỗ. Việc dừng tiến trình, kiểm tra nó đã dừng và loại bỏ cơ chế khởi động lại là các bước riêng.

3. Thu hồi truy cập và xử lý tệp bị can thiệp

Đổi mật khẩu không thay thế cho việc rà các phương thức truy cập khác. Quy trình yêu cầu kiểm tài khoản giả, phiên đăng nhập, khoá ứng dụng và thông tin kết nối có thể đã lộ. Với thông tin bí mật từng nằm trong tệp công khai, chuyển tệp đi chỉ ngăn truy cập tiếp, chưa thu hồi được bí mật đã phơi ra.

Các thay đổi có thể làm gián đoạn dịch vụ cần được thống nhất trước. Chẳng hạn, thay khoá xác thực WordPress có thể đăng xuất người đang dùng; thu hồi khoá ứng dụng có thể ngắt tác vụ tự động. Người xử lý phải biết thành phần nào đang phụ thuộc vào chúng.

Đối với tệp, checksum là mã dùng để đối chiếu nội dung với bản phát hành chính thức. Đây là cơ sở giúp khoanh vùng tệp khác biệt để đọc kỹ. Plugin trả phí hoặc tự viết có thể không nằm trong tập đối chiếu tự động; phần bị bỏ qua phải được liệt kê và kiểm riêng, không tính như đã đạt.

4. Bịt đường tái nhiễm

Dọn tệp mà để nguyên điểm yếu có thể khiến sự cố lặp lại. Phạm vi rà soát gồm cấu hình thực thi, quyền truy cập, thư mục ghi được và các tác vụ định kỳ. Cron là cơ chế chạy tác vụ theo lịch; cần phân biệt tác vụ hợp lệ của website với tác vụ do mã độc thêm vào.

Các quy tắc bảo vệ cũng có thể làm hỏng chức năng hợp lệ. Vì vậy, trước khi siết cấu hình phải ghi nhận trạng thái ban đầu, sau đó kiểm lại đăng nhập, giao diện dữ liệu và chức năng động liên quan. Trang tĩnh còn trả 200 chưa chứng minh những phần này vẫn hoạt động.

Nghiệm thu cần cả phép đo bên trong và bên ngoài

Trên máy chủ, cần đối chiếu tệp, kiểm tiến trình, tài khoản và cơ chế tự chạy lại. Quy trình quét có vòng cơ bản, vòng phản biện kết quả và vòng tìm phần bỏ sót. Mỗi phát hiện phải được đọc, xác minh; không chỉ nhìn tổng số cảnh báo.

Từ bên ngoài, cần so nội dung trả về cho trình duyệt và công cụ tìm kiếm, đồng thời xử lý đúng chuyển hướng. Nếu cả hai phép đọc đều không lấy được nội dung, không thể kết luận chúng giống nhau. Những URL spam cần được kiểm riêng với sitemap và trang thật để tránh chặn nhầm nội dung hợp lệ.

Phải kiểm máy chủ gốc và lớp CDN nếu có. CDN là mạng phân phối nội dung có thể lưu bản đệm. Bản đệm cũ có thể tiếp tục hiện nội dung bị chèn dù bản gốc đã được sửa. Ngược lại, chặn ở CDN chưa chứng minh đường truy cập trực tiếp tới máy chủ gốc đã bị chặn.

Biên bản cần ghi số đo, thời điểm, phạm vi đã kiểm và phần chưa thể kết luận. Cảnh báo bị loại phải có lý do dương tính giả. Nếu thiếu quyền truy cập cơ sở dữ liệu hoặc mất log, phải ghi rõ giới hạn đó. Kết quả công cụ quét bên ngoài không thay thế được các phép kiểm trực tiếp này.

Theo dõi sau xử lý

Halo yêu cầu hẹn kiểm lại sau 24 giờ, 7 ngày và 30 ngày bằng bộ nghiệm thu đã dùng lúc bàn giao. Việc này có cơ sở: đường vào gốc có thể chưa xác định do thiếu log, cơ chế tự chạy lại có thể còn sót và cảnh báo có thể chưa đến được người phụ trách.

Phòng tái nhiễm vì thế còn bao gồm kiểm công cụ bảo vệ thực sự hoạt động, tác vụ định kỳ gọi đúng chương trình và cảnh báo tới hộp thư có người đọc. Cài một công cụ chưa chứng minh nó đang chạy. Hồ sơ bàn giao cần để lại cả lịch kiểm tiếp theo và những vấn đề còn mở.

Nguồn

1. ma-doc-01-quy-trinh.md, quy trình nội bộ Halo Media, rút từ ca xử lý ngày 26/09/2026.
2. ma-doc-02-phat-hien.md, hướng dẫn phát hiện nội bộ Halo Media, rút từ ca ngày 26/09/2026.
3. ma-doc-03-nghiem-thu.md, hướng dẫn nghiệm thu nội bộ Halo Media, rút từ ca ngày 26/09/2026.
4. 02-IOC-MALWARE.md, bộ kiểm tra WordPress nội bộ Halo Media, các ca năm 2026; tệp không ghi ngày ban hành cụ thể.