Hacked Websites Are Not Always Obvious: How to Organize Logs and Useful Audit Trails

Hacked websites do not always immediately turn into pages filled with strange messages. Sometimes the attacks are more subtle: a new admin account is created, a plugin is replaced, a PHP file is injected, or multiple login attempts are made repeatedly in the early morning. From the visitor's perspective, everything may appear normal.

This is where logs and audit trails become important. Logs are records of system activity, while audit trails are histories of actions that help us answer questions like: who did what, when, from where, and against which part of the website. Both are not just the needs of server administrators. Small website owners, online store operators, and WordPress managers can also benefit greatly from them.

Logs Are Not Just Technical Files

Logs are often seen as a pile of text lines that are only useful to developers. However, well-designed logs can serve as digital security camera recordings. They may not always show the perpetrator's identity completely, but they can reveal the IP address, time of the event, accessed endpoints, server responses, accounts used, and changes made.

OWASP recommends that applications log important security events, not just technical errors. Examples include successful and failed logins, changes in access rights, new account creations, configuration changes, use of sensitive features, and activities that violate input rules.

For WordPress, the official documentation also places logging and monitoring as part of the hardening process. Logs can help identify brute force attempts, file changes, use of plugin or theme editors, and the addition of unauthorized content.

Differentiate Three Types of Records

Before installing plugins or enabling all logging features, first differentiate the sources of information. Each type of record answers different questions.

• Web server access log: records HTTP requests, such as URL, time, status code, IP address, and user agent. This is useful for observing scanning patterns, brute force attempts, or suspicious requests.
• Error log: records PHP errors, server configuration issues, and application failures. This record helps identify broken code, but should not be displayed to visitors as it may leak sensitive information.
• Application audit log: records actions within the application, such as an admin changing a user's email, installing a plugin, deleting an order, or changing payment settings.

The access log may show that the settings page was opened, but only the application audit log can explain whether the settings were actually changed and which account did it.

What Should Be Logged?

The principle is simple: log events that help detect abuse or investigate incidents. For a typical website, start with the following list:

• Successful logins, repeated failed logins, logouts, and password resets.
• Creation, deletion, or changes in user roles.
• Changes to plugins, themes, configurations, and important files.
• Changes to admin email addresses, payment methods, or webhooks.
• Deletion of content, orders, customers, or important data.
• Requests that generate many status codes 401, 403, or 404.
• Activities from unusual locations, devices, or times.

Log sufficient context: time in a consistent zone, event names, user IDs, IP addresses, request IDs, action results, and affected objects. Request ID is a unique identifier for a single request. It helps link records from applications, servers, and third-party services.

Do Not Include Secrets in Logs

Overly detailed logs can also create new problems. Do not log passwords, session tokens, API keys, credit card numbers, or complete personal data unless necessary. URLs containing tokens should also be sanitized before being stored.

A bad example:

password=secret123&token=abc-xyz-123

A safer example:

event=login_failed user_id=184 ip=203.0.113.10 reason=invalid_password

In the second example, we can still investigate the incident without storing user secrets. Logs also need to have access restrictions. Those who can read the logs may potentially see activity patterns, IP addresses, or internal website information.

WordPress: Start with Available Options

If using WordPress, go to Tools > Site Health > Info to understand the website configuration, PHP version, active plugins, themes, and system conditions. Also check if debug mode writes errors to publicly accessible files. Open debug files can leak server paths, queries, or configuration details.

For auditing admin activity, use a solution that logs changes to users, plugins, themes, and settings. Choose plugins from trusted sources, check when they were last updated, and avoid installing multiple logging plugins with the same functions. Too many logs without a filtering system only drown important signals in noise.

If you have access to the server, store log copies in a location separate from the main website. The reason is simple: attackers who have gained access to the server may try to erase traces. CISA also recommends centralizing logs, protecting against unauthorized deletions, and having clear retention policies.

What You Can Do Now

1. Identify three high-risk events. For example, admin logins, changes in access rights, and plugin changes.
2. Ensure system time is consistent. Time zone differences make the sequence of events hard to read.
3. Create simple alerts. For example, notify if there are 10 failed logins within five minutes or a new admin account is created.
4. Store logs in a separate location. Do not rely solely on files on the website server.
5. Test log searches. Simulate a failed login or setting change, then ensure the records can be found.
6. Determine who will check. Logs that are never read do not constitute a monitoring system.

When You Discover Suspicious Activity

Do not immediately delete files or reinstall without preserving evidence. Note the time the issue was first observed, save relevant log copies, and limit new changes to the website. After that, revoke active sessions, reset important credentials, check admin accounts, and look for file or plugin changes.

The purpose of logs is not to allow us to know everything. The goal is to shorten the distance between an event and understanding. Websites that have prevention, logging, and response plans will be better prepared to face issues than those that merely hope they will never be attacked.

Sources & Further Reading

• OWASP Logging Cheat Sheet
• Hardening WordPress – Advanced Administration Handbook
• Use Logging on Business Systems – CISA
• Site Health screen – WordPress.org Documentation

– Rio Yotto @rioyotto