Sites get hacked, it’s not pleasant but it happens. A critical part of it, especially in my experience, has been the web application log forensics applied directly after an attack. You can usually piece together what happened, especially if the attacker doesn’t rotate IP addresses during the attack. With a little poking around and after creating a timeline, you can usually figure out what the entry point was and where the flaw in your site/software is.
It’s a critical skill to learn and a great reason to have all your logs turned on, all the time as verbose as your server and storage can handle it. This article from Acunetix walks you through some of the things to look for, and the flow to use when examining a server post-attack.
A log file is an extremely valuable piece of information which is provided by a server. Almost all servers, services and applications provide some sort of logging. But what is a log file? A log file records events and actions that take place during the runtime of a service or application.
So why are log files so important? Log files provide us with a precise view of the behavior of a server as well as critical information like when, how and “by whom” a server is being accessed. This kind of information can help us monitor the performance, troubleshoot and debug applications, as well as help forensic investigators unfold the chain of events that may have led to a malicious activity.
Let’s take as an example a web-server. Most commonly, Apache HTTP Server will provide two main log files – access.log and the error.log. The access.log records all requests for files. If a visitor requests www.example.com/main.php, the following entry will be added in the log file.
Read the full article by Acunetix here: Using logs to investigate a web application attack