Unexpected WordPress admin activity: a first-hour response plan
An administrator you do not recognize appears in WordPress. A plugin changes when nobody remembers updating it. An application password turns up on an account that should not need one.
A useful WordPress security incident response starts by preserving what you can, checking the explanation and limiting the access you have reason to distrust. Deleting the unfamiliar account immediately can remove context while leaving other credentials working.
My priority in that first hour is to get three things clear: what we have actually observed, what access should end now, and what still needs investigation. You do not need a complete explanation before containing ongoing harm. You do need to keep uncertainty visible instead of declaring the site safe because one warning disappeared.
This guide includes a checklist, an access diagram and a fictional worked example. It is a plan for the first hour, not a promise that an incident will be resolved in sixty minutes.
Keep this checklist beside you
The phases overlap. One person can preserve logs while another contacts the host or restricts access. If you are working alone, record the essential details and prioritize stopping harm that is continuing.
The first hour, in seven checks
Work in parallel when you can. If harm is continuing, contain it while someone preserves the record.
1. Preserve what you found
Start a short incident note. Write down the site, when you noticed the issue, the timezone and the exact account, event or file involved. Distinguish an event’s time from the time a check reported it. A file first noticed at 09:23 might have changed much earlier.
Export the relevant activity if a log was already recording. Ask your host to retain access logs, error logs and a snapshot of the site’s current files and database. Keep the evidence somewhere access-controlled outside the affected installation, and record where it is. Do not paste credentials, recovery links or customer data into a shared document.
A current snapshot preserves the state you are investigating. It is not automatically a safe restore point. Keep older backups too, and establish when each was taken relative to the earliest suspicious activity. WordPress’s hardening guidance discusses both logging and backup integrity.
Avoid clearing logs, marking every file change expected or reinstalling everything before preserving what is available. If active harm requires an immediate change, make it and record what you did; evidence preservation should not become a reason to leave damaging access open.
If BetterShield was already running, Activity › Site activity lets you filter and Export CSV. Installing it now will not reconstruct earlier activity. Missing records are a limit on the investigation, not evidence that nothing happened. The activity-log guide explains what is recorded and what is left out.
2. Establish trusted access and verify the explanation
Use a device and account you have reason to trust. Confirm an independent route through your host and a working recovery method before removing access. If you cannot trust any administrator account or your recovery mailbox, ask the host for help through its established support channel.
Contact the site owner or developer using a known phone number or existing conversation. Do not rely on an email address that only just appeared on the suspicious account.
Ask specific questions:
- Was an administrator or integration supposed to be created?
- Which account was doing the work, and during what time window?
- What should the new integration be able to do?
- Which files or settings should have changed?
Compare the answer with the records. “We did maintenance” is a starting point, not a match for an unexplained credential or file difference. A recorded account identifies the credentials used, not necessarily the person using them.
Where BetterShield has grouped events under Activity › Incidents, open Review timeline and follow the related activity. Its incident grouping connects records worth reviewing; it does not establish intent or identify malware.
3. Contain the access you have reason to distrust
Ending a session, changing a password and revoking a connection solve different problems. Check the paths that matter to this incident rather than assuming one action closes them all.
One action closes one kind of access
Choose an action to see what it ends and what still needs your attention. These controls explain the options; they do not change a site.
End the account’s browser sessions
- What ends
- Those existing browser sessions stop working.
- Still review
- The account can sign in again with a valid password or passkey. Application passwords and assistant connections need their own review.
A sign-out is useful containment. It does not remove the credential that could open the next session.
Replace the account’s password
- What ends
- The old account password stops working.
- Still review
- Application passwords, passkeys, assistant connections and other accounts are separate. Explicitly review and end sessions instead of assuming every access path is covered.
Secure the recovery email too. Otherwise someone who controls that mailbox may be able to reset it again.
Revoke one application password
- What ends
- Requests authenticated with that application password are refused.
- Still review
- Other application passwords, browser sessions and the account’s normal sign-in methods can still work.
Name the integration and its owner first. Revocation can interrupt legitimate publishing or maintenance.
Revoke the assistant connection
- What ends
- The selected BetterShield app connection loses access through that grant.
- Still review
- Other grants, credentials and connectors can still work. Review the account that approved the connection and any other route the same tool holds.
A pause may be temporary. Revoke the connection when its access should end, and verify the result on the site.
For a suspicious account, consider its roles, browser sessions, application passwords, passkeys and connected assistants together. Preserve the relevant metadata first where feasible. Confirm which integrations are legitimate before revoking their credentials, and do not remove your last trusted way to manage the site.
Application passwords deserve particular attention. They authenticate tools separately from interactive two-factor sign-in. They are not a second factor, and changing the account’s normal password is not a substitute for reviewing them. See the WordPress application-password reference and our guide to finding, limiting and revoking them.
If several accounts or administrative routes are involved, broader restrictions may be necessary. BetterShield’s Lock the site down control can interrupt legitimate staff access and integrations. It also restricts installs and updates, which matters when an update is part of the response. Read the lockdown reference before using it.
Lockdown does not isolate the hosting account or take the public site offline. If visitors are being redirected, malicious content is being served or damage is continuing beyond WordPress sign-ins, work with the host to isolate the affected service. A WordPress switch is not complete containment of the server.
4. Review a response plan, then verify its result
In BetterShield, Prepare response plan shows proposed actions before applying them. Read each target and consequence, select what is justified, and use Apply selected actions only after checking the plan. Ending sessions and revoking application passwords cannot be undone; other actions have their own conditions for reversal.
Afterward, read After the response. Distinguish Not open from Not checked, Not done and Yours to do. A successful action is one piece of evidence, not a verdict on the whole site. The incident guide lists the plan’s limits and the follow-up checks.
Whether you use a plugin or work manually, verify the specific outcome:
- Does the account still have permissions it should not hold?
- Were the relevant sessions ended and credentials revoked?
- Has unexplained activity continued since the change?
- Do legitimate sign-in, publishing and store workflows still work?
- Which checks could not run, and who will complete them?
For a changed file, compare against a trusted copy of the exact version and keep the original evidence. A legitimate customization can differ from the published copy. Conversely, restoring one file does not establish that the database, uploads, other code or hosting account are clean. BetterShield’s file integrity check is not a malware scanner or a complete cleanup service.
A fictional example: follow the evidence, not the account name
Consider a site owner who notices a new administrator named site-maintenance. The following example is invented for this article. No real customer, incident, scan or investigation is being described.
Three events. An explanation still needed.
Invented names, times and records, all in UTC. This illustrates reasoning, not a real customer incident or a measured detection result. Open each event.
- 09:12UTC
A privileged account appears
- Observed
- The activity record shows an existing administrator creating “site-maintenance” with an Administrator role.
- Unknown
- Was this account approved, and does the recorded actor recognize the action?
- Next check
- Record the account and timestamp. Contact the administrator through a known channel; the account name alone tells you very little.
- 09:16UTC
A new application password follows
- Observed
- The new account creates an application password labeled “content-sync”.
- Unknown
- Which integration needs it, who owns that integration, and was it part of the agreed work?
- Next check
- Preserve the credential’s metadata, never its secret. Treat it as a separate access route even if you reset the account password.
- 09:23UTC
A plugin file differs
- Observed
- A later file check reports an altered PHP file. This is when it was noticed, not necessarily when it changed.
- Unknown
- Does the difference match a known update or approved change?
- Next check
- Preserve the difference and compare it with the exact published version. A changed file by itself does not establish intent or who changed it.
The developer confirms an approved integration through a known contact. The change record and file comparison support the account activity.
Document it and remove unnecessary access.No one can account for the credential, or the file difference does not match the agreed work. A maintenance message alone is insufficient.
Contain the relevant access and escalate.Suppose the developer confirms through a known contact that a publishing integration was scheduled. That explains why an account might exist. You still check whether the integration needs Administrator access, whether the credential belongs to it and whether the PHP difference matches the work.
If those checks line up, record the explanation and reduce access that was broader than necessary. If they do not, keep the unexplained items open, contain the relevant access and ask for further investigation. Neither the reassuring account name nor the alarming sequence of events settles the question by itself.
Before the hour ends, leave a clear handoff
You may still be investigating. The useful outcome is a preserved record, a documented containment decision and a named owner for every unresolved issue.
Bring in your host or an incident specialist when you cannot establish trusted access, changes return after you reverse them, evidence points outside WordPress or you cannot assess the affected files and database confidently. A request for help is more actionable when it names what you observed, what you changed and what remains unknown.
Copy this note into your own incident record:
Site:
Discovered at / timezone:
Confirmed observations and event times:
Evidence preserved / secure location:
Actions taken / by whom / when:
Verified results:
Unresolved items / checks not completed:
Affected workflows / people informed:
Next action / responsible person:
Next update at / timezone:
Keep secrets out of the note. Link to the restricted evidence rather than copying sensitive records into it. Describe suspected activity as suspected until you can support a firmer conclusion.
The first hour is successful when the next person can understand the state of the site and continue the work without guessing. Keep the incident reference, session controls and recovery setup close by as you work.