Comprehensive Guide to Emergency Response Training in Cybersecurity Incident Investigation

Download the target environment (Challenge here! Emergency Response Training – Web2) and set up the environment. Use the account credentials (administrator / [email protected]) to log into the target machine.

1. What are the attacker’s IP addresses (two)?

Open phpStudy to check middleware logs and notice that Nginx has no logs while Apache has logs.

Copy Apache’s accesslog to Kali for analysis using the command cat access.log.1709164800 | grep -v "404\|js\|css", which reveals that only 192.168.126.135 has access records.

The accessed /system.php does not resemble a normal web address provided by a site, and upon opening, it’s found to be a web shell. Therefore, 192.168.126.135 is an attacker’s IP address.

Open Computer Management using compmgmt.msc and in System Tools -> Event Viewer -> Windows Logs -> Security, click Filter Current Log. Filter logs for Event ID 4624 (successful login) and find that 192.168.126.129 had logged in before.

Click Filter Current Log and filter for Event ID 4625 (failed login). No logs are found, which cannot prove that 192.168.126.129 was involved in brute force behavior or that it is an attacker’s IP address.

Reviewing the timestamps when the web shell was accessed, it coincidentally aligns with 192.168.126.129’s login. It is suspected that the attacker might create an operating system account through the web shell and then log in.

Click Filter Current Log and filter for Event ID 4720, the account creation logs, and the timings match. Therefore, 192.168.126.129 is an attacker’s IP address.

2. What is the attacker’s web shell file name?

From Question 1, it was identified as system.php.

3. What is the attacker’s fake QQ number?

Open File Explorer and in “Quick Access,” find the “frp_0.54.0_windows_amd64” folder.

Upon entering, it’s surprisingly under the QQ folder, revealing that the FRP file was received via QQ, providing the QQ number: 777888999321.

4. What is the attacker’s fake server IP address?

Open the frp configuration file “frpc.ini” to obtain the attacker’s server IP address: 256.256.66.88.

5. What is the attacker’s server port?

Open the frp configuration file “frpc.ini” to obtain the attacker’s server port: 65536.

6. How did the attacker compromise the system (multiple-choice)?

1. Not a web attack.

From the web access logs acquired in Question 1, the attacker did not brute force a weak admin password but logged in directly. There were no POST requests to upload the web shell; it was directly accessed. Therefore, the web is not the entry point.

2. Not a database attack.

Start Apache and MySQL through phpStudy and check the database password.

After logging into the database locally, use the command show variables like '%general%'; to check if logging is enabled and the log file location. Logging is not enabled, and no log files exist, so it’s impossible to determine if the database was attacked.

Attempt to log in to the database remotely and find that it fails, indicating local login only. Thus, the attacker could not remotely attack the database.

3. It was an FTP attack.

Check the FTP logs and find numerous failed login attempts by 192.168.126.135, suggesting brute force of a weak FTP password.

The attacker eventually succeeded, seemingly cracking the weak FTP password.

The web shell file system.php was uploaded, indicating FTP serves as the attack entry point. The attacker initially gained FTP access through a weak password vulnerability, then uploaded the web shell to the web path, and subsequently created an RDP account via the web shell to log into the OS through RDP.

4. Not an RDP attack.

During Question 1 filtering for Event ID 4625, no failed login logs were found, suggesting no RDP brute-force activity (or the attacker deleted the 4625 logs), confirming RDP was not used as the entry point.

7. What is the attacker’s hidden username?

Use the command compmgmt.msc to open Computer Management under System Tools -> Local Users and Groups -> Users to find