How to Audit Unknown WordPress Admin Users After a Site Hack

Finding a WordPress administrator with an unfamiliar name or email address is a reason to investigate. It is not, by itself, enough to establish who created the account or when access was gained. The account could belong to an attacker, a former agency, a developer, a migration process, or a hosting installer. Deleting it immediately can destroy evidence, remove a legitimate owner, or leave content without the right author.

The short answer is: preserve the database and available logs, match every privileged account to an authorised owner, review roles and capabilities plus tokens and sessions, then revoke access that is confirmed as unauthorised and close the entry point. Do not stop at the Users screen: access may persist through an application password, plugin, hosting account, or another integration.

This guide covers the administrator-account audit when a WordPress compromise is suspected. For the wider incident response sequence, see what to do when a website is hacked. If you have only found comments or spam posts, first check whether there are unfamiliar users or system changes; our guide to WordPress spam comments helps distinguish those cases.

An unfamiliar account is not a complete incident record

WordPress stores user profiles, roles, registration times, and content associations. However, a standard installation does not provide a complete audit trail that always shows who created an account, the creator’s IP address, every role change, or the last login. That evidence may be available from an audit plugin already installed, hosting logs, a WAF, single sign-on, or organisational records, but it is not guaranteed.

Use multiple sources and label your confidence. The user_registered value is the stored registration time; it is not standalone proof of when an attacker obtained access. An unfamiliar email, random username, administrator role, or suspicious post is a lead to investigate, not attribution.

Start an inventory with:

• user ID, login name, display name, email, role and effective capabilities, and registration date;
• the person who claims the account and why the access is needed;
• related posts, pages, media, plugin or theme changes, and settings;
• active sessions and application passwords associated with the account;
• available hosting, panel, SFTP/SSH, WAF/CDN, SSO, and notification logs;
• recent changes, with timestamps and time zone.

Compare the list with staff, vendors, service accounts, migration accounts, and documented emergency users. If an account may have been created by a hosting or integration process, identify who owns that process before changing it.

Step 1: preserve evidence and contain active risk

Take a files-and-database backup and export available logs before deleting users, plugins, or records. Store the copy separately with limited access; do not upload a database dump to a public service because it may contain personal information and credential hashes. Record who collected it and when.

If an unknown account is actively adding pages, changing configuration, or creating more administrators, access must not remain open indefinitely just to preserve an investigation. After taking a minimum safe copy and notifying the site owner, restrict or revoke access through an approved method; coordinate with the host if it is managing the incident. Do not send passwords or secrets to an unverified party.

If the site is serving phishing, malware, or an unexpected redirect, limit exposure with the host or CDN. Our guide to malware symptoms on a WordPress site covers broader symptoms and containment. Do not test an unknown account’s password or email an address that may be controlled by an attacker.

Step 2: list every user and privileged account

In the dashboard, open Users → All Users and review every account, not just the newest one. The official WordPress Users Screen documentation explains how to manage the list. Record users with the Administrator role, but also check custom roles and capabilities granted by plugins. A built-in role label is not the only way a user can obtain privileged capabilities.

WP-CLI’s wp user list command lists Administrator-role accounts and useful fields for comparison:

wp user list --role=administrator --fields=ID,user_login,display_name,user_email,user_registered,roles

Run it only on the correct installation with authorised access. On a multisite network, specify the site you are checking and also review Network Admin → Users and the Super Admin list. Network users may have access that is not visible on one individual site. Do not assume every Administrator entry applies across the network.

Look for accounts whose roles changed, old accounts that became active again, email addresses that were redirected, and users with no current internal owner. Compare their effective access with their actual work. WordPress explains its built-in roles and capabilities in the official roles and capabilities documentation; plugins can add capabilities of their own.

Step 3: correlate activity without inventing a history WordPress does not keep

For each high-risk account, look for corroborating evidence:

• Does the organisation’s owner, staff, agency, or developer recognise the username, email, and reason for the role?
• Does the registration date align with a contract, migration, site launch, or support ticket?
• Did the account author unknown posts or pages, change the administrator email, install a plugin or theme, or alter settings?
• Do hosting or WAF logs show logins, file changes, or unusual requests in the same period?
• Could a known integration, single sign-on, backup restore, or automated setup explain the change?

WordPress core does not provide a reliable “last login” value on the Users screen. Do not rush to install an audit plugin and assume it can prove what happened before it existed. A new plugin only records activity after installation and adds another component to the site. Use systems that already had logs and preserve their retention window.

If the evidence is incomplete, label the account “unverified”, not automatically “attacker”. Continue with the related files, database, and credentials. Overstating certainty can make account deletion more dangerous.

Step 4: audit sessions, application passwords, and access beyond the dashboard

The main username and password are not the only credentials. WordPress application passwords allow integrations to authenticate to the REST API; the official REST API authentication guide explains this mechanism. Inventory the application name, owner, creation details, and whether the integration is still used. Do not copy or share the secret value.

WP-CLI can help review application credentials and end sessions. The commands below are administrative actions: confirm the backup, user ID, site, and target before running them:

# List application passwords for a specific user ID
wp user application-password list 42

# End every WordPress session belonging to that user
wp user session destroy 42 --all

# Revoke only an application password confirmed as unauthorised
wp user application-password delete 42 UUID

Replace 42 and UUID with the verified values. wp user session destroy ... --all signs that user out of all WordPress sessions, so consider the impact on a legitimate owner. Revoke application passwords individually after identifying any integration that must remain. See the WP-CLI documentation for application passwords and destroying a session.

Outside WordPress, review recovery email, the hosting panel, SFTP/SSH, database, CDN/DNS, CI/CD, webhook tokens, and agency access. If the administrator’s email or hosting panel is compromised, changing only the WordPress password leaves the account recovery path exposed.

Step 5: revoke, downgrade, or remove the account safely

After preserving a backup and checking ownership and content impact, choose the narrowest action that restores control:

• The account is legitimate but over-privileged: reduce its role or capabilities to the minimum needed and confirm the work still functions.
• The account is legitimate but no longer used: revoke access or remove it after transferring assets, integrations, and ownership.
• The account is confirmed as unauthorised: revoke its sessions, application passwords, related tokens, and permissions, then remove or disable it using an appropriate process.
• Ownership is unclear: restrict access temporarily with the site owner and host while you verify it. If harmful activity is ongoing, do not leave a privileged account active and unmonitored.

Before deleting a user, review associated posts, pages, media, comments, and other objects. Decide whether the content is part of cleanup or should be preserved and reassigned to a trusted user. With WP-CLI, wp user delete with --reassign=KNOWN_ID can reassign posts. On multisite, WP-CLI distinguishes removing a user from one site from using --network; do not remove someone from the whole network without the network owner’s approval. Do not delete the only trusted Administrator or Super Admin before testing a replacement account.

Step 6: close the source that could recreate the account

An unknown administrator can be persistence, rather than the original entry point. Investigate how it was created and review:

• vulnerable or nulled plugins and themes, outdated WordPress, changed files, and must-use plugins;
• endpoints, scripts, or registration features that can grant users elevated rights;
• code in a theme or plugin that creates a user when a particular hook runs;
• database records, scheduled tasks, configuration, uploads, and rewrite rules;
• reused passwords, recovery email, hosting credentials, SSH/SFTP, APIs, or deployment tokens.

Do not delete every file that contains the word admin, eval, or a particular string. Compare it with official packages, a clean baseline, and logs. Rotate secrets from a trusted device after securing the device and work environment. Rotate database or API credentials stored in configuration as well, and update the integrations that rely on them. For follow-up hardening, see how to secure WordPress for a small business.

Step 7: verify that privileged access does not return

After cleanup and credential rotation, create a new snapshot as a baseline, then test:

1. Administrator and Super Admin lists for the correct site and network; confirm that each owner is known.
2. Revoked sessions no longer work for removed accounts and unauthorised tokens cannot call the REST API.
3. Unknown users do not reappear after cache clearing, a scheduled task runs, or the site is accessed externally.
4. Unauthorised posts, forms, and pages have been removed or restored; legitimate users can still do their work.
5. Hosting and file-change logs, notification email, and the Search Console report are monitored after reopening.

Do not treat one screenshot of the user list as permanent proof. Record the time of the check and repeat it after a monitoring interval chosen by the site owner. If an account returns, stop deleting it repeatedly and find the code, integration, or credential that is recreating it.

Common mistakes when an unfamiliar administrator appears

• Deleting the account before preserving evidence. You may lose links to content, timing, or activity that needs investigation.
• Treating an odd name as proof of an attacker. It may be a service account; confirm ownership and logs.
• Changing only the password. Sessions, application passwords, email, and hosting access may remain active.
• Removing the user but leaving attacker content. A harmful page may still be served under a different author.
• Deleting every administrator except your own. A plugin, vendor, or recovery process may stop working; verify dependencies and use least privilege.
• Removing a network user without understanding multisite. Network-wide deletion differs from revoking access on one site.
• Confusing a user audit with malware cleanup. Backdoors and hosting-level access need separate checks.

When to escalate

Escalate to your host or a security specialist if new administrators continue appearing, the owner’s email or password changes unexpectedly, you lose access, file modifications cannot be explained, the website processes payments, or you do not control the full multisite network. Do not edit database tables directly if you cannot verify the schema and rollback plan; an incorrect role value can lock out a legitimate owner.

Rawat Web offers initial diagnosis through Website Emergency Assistance and a Free Audit. Send the URL and observed symptoms without a password or token. If technical work is needed, access and scope are agreed before changes; we can help inventory users, review permissions, secure accounts, and verify recovery without promising search rankings or third-party decision times.

Frequently asked questions

Does an administrator with an unfamiliar email mean an attacker created it?

No. An unknown email is a signal to verify, not proof of attribution. Check the site owner, vendors, service accounts, registration details, recorded activity, and available logs first.

Does WordPress record who created a user and their IP address?

A standard WordPress installation does not always keep a complete audit trail of the account creator, IP address, or every role change. Evidence may exist in an audit plugin that was already active, SSO, a WAF, hosting logs, or organisational records.

Can I delete an unfamiliar administrator immediately?

If active activity is harming the site, safely restrict access after preserving minimum evidence and coordinating with the owner or host. Before deleting, verify ownership, revoke sessions and tokens, review content, and reassign posts if needed. Do not remove the only trusted account.

Is changing the administrator password enough?

Not always. End old sessions, revoke unknown application passwords and tokens, secure recovery email and hosting, close the entry point, and verify that the user is not being recreated.