SOC167 - LS Command Detected in Requested URL

Tackling another LetsDefend alert! This time it looks like we're dealing with a basic command found in a requested URL. Let's see if we should be worried.

Immediately looking at the alert details, I could see why this alert was triggered. The end of the URL contains the word "skills," the last two letters of which are "ls." Ls is a typical Linux-based terminal command used to enumerate the contents of the current directory. Our SIEM alert must be configured to detect basic commands like "ls" within web traffic logs to warn us of potential command injections. In this case, I'm not too worried, but I followed the playbook just to be sure.

As expected, I discovered the source IP belonged to a device on the network. I looked through its browser history and confirmed that it had requested the URL detected in the alert. The destination IP belonging to the URL was not very concerning, as indicated by a VirusTotal scan. The IP subnet also belonged to CloudFlare, which doesn't absolve suspicion but didn't raise any immediate flags. AbuseIPDB actually listed the IP in their whitelist!

The HTTP logs showed that there were other traffic requests, but they were expected as the user was navigating between pages on the letsdefend[.]io domain. The other requested URLs did not contain evidence of abnormalities like command injection or suspicious queries. The requested URL of interest was a simple case of the user querying the "skills" parameter on the letsdefend[.]io/blog webpage.

Just for safety, I checked the network, command and process history on the device. I didn't see any evidence of foul play or intrusion.

We defined in our playbook that the traffic was therefore not malicious, reported our artifacts, added our final conclusions and closed the alert.