How to scan WordPress malware and handle it thoroughly with AI Agent

How to scan WordPress malware and handle it thoroughly with AI Agent

SEO / WordPress Security Tool
How to scan WordPress malware and thoroughly handle malware using an AI Agent
When a WordPress website is suspected of being infected with malware, the issue is not just deleting a few strange files. Malware is often scattered across source code, database, server logs, cron jobs, suspicious users, and even hidden files in wp-content. This tool page was created to help the technical team follow the correct process, reduce oversights, and limit reinfection after cleanup.

What is this tool used for?

This is a practical checklist for teams handling a WordPress website suspected of being attacked. It guides users through 3 stages: responsibility confirmation, diagnosis using local AI scan, and incident handling in a logical order. Each step includes a brief explanation and sample prompts for the AI Agent to directly read source code, database, or access logs.

Determine whether the site falls within the team’s responsibility before starting.
Collect source code, database, and logs to a local machine for the AI Agent to scan.
Detect malicious files, suspicious users, cron jobs, and remaining persistence indicators.

Why use an AI Agent to scan WordPress malware?

Most WordPress incidents are not located in a single file. Hackers may insert backdoors into themes, hide shells in uploads, create new admin users in the database, or attach redirects in options. Manual inspection can easily miss issues due to the large amount of data. AI Agent helps quickly read the entire local workspace and summarize suspicious points in a structured format.

Main process in the checklist

Phase A: Confirm whether the website is under the team’s responsibility.
Phase B: Scan source code, database, and access logs using an AI Agent.
Phase C: Backup, lock the website, change credentials, reset core, scan wp-content, delete suspicious users, check cron jobs, and hand over.

Key differences of the tool

This page not only lists tasks. It also tracks processing progress, provides ready-made sample prompts, suggests priority files and database tables, and helps the team not forget important steps such as changing database passwords, checking cron jobs, or re-verifying Google Search Console after cleanup.

When to use?

Website automatically redirects or shows security warnings.
There are unusual PHP files in uploads or theme/plugin files have been abnormally modified.
Search Console, access logs, or database show signs of contamination.
In short, this is a complete workflow to handle WordPress malware systematically, reduce the risk of missing backdoors, and increase the likelihood of thorough cleanup from the first attempt.
A
Phase A
Confirm responsibility
Before doing anything, ask these 2 questions to ensure this is your task.
Confirmation questions
A.01
Is the web hosted at DPS?
If it's not DPS hosting, this might not be our team's task. Ask immediately before getting started.
Ask DevAsk Accounting
A.02
Does the web belong to a project running at DPS?
SEO, Ads… If there is a running project, the team is responsible for handling it.
Ask AccountAsk Accounting
B
Phase B
Diagnosis & Scan
Collect artifacts before processing. Without this step, you won't know how it was hacked, and it will happen again after cleaning.
Collect artifacts & AI scan
B.01
Collect source, DB, logs, then let the AI agent scan locally
Do it in a single loop: download source code, database, and logs to your machine; open them in an IDE; then let the AI agent browse the local workspace directly to scan.
iIf the source is too heavy, prioritize source root + wp-content + wp-config.php + .htaccess + index.php. The goal is to keep enough evidence for the agent to read the full picture.
!This is the diagnostic step. After finishing, you must identify: which files are suspicious, which DB rows are infected, which logs show the entry vector, and which files/paths are likely entry points.
Prompt — Scan source code
You are a WordPress security expert. I have downloaded the entire source code of a suspected hacked WordPress website to my machine and opened it in an IDE. Please browse directly in this local workspace.\n\nPlease analyze and return:\n\n1. DANGEROUS FILES\n – Files containing: eval(base64_decode), gzinflate, str_rot13, assert(), preg_replace /e, system(), exec(), passthru()\n – .php files located in the uploads/ folder (unusual)\n – Files with random names or fake WP core names (e.g., wp-logln.php, hello.php)\n\n2. RECENTLY MODIFIED FILES\n – List files with unusual modified timestamps compared to the rest\n – Priority: functions.php, wp-config.php, .htaccess, index.php\n\n3. SPECIFIC MALWARE\n – Suspected code snippets, explaining what they do\n – Classification: backdoor shell / spam injector / redirect / credential stealer / cryptominer\n\n4. VECTOR CONCLUSION\n – Based on the location and type of malware, what could the attack vector be?\n – Which plugin/theme is likely the entry point?\n\nFormat: clear headings, for each dangerous file specify path + code line + severity (CRITICAL / HIGH / MEDIUM).
Prompt — Scan database
You are a WordPress security expert. I have downloaded the SQL dump file of a suspected hacked website to my machine and opened it in an IDE. Please browse this local file directly.\n\nPlease analyze the following tables and return:\n\n1. wp_options\n – Have siteurl or home been changed or had redirects inserted?\n – Are there suspicious plugins in active_plugins (unusual paths, non-existent plugins in wp-content)?\n – Are there any options containing suspicious base64, eval, iframe, or ?\n – Has admin_email been changed?\n\n2. wp_posts / wp_postmeta\n – Which posts contain spam keywords (viagra, casino, pharma, 카지노, 薬)?\n – Which posts have hidden iframes or hidden links (display:none, font-size:0)?\n – Post_status = publish but no title or unusual content?\n\n3. wp_users / wp_usermeta\n – Which users with the administrator role were recently created?\n – Unusual user_registered timestamps?\n – Are there user_logins that look like bots (random strings, fake emails)?\n\n4. CONCLUSION\n – Hack type: Pharma hack / Japanese SEO hack / Backdoor user / Option inject?\n – Infection level: how many records are affected?\n – What needs to be done to clean the DB?\n\nFormat: table for the list of infected users/options, clearly stating table + field + suspicious value.
Prompt — Scan access log
You are a WordPress security expert. I have downloaded the access log (and/or error log) file of the web server to my machine and opened it in an IDE. Please browse this local file directly.\n\nPlease analyze and return:\n\n1. INCIDENT TIMELINE\n – When did the first request showing signs of attack appear?\n – What was the sequence of events from scan → exploit → backdoor upload?\n\n2. EXPLOITED ENDPOINTS\n – xmlrpc.php: is there brute force or multicall abuse?\n – wp-login.php: unusual request volume?\n – admin-ajax.php: suspicious actions?\n – Upload endpoint: were any PHP files successfully uploaded?\n – Which URLs returned 200 but look like shell paths?\n\n3. ATTACKING IPS\n – Which IPs showed unusual behavior (scanning multiple paths, continuous POST)?\n – List the top 10 suspicious IPs + number of requests + behavior\n\n4. PERSISTENCE SIGNS\n – After the initial attack, were there subsequent requests to backdoor files?\n – How many times did the hacker return, and from which IPs?\n\n5. VECTOR CONCLUSION\n – What is the most probable attack vector based on the logs?\n – Which plugin/path is the entry point?\n\nFormat: chronological timeline, IP list in table format, endpoints as a list with HTTP method + status code.
Confirm current protection
B.02
Check the DPS Shield WordPress Security plugin
Access websitename.com/admindps to check. Able to access = DPS Shield is installed. Unable to access = not installed.
!No DPS Shield = up to 80% risk of being hacked. This is DPS's internal security plugin.
iDownload plugin at:
github.com/hienhoceo-dpsmedia/dps-wordpress-security
B.03
Check if server-side firewall/WAF is enabled
Check if the application WAF or server-side traffic filtering layer is enabled and configured correctly.
+Server-side WAF = reduces bad traffic before it reaches WordPress.
C
Phase C
Processing steps
Follow the correct order. Do not skip steps. Each step has a specific reason.
Preparation
C.01
Notify the team
Inform everyone so they know you are handling it. Avoid overlapping work or needing someone to coordinate.
C.02
Backup source code and database
Backup everything before touching anything. If UpdraftPlus is not available, backup manually via the Hosting Panel.
iEven if the web is infected, you still need to keep the original copy for comparison or content recovery. This step is different from B.01–B.02 — this is storage backup, not for scanning.
C.03
Lock the website (Suspend)
Go to Hosting Panel or VPS Script, suspend/lock the domain.
iThe hacker cannot continue to access while you are processing. Do this step right before continuing.
Server intervention
C.04
Restart PHP
CyberPanel: Switch to a different PHP version then switch back to the old version.
cPanel: Similarly, switch back and forth.
iThis command forces the server to kill all PHP processes running in RAM, cutting off background connections from hackers.
C.05
Change Database password
Create a new password for the database, update it immediately in the file wp-config.php.
iHackers often save database info to return later. Changing the password cuts off that route.
C.06
Change FTP / SFTP / SSH password
Change all file system access credentials: FTP accounts in Hosting Panel, SSH keys or passwords if using VPS directly.
!Many WordPress hack cases come from leaked FTP credentials (malware on client machines, old credentials not changed). Changing the DB password without changing FTP allows the hacker to get back in immediately.
Clean source code
C.07
Check wp-config.php
Open wp-config.php Read carefully: check the beginning and end of files for strange code segments, eval, base64, or unusual includes. No need to check .htaccess because step C.08 (WP reset) will delete it and C.17 (Save Permalink) will recreate a clean file.
!wp-config.php is the file most susceptible to malware injection. Confirm it is clean before proceeding.
C.08
Reset WordPress source code to the latest version
Delete all old WordPress files, reinstall a clean version of the latest release.
+Keep: the folder wp-content, file wp-config.php, and other website subdirectories if any.
C.09
Download wp-content and have an AI agent scan everything
Download the entire directory wp-content to your computer and have an AI agent (Claude, Codex, Gemini) scan it. The scan scope includes:
uploads/ — find hidden .php files in images/media
themes/ — both active and inactive themes
plugins/ — all plugins, including deactivated ones
mu-plugins/ — the most commonly overlooked location
• Drop-in files: advanced-cache.php, object-cache.php, db.php
iAsk the agent to find: eval, base64_decode, gzinflate, shell_exec, assert, system, exec, passthru, preg_replace /e. Open each hit file to verify manually.
!The WP core reset does not touch wp-content. This is where shells, drop-ins, and persistence mechanisms are most likely to remain.
C.10
Generate new Security Keys and Salt
Go to the link: https://api.wordpress.org/secret-key/1.1/salt/
Copy everything, paste into wp-config.php replacing the old section.
iAll currently logged-in users will be logged out immediately, including hackers.
C.11
Delete unused themes and plugins
Clean up everything unnecessary in WordPress. This includes default themes (Twenty*) if not in use.
iLess code = fewer vulnerabilities. Every unused plugin is a potential weak point.
C.12
Reset file permissions
Run the following 3 commands via SSH or Terminal in the Hosting Panel:
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 600 wp-config.php
iIncorrect file permissions (777) are a common reason malicious scripts can write themselves to the server. Reset to standard before reopening the site.
User & Access control
C.13
Delete suspicious users in the database
Go to phpMyAdmin → table wp_users, delete any strange users not belonging to the team. Cross-check with the user list reported by the agent in B.05. Do this before reopening the site to ensure no unauthorized admins remain.
!If done after unsuspending, a hacker could log back in immediately during the window while the site is open and the unauthorized user still exists.
C.14
Disable open registration
Go to Settings → General, uncheck “Anyone can register”. If the site does not need a registration feature, disable it entirely.
!Open registration allows bots to create users automatically, which is the first step in many privilege escalation attacks.
C.15
Change all admin account passwords
Change all administrator accounts to strong passwords. Use a password manager to generate random passwords of 20+ characters.
iCombined with the new Security Keys in C.10, all old sessions—including the hacker's—will be invalidated.
Restore and configure
C.16
Reopen the website (Unsuspend)
Go to the Hosting Panel and unsuspend the domain. The website is now live. Only perform this step after deleting suspicious users (C.13) and changing admin passwords (C.15).
C.17
Save Permalink
Go to WP Admin, go to Settings > Permalinks, click Save Changes.
iResetting WordPress causes the loss of the .htaccess. file. Saving permalinks recreates this file. Security plugins require .htaccess to function properly.
C.18
Reinstall necessary security plugins
Install the latest versions and configure them fully. Prioritize installing DPS Shield first as it requires the .htaccess from the previous step.
DPS Shield SecurityUpdraftPlusLiteSpeed Cache
C.19
Update remaining themes and plugins
!Be careful when updating. It may cause version conflicts and break the site. Test thoroughly after updating each plugin.
C.20
Check cron jobs / scheduled tasks
Check WP Admin > Tools > Scheduled Actions or run wp cron event list to find suspicious jobs or jobs that reactivate malware.
!Hackers often install WP-cron or server cron to reload shells after they have been deleted. This is the most common persistence mechanism.
C.21
Check peer subdirectories
Check if there are other websites located in the same parent directory. If so, those websites are also at risk of infection.
!Peer directories do not have open_basedir protection. A hack on this website can immediately spread to other websites in the same parent directory.
Post-inspection and handover
C.22
Verify / test that the website is operating normally
Before notifying the client, perform a quick self-check:
• Home page loads normally, no red warnings from Chrome/browser
• Access a few content pages, no strange redirects
• Able to log in to WP Admin
• Main functions (form, menu, search) work correctly
• Check on mobile
!Do not notify the client before completing self-verification. Resetting WP sometimes breaks the layout or loses permalinks if any step is missed.
C.23
Confirm Google Search Console
Check Google Search Console to see if the website is still marked as dangerous, then submit a review request after processing is complete.
iIf the website has been hacked for a long time, Google may still display warnings even if the site is clean. Reviewing is a mandatory step to remove warnings.
C.24
Notify client / stakeholder
Inform the client or stakeholder about the status of the incident, the steps taken, and the points to monitor next.
!If this is a client's website, do not just notify the internal team. You need to update the processing results and safety status for the person in charge.
Processing progress
Completed!
Ask a senior to check before closing the ticket.
0 / 29 items
Not started yet
A Confirm 0/2
B Diagnosis 0/3
C Processing 0/24
Recent activity
No activity yet.