LetsDefend SOC167 – LS Command Detected in Requested URL

Introduction

This post walks through my investigation of a “High” severity alert in the LetsDefend SOC platform. The case centers around EventID: 117 (Rule: SOC167 – LS Command Detected in Requested URL), which at first glance appears suspicious but ultimately proves to be a classic false positive. Below is a step-by-step breakdown of the investigation, supported by screenshots throughout the analysis.

Alert Overview

The alert triggered on February 27, 2022, at 12:36 AM, when the SIEM detected the substring “ls” in a requested URL. This is commonly used to flag potential command injection attempts, as “ls” is a basic Linux shell command.

Event & Endpoint Details

• Source Device: EliotPRD (172.16.17.46, Ubuntu 16.04.4)

• Destination: 188.114.96.15 (letsdefend.io)

• Request URL: https://letsdefend.io/blog/?s=skills

• Method: GET

• Device Action: Permitted

Network Actions Timeline

Multiple network connections from the source device to the letsdefend.io IP address, matching normal web browsing activity.

Browser History Review

Reviewing the user’s browser history confirms only benign activity, with requests to various blog pages on letsdefend.io, including a search for “skills.”

Guided Investigation Step 1: Understand the Trigger

The rule flagged the presence of “ls” in the URL because “ls” is in word “skills” rather than a malicious command.

Guided Investigation Step 2: Collect Data

Key questions at this stage include who owns the IP addresses, which way the traffic is flowing, device ownership/user identity, and recent login history.

Guided Investigation Step 3: Examine HTTP Traffic

No evidence of web attack payloads, such as SQLi, XSS, or command injection, was found in the traffic content.

Guided Investigation Step 4: Malicious or Not?

Based on the investigation, the traffic was non-malicious, as it was just a blog search for “skills.”

Guided Investigation Step 5: Check for Other Traffic

Yes, there were other HTTP requests, but after cross-checking for suspicious requests or behaviors from the same source confirmed all activity was normal.

Analyst Note Entry

My Analyst Note:
“It detected the ls command in the url from the word skills which makes it non malicious.”

Closing the Alert as False Positive

Marking the alert as a False Positive with a supporting note.

Case Closed – SOC Summary

Case Review:

“It detected the ls command in the url from the word skills which makes it non malicious.
When the Request URL is examined, it is seen that the word “skills” is searched on the LetsDefend Blog page. However, the letters “ls” at the end of the word caused the rule to be triggered incorrectly. It is a false positive alarm.
To be sure, when the Browser History of the device is examined from the Endpoint Security page, it is confirmed that there is no attack.”

Summary & Lessons Learned

This case is a textbook example of how overly broad SIEM rules can generate false positives. Context matters: while “ls” is a sensitive keyword, substring matches within safe words like “skills” can lead to incorrect alerts. Careful analysis of browser history and network activity is critical to avoid wasting time on non-issues.

Key Takeaways:

• Always check the context of suspicious keywords in alerts.

• Review endpoint/browser/network history before escalating.

• False positives are a normal part of SOC work.