Reading Your Access Logs to Find the Entry Point

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Every cleanup eventually runs into the same question: how did they get in? Guessing produces a site that gets hacked again. The answer is usually sitting in a file your server has been writing the whole time, and while access logs look impenetrable at first, you only need a handful of techniques to get what you need out of them.

Finding your logs

On cPanel hosting there is usually a raw access logs section that lets you download them, and archived logs from previous days or months are often available separately. On a managed host they may be in a control panel section or available on request. With SSH access they are commonly in a logs directory in your home folder or under the server's own log path.

Get the error log as well as the access log. The access log records requests; the error log records PHP problems, and a malicious script that failed halfway frequently leaves a revealing entry there with a full file path. The two together are considerably more useful than either alone. Retention is the thing to check first — many hosts keep only a few weeks, so if you suspect an older compromise, download everything available before it rotates away.

Reading a log line

A standard line gives you the requesting IP address, a timestamp, the request method and path, the status code the server returned, the response size, the referring URL and the user agent string. That is enough to reconstruct almost anything.

The two fields that do most of the work are the method and the status. POST requests are where things get changed — uploads, logins, form submissions — so they are far more interesting than the thousands of GETs around them. And a 200 status on a POST to something unusual means the request succeeded, which is exactly what you are looking for.

What to look for

Start from a timestamp if you have one. If you know roughly when a malicious file appeared, look at everything in the surrounding window — my guide on file timestamp forensics covers establishing that time. Narrowing a log to a two-hour window turns an impossible reading task into a manageable one.

Then look for the classic patterns: POST requests to files in the uploads directory, which should never receive them; requests to PHP files you do not recognize, especially ones that return 200; long sequences of requests from a single IP address probing different plugin paths; repeated POSTs to wp-login.php or xmlrpc.php indicating credential attacks; and requests with obviously malformed parameters containing encoded payloads or directory traversal sequences.

Practical techniques

With shell access, grep is the whole toolkit. Filter for POST requests, filter for a specific path, filter for a date range, filter for an IP address, then count and sort to find the addresses making the most requests. Piping a filter into a sort-and-count is how you turn a million lines into a ranked list of twenty things worth reading.

Without shell access you can still do this. Download the logs and open them in a text editor with decent search, or load them into a spreadsheet and filter by column. It is slower but perfectly workable, particularly once you have narrowed the time window. The important thing is to filter aggressively rather than trying to read sequentially.

Reconstructing what happened

Once you find a suspicious request, pivot on the IP address and pull everything that address did. That gives you the whole session — the probing, the successful exploit, the upload, and the subsequent requests to whatever was uploaded. It is usually the moment the picture snaps into focus.

Then pivot the other way: take the path of any backdoor you found and search for every request to it. The first request tells you when it went live, and the pattern of requests afterwards tells you how it was used and for how long. That timeline is what you will need for deciding what to tell customers and for your host if the account was suspended.

What logs will not tell you

Be realistic about the limits. Logs record HTTP requests, so a compromise through stolen FTP credentials or a hosting control panel login may not appear in them at all — you would need FTP or panel logs for that. Requests made over HTTPS are logged normally, but POST bodies are not, so you see that a request happened without seeing what it contained.

And logs can be tampered with, though on shared hosting that is less common than people fear since the web server user often cannot write to them. If your logs have gaps around the relevant period, treat that as a finding in itself. When you have exhausted what the logs can tell you and still cannot identify the entry point, that is a reasonable moment to hand it over — tracing entry from partial evidence is routine work for my malware removal service.

Common questions

Where do I find my access logs?

On cPanel, look for raw access logs, which also usually offers archived logs from previous periods. Managed hosts often expose them in a control panel section or provide them on request. With SSH, check a logs directory in your home folder. Download the error log too — it frequently names the exact script that failed.

How far back do logs go?

It varies a great deal. Many shared hosts keep only a few weeks and rotate the rest away, while some retain months of archives. If you suspect the compromise is older than your retention window, download everything available immediately before more of it disappears.

What should I search for first?

POST requests to paths that should never receive them, particularly anything inside the uploads directory, and requests to PHP files you do not recognize that returned a 200 status. If you know roughly when a malicious file appeared, filter to that time window first — it makes everything else tractable.

Can I do this without command line access?

Yes. Download the logs and use a text editor with good search, or import them into a spreadsheet and filter by column. It is slower than grep but entirely workable, especially once you have narrowed down the relevant time period from file timestamps.

What if the logs show nothing unusual?

Then the entry point probably was not an HTTP request. Stolen FTP or control panel credentials, a compromise of another site on the same hosting account, or access through a developer's compromised machine would all leave little or nothing in the web access log. Those are the next places to look.