Comprehensive Network Security Investigation: Webshell Threat Detection and Analysis

Network security

I. Submitting the Attacker’s IP Address in bt-panel

The background of this network security investigation is a detected webshell alert that requires on-site examination. First, we need to identify the web application and access the web logs to investigate the attacker’s IP address. Using the command `netstat -tunlap`, we can view network processes and identify a significant attack surface. The web application processes include nginx running with PID 1213 on ports 80 and 888, and bt-panel running with PID 2201 on port 12485.

network security investigation> />

1.1. bt-panel nginx

First, let’s investigate the nginx web logs. Using the command lsof -p 1213 | grep log to view the files opened by nginx and filter for log files, we find that the nginx log files are located in the /www/wwwlogs/ directory.

Using the command ls -laS /www/wwwlogs/ to sort by file size, we locate the web log files access.log and 127.0.0.1.log.

network security investigation> />

Using commands such as cat /www/wwwlogs/access.log | cut -d ' ' -f 1 | sort | uniq -c | sort -n, we examine both log files and find IP addresses 192.168.20.1 and 192.168.20.131.

Using commands such as cat /www/wwwlogs/access.log | grep 192.168.20.1 | cut -d ' ' -f 7 | grep -v "js\|css\|img" | less, we examine the URL paths accessed by both IP addresses.

The access.log record shows that the URL paths accessed by 192.168.20.1 do not show any obvious signs of an attack.

The 127.0.0.1.log record shows that the URL paths accessed by 192.168.20.1 show clear signs of an attack.

The 127.0.0.1.log record shows that the URL paths accessed by 192.168.20.131 show clear signs of an attack.

However, the final answer only includes 192.168.20.1, not 192.168.20.131, which seems inaccurate.

1.2. bt-panel

Next, let’s investigate the bt-panel web logs. Using the command ls -l /proc/2201/exe to view the bt-panel program path, we locate bt-panel deployed at the /www/server/panel/ path.

Using the command find /www/server/panel/ -name *log 2>/dev/null, we locate the log files stored in the /www/server/panel/logs/ path.

Using the command ls -laS /www/server/panel/logs/ to sort by file size, we don’t find any web log files. Examining these log files individually, we also don’t find any intrusion attempts.

II. Submitting the Attacker’s Modified Administrator Password (Plaintext)

Since the attacker targeted the web application on nginx, this administrator password should refer to the administrator password of the web application on nginx.

At the log level, web applications generally don’t record “user xx changed their password to yy”; they might at most record “user xx changed their password.” Therefore, to view the attacker’s modified administrator password, we need to check the database.

Here, we choose to log in to the database of the web application on nginx through the BT Panel’s management backend. We use the command bt and select 5 to change the BT Panel management backend password, then use the command bt default to obtain the login address for the BT Panel management backend.

After logging into the BT Panel, we find the database for the nginx web application and click “Manage” to access phpMyAdmin.

Since we’re searching for user passwords, let’s search for tables related to the “user” keyword. In the x2_user_group table, we find that groupid 1 represents the administrator group.

In the x2_user table, using usergroupid 1, we find that peadmin is the administrator, and the password hash is: f6f6eb5ace977d7e114377cc7098b7e3.

After decrypting the password hash, we obtain the password for administrator peadmin: Network@2020.

III. Submitting the URL of the First Webshell Connection

Using the command cat /www/wwwlogs/127.0.0.1.log | grep 192.168 | cut -d ' ' -f 6,7 | sort | uniq -c | sort -nr | head to view the URLs accessed by the attacker, we find that the most frequently accessed URL is /index.php?user-app-register, followed by /version2.php.

/version2.php doesn’t seem like a URL that a normal business application would provide. Using the command cat /www/wwwlogs/127.0.0.1.log | grep 192.168 | cut -d ' ' -f 6,7 | uniq -c | grep -C 10 version2.php to view what happened when the attacker accessed /version2.php, we find that the attacker accessed /index.php?user-app-register many times before accessing /version2.php many times.

In Wireshark, using the syntax http.request.uri contains version2.php to view the attacker’s access to /version2.php, we find that both the request body and response body are encoded content, suggesting an encrypted communication tunnel.

In Wireshark, using the syntax http.request.uri contains index.php?user-app-register to view the attacker’s access to /index.php?user-app-register, we find that both the request body and response body are encoded content, indicating webshell communication.

After asking GPT, it also confirmed it was a webshell.

Therefore, we judge that /index.php?user-app-register is the webshell first used by the attacker, and /version2.php is the backdoor trojan subsequently used by the attacker.

IV. Submitting the Webshell Connection Password

Reviewing the communication content of /version2.php, we find that Network2020 is the webshell connection password.

V. Submitting the flag1 from the Data Packet

Using the command cat /www/wwwlogs/127.0.0.1.log | grep 192.168. | cut -d ' ' -f 7 | uniq -c | less to view the URLs accessed by the attacker.

We find that the attacker accessed the file /flag1.

However, the /flag1 file is not in the web path; later review of the history shows it was deleted.

Downloading the data packet “/root/æ•°æźćŒ…1.pcapng” from the server to my local machine, opening Wireshark and using the syntax http.request.uri contains flag1 to search for the attacker’s access to the /flag1 file, and then using “Follow TCP Stream” to obtain the content of the /flag1 file: flag1{Network@_2020_Hack}.

VI. Submitting the Name of the Trojan File Subsequently Uploaded by the Attacker

In question 3, we already confirmed that the name of the subsequently uploaded trojan file is: version2.php.

VII. Submitting the Attacker’s Hidden flag2

Using the command history | grep vi to view the command history, and filtering for edited files using grep vi, we find the following edited files are noteworthy: .api, mpnotify.php, alinotify.php, /etc/profile.

Using commands like find / -name .api 2>/dev/null to view the file path, and then less /www/wwwroot/127.0.0.1/.api to view the file content.

Finally, we find flag2 in the file /www/wwwroot/127.0.0.1/.api/alinotify.php: flag{bL5Frin6JVwVw7tJBdqXlHCMVpAenXI9In9}.

VIII. Submitting the Attacker’s Hidden flag3

Using the command less /etc/profile to view the /etc/profile file identified in question 7, we find flag3: flag{5LourqoFt5d2zyOVUoVPJbOmeVmoKgcy6OZ}.

Using the command history to view the command history, we also obtain flag3.

Share this