PHP backdoor hoặc mã độc nằm trong wp-config.php, .htaccess, index.php hay một file bootstrap/configuration có mức độ ảnh hưởng đặc biệt vì các file này thường được đọc rất sớm hoặc tác động tới phần lớn request. Chỉ cần một đoạn include, redirect rule hoặc loader trái phép cũng có thể làm malware chạy lại trên nhiều page dù plugin/theme nhìn bề ngoài đã sạch.
WordPress xác nhận wp-config.php chứa các thông tin cấu hình quan trọng như database credentials và security keys, đồng thời khuyến nghị bảo vệ file này khỏi truy cập trái phép. Tài liệu xử lý website bị hack của WordPress cũng lưu ý các file như index.php, header.php, footer.php và functions.php thường bị sửa trong incident. CISA và OWASP đều ghi nhận PHP web shell/backdoor có thể được cài dưới tên hoặc vị trí nhìn giống file hợp lệ để duy trì execution. Nguồn: WordPress — Editing wp-config.php, WordPress — FAQ My Site Was Hacked, CISA — Web shell persistence example và OWASP WSTG — Web Shells.
Bối cảnh: website vẫn tái nhiễm dù plugin và theme đã được kiểm tra
Giả sử website đã remove plugin nghi ngờ, scan lại thư mục wp-content và không còn IOC rõ ràng. Tuy nhiên redirect hoặc malicious JavaScript vẫn quay lại. Diff tiếp theo phát hiện vài dòng PHP lạ được chèn gần đầu wp-config.php hoặc index.php, hoặc một rule bất thường trong .htaccess.
Vì sao config/bootstrap files là vị trí nhạy cảm?
wp-config.phpđược load trong bootstrap WordPress và chứa secrets quan trọng.index.phpthường nằm trên request path chính của site..htaccesscó thể thay đổi rewrite/redirect trước khi request vào WordPress.- Code chèn sớm có thể load file khác từ path ít được kiểm tra.
- Malware có thể masquerade bằng tên file hoặc location nhìn hợp lệ.
Bước 1: xác minh modification có hợp lệ hay không
Không nên coi mọi dòng khác baseline là malware. wp-config.php có thể chứa custom constants, caching, multisite, cron hoặc environment settings hợp lệ; .htaccess có thể được plugin cache/security chỉnh sửa. Investigation cần so sánh với trusted baseline, deployment artifact, backup hoặc configuration history.
Tham chiếu WordPress bị chèn mã độc vào wp-config.php, .htaccess hoặc index.php để xây baseline diff theo từng loại file.
Bước 2: đọc code path thay vì chỉ tìm chuỗi đáng ngờ
Một backdoor không nhất thiết chứa một signature dễ nhận biết. Cần đọc behavior: file có include path bất thường, fetch remote content, evaluate dynamic code, write file, alter redirect hoặc đọc secret không thuộc business logic hay không.
Những pattern cần escalation
include/requiretới file ẩn hoặc path không có owner.- Code obfuscated/encoded không thuộc package chuẩn.
- Remote fetch hoặc loader tới domain không rõ nguồn gốc.
- Dynamic execution hoặc command-execution primitive không có use case hợp lệ.
- Conditional redirect theo referrer, user-agent hoặc cookie.
- Đọc/ghi credential, salts hoặc config ngoài flow dự kiến.
OWASP lưu ý file inclusion và web shell có thể dẫn đến thực thi code khi server xử lý PHP. CISA cũng ghi nhận threat actors đặt web shell dưới tên có vẻ hợp lệ để giảm khả năng bị phát hiện.
Bước 3: xác định loader, payload và persistence chain
Một đoạn PHP ngắn trong wp-config.php có thể chỉ là loader cho payload nằm nơi khác. Vì vậy phải follow include chain: file nào được gọi, payload ở đâu, ai có quyền ghi, callback nào tái tạo file và có account/session/cron/MU-plugin liên quan hay không.
Nếu chỉ xóa loader mà payload hoặc cơ chế tái tạo còn tồn tại, website có thể tái nhiễm. Dùng case phát hiện Backdoor bằng File Integrity Monitoring để mở rộng scope khi có nhiều file liên quan.
Khi nào có thể xác nhận config file bị cài backdoor?
Confidence cao khi modification vừa không có owner hợp lệ vừa có behavior cho phép execution/persistence hoặc redirect trái phép.
- Diff không khớp trusted baseline hoặc change record.
- Code/path được gọi không thuộc WordPress, host hoặc deployment hiện hành.
- Behavior cho phép load/execute payload hoặc thay đổi request flow trái phép.
- Timestamp khớp incident window.
- Loại bỏ/quarantine loader làm malicious behavior dừng lại, sau khi alternate path được loại trừ.
Containment: preserve evidence trước khi sửa file sống

Config/bootstrap file là nơi dễ bị overwrite trong lúc khẩn cấp, nhưng thao tác quá sớm có thể phá evidence về loader path và root cause. Trước remediation nên lưu copy, hash, metadata, diff và các file được include nếu incident cần RCA.
Tham chiếu quy trình bảo toàn evidence khi website bị hack trước khi replace file hoặc rotate secret.
Eradication: rebuild trusted file và xử lý secret exposure
Không nên “clean bằng tay” một đoạn code rồi coi incident đã xong nếu file chứa secrets hoặc loader chain đã bị attacker đọc/ghi. Với wp-config.php, remediation có thể cần dựng lại file từ trusted configuration, thay database credential/security keys nếu có risk exposure và giảm file write permission theo deployment model.
- Replace compromised bootstrap/config file bằng trusted version.
- Remove loader/payload/include chain đã xác nhận malicious.
- Reinstall core/plugin/theme bị sửa từ trusted source.
- Rotate database/API/hosting secrets nếu evidence cho thấy có thể bị lộ.
- Patch/remove entry point và review account/session/persistence liên quan.
- Không dùng chmod 777 như “fix” cho lỗi permission sau cleanup.
Validation sau remediation
| Gate | Điều kiện PASS |
|---|---|
| Config/bootstrap integrity | Khớp trusted baseline và change record |
| Include chain | Không còn loader/payload trái phép |
| Secrets | Credential/key có risk đã được rotate |
| Permissions | Write access chỉ còn cho principal cần thiết |
| Request behavior | Không còn redirect/script trái phép |
| Persistence | Không tái xuất hiện artifact sau cleanup |
| Monitoring | Alert khi config/bootstrap file thay đổi ngoài window |
Bài học vận hành
- Config/bootstrap file bị sửa có blast radius lớn nhưng mismatch chưa tự động là malware.
- Điều tra phải follow code path và include chain, không chỉ grep signature.
wp-config.phpvừa là bootstrap config vừa chứa secrets nên cần xử lý integrity và credential exposure cùng lúc..htaccesscó thể thay đổi request flow trước WordPress.- Preserve evidence trước khi overwrite giúp giữ khả năng RCA.
- Closure chỉ nên xảy ra khi loader, payload, entry point và secret exposure đều được xử lý.
