How to Investigate Suspicious WordPress Activity With Audit Logs
Start with the suspicious change, build a timeline around it, compare other evidence, and preserve what you find before cleanup changes the record.
Start With the Suspicious Activity You Already Know About
Do not start by reading thousands of log entries from the top. Begin with the event or symptom that made you investigate the site in the first place.
For example:
- an administrator account appeared that nobody recognizes
- 2FA or another security control was changed
- a plugin was installed or activated unexpectedly
- a malware finding appeared
- the site started redirecting visitors
- a client reported a change nobody remembers making
Note when the problem was first noticed, then inspect activity before and after that point. The time you discovered a problem is not necessarily when it started.
Look first for logins, user changes, plugin or theme activity, security-setting changes, and sensitive administrative actions near that window. If you find something suspicious, work backward until the activity starts to make sense.
Build a Timeline, Not a List of Interesting Events
An isolated event may tell you very little. The sequence around it often tells you much more.
| Question | What to look for |
|---|---|
| Who acted? | User or account associated with the event |
| When? | Exact timestamp and surrounding activity |
| From where? | Source IP and related requests where available |
| What changed? | User access, plugins, themes, settings, security controls, or content |
| What happened next? | Actions from the same account, IP, or time window |
| Was it expected? | Known maintenance, deployment, administrator action, or client work |
For example, an administrator login on its own may be routine. This sequence is different:
Administrator login → security control disabled → new administrator created → unfamiliar plugin installed
Read related events in order and ask whether the sequence matches legitimate work on the site.
Pay More Attention to Changes That Affect Access or Security
Some WordPress events deserve closer inspection because they can change who controls the site or weaken protections already in place.
| Event | Why it deserves attention |
|---|---|
| Administrator created or privileges increased | Creates or expands privileged access |
| Password or 2FA changed | May indicate an account-security change or takeover |
| Security plugin or control disabled | Reduces protection or visibility |
| Plugin or theme installed | Introduces new executable code to the site |
| Sensitive administrative tool used | May explain file, database, or configuration changes |
| Unexpected privileged login | Can be the beginning of a larger sequence of changes |
| Audit records cleared unexpectedly | May remove context needed to understand earlier activity |
Any one of these may be legitimate. What matters is whether the actor, timing, and surrounding activity match work you expected.
A sequence of unexplained security changes is more significant than one unusual event viewed in isolation.
Check the Audit Log Against Other Evidence
A WordPress audit log records what the application observed. It is not a complete record of everything that happened on the server.
When an event looks suspicious, compare the same time window against other available evidence:
| Evidence source | What it can add |
|---|---|
| Web-server access logs | Requests, paths, IP addresses, response codes, and request timing |
| Firewall or traffic logs | Probes, blocked requests, repeated sources, and attack patterns |
| Malware and integrity findings | Suspicious files, modified code, and when changes may have occurred |
| Hosting or control-panel logs | Activity that may have happened outside WordPress |
| SFTP or SSH logs | Direct server access where those services are available |
| Cron and scheduled tasks | Processes that may explain recurring or automated changes |
If you compare logs from different systems, check their time zones before building the sequence. Two entries that appear an hour apart may represent the same moment if the systems record time differently.
With SiteFort, compare suspicious Audit Log timestamps with the Traffic Log and relevant malware findings when they cover the same period.
Preserve the Relevant Evidence Before Cleanup
Incident cleanup changes the site. Deleting an account, removing a plugin, restoring a backup, or clearing logs can also remove information you still need to understand what happened.
Before making major remediation changes, preserve the relevant material where practical:
- export the audit-log window around the incident
- record suspicious usernames and account IDs
- record timestamps and source IPs
- preserve relevant malware or file findings
- save related web-server, firewall, or hosting logs when available
This does not mean delaying containment of an active attack to create a perfect evidence set. Preserve what you reasonably can, then stop the harmful activity.
Use the Timeline to Verify the Cleanup
After remediation, return to the evidence that led you to the incident in the first place.
Confirm that:
- unexpected administrator or privileged accounts are gone
- security controls are enabled and configured as expected
- 2FA remains enforced where required
- no unexpected plugin or theme was added after cleanup
- the same suspicious account or activity has not returned
- related malware findings or modified files have not reappeared
- temporary incident-response changes are understood and documented
If the logs show malicious activity but do not reveal the original entry point, do not invent one. Record the entry point as unknown and continue checking server, hosting, credential, vulnerability, and malware evidence.
A useful incident timeline should explain what changed, what you did about it, and why you believe the suspicious activity has stopped.