Website Log Analysis & Forensics

A large share of the “we were hacked again” cases we see are not new attacks. They are the same attacker using the same backdoor or the same unpatched flaw, because the first cleanup treated the visible mess and never found the root cause. A forensic pass finds the door, not just the muddy footprints.

Servers record far more than people realise. The request that exploited a vulnerable plugin, the successful login from an unfamiliar address, the moment a web shell was uploaded and first called: these leave traces in the logs and on disk. With the right correlation, the entry point usually stops being a mystery.

Before anything is changed, we capture the logs, file timestamps and relevant database state, because a hasty cleanup destroys the very evidence needed to understand the attack. Working from preserved copies means the investigation does not contaminate the scene, which matters if the findings feed a claim or a legal process.

We work through the access and error logs, pulling together attacker IP addresses, user-agent strings, request patterns and response codes. A spray of requests to a known plugin path, followed by a 200 on a file that should not exist, followed by POSTs to that file, tells a story. This is where a website forensic analysis earns its value: turning thousands of raw log lines into a clear sequence of what the attacker did and when.

Building the timeline

The correlated events become a timeline with timestamps: initial compromise, persistence established, actions taken, data reached, and the point of discovery. That timeline is the backbone of the report and the anchor for any breach-notification decision, because notification law turns on when you became aware and what was affected.

We compare the site’s files against a clean baseline to find what was added or modified, identify web shells and injected code, and check file modification times against the log timeline to confirm the sequence. The database is reviewed for injected content, tampered records, exported data and rogue administrator accounts. Together these show what the attacker changed and what they were able to reach.

The investigation ends with two conclusions stated plainly: how the attacker got in, and what data was exposed. From there we give you the specific fix for the entry point so the same route cannot be used again, which is the piece that stops the reinfection cycle. Root cause is not always a single flaw; sometimes it is a chain, such as a weak password that let an attacker in and an over-privileged account that let them reach the data. We report the whole chain, because fixing one link and missing another leaves the door ajar.

The web server access and error logs are the primary record, but the application layer often logs its own events too: WordPress security plugins, authentication logs, PHP error logs. Each holds a piece of the picture, and the useful window can be short because many hosts rotate logs after a few weeks, so acting early matters.

If a web application firewall or a CDN sits in front of the site, it keeps its own request history, sometimes retained longer than the origin server’s. Hosting control panels record FTP and SSH sessions and file-manager activity. These often survive even when the site’s own logs have been tampered with, which is exactly why an attacker who wipes local logs can still be caught.

An old backup is a photograph of the site at a point in time. Comparing a pre-incident backup against the compromised site shows precisely which files changed, and lining several backups up narrows when the change happened. We use them as evidence, not just as a restore point.

External signals

Google Search Console manual actions, Safe Browsing warnings and blacklist entries carry timestamps and sometimes sample URLs, which help corroborate the internal timeline and confirm when the damage became publicly visible.

We assess which records and data the attacker could reach and whether there is evidence of exfiltration. That assessment is what your legal counsel needs to decide on notification, and having it documented is far stronger than notifying on a worst-case assumption.

Backdoors, scheduled tasks and rogue accounts let an attacker return after a cleanup. The investigation enumerates every persistence mechanism we find, so remediation removes all of them rather than leaving one quietly in place.

Cyber-insurance claims and legal processes need evidence, not assertions. The preserved logs, the timeline and the indicators of compromise are assembled into a report written to support a claim or hand to counsel.

GDPR Article 33 gives you 72 hours to notify the supervisory authority of a personal-data breach, and Article 34 governs notifying affected individuals. Both require you to describe the nature of the breach and the data involved. A forensic timeline and impact assessment is precisely the factual basis those notifications demand, and it protects you from either missing the obligation or over-reporting out of uncertainty.