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.
> />
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.
> />
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.