Mã độc thường giấu ở đâu trong WordPress

Mã độc trong WordPress thường không nằm ở chỗ dễ thấy. Kẻ tấn công giấu nó ở những nơi ít ai ngó tới và đặt tên na ná file thật để qua mắt. Biết trước các vị trí quen thuộc giúp bạn dò nhanh và không bỏ sót — nhất là cửa hậu, thứ khiến web “dọn rồi vẫn dính”.

Những vị trí trong mã nguồn

• wp-content/mu-plugins/ — thư mục “must-use plugin” tự động nạp và không hiện nút tắt trong trang quản trị, nên là chỗ ẩn rất được ưa chuộng. Một ca thật do Sucuri ghi nhận năm 2025 là file wp-index.php nằm ở đây.
• wp-content/uploads/ — đáng lẽ chỉ chứa ảnh và tài liệu, nhưng hay bị nhét file .php lạ trộn giữa các thư mục theo tháng, hoặc payload tạm dạng .sess-*.php.
• wp-config.php và .htaccess — mã chèn ngay đầu file cấu hình, hoặc rule chuyển hướng trong .htaccess (chạy ở tầng máy chủ, trước cả WordPress).
• functions.php của theme — đặc biệt là theme không kích hoạt nhưng vẫn còn trong web; ít người để ý nên dễ thành nơi trú.
• File giả mạo lõi đặt trong wp-includes/, wp-admin/ với tên gần giống file thật để lẫn vào.
• Plugin giả — một thư mục trông như plugin bình thường trong plugins/ nhưng bên trong chỉ là cửa hậu.

Những vị trí trong cơ sở dữ liệu

Nhiều người chỉ quét file mà quên cơ sở dữ liệu (database) — nơi mã độc cũng thường trú:

• Bảng wp_options — sửa siteurl/home thành tên miền lạ để chuyển hướng cả web; hoặc thêm tuỳ chọn lạ. Một ca thật ghi nhận key _hdra_core được cài vào đây.
• Bảng wp_posts — chèn thẻ <script> hoặc iframe vào nội dung bài viết, widget.
• Bảng wp_users — tạo tài khoản quản trị ẩn (một ca thật là user officialwp).

Dấu hiệu nhận ra mã đã bị làm rối

Mã độc hay được “làm rối” (obfuscate) để khó đọc. Khi mở file, hãy nghi ngờ những đoạn:

• Chuỗi rất dài, vô nghĩa, kèm các hàm như base64_decode, gzinflate, gzuncompress, str_rot13, eval.
• Nhận dữ liệu từ $_POST, $_GET, $_REQUEST, $_COOKIE rồi đem thực thi.

Lưu ý: các hàm trên cũng xuất hiện trong code hợp lệ, nên đừng xoá mù. Dấu hiệu thật của cửa hậu là code bị rối nhiều lớp và nhận lệnh từ bên ngoài. Cách an toàn là đối chiếu với file gốc — xem bài kiểm tra website nhiễm mã độc để dùng verify-checksums.

Vì sao hacker chọn đúng những nơi này

Điểm chung của mọi vị trí trên là chúng ít bị ngó tới nhưng vẫn được WordPress tự động chạy. Thư mục mu-plugins nạp mọi file bên trong mà không hiện nút quản lý; uploads thì ai cũng nghĩ chỉ chứa ảnh nên hiếm khi soi; .htaccess chạy ở tầng máy chủ trước cả WordPress nên qua mặt được nhiều công cụ quét; còn cơ sở dữ liệu thì phần lớn người dùng không biết cách mở ra xem. Hiểu logic “ẩn mà vẫn chạy” này giúp bạn đoán được nơi cần soi kể cả khi gặp một biến thể mã độc mới chưa từng thấy.

Soi nhanh bằng dòng lệnh

Nếu hosting cho phép truy cập SSH, vài lệnh giúp khoanh vùng rất nhanh:

• Tìm file PHP nằm sai chỗ trong uploads: find wp-content/uploads -name "*.php"
• Tìm file mới bị sửa trong 7 ngày qua: find . -name "*.php" -mtime -7
• Tìm các hàm hay dùng trong mã độc: grep -RIl --include=*.php -E "eval(|base64_decode(|gzinflate(" .

Nhớ rằng kết quả chỉ là điểm khởi đầu để soi tiếp, không phải bản án — hãy đối chiếu với bản gốc trước khi xoá bất cứ thứ gì.

Bảng tra nhanh: nơi giấu và cách soi

Phần lớn người tự dọn chỉ soi file mà quên hẳn cơ sở dữ liệu — đó là lý do mã độc “mọc lại”: bạn xoá file nhưng một đoạn script vẫn nằm trong bài viết, hoặc một tài khoản ẩn vẫn còn đó chờ ngày tái xuất. Luôn rà cả hai mặt: file và cơ sở dữ liệu.

Vài ví dụ có thật để hình dung

Các vụ được hãng bảo mật Sucuri ghi nhận năm 2025 cho thấy mã độc nay rất tinh vi trong việc đặt tên và chọn chỗ trú:

• Cửa hậu nằm trong wp-content/mu-plugins/wp-index.php — tên nghe như file hệ thống nhưng hoàn toàn không phải.
• Một trình quản lý file ẩn đội lốt pricing-table-3.php trong thư mục theme.
• Payload tạm dạng .sess-[chuỗi ký tự].php nằm lẫn trong uploads/.
• Trong cơ sở dữ liệu: một tuỳ chọn lạ tên _hdra_core ở bảng wp_options, và một tài khoản quản trị ẩn tên officialwp trong wp_users.

Điểm chung là chúng cố trông “có vẻ thuộc về WordPress” để bạn lướt qua. Vì vậy khi rà, hãy nghi ngờ cả những cái tên nghe quen — đối chiếu với bản gốc thay vì tin vào cảm giác “chắc là file hệ thống”.

Tìm thấy rồi, gỡ thế nào

Sau khi khoanh vùng, hãy theo quy trình tự gỡ mã độc từng bước và đặc biệt là dọn sạch cửa hậu — nếu sót, mọi công sức sẽ đổ bể. Web quan trọng thì nên để Web22 lo phần bóc gỡ mã độc và gia cố, vì Web22 rà cả file lẫn cơ sở dữ liệu.

Câu hỏi thường gặp

Vì sao quét plugin xong vẫn còn mã độc?

Thường vì chỉ quét thư mục plugins mà bỏ qua mu-plugins và cơ sở dữ liệu. Phải rà cả hai nơi này.

Thư mục uploads chỉ chứa ảnh, có cần soi không?

Rất cần. Đây là một trong những chỗ giấu mã phổ biến nhất. Uploads không nên có file .php nào chạy được.

Nguồn: Sucuri — backdoor ẩn trong mu-plugins (2025).