WordPress forensic audit: how to identify malicious users via terminal (wp-cli and logs)

Unknown administrator accounts in WordPress are a strong compromise indicator. In forensic work, deleting the account is not enough. You need to determine when it appeared, how it accessed the system, and what it changed.

1) Php-cli vs php-cgi: common early mistake#

On multi-PHP servers (such as Plesk), using the wrong binary causes WP-CLI failures like 404 Not Found or No such file or directory.

Use the correct CLI binary for the site version:

/opt/plesk/php/8.2/bin/php /usr/local/bin/wp core version --allow-root

2) Audit admin users and look for attack patterns#

Start by listing all administrators:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --allow-root

Red flags:

• random-looking usernames (xtw18387...)
• suspicious or disposable email domains
• multiple admin users created in a very short time window

3) Use IDs as chronological evidence#

Dates can be forged. AUTO_INCREMENT IDs usually preserve insertion order.

If a trusted user has ID 2 and a suspicious user has ID 17 but claims an older registration date, user_registered was likely manipulated.

4) Inspect metadata and recent session traces#

WordPress does not store complete login history by default, but session_tokens may still expose IP, user-agent, and timestamp.

wp user meta get [USER_ID] session_tokens --allow-root

This helps correlate a suspicious account to real access origin.

5) Validate evidence with server access logs#

If database data is unreliable, Apache/Nginx logs are your black box. Check successful login flow via POST /wp-login.php followed by 302.

grep "POST /wp-login.php" /var/log/httpd/domains/domain.com.log | grep " 302 "

302 usually means authentication succeeded and redirect to dashboard occurred.

6) Incident response and remediation#

If compromise is confirmed:

1. Delete malicious users and reassign content:

wp user delete [ID] --reassign=[TRUSTED_ADMIN_ID] --allow-root

1. Force password reset for all legitimate users.
2. Scan public_html for recent backdoor PHP files.
3. Enable audit logging (for example, WP Activity Log / Simple History).

In WordPress forensics, GUI data is limited. Terminal evidence, WP-CLI output, and server logs provide the real timeline. Attackers can forge visible fields, but consistent metadata and access logs usually reveal the truth.

See also

WordPress WordPress Admin Locked Out: Forensic Diagnosis, Unblocking, and Access Recovery via WP-CLI and MySQL

Servers The mystery of deleted files: tracking removals across cPanel, FTP, and PHP application layers

WordPress Choosing WordPress Plugins Without Breaking Production: A SysAdmin Guide

This post is licensed under CC BY-NC.