LetsDefend

Introduction

This post walks through my investigation of a “High” severity alert in the LetsDefend SOC platform. The case centers around EventID: 120 (Rule: SOC170 – Passwd Found in Requested URL – Possible LFI Attack), which at first glance appears suspicious since the requested URL contains directory traversal into the /etc/passwd/ file on a Web Server.

Alert Overview

The alert triggered on March 01, 2022, at 10:10 AM, when the SIEM detected the string passwd in a requested URL

https://172.16.17.13/?file=../../../../etc/passwd

This path is a classic indicator of a Local File Inclusion (LFI) attack, where an attacker attempts to access sensitive files by manipulating input parameters.

• EventID: 120

• Rule: SOC170 – Passwd Found in Requested URL – Possible LFI Attack

• Level: Security Analyst

• Hostname: WebServer1006

• Destination IP Address: 172.16.17.13 (letsdefend.io)

• Source IP Address: 106.55.45.162 (Internet)

• Request Method: GET

• User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

Event & Endpoint Details

Raw Log Evidence

• Request URL:
  https://172.16.17.13/?file=../../../../etc/passwd

• User-Agent:
  Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

• HTTP Method: GET

• Device Action: Permitted

• HTTP Response: 500 (0 bytes)

Log Management View

Filtering by destination IP confirms the event:

Endpoint Security View

• No direct endpoint match for the source IP (attacker) was found within the company network.

Analysis Steps

A. Understanding Why the Alert Triggered

• The rule is designed to catch attempts to access sensitive files like /etc/passwd through directory traversal (LFI) attacks.

• The attacker tried a classic payload by injecting the following into the URL.  ../../../../etc/passwd

B. Collect Data

• Source IP: 106.55.45.162 (Attacker, external)

• Destination IP: 172.16.17.13 (Web Server, internal)

• Direction: Internet → Company Network

C. Examine HTTP Traffic

• The HTTP request was made from the external IP to the internal web server, targeting a sensitive Linux file.

• Response status was 500 with 0 bytes, suggesting the attack was not successful (the web server likely crashed or timed out rather than serving the file).

Investigation Results

Was the Traffic Malicious?

Yes – The traffic matched the signature of an LFI attack, targeting sensitive files.

Attack Type

• LFI (Local File Inclusion)

• The goal was to retrieve sensitive contents from the web server’s file system

Was This a Planned Test?

• No –there was no evidence of a planned test

Direction of Traffic

• Internet → Company Network

Was the Attack Successful?

No – The web server responded with a 500 status code and did not return any data.

Artifacts

• Attacker IP: 106.55.45.162

• Target IP: 172.16.17.13

Escalation Decision

Because the attack was unsuccessful (no sensitive data was exfiltrated), Tier 2 escalation was not required.

Analyst Note

The attacker’s IP is 106.55.45.162, which attempted an LFI attack on the Web Server 172.16.17.13, but was unsuccessful because the web server timed out. HTTP Response =  500 with 0 bytes.

Close Alert

The alert was closed as a True Positive (malicious activity detected), but due to the server’s configuration and timely error response, no harm was done. Escalation was not needed as there was no evidence of compromise.

Lessons Learned

• Directory traversal and LFI attacks remain common techniques for probing web servers.

• Even unsuccessful attacks provide valuable information about adversary behavior.

• Properly handling errors and input validation on web applications is essential to prevent exploitation.

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.