Recently Created Administrators: A Compromise Indicator

Creating a new admin account is almost always the second step of an attacker who has just compromised a site — the first step is exploiting a vulnerability, and the second is establishing a way back in even if the existing password is rotated. Any administrator you do not recognize is a compromise indicator until proven otherwise, and even a "familiar" account created at 3 a.m. deserves a look.

Why this matters

An admin in WordPress can do everything: install plugins (and the malware bundled inside), edit theme files, register a webhook that exfiltrates content, change other administrators' email addresses, and download the full user database. When an attacker creates a secondary account after the initial breach, they are establishing persistent access — even if you detect the intrusion and rotate passwords, their new account is still there. Common names attackers pick: wpadmin, backup, support, seo-admin — names that look innocent on a quick scan.

How to detect

On Users > All Users, filter by "Administrator" and sort by registration date descending. Compare the list to your real staff. Warning signs: an email address on a domain that is not your organization (gmail/yandex/protonmail) for an account that should be internal, generic logins (admin, editor, seo), registration timestamps in unreasonable hours, last-login IP in a country your team does not work from.

Direct database query:

SELECT u.ID, u.user_login, u.user_email, u.user_registered, m.meta_value AS roles
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID AND m.meta_key = 'wp_capabilities'
WHERE m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

How to fix

If you identify a suspicious admin: demote them to Subscriber first (do not delete yet — you may need evidence for the investigation), then audit wp-content/plugins and wp-content/themes for unfamiliar PHP files. Only after the site is clean, delete the account and reassign their content to your own user. Rotate the salts in wp-config.php — this invalidates every existing session. Reset passwords for every legitimate admin, and rotating the database password is also wise.

// Log every new admin role grant — add as an mu-plugin
add_action('set_user_role', function ($user_id, $role) {
    if ($role === 'administrator') {
        error_log("[ADMIN-CREATED] User $user_id became admin at " . date('c') . " from IP " . $_SERVER['REMOTE_ADDR']);
    }
}, 10, 2);

Common mistakes

Mistake one: deleting the suspicious admin immediately without auditing the files. If a new admin was created, there is a backdoor that allowed it — deleting the account does not close the underlying hole. Mistake two: assuming "probably someone internal I forgot about". If you do not remember creating an account, you did not create it. Document admin creation, do not rationalize it. Mistake three: not rotating salts. Without invalidating sessions, the attacker's logged-in cookie still works after the account is gone (if they signed in before deletion). Mistake four: not enabling 2FA after the incident — if the first entry was via brute force or stuffed credentials, the next attempt will succeed identically without 2FA.

Verifying the fix

Run a full Wordfence or MalCare scan, not "Quick Scan". Inspect the wp_options table: SELECT option_value FROM wp_options WHERE option_name = 'active_plugins' — confirm every active plugin is one you recognize. Walk the .htaccess file for unexpected redirects. Twenty-four hours later, re-run the audit — if a new admin appears again, there is still a backdoor on the system.