An airline received an electronic bomb threat for one of its long-haul flights scheduled for a particular date. This threat was communicated to the airline via its customer support/feedback page, which was hosted on its Internet-facing server. As was the norm, the data was collected by the web form and posted to an offshore support and feedback-handling center. The operator handling the complaint looked at the threat and notified her supervisor. Based on the supervisor's assessment, the threat was further escalated and both the airline and law enforcement were notified. To assist in the technical investigation of the case, our team was called in.

As a first step, we requested access to all the digital evidence as well as the logs of the web server, where the Support Form was posted. It was found that there was no record of the IP addresses used to send such e-mails. This itself was a major setback.

A quick look at the received communication established that the web Support Form sent the message in the form of a structured e-mail to the relevant support center. The headers of the e-mail were examined and the first thing we noticed was that the time taken by the e-mail to travel from the web server to the next SMTP server in a chain was slightly over 27 minutes. This seemed quite odd, therefore, we attempted to replicate the process by sending a test e-mail from the web form and found that, in this case, the time taken to traverse the same hop was just under one minute.

Confronted by this anomaly, we repeated the test numerous times and came up with the same result every time: under one minute. The 27 minutes taken by the original mail were unexplained. We approached the administrator with this issue and were informed that at the time when we had requested for the evidence, they had observed that the computer time was incorrect and not synchronized with the current time. Therefore, they had "fixed" this by shifting the time by "approximately" 30 minutes. This really threw a spanner in the works. We could no longer rely on the accuracy of the data in the header with respect to the time. To understand the impact of this "discrepancy", we need to realize that on a highly trafficked airline site, there can be a thousand visitors/hour. Therefore, an offset of about 30 minutes results in increasing the investigation window by about 500 visitors.

Time was short! The threatened event date was close. A herculean round-the-clock effort was put underway. All the web logs were acquired and an in-depth analysis of the logs was done. Approximate time offsets were incorporated with e-mail time and correlated with website hit logs and analyzed. Sixty-one suspect IP addresses were identified. The assistance of local Internet service providers (ISPs) was requested on an emergency basis. Each of the IP addresses was painstakingly identified and attributed. Two of these belonged to cyber cafes, which worked on a pay-as-you-use model. Cyber cafe owners assisted the local police in identifying the computers that were used at the time. Forensic images were made for later analysis. CCTV video was examined and some suspects were identified. Pictures were made and circulated to the airport security. At the same time, our forensic specialists examined the hard drive images and identified one of them as having being used to access the airline webpage and send the message. Any additional hard drive activity around the time of the webpage access was examined in detail. We found that the suspect had also accessed their personal e-mail account. Bingo—we had him! With a little assistance from the Mail Service Provider (MSP), local law enforcement identified the suspect and picked him up for questioning. It turned out that the suspect who had sent the mail was a student. A friend of his was traveling in that flight and he had threatened him that he would not let his friend leave the country.

As you can see, this time the critical investigation could have had a considerably shorter investigation time had the server's time been synchronized properly. Indeed, it is recommended that a Network Time Protocol (NTP) server be deployed to maintain time across a network so that occurrences of this nature do not mar a network forensic investigation.

To understand the structure of a log file better, let's look at the standard by the World Wide Web Consortium (W3C). (https://www.w3.org/).

The following is the structure of the Common Logfile Format:

Let's understand each of these one by one, as shown in the following:

Let's assume that an outsider wishes to access a webpage called forensics.html on our web server.

The log entries that would be generated would be similar to the following:

216.168.5.3 - - [28/Aug/2015:13:20:39 +0530] "GET /forensics.html HTTP/1.1" 200 177
216.168.5.3 - - [28/Aug/2015:13:20:40 +0530] "GET /image1.jpg HTTP/1.1" 200 431
216.168.5.3 - - [28/Aug/2015:13:20:41 +0530] "GET /image2.jpg HTTP/1.1" 200 2332

To put it simply, this means that a web browser based at the IP address 216.168.5.3 put in a request for the forensics.html page on August 28, 2015, at 13:20:39 hours IST, GMT +5.30 hours. The server responded with a successful response (200) and sent the file across. The file size was 177 bytes.

On receipt of this file, the web browser found that the webpage forensics.html had two inline images, namely: image1.jpg and image2.jpg. Subsequently, the browser put in a request for each of these images, which were successfully responded to by the server. The sizes of the images transmitted were 431 and 2332 bytes respectively.