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:

Delete malicious users and reassign content:

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

Force password reset for all legitimate users.
Scan public_html for recent backdoor PHP files.
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.

This post is licensed under CC BY-NC.