Scribd
Upload
2 views

LetsDefend Practice Solution

The document outlines a step-by-step procedure for investigating a SQL injection alert detected by LetsDefend. It includes checking alert details, validating external IP reputation, escalating true positives to formal cases, and analyzing log responses. The investigation confirmed a malicious attempt from IP 167.99.19.17, which was unsuccessful, and no further escalation was required.

Uploaded by

Sreekanth Daravath
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
2 views

LetsDefend Practice Solution

The document outlines a step-by-step procedure for investigating a SQL injection alert detected by LetsDefend. It includes checking alert details, validating external IP reputation, escalating true positives to formal cases, and analyzing log responses. The investigation confirmed a malicious attempt from IP 167.99.19.17, which was unsuccessful, and no further escalation was required.

Uploaded by

Sreekanth Daravath
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

LetsDefend Practice solution for alert

“SOC165 - Possible SQL Injection Payload Detected EventID: 115"

Solution by JITESH KUMAR


1. Check the alert in the investigation channel in LetsDefend portal.

Begin by logging into the LetsDefend Portal and navigating to the Investigation channel.
This is where active alerts are presented for review and action by the SOC team.

2. Review alert details

Click on the alert to expand and examine its metadata and context. It’s important to
take a careful look at all available fields before proceeding. During this phase, you'll
want to collect several key pieces of evidence that may be crucial for further
investigation or escalation.

Evidence to Collect from the Alert

Make sure to document the following details from the alert panel:

a. Date and time of alerts triggered.


b. Direction of traffic
c. Reason for triggering an alert
d. HTTP method
e. Action taken
f. Requested URL

3. Check External IP Reputation

To validate the threat, it’s important to check the reputation of any external IP
addresses involved in the alert.

Here are some trusted open-source Threat Intelligence (TI) platforms to use:
• VirusTotal – Aggregate of multiple AV engines and reputation scores.

• AbuseIPDB – Community-driven database of reported abusive IPs.

• Hybrid Analysis – Behavioral analysis of suspicious files and URLs.

• Talos Intelligence – Cisco’s threat database for IP/domain reputation.

4. Escalate to a Case (True Positive)

If your initial investigation confirms the alert as a True Positive, the next step is to
escalate it for full incident response.

Here’s how to create a case in LetsDefend:

1. In the Investigation view, locate the Attack Type column for the alert.

2. Click the double arrow icon next to the attack type.

3. This action converts the alert into a case and links it to the appropriate playbook
for further steps.

This process ensures the alert is now tracked as a formal incident, with workflows and
containment/remediation tasks assigned.

5. The Case and Playbook Are Now Active

Once a case is created, LetsDefend automatically links a predefined playbook based


on the attack type.
Here’s what you can expect:

• A structured workflow tailored to the threat (e.g., phishing, malware, C2 traffic).

• Tasks for gathering more evidence, containment, remediation, and reporting.

• The ability to collaborate with team members inside the case dashboard.

6. Begin Playbook – Understand Triggering RulesAnswer –

The first step in the playbook is to understand the specific rule that triggered the
alert, including:

• Trigger Reason: Requested URL Contains OR 1 = 1


→ This is a classic SQL Injection pattern, often used to manipulate or bypass
authentication.

• Traffic Direction: Inbound


→ Indicates that the suspicious request originated from the internet targeting
an internal asset.

• Protocol Used: Identified via logs (typically HTTP/HTTPS for web-based attacks)

Note: Navigate to Log Management and search using either the source IP or
destination IP to view the full event context and request payloads.
7. Identify IP and Device Ownership.

Understanding who owns the source and destination devices is critical in validating the
scope and impact of the alert.

➔ If Source Is External (Internet):

• Check ownership of the IP (e.g., is it from a VPS, web hosting, or proxy provider?)

• Determine if it’s a static or pooled address

• Confirm its reputation via:

o VirusTotal

o AbuseIPDB

o Cisco Talos

In our case:

• Source IP: 167.99.19.17

• Confirmed Malicious: Traffic is from the Internet

➔ If Destination Is Internal:

• Go to Endpoint Security

• Search for the destination machine by IP

• Collect:

o Hostname: WebServer100

o Operating System: Windows Server 2019

o Primary User: webadmin

o Last User Logon Time: Checked and recorded


Note: No suspicious processes or logon activity were found on the destination host.

8. Analyze Log Response Codes

Upon reviewing the logs:

• Most events returned HTTP response code 500, indicating the server rejected the
request.

• One event returned 200, but analyzing the overall pattern confirms the attack
attempt failed.

This is a common behavior when input validation or security controls block malformed
or malicious requests.

9. Complete the Playbook Questions

Here’s a summary of the playbook’s key questions and answers:

➔ Question Answer
a. Is Traffic Malicious? Yes (SQL code in decoded URL)
b. What Is the Attack Type? SQL Injection
c. Was this part of a planned test? No
d. What Is the Direction of Traffic? Internet ➝ Company Network
e. Was the Attack Successful? No (Rejected with HTTP 500)
f. Is Tier 2 Escalation Required? No

10. Add Artifacts

Be sure to log all observables in the case:

Source IP (Malicious): 167.99.19.17

11. Add Notes to the Case:

External attacker 167.99.19.17, a known malicious IP, attempted to exploit the internal
web server (WebServer100) by injecting SQL code. The HTTP request method used was
GET, but the server denied the request with a 500-response code, indicating rejection.
No signs of successful exploitation were found."

12. Close the Alert with Final Statement

Closing Summary:
This was a true positive alert involving an actual SQL injection attempt from an external
attacker. The source IP 167.99.19.17 is malicious and attempted to exploit an internal
web server. The attack was unsuccessful — confirmed via HTTP 500 response codes
and absence of suspicious activity on the host. No escalation is required. All related
logs indicate SQL injection attempts only.

You might also like