Today, we are looking into a security incident on the Linux server gitServer (172.16.20.4), where a suspicious request was detected targeting a vulnerable web application. The alert was triggered after an attempt to exploit a Local File Inclusion (LFI) vulnerability using directory traversal to access the sensitive file /etc/passwd. Although the request was allowed by the server, the response resulted in a 404 error, indicating that the attack was not successful. However, this activity is closely linked to a previous malicious file upload attempt, showing clear signs of an ongoing attack against the server.

EventID : 63 Event Time : Feb, 21, 2021, 05:02 PM Rule : SOC129 — Successful Local File Inclusion Level : Security Analyst Source Address : 49.234.71.65 Source Hostname : unknown Destination Address : 172.16.20.4 Destination Hostname : gitServer Username : www-data Request URL : 172.16.20.4/srcCode/show.php?page=../../../../../../../etc/passwd User Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Type : Proxy Device Action : Allowed

Before starting the investigation, let us understand what local file inclusion is.

What is Local File Inclusion?

None
Fig 1. Local File Inclusion Attack Path

Local File Inclusion (LFI) is a type of security vulnerability found in some websites where an attacker can trick the system into loading files from the server that it should not normally show. This usually happens when a website takes user input (like a file name in a URL) and does not properly check it before using it. Because of this, a hacker might be able to access sensitive files such as system data or configuration files, and in some cases even run malicious code. It mainly occurs due to poor input validation and can be dangerous if not fixed properly.

On Feb 21, 2021, at 05:02 PM, the source IP 49.234.71.65 sent a GET request to the Ubuntu server (172.16.20.4) targeting the URL /srcCode/show.php?page=../../../../../../../etc/passwd. In this request, the attacker used the username 'www-data', attempting to access sensitive system files through the vulnerable parameter.

None
Fig 2. srcCode/show.php?page=../../../../../../../etc/passwd web request

That URL is a Local File Inclusion (LFI) attack using directory traversal. Here, the parameter page=../../../../../../../etc/passwd is trying to move out of the current folder (using ../ multiple times) and access the system file /etc/passwd, which exists on Linux servers. If the web server is vulnerable, it will include and display the contents of that file. Attackers use this technique to read sensitive files from the server, which can expose user information or system details. In the alert page, it is showing Allowed means our server or firewall did not block that request.

This activity is related to our previous case raised on 22–03–2026 (Alert: SOC128 — Malicious File Upload Attempt, Event ID: 62). In that case, the attacker exploited the same vulnerable endpoint /srcCode/show.php and attempted a file upload. Interestingly, the LFI attempt in this case happened one day before the file upload activity.

What is /srcCode/show.php

/srcCode/show.php on an Ubuntu server is simply a file path pointing to a PHP script named show.php inside a directory called srcCode at the root (/) of the filesystem; it is not a standard or built-in Ubuntu file, but rather something created by a developer or application. In typical use, this file would be part of a web application and executed by a web server like Apache HTTP Server or Nginx with PHP support, meaning when accessed via a browser, the PHP code inside show.php runs on the server and outputs dynamic content (such as displaying data from a database or rendering a page). The /srcCode directory name suggests it might store source code files.

As discussed in the previous blog, on Feb 22, 2021, the attacker first sent a request to /srcCode/upload.php at 04:31 PM, followed by accessing /srcCode/phpshell.php?cmd=whoami at 04:32 PM, and then /srcCode/phpshell.php?cmd=cat /etc/passwd at 04:33 PM. All these requests were allowed, which clearly shows the attacker was able to upload and interact with a web shell.

None
Fig 3. Ougoing web request from the server (172.16.20.4) to the source IP 49.234.71.65

Coming back to this case, at Feb 21, 2021, 05:02 PM, there were also two response attempts from the server (172.16.20.4) to the source IP 49.234.71.65, but both resulted in 404 errors. This indicates that while the attack request was accepted, the actual file access was not successful.

The user agent shows the request was made from a Mac system (Mac OS X 10.14.4) using a WebKit-based browser, likely Safari.

None
Fig 4. Source IP Address Reputation

The source IP 49.234.71.65 belongs to Tencent Cloud (Beijing, China) and has been previously reported for suspicious activities like SSH and brute-force attempts, which further strengthens the malicious intent behind this activity.

Attack Timeline

  1. 21 Feb 2021, 05:02 PM — The attacker initiated an LFI attack against the vulnerable parameter in /srcCode/show.php, using directory traversal (../../../../../../../etc/passwd) to attempt access to the /etc/passwd file.
  2. 21 Feb 2021, 05:02 PM — The server processed the request and returned a 404 response, indicating the file was not successfully retrieved.
  3. 22 Feb 2021, 04:31 PM — The attacker exploited the /srcCode/upload.php endpoint to upload a malicious file as part of a webshell deployment attempt.
  4. 22 Feb 2021, 04:32 PM — The attacker accessed the uploaded webshell (phpshell.php) and executed the command whoami to confirm remote command execution capability.
  5. 22 Feb 2021, 04:33 PM — The attacker further escalated activity by executing /srcCode/phpshell.php?cmd=cat /etc/passwd, retrieving sensitive system user information from the host.
None
Fig 5. Attack Flow Diagram

MITRE Mapping

None
Fig 6. MITRE Attack Mapping

Let's Defend Playbook Answer

  1. Analyze URL Address. Analyze URL in 3rd party tools. Please click "Malicious" if it is malicious and click "Non-malicious" if it isn't. Malicious.
  2. Has Anyone Accessed IP/URL/Domain? Not Accessed

Containment Actions

  1. The machine is isolated from the network to prevent further attacker interaction or lateral movement.
  2. Block the source IP (49.234.71.65) at the firewall, WAF, and proxy level to stop further requests.
  3. Disable or restrict access to vulnerable endpoints such as /srcCode/show.php, /srcCode/upload.php, and any file handling scripts.
  4. Temporarily disable web access to the application if full isolation is not possible.

Eradication Actions

  1. Identify and remove any malicious files, such as uploaded webshells (e.g., phpshell.php) from the server.
  2. Conduct a full scan of the web directory for hidden backdoors, modified scripts, or unauthorized files.
  3. Patch the Local File Inclusion (LFI) vulnerability in show.php by implementing strict input validation and whitelisting allowed file paths.
  4. Fix the file upload vulnerability by enforcing file type validation, renaming uploads, and disabling execution permissions in upload directories.
  5. Review and clean up any unauthorized system changes or suspicious cron jobs/users created during compromise.
  6. Apply security patches to the application and underlying OS if outdated components are present.
  7. Restart services only after validation that the system is clean and secure.

Incident Artifacts

Source IP Address: 49.234.71.65 Destination IP Address: 172.16.20.4 (gitServer Ubuntu server) Affected Application: /srcCode/show.php (vulnerable endpoint) Additional Endpoints Involved: /srcCode/upload.php, /srcCode/phpshell.php Malicious Request URL (LFI attempt): /srcCode/show.php?page=../../../../../../../etc/passwd Webshell Command Execution URLs: /srcCode/phpshell.php?cmd=whoami, /srcCode/phpshell.php?cmd=cat /etc/passwd User Account Observed: www-data User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) (Safari/WebKit-based browser)

Conclusion

This incident shows a clear attempt by the attacker to exploit a vulnerable web application on the gitServer. The attack started with an LFI attempt, followed by file upload and webshell execution activities on the next day. Although the initial LFI request did not succeed, the same host later appears to have been compromised through a successful upload and command execution flow, indicating an ongoing and targeted attack against the system.