Consider a scenario where we have been tasked to investigate a server that was compromised and defaced by the attackers. The administration team has all the practices, such as logging and full packet capturing, in place. However, it seems that someone also cleared out logs, as suggested by its Modified, Accessed, Created, Executed (MACE) properties. There are very few entries in the Apache logs, as shown in the following log set:

    192.168.153.1 - - [25/Mar/2019:14:43:47 -0400] "GET /site/ HTTP/1.1" 200 701 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:47 -0400] "GET /icons/blank.gif HTTP/1.1" 200 431 "http://192.168.153.130/site/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:47 -0400] "GET /icons/folder.gif HTTP/1.1" 200 509 "http://192.168.153.130/site/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:47 -0400] "GET /icons/back.gif HTTP/1.1" 200 499 "http://192.168.153.130/site/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:49 -0400] "GET /site/includes/ HTTP/1.1" 200 1219 "http://192.168.153.130/site/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:49 -0400] "GET /icons/unknown.gif HTTP/1.1" 200 528 "http://192.168.153.130/site/includes/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:49 -0400] "GET /icons/text.gif HTTP/1.1" 200 512 "http://192.168.153.130/site/includes/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:49 -0400] "GET /icons/compressed.gif HTTP/1.1" 200 1323 "http://192.168.153.130/site/includes/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:44:09 -0400] "GET /site/includes/server.php HTTP/1.1" 200 148 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:44:17 -0400] "GET /site/includes/server.php HTTP/1.1" 200 446 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:44:26 -0400] "GET /site/includes/server.php HTTP/1.1" 200 156 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:45:20 -0400] "GET /site/includes/server.php HTTP/1.1" 200 2493 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:58:44 -0400] "GET /site/includes/server.php HTTP/1.1" 200 148 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:58:49 -0400] "GET /site/includes/server.php HTTP/1.1" 200 446 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:59:05 -0400] "GET /site/includes/server.php HTTP/1.1" 200 147 "-" "-"
...

It looks like the attack came from the 192.168.153.1 IP address. However, looking at the details in the preceding logs, we can see that there is no user-agent in most of the requests. Additionally, no data is posted on the hacked server since the request is of the GET type, and there are no parameters involved as well. Strange, right? There had to be something in the parameters.

As of now, most of the logs look like legitimate requests to access the file. Nothing out of the box. But why would an attacker send that many GET requests to a resource page with no parameters? Maybe because we aren't looking at it right. Let's open the PCAP file for the capture as well:

This seems like a normal HTTP GET request. However, scrolling down a little further, we can see that we have few entries:

We can see a request that was generated from the compromised 192.168.153.130 server to 192.168.153.142. The user-agent is wget, so we can assume that a file was downloaded to the server. Let's investigate this as follows:

Looking the HTTP stream, it seems like an ELF file was downloaded to the compromised server. We will investigate this file in detail. But first, let's see what those simple looking GET requests reveal:

Oh! It looks like the backdoor code was in the cookie, and that was the reason it didn't show up in the Apache logs. We can see that it looks like the output of a dir command. Could this be the reason there was a download of a file on the server? Let's check by decoding the cookie values, as follows:

Decoding the value by Base64, we can get the clear text commands that were used. However, we would like to see all the commands executed by the attacker. We can accomplish this task using tshark, as follows:

The first command filters out all the cookies since we used -R with http.cookie as the filter. The output contained unwanted 'z=' characters, so we stripped it off using the Linux cut command. We stored the output of tshark in a file called base.

In the next command, we used a while loop to read and print every line individually, and, while doing so, should be decoded with Base64. We can see that we got the results showing that the attacker did the following:

1. Printed 1
2. Listed the command to see the directory's contents
3. Ran the whoami command to see the current user
4. Issued a ls -la command to view all files, including the hidden ones
5. Issued a wget command to download a file from another server that might be a backdoor as well
6. Again tried the same after printed some 1's and again listed the directory

7. Tried to download the file again, but this time to a file called shell.txt, and repeated it for shell.txt
8. Tried to download the shell.e file
9. Again tried to download the shell.zip file
10. Tried to print out IP addresses, PHP version, disabled PHP functions, and much more

A point to note here is that the attacker has not executed the shellcode file that might be a local exploit to gain high privileges. Additionally, it looks like their download attempts failed. However, we saw a file being transferred in the PCAP. Let's investigate this as well:

We have selected only the response from this packet. Let's save it by selecting raw from the Show and save data as option, and then clicking the Save button, as follows:

Additionally, we have to remove everything before the ELF magic header for the file to be recreated successfully. After saving the file, open it up in Notepad and remove the server headers and save the file as follows:

Now that we've removed the additional header, we have the executable file for our malware analysis teams to analyze. However, when we tried analyzing it on Hybrid Analysis, we got nothing, as shown in the following screenshot:

We can see that we got nothing from the file. However, we got a good number of inputs and strong evidence based on log analysis and PCAP analysis. We have seen throughout this chapter that log analysis and PCAP analysis are dependent on each other. We also saw that SSH logs are dependent on logs and that server logs are dependent on PCAPs to be able to reveal more about attacks.