Cách quét mã độc WordPress và xử lý malware triệt để bằng Ai Agent

Cách quét mã độc WordPress và xử lý malware triệt để bằng Ai Agent

SEO / WordPress Security Tool
Cách quét mã độc WordPress và xử lý malware triệt để bằng AI Agent
Khi một website WordPress bị nghi nhiễm mã độc, vấn đề không chỉ là xóa vài file lạ. Malware thường nằm rải rác ở source code, database, log máy chủ, cron job, user lạ và cả các file ẩn trong wp-content. Trang công cụ này được tạo ra để giúp team kỹ thuật xử lý theo đúng quy trình, giảm bỏ sót và hạn chế bị hack lại sau khi dọn xong.

Công cụ này dùng để làm gì?

Đây là checklist thực chiến dành cho team đang xử lý một website WordPress nghi bị tấn công. Nó dẫn người dùng qua 3 giai đoạn: xác nhận trách nhiệm, chẩn đoán bằng AI scan local, và xử lý sự cố theo thứ tự hợp lý. Mỗi bước đều có giải thích ngắn gọn và prompt mẫu để đưa cho AI Agent đọc trực tiếp source code, database hoặc access log.

Xác định site có thuộc phạm vi xử lý hay không trước khi bắt đầu.
Thu thập source code, database và log về máy local để AI Agent quét.
Phát hiện file độc hại, user lạ, cron job và các dấu hiệu persistence còn sót lại.

Vì sao nên dùng AI Agent để quét malware WordPress?

Phần lớn sự cố WordPress không nằm ở một file duy nhất. Hacker có thể chèn backdoor vào theme, ẩn shell trong uploads, tạo user admin mới trong database hoặc gắn redirect trong option. Nếu kiểm tra thủ công, rất dễ bỏ sót vì dữ liệu quá nhiều. AI Agent giúp đọc nhanh toàn bộ workspace local và tóm ra các điểm đáng nghi theo đúng format.

Quy trình chính trong checklist

Giai đoạn A: Xác nhận website có thuộc trách nhiệm xử lý của team hay không.
Giai đoạn B: Scan source code, database và access log bằng AI Agent.
Giai đoạn C: Backup, khóa website, đổi credential, reset core, quét wp-content, xoá user lạ, kiểm cron job và bàn giao.

Điểm khác biệt của công cụ

Trang này không chỉ liệt kê việc cần làm. Nó còn theo dõi tiến độ xử lý, cung cấp prompt mẫu có sẵn, gợi ý những file và bảng dữ liệu cần ưu tiên, đồng thời giúp team không quên các bước quan trọng như đổi password database, kiểm tra cron job hay xác nhận lại Google Search Console sau khi làm sạch.

Khi nào nên dùng?

Website tự redirect hoặc báo cảnh báo bảo mật.
Có file PHP lạ trong uploads hoặc theme/plugin bị sửa bất thường.
Search Console, access log hoặc database xuất hiện dấu hiệu nhiễm bẩn.
Nói ngắn gọn, đây là một workflow hoàn chỉnh để xử lý malware WordPress theo hướng có hệ thống, giảm rủi ro bỏ sót backdoor và tăng khả năng làm sạch triệt để ngay từ lần đầu.
A
Giai đoạn A
Xác nhận trách nhiệm
Trước khi làm bất cứ điều gì, hỏi 2 câu này để chắc đây là việc của mình.
Câu hỏi xác nhận
A.01
Web đang được lưu trữ tại DPS không?
Nếu không phải DPS hosting thì có thể đây không phải việc của team mình. Hỏi ngay trước khi bắt tay vào làm.
Hỏi DevHỏi Kế toán
A.02
Web thuộc dự án đang chạy tại DPS không?
SEO, Ads… Nếu có dự án đang chạy thì team có trách nhiệm xử lý.
Hỏi AccountHỏi Kế toán
B
Giai đoạn B
Chẩn đoán & Scan
Thu thập artifact trước khi xử lý. Không có bước này thì không biết hack từ đâu vào, dọn xong vẫn bị lại.
Thu thập artifact & AI scan
B.01
Thu thập source, DB, log rồi cho AI agent quét local
Làm trong một vòng duy nhất: tải source code, database và log về máy; mở chúng trong IDE; rồi cho AI agent browse trực tiếp workspace local để scan.
iNếu source quá nặng, ưu tiên source root + wp-content + wp-config.php + .htaccess + index.php. Mục tiêu là giữ đủ evidence để agent đọc được toàn cảnh.
!Đây là bước chẩn đoán. Làm xong phải ra được: file nào nghi ngờ, DB rows nào dính, log nào cho thấy vector vào, và file/path nào có khả năng là điểm xâm nhập.
Prompt — Scan source code
Bạn là chuyên gia bảo mật WordPress. Tôi đã tải toàn bộ source code của một website WordPress nghi bị hack về máy và mở nó trong IDE. Hãy browse trực tiếp trong workspace local này.Hãy phân tích và trả về:1. FILE NGUY HIỂM – File chứa: eval(base64_decode), gzinflate, str_rot13, assert(), preg_replace /e, system(), exec(), passthru() – File .php nằm trong thư mục uploads/ (không bình thường) – File có tên ngẫu nhiên hoặc giả mạo tên WP core (vd: wp-logln.php, hello.php)2. FILE BỊ SỬA GẦN ĐÂY – Liệt kê file có timestamp modified bất thường so với phần còn lại – Ưu tiên: functions.php, wp-config.php, .htaccess, index.php3. MÃ ĐỘC CỤ THỂ – Trích đoạn code nghi ngờ, giải thích nó làm gì – Phân loại: backdoor shell / spam injector / redirect / credential stealer / cryptominer4. KẾT LUẬN VECTOR – Dựa vào vị trí và loại mã độc, vector tấn công có thể là gì? – Plugin/theme nào khả năng cao là điểm vào?Format: heading rõ ràng, mỗi file nguy hiểm ghi rõ path + dòng code + mức độ (CRITICAL / HIGH / MEDIUM).
Prompt — Scan database
Bạn là chuyên gia bảo mật WordPress. Tôi đã tải file SQL dump của một website nghi bị hack về máy và mở nó trong IDE. Hãy browse trực tiếp file local này.Hãy phân tích các bảng sau và trả về:1. wp_options – siteurl, home có bị đổi hoặc chèn redirect không? – active_plugins có plugin lạ không (path bất thường, plugin không tồn tại trong wp-content)? – Có option nào chứa base64, eval, iframe, <script> lạ không? – admin_email có bị thay không?2. wp_posts / wp_postmeta – Bài viết nào chứa từ khoá spam (viagra, casino, pharma, 카지노, 薬)? – Bài viết nào có iframe ẩn, link ẩn (display:none, font-size:0)? – Post_status = publish nhưng không có title hoặc content bất thường?3. wp_users / wp_usermeta – User nào có role administrator được tạo gần đây? – user_registered timestamp bất thường? – Có user_login trông như bot không (chuỗi random, email fake)?4. KẾT LUẬN – Loại hack: Pharma hack / Japanese SEO hack / Backdoor user / Option inject? – Mức độ lây nhiễm: bao nhiêu bản ghi bị ảnh hưởng? – Cần làm gì để clean DB?Format: table cho danh sách user/option bị nhiễm, ghi rõ table + field + giá trị nghi ngờ.
Prompt — Scan access log
Bạn là chuyên gia bảo mật WordPress. Tôi đã tải file access log (và/hoặc error log) của web server về máy và mở nó trong IDE. Hãy browse trực tiếp file local này.Hãy phân tích và trả về:1. TIMELINE SỰ CỐ – Request đầu tiên có dấu hiệu tấn công xuất hiện lúc nào? – Chuỗi sự kiện từ scan → exploit → backdoor upload diễn ra thế nào?2. ENDPOINT BỊ KHAI THÁC – xmlrpc.php: có bị brute force hoặc multicall abuse không? – wp-login.php: volume request bất thường? – admin-ajax.php: action lạ không? – Upload endpoint: có file PHP nào được upload thành công không? – URL nào trả về 200 nhưng trông như shell path?3. IP TẤN CÔNG – IP nào có hành vi bất thường (scan nhiều path, POST liên tục)? – Liệt kê top 10 IP đáng ngờ + số request + hành vi4. DẤU HIỆU PERSISTENCE – Sau lần tấn công đầu, có request tiếp theo đến file backdoor không? – Hacker quay lại bao nhiêu lần, từ IP nào?5. KẾT LUẬN VECTOR – Vector tấn công xác suất cao nhất dựa trên log là gì? – Plugin/path nào là điểm vào?Format: timeline dạng chronological, IP list dạng table, endpoint dạng list với HTTP method + status code.
Xác nhận bảo vệ hiện tại
B.02
Kiểm tra plugin DPS Shield WordPress Security
Truy cập tênweb.com/admindps để kiểm tra. Vào được = đã cài DPS Shield. Không vào được = chưa cài.
!Không có DPS Shield = nguy cơ bị hack tới 80%. Đây là plugin bảo mật nội bộ của DPS.
iTải plugin tại:
github.com/hienhoceo-dpsmedia/dps-wordpress-security
B.03
Kiểm tra tường lửa/WAF phía server đã bật chưa
Kiểm tra WAF ứng dụng hoặc lớp lọc traffic phía server đã được bật và cấu hình đúng chưa.
+Có WAF phía server = giảm bớt traffic xấu trước khi vào WordPress.
C
Giai đoạn C
Các bước xử lý
Làm đúng thứ tự. Không bỏ bước. Mỗi bước đều có lý do cụ thể.
Chuẩn bị
C.01
Thông báo cho team biết
Báo để mọi người biết mình đang xử lý. Tránh đụng việc nhau hoặc cần ai đó phối hợp.
C.02
Backup source code và database
Backup toàn bộ trước khi động vào bất cứ thứ gì. Nếu chưa có UpdraftPlus thì backup thủ công qua Hosting Panel.
iDù web đang nhiễm, vẫn cần giữ lại bản gốc để đối chiếu hoặc khôi phục nội dung. Bước này khác với B.01–B.02 — đây là backup lưu trữ, không phải để scan.
C.03
Khoá website lại (Suspend)
Vào Hosting Panel hoặc Script VPS, suspend/khoá domain lại.
iHacker không thể tiếp tục truy cập trong lúc mình đang xử lý. Làm bước này ngay trước khi tiếp tục.
Can thiệp máy chủ
C.04
Restart PHP
CyberPanel: Đổi sang version PHP khác rồi đổi lại version cũ.
cPanel: Tương tự, đổi qua lại.
iLệnh này buộc máy chủ kill toàn bộ tiến trình PHP đang chạy trong RAM, cắt đứt kết nối hacker đang chạy ngầm.
C.05
Đổi mật khẩu Database
Tạo mật khẩu mới cho database, cập nhật ngay vào file wp-config.php.
iHacker thường lưu lại thông tin database để vào lại sau. Đổi pass chặn đứt con đường đó.
C.06
Đổi mật khẩu FTP / SFTP / SSH
Đổi toàn bộ credential truy cập file system: FTP account trong Hosting Panel, SSH key hoặc password nếu dùng VPS trực tiếp.
!Rất nhiều case hack WordPress đến từ FTP credential bị leak (malware trên máy client, credential cũ chưa đổi). Đổi DB password mà không đổi FTP thì hacker vào lại ngay.
Làm sạch mã nguồn
C.07
Kiểm tra wp-config.php
Mở wp-config.php ra đọc kỹ: kiểm tra đầu file và cuối file xem có đoạn code lạ, eval, base64, include bất thường không. Không cần kiểm tra .htaccess vì bước C.08 reset WP sẽ xoá và C.17 Save Permalink sẽ tạo lại file sạch.
!wp-config.php là file dễ bị chèn mã độc nhất. Xác nhận sạch trước khi tiếp tục.
C.08
Reset mã nguồn WordPress về phiên bản mới nhất
Xoá toàn bộ file WordPress cũ, cài lại sạch phiên bản mới nhất.
+Giữ lại: thư mục wp-content, file wp-config.php, và các subdirectory website khác nếu có.
C.09
Tải wp-content về và cho AI agent quét toàn bộ
Tải toàn bộ thư mục wp-content về máy rồi cho AI agent (Claude, Codex, Gemini) quét. Phạm vi scan bao gồm:
uploads/ — tìm file .php ẩn trong ảnh/media
themes/ — cả theme đang dùng và theme không dùng
plugins/ — tất cả plugin, kể cả plugin đang deactivate
mu-plugins/ — thường bị bỏ qua nhất
• Drop-in files: advanced-cache.php, object-cache.php, db.php
iYêu cầu agent tìm: eval, base64_decode, gzinflate, shell_exec, assert, system, exec, passthru, preg_replace /e. Mở từng file hit để xác minh thủ công.
!WP core reset không đụng đến wp-content. Đây là nơi dễ còn sót shell, drop-in và persistence nhất.
C.10
Tạo Security Key và Salt mới
Vào link: https://api.wordpress.org/secret-key/1.1/salt/
Copy toàn bộ, dán vào wp-config.php thay đoạn cũ.
iTất cả user đang đăng nhập sẽ bị logout ra ngay, kể cả hacker.
C.11
Xoá theme và plugin không dùng
Dọn sạch mọi thứ không cần thiết trong WordPress. Bao gồm cả theme mặc định (Twenty*) nếu không dùng.
iÍt code hơn = ít lỗ hổng hơn. Mỗi plugin không dùng là một điểm yếu tiềm ẩn.
C.12
Reset file permissions
Chạy 3 lệnh sau qua SSH hoặc Terminal trong Hosting Panel:
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 600 wp-config.php
iFile permission sai (777) là nguyên nhân phổ biến khiến script độc có thể tự ghi vào server. Reset về chuẩn trước khi mở lại web.
User & Access control
C.13
Xoá user lạ trong database
Vào phpMyAdmin → bảng wp_users, xoá user lạ không thuộc team. Đối chiếu với danh sách user mà agent đã báo ở B.05. Làm bước này trước khi mở lại web để chắc chắn không còn admin lạ.
!Nếu làm sau khi unsuspend, hacker có thể login lại ngay trong khoảng thời gian web đang mở mà user lạ vẫn còn.
C.14
Tắt đăng ký tự do (open registration)
Vào Settings → General, bỏ tick “Anyone can register”. Nếu web không cần tính năng đăng ký thì tắt hẳn.
!Open registration cho phép bot tạo user tự động, là bước đầu của nhiều loại tấn công leo thang quyền hạn.
C.15
Đổi mật khẩu tất cả tài khoản admin
Đổi mật khẩu mạnh cho toàn bộ tài khoản administrator. Dùng password manager để tạo mật khẩu ngẫu nhiên dài 20+ ký tự.
iKết hợp với Security Key mới ở C.10, toàn bộ session cũ kể cả của hacker đều hết hiệu lực.
Khôi phục và cấu hình
C.16
Mở lại website (Unsuspend)
Vào Hosting Panel, unsuspend domain. Website hoạt động trở lại. Chỉ làm bước này sau khi đã xoá user lạ (C.13) và đổi pass admin (C.15).
C.17
Save Permalink
Vào WP Admin, vào Settings > Permalinks, nhấn Save Changes.
iReset WordPress làm mất file .htaccess. Save permalink tạo lại file này. Các plugin bảo mật cần .htaccess mới chạy được.
C.18
Cài lại plugin bảo mật cần thiết
Cài phiên bản mới nhất và cấu hình lại đầy đủ. Ưu tiên cài DPS Shield trước vì cần .htaccess từ bước trước.
DPS Shield SecurityUpdraftPlusLiteSpeed Cache
C.19
Cập nhật theme và plugin còn lại
!Cẩn thận khi update. Có thể gây xung đột phiên bản và làm web lỗi. Test kỹ sau khi update từng plugin.
C.20
Kiểm tra cron job / scheduled tasks
Kiểm tra WP Admin > Tools > Scheduled Actions hoặc chạy wp cron event list để tìm job lạ, job tự kích hoạt lại mã độc.
!Hacker thường cài WP-cron hoặc server cron để tải lại shell sau khi bị xoá. Đây là cơ chế persistence phổ biến nhất.
C.21
Kiểm tra subdirectory cùng cấp
Kiểm tra xem có website khác nằm trong cùng thư mục cha không. Nếu có, các web đó cũng có nguy cơ bị lây nhiễm.
!Các thư mục cùng cấp không có open_basedir bảo vệ. Hack ở web này lây ngay sang các web khác cùng thư mục cha.
Hậu kiểm và bàn giao
C.22
Verify / test web hoạt động bình thường
Trước khi báo client, tự kiểm tra nhanh:
• Load trang chủ bình thường, không còn cảnh báo đỏ của Chrome/browser
• Truy cập một vài trang nội dung, không bị redirect lạ
• Login WP Admin được
• Các chức năng chính (form, menu, search) hoạt động đúng
• Kiểm tra trên mobile
!Đừng báo client khi chưa tự verify xong. Reset WP đôi khi làm vỡ layout hoặc mất permalink nếu bỏ sót bước nào đó.
C.23
Xác nhận Google Search Console
Kiểm tra Google Search Console xem web còn bị đánh dấu nguy hiểm không, rồi gửi request review sau khi đã xử lý xong.
iNếu web bị hack lâu, Google có thể vẫn hiển thị cảnh báo dù site đã sạch. Review là bước bắt buộc để gỡ cảnh báo.
C.24
Thông báo client / stakeholder
Báo cho client hoặc stakeholder biết tình trạng sự cố, những bước đã xử lý, và các điểm cần theo dõi tiếp theo.
!Nếu đây là web khách hàng, không chỉ báo team nội bộ. Cần cập nhật kết quả xử lý và trạng thái an toàn cho người phụ trách.
Tiến độ xử lý
Hoàn thành!
Báo senior kiểm tra trước khi đóng ticket.
0 / 29 mục
Chưa bắt đầu
A Xác nhận 0/2
B Chẩn đoán 0/3
C Xử lý 0/24
Hoạt động gần đây
Chưa có hoạt động nào.