This time we have a quick little task to deal with in the form of someone possibly trying to access the passwd file on a webhost with a local file inclusion attack technique. So let’s start our playbook and let’s start defending.
Alert
We get an alert from the SIEM stating that Passwd Found in Requested URL - Possible LFI Attack. The description is rather straightforward, and tells us that someone was trying to access the passwd file on our webserver in order to get access to user credentials for further penetration.
Detection
The actual Request URL listed in the alert is https://172.16.17.13/?file=../../../../etc/passwd, but from the logs we can immediately see that the HTTP Response Status 500 (Internal Server Error) and HTTP Response Size: 0 tell us that the attack wasn’t successful, and the rather obvious reason for this is that we are dealing with a Windows-based host, yet the attack is aimed at a Linux host.
Nevertheless, to cover our bases we should still check it out for future reference.
Analysis
Is The Traffic Malicious?
Yes, it very much is, as the objective of a LFI attack is to access the local filesystem on the host, and in this case the passwd file to gather essential information about the users and user accounts on the system, which can then in turn be used for further attacks.
What Is the Attack Type?
Local File Inclusion, LFI.
What Is the Direction of Traffic?
Since we know both IP addresses, we can see that the direction of the traffic is Internet -> Company Network (106.55.45.162 -> 172.16.17.13). For further investigation we can use tools like VirusTotal, AbuseIPDB, and Cisco Talos to look up the reputational data of the attacking IP address in question. In our case, we can see that the IP address originates from China, and is suspicious at best, malicious at worst.
It’s good to keep in mind that IP addresses can and will change and be rotated, so a clean record is not necessarily an indication of smooth sailing, but here we have enough red flags to confirm our suspicions on the IP being used for malicious purposes.
Is the Malicious Traffic Caused by a Planned Test?
We can check our Mailbox to find no notification in relation to any planned test, so we can safely assume that this is not a drill and that the alert and attack are genuine.
Check Whether the Attack Was Successful
As we already established in the beginning, the HTTP Response Status 500 (Internal Server Error) and HTTP Response Size: 0 tell us that the attack wasn’t successful, and the main reason for this was that the operating system on the host isn’t a one the attacker wanted to target.
Do You Need Tier 2 Escalation?
Since the attack was unsuccessful there is no reason to escalate this alert, we can handle it all on our own. There is also no need to contain the host, as it isn’t vulnerable to this attack nor did any kind of breach occur.
All in all, this was indeed a True Positive, but due to the LFI target being a Linux host and our host being Windows, the attack was thwarted by incompatible operating system so we can close this alert without any further action being needed.
Lessons Learned
Knowing what to look for, we can immediately see from the logs that the attack failed, and while that would be enough to close the task and move on, we may want to make sure that the attacker isn’t going around our network trying to find hosts that could or would actually be vulnerable to this attack.
Artifacts
https://172.16.17.13/?file=../../../../etc/passwd - While our SIEM did already catch the /etc/passwd in the URL in its ruleset like it should, we should note it down as a meaningful component of the attempted attack.
106.55.45.162 - Source IP Address, which we could possibly blacklist if this is the approach we’re taking with our firewall. But in any case the IP address should be reported for the attack.