WordPress Activity Logs After a Hack: What They Show

Removing malware tells you what was put on the site. It does not tell you how it got there, which account was used, or what else the attacker touched along the way. Those answers live in logs: records the site and the server keep about logins, changes and requests. Read carefully, they turn “something bad happened” into a rough timeline you can act on.

This post is about reading that trail after a hack. It covers which logs exist on a typical WordPress site, what each one can and cannot show, and the patterns worth looking for. You do not need to be a server administrator to follow it, though you will need access to your hosting panel.

Save the logs before anything else changes

Logs are easy to lose. Many hosts keep access logs for a short window and then rotate them away. A cleanup, a restore or a host-side malware scan can overwrite or remove files you would have wanted. Attackers sometimes delete logs themselves.

So the first job is to copy what exists to somewhere off the server: download the access and error logs from the hosting panel, export any WordPress activity log plugin’s records, and note the date you did it. Work from the copies. Do not trim or “tidy” them first.

The logs you might have

A WordPress site can have several separate records, and most sites have only some of them. Here is what each one is good for.

One thing to know about WordPress itself: out of the box, it does not keep a log of who logged in or what they changed. If no activity log plugin was installed before the hack, that layer simply does not exist for the period you care about. Installing one now still helps, because it will show you whether the attacker comes back.

Step 1: Anchor the timeline

Before searching, you need a rough date to search around. Good anchors include:

• The date of the first warning from Google, your host or a customer.
• The registration date of an unknown admin account. WordPress stores this for every user, and you can see it in the database’s users table or with WP-CLI.
• The modification date of the first malicious file found in the cleanup.

Treat file dates with some suspicion. An attacker with file access can change a file’s modification time to make it look old. A user registration date is harder to fake casually, and a request in the access log is harder still, so where they disagree, trust the log.

Once you have an anchor, look at a window that starts well before it. The visible damage often comes days or weeks after the first access.

Step 2: Find the first malicious request

Open the access log copy and search for the name of a malicious file the cleanup found, for example a strange PHP file in the uploads folder. Each line that mentions it shows an IP address and a time.

The earliest line is not always the entry point, but it is close to it. Now search the same log for that IP address and read everything it did around that time. You are looking for the request just before the file appeared. Common patterns:

• A POST request to a plugin’s file or to admin-ajax.php just before a new file shows up. That often points at a vulnerable plugin that allowed an upload.
• Many POST requests to wp-login.php from one address, then a successful login, then plugin or theme editor activity. That points at a guessed or stolen password. Our post on how brute-force login attacks work covers that pattern.
• A request to a plugin path that should not exist on your site, or to a plugin you deleted months ago. Attackers probe for known vulnerable files.
• No web request at all before the file appeared. If the file showed up with no matching web activity, check FTP and hosting panel logs. Access may have come through credentials rather than the website.

Response codes help here. A 200 on a POST to a file that should not accept uploads is far more interesting than a stream of 404s from a bot guessing paths.

Step 3: Follow the accounts

If an activity log plugin was running, its records are usually the easiest part of the trail to read. Filter by the suspicious period and look for:

• Logins from accounts that rarely log in, or at hours your team does not work.
• New users created, or existing users promoted to administrator.
• Plugins installed or activated, especially file manager or code snippet plugins.
• Changes in the theme or plugin editor.
• Changes to the site address, admin email, or user registration settings.

If you found an administrator nobody recognises, our post on what an unknown admin account means explains what else to check about it. The activity log can tell you which existing account created it, which is often the real compromised login.

Without a plugin, you can still learn something. The database records when each user was registered, and the access log shows requests to wp-login.php and wp-admin. Successful logins usually show a redirect (302) after the login POST rather than the login page being served again, which lets you see roughly when an account got in, even if you cannot see which one.

Step 4: Look for what was done after entry

Once you know roughly when and how the attacker arrived, the next question is what they did with the access. Search the logs from the entry time forward for:

• Requests to the files they planted. Repeated POSTs to a single odd PHP file usually means it is a web shell being used to run commands.
• Database export tools or large downloads. Requests that returned an unusually large response, or that touched backup files, may mean data was taken.
• Requests to other sites on the same hosting account, if you host more than one. An attacker on one site often looks at its neighbours.
• Errors in the error log pointing to files you did not know about. A PHP warning that names a file path is a quick way to find a hidden script.

This is the part that matters most for decisions. If the logs suggest customer data may have been downloaded, that changes who you may need to tell. If they show only spam being injected, the concern is mostly search visibility.

Step 5: Check whether they came back

After the cleanup, keep watching. The same IP addresses, or requests to the same deleted file names, returning a few days later tells you a backdoor was missed or the entry point is still open. Our page on malware that returns after a cleanup covers what usually causes that.

Attackers do change IP addresses, so watch for the pattern as well as the address: the same file names, the same request paths, the same unusual browser strings.

Reading log lines without getting lost

A single access log line looks dense, but it has a regular shape. In most formats you will see, in order:

1. The visitor’s IP address.
2. The date and time, with a time zone offset. Check it, because your host’s server time may not match your local time.
3. The request: method (GET or POST), the path, and the protocol.
4. The response code, such as 200, 302, 403 or 404.
5. The size of the response.
6. The referrer and the user agent (the browser or tool name the visitor sent).

A few practical tips:

• Search, do not scroll. Use your text editor’s search, or on a server, grep for an IP or a file name.
• Ignore your own IP. Find it first so you can filter yourself out.
• Do not trust the user agent. It is whatever the visitor chose to send, and bots often pretend to be Googlebot or a normal browser.
• Check whether a CDN or firewall service sits in front of the site. If it does, the server log may show the CDN’s addresses instead of the real visitor’s, and the real IP may be in a separate header or in the CDN’s own dashboard.

What logs cannot tell you

Logs are evidence, not certainty. Some limits to keep in mind:

• If logs were rotated away before you saved them, the entry may be lost for good.
• A POST request’s body, which holds the actual data sent, is normally not recorded. You can see that something was sent, not what.
• Activity log plugins only see actions that go through WordPress. An attacker running commands through a web shell can change files and the database without the plugin noticing.
• An attacker who had full access may have edited the logs.

So a good write-up says “the evidence suggests” rather than “this is what happened”, and notes what is missing.

Setting up logs for next time

If this hack taught you that the logs you needed were not there, fix that now:

• Install an activity log plugin, such as WP Activity Log or Simple History, and check that it records logins and user changes.
• Ask your host how long access logs are kept, and whether you can download them or have them archived.
• Store a copy of logs off the server on a schedule, so an attacker on the server cannot erase the only record.
• Keep each person on their own WordPress account, so the activity log can tell you which person did what. Shared logins make logs far less useful.

For the general cleanup steps that sit alongside this kind of review, our guide to recovering a hacked WordPress site step by step is the companion piece. And for the full picture of how we handle hacked sites, including urgent contact, see our hacked website repair page.

When to hand it over

Log reading is slow, careful work, and it gets harder when there are several sites on one account or the logs are incomplete. If you need a clear answer about how the attacker got in and what they touched, written up so you can act on it, our website hack investigation service does exactly that. Send us what you have saved, and we will tell you honestly what the logs can and cannot answer.

Next in this series: WordPress Plugin Vulnerabilities Explained