“ SOC167 — LS Command Detected in Requested URL” investigation

Hello, today I will write about investigation of “SOC167 — LS Command Detected in Requested URL” alarm from letdefend.io.

The alert is appears in our investigation channel. After that, we proceed to build the case.

Let’s start the playbook.

The first step of the playbook is asking us to understand why the alert was triggered.

To understand the alert, we are supposed to examine the rule name. The rule name mentions of the URL Containing the Linux command LS which lists the contents of the directory the user is in.

The next step then asks us to determine the traffic path on which it is occurring.

The playbook’s next phase instructs us to Collect data.

· Ownership of the IP addresses and devices.

Checking the Endpoint management displays that the address 172.16.17.46 belongs to EliotPRD.

o 172.16.17.46 (EliotPRD)

o 188.114.96.15 (Internet Address)

· If the traffic is coming from outside (Internet);

Ownership of IP address (Static or Pool Address? Who owns it? Is it web hosting?)

· We can verify that it is a Static Address. We are able to determine that the device is being web hosted on the Cloudflare ISP using abuseIPDB, a centralized database for abusive IP addresses. The IP does not have a large enough report history to be deemed malicious.

Reputation of IP Address (Search in VirusTotal, AbuseIPDB, Cisco Talos)

Neutral

Next, we are advised to look for probable web attack payloads in the HTTP traffic.

The next step is to determine whether the traffic is malicious. We are able to mark the traffic as malicious simply based on the IP address and its reputation. We can perform log analysis in the log management to verify our suspicions.

We start our search for the 188.114.96.15 IP in the Log Management section, and we find several logs that show communication between the Web server and it.

According to the logs, there doesn’t appear to be any malicious traffic between the two machines, since all of it appears to be from a regular user visiting the letsdefend.io domain on various websites.

In this particular Request URL (https://letsdefend.io/blog/?s=skills), we discover the one log that most likely caused the ls warning. This, in my opinion, is a sign of a false positive because the alert was improperly triggered.

Since the traffic shows all the characteristics of typical user behavior, we can say with confidence that it is not malicious.

The next stage in the playbook instructs us to look for further traffic coming from the same source address that could have possibly triggered the alert. We can confirm there is since the Logs show many different instances between the two devices, but non-malicious.

Summary: