Consider a simple scenario where you are tasked with finding the origin of incoming attacks on a particular web application. The only thing you know about the network is that the application is internally hosted and is not connected to the outside world. There is a caching proxy running in the network as well. As the forensic investigator, the first thing you requested from the client is the logs of the application server, which you started to investigate in Apache Logs Viewer:

We quickly deduce that there are two IP addresses of supreme interest, 192.168.174.157 and 192.168.174.150, and since the User-Agent contains sqlmap, it's a SQL injection attempt. We can also see the requests that contain buzzwords, such as WHERE and SELECT, which are typically used in SQL injections on a vulnerable parameter. Upon further investigation and talking to the client, we see that the 192.168.174.150 IP is a caching proxy server. Therefore, we request the client for the proxy server logs, which can be investigated in the Sawmill software:

The attacker has made use of the proxy server to forward all the traffic to the target application. Making use of the proxy logs, we will be able to pinpoint the original IP that made the requests. Keep the URL as 192.168.174.142 as the filter and browsing to the source, which gives us the following information:

Again, we get the 192.168.174.157 IP address as the culprit. At this point, we are sure that the attack originated internally from this IP, so let's investigate this IP address. Having gone through the server, we see the Apache server running on it and hosting a vulnerable app, which is php-utility-belt. We are pretty sure that someone obtained access to this machine through here. Let's manually investigate the logs from Apache:

We can see that only one IP address accessed the application on this server's Apache, which is 192.168.174.152. Let's open Wireshark to see whether there are still any packets traveling to and from this IP:

Yes, there's plenty going around on port 4433 and 4444. This confirms that the user of 192.168.174.152 is the culprit, as the system is not connected to the internet and has only internal access.

Throughout this case study, we saw how logs could be very helpful during the investigation process and reveal a lot about the incoming attacks. Creating a root-cause analysis gives us the following:

The attacker attacked the PHP utility belt application that was running on the 192.168.174.157 system and gained access to the machine. Since the compromised system used the Squid proxy as a system-wide proxy, all the attacks to the application at the 192.168.174.142 server came through the proxy server at 192.168.174.150. The Apache logs at 192.168.174.142 revealed 192.168.174.150, and the Squid logs at 192.168.174.150 revealed 192.168.174.157. Investigating the Apache logs on 192.168.174.157 finally revealed the attacker at 192.168.174.152.