LetsDefend SOC127 - SQL Injection Detected

Above is the screenshot of the alert that we are going to investigate.

We start with taking the ownership of the alert and then head to the investigation channel.

Now we create the case for this alert.

The next thing for us to do is starting the playbook.

The next thing I do is copy the url from the Request URL field and head to CyberChef to URL Decode it:

It code looks like a malicious HTTP GET request trying to combine multiple attacks into one command:

1. SQL Injection (Boolean + Union-Based)
   The attacker injects AND 1=1 to confirm the parameter is vulnerable, followed by a UNION ALL SELECT query to extract table_name from information_schema.tables. This aims to enumerate the database schema.

2. Reflected XSS Payload
   The string 'alert("XSS")' is injected into the UNION query. If unsanitized in the HTTP response, it will execute JavaScript in the victim's browser — used for session hijacking.

3. Command Injection via xp_cmdshell
   The attacker calls xp_cmdshell('cat ../../../etc/passwd'), a SQL Server stored procedure that runs OS-level commands. This attempts to read the system's password file, indicating privilege escalation or host compromise. (I looked up the use of the command)

4. Evasion Techniques Observed
   The payload uses --/**/ to break the comment without spaces (bypassing naive WAF rules) and a # at the end to terminate the query early. The 200 OK response suggests the server executed at least part of the request.

The HTTP GET request contains HTTP/1.1 200 865, here the number 200 means that the attack was successful.

We can conclude that it is malicious

We can answer this easily, it is the name of the alert: SQL Injection

We go to the Email Security tab and check for the hostnames and IP addresses and check for any email that may be regarding a planned test, alas we find none.

Next we go to VirusTotal and check the reputation of the Source IP address:

9/94 vendors flag this IP as malicious, so we can say it is malicious, with low confidence.

It was NOT a planned test.

The destination IP is a part of the company network, and the source IP, as we know, is an external IP.
Internet -> Company Network

YES, the attack was successful since we can see the code 200 in the HTTP Request

Now we move on to the containment phase.

Artifacts added:

Do we need Tier 2 escalation? Answer: Yes, since we know the attack was successful.

After adding Analyst's notes, we close the playbook:

Now we close the alert:

True positive alert, malicious HTTP traffic detected and successful on our internal server. Escalation to Tier 2 needed for deeper investigation and forensics