Mối đe dọa

Phân tích mã độc WordPress 'SC': Cơ chế tự phục hồi đa tầng và kỹ thuật ẩn mình

Các nhà nghiên cứu bảo mật vừa phát hiện một loại mã độc WordPress mới có khả năng tự phục hồi thông qua cơ chế đa tầng, sử dụng blockchain làm kênh C2 và lưu trữ payload trong bộ nhớ chia sẻ.

RSS Source
RSS SourceAI Rewrite
Thời gian đọc: ~1 phút
WordPress Backdoor Rebuilds Itself After Cleanup Using Files, Database, and Shared Memory
  • Cơ chế tự phục hồi: Mã độc 'SC' sử dụng cấu trúc mesh phân tán trên 8 vị trí khác nhau (file, database, shared memory) để tự tái tạo khi bị xóa.
  • Kênh điều khiển C2: Sử dụng hạ tầng blockchain Ethereum để ẩn giấu kênh liên lạc, gây khó khăn cho việc phát hiện bằng các phương pháp truyền thống.
  • Kỹ thuật né tránh: Tự động ẩn mình khỏi giao diện quản trị WordPress và các công cụ kiểm tra cập nhật, đồng thời sử dụng mã hóa thay thế (substitution cipher).
  • Lỗ hổng liên quan: Cảnh báo khai thác tích cực lỗ hổng SQL Injection nghiêm trọng CVE-2026-1581 trong plugin wpForo Forum.

1. Bối cảnh & Tổng quan về mã độc SC

Các chuyên gia an ninh mạng tại Sucuri vừa công bố báo cáo chi tiết về một chiến dịch tấn công WordPress tinh vi, nơi kẻ tấn công triển khai nhiều cơ chế duy trì sự hiện diện (persistence mechanisms) nhằm đảm bảo mã độc luôn tồn tại ngay cả khi quản trị viên đã thực hiện các biện pháp làm sạch thủ công. Mã độc này được định danh là SC, dựa trên các tiền tố 'SC_' xuất hiện trong các đoạn mã được tiêm vào hệ thống.

Điểm đáng chú ý nhất của mã độc này là kiến trúc 'self-healing mesh' (lưới tự phục hồi). Thay vì dựa vào một file duy nhất, mã độc phân tán payload của nó trên nhiều thành phần của WordPress, bao gồm các file hệ thống, cơ sở dữ liệu và phân đoạn bộ nhớ chia sẻ (System V shared memory). Điều này tạo ra một hệ thống tuần hoàn mà tại đó, bất kỳ thành phần nào bị xóa đều có thể được tái tạo bởi các thành phần còn lại.

2. Phân tích Kỹ thuật & Chuỗi Khai thác (Kill Chain)

Mã độc SC không sử dụng các tên hàm dễ đọc mà thay vào đó là một bộ giải mã (decoder) sử dụng mật mã thay thế để khôi phục mã nguồn thực thi. Dưới đây là 8 thành phần cốt lõi tạo nên hệ thống này:

  • .user.ini: Thiết lập chỉ thị auto_prepend_file để ép buộc tải loader trước mọi yêu cầu PHP trong thư mục.
  • wp-content/c1b12371.php: Loader chính thực hiện việc kiểm tra và bao gồm file ẩn có tiền tố dấu chấm.
  • wp-content/.c1b12371.php: File ẩn đóng vai trò giai đoạn 1, tìm kiếm và tái tạo plugin giả mạo trong thư mục mu-plugins.
  • wp-content/db.php: Chứa toàn bộ payload đã được nén và mã hóa Base64, tự động triển khai lại plugin nếu bị thiếu.
  • wp-content/advanced-cache.php: Tận dụng cơ chế cache của WordPress để tái tạo plugin từ 5 nguồn độc lập, bao gồm cả bộ nhớ RAM.
  • wp-content/themes/khorshidi/functions.php: Bản sao của db.php nằm trong theme, đảm bảo tính dự phòng.
  • wp-content/mu-plugins/hyper-engine-kit.php: Payload thực thi chính được cài đặt dưới dạng must-use plugin.
  • wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php: Bản sao dự phòng của payload chính.

Theo khung MITRE ATT&CK, chiến dịch này thể hiện các kỹ thuật như T1547.001 (Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder - trong ngữ cảnh WordPress là mu-plugins), T1059.003 (Command and Scripting Interpreter: Windows Command Shell/PHP), và T1071.004 (Application Layer Protocol: DNS/Blockchain).

3. Dấu hiệu Nhận biết & Bảng Chỉ số IOCs

Việc phát hiện mã độc SC đòi hỏi sự kiểm tra kỹ lưỡng các file hệ thống và bộ nhớ. Dưới đây là các chỉ số cần lưu ý:

Loại thực thểGiá trị / Chỉ sốMô tả tác động
File Pathwp-content/c1b12371.phpLoader chính của mã độc
File Pathwp-content/db.phpPayload nén và mã hóa Base64
File Pathwp-content/mu-plugins/hyper-engine-kit.phpPayload thực thi chính
Lỗ hổngCVE-2026-1581SQLi trong wpForo Forum (CVSS 7.5)
⚠️ Cảnh báo quan trọng: Trên các máy chủ hỗ trợ System V shared memory, payload được lưu trữ trực tiếp trong RAM. Điều này có nghĩa là ngay cả khi bạn xóa sạch file trên ổ cứng và làm sạch cơ sở dữ liệu, mã độc vẫn có thể tồn tại trong bộ nhớ và tái nhiễm hệ thống ngay khi có yêu cầu truy cập trang web tiếp theo.

4. Hướng dẫn Phát hiện & Săn tìm mối đe dọa

Để phát hiện sự hiện diện của mã độc SC, quản trị viên cần thực hiện quét các file có cấu trúc bất thường và kiểm tra các hook cron. Dưới đây là ví dụ về truy vấn kiểm tra các file có khả năng bị tiêm mã:

# Tìm kiếm các file có tiền tố dấu chấm trong thư mục wp-content nghi vấn 24 giờ qua 

Ngoài ra, cần kiểm tra các hook cron không xác định bằng cách sử dụng WP-CLI:

wp cron event list --fields=hook,next_run_relative

5. Biện pháp Khắc phục & Khuyến nghị Phòng thủ

Để bảo vệ hệ thống khỏi các cuộc tấn công tương tự, cần áp dụng các biện pháp hardening nghiêm ngặt:

  • Cập nhật phần mềm: Ngay lập tức cập nhật plugin wpForo Forum lên phiên bản mới nhất để vá lỗ hổng CVE-2026-1581.
  • Phân quyền file: Thiết lập quyền truy cập file nghiêm ngặt (ví dụ: 644 cho file, 755 cho thư mục) và đảm bảo người dùng web không có quyền ghi vào các thư mục nhạy cảm.
  • Giám sát tính toàn vẹn: Sử dụng các công cụ File Integrity Monitoring (FIM) để phát hiện thay đổi trái phép trong thư mục mu-plugins và các file drop-in như db.php.
  • Hardening PHP: Vô hiệu hóa các hàm nguy hiểm trong php.ini như exec, passthru, shell_exec nếu không cần thiết.
  • Kiểm tra định kỳ: Thực hiện quét mã độc định kỳ bằng các giải pháp bảo mật chuyên dụng để phát hiện các payload ẩn trong bộ nhớ hoặc cơ sở dữ liệu.

Tham khảo thêm thông tin chi tiết về các lỗ hổng WordPress tại National Vulnerability Database (NVD) để cập nhật các bản vá mới nhất cho hệ thống của bạn.

Tổng hợp, và phân tích kỹ thuật từ:The Hacker News
Xem bài gốc

Mạng Lưới An Ninh Mạng & Cộng Đồng

24/7 Alerts

Nhận cảnh báo 0-Day khẩn cấp, phân tích mã độc và tham gia thảo luận kỹ thuật cùng chuyên gia.

RSS Source

Ban biên tập nội dung và phân tích an ninh mạng tại ADSECVN.COM.

Bài Viết Liên Quan

Cùng chuyên mục & chủ đề