“ SOC165 — Possible SQL Injection Payload Detected” investigation

4 min readNov 28, 2022

Hello, today I will write about investigation of “SOC165 — Possible SQL Injection Payload Detected” 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 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.18 belongs to WebServer1002.

o 172.16.17.18 (WebServer1001)

o 167.99.169.17 (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 using the DigitalOcean ISP on a ubuntu-20.04 host using abuseIPDB, a centralized database for abusive IP addresses.

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

Malicious

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

We can see from the requested URL that the request contained JavaScript code.

https://172.16.17.18/search/?q=%22%20OR%201%20%3D%201%20--%20-

We begin by running the Requested URL through a URL Decoder we get the following query, “https://172.16.17.18/search/?q=" OR 1 = 1 — -” which we can safely say is an attempted SQL (Structured Query Language) Injection attack. Requested URL is essentially asking is to search the 172.16.17.18 host or 1 = 1. The query will always be true as a result of the 1=1.

After that, we asked to determine if the traffic is malicious. I believe the URL gave all the signs of malicious traffic due to obvious query and a malicious IP.

We see that the attack type is an SQL Injection.

Search for associated artifacts from the alert in Mailbox, such as the source IP, destination IP, or server name, but nothing appears to be connected, therefore this was not planned.

We are required to determine the direction of traffic while look back to the alert.

The alert’s 167.99.169.17 source address is external to the company network. WebServer1002, 172.16.17.18, is the internal destination address. This denotes a direction flow on the Internet → Company Network.

We are next instructed to determine whether or not the attack was successful.

I noticed multiple records of connections being attempted to the WebServer1002 address, 172.16.17.18, while I searched the logs using the malicious address, 167.99.169.17.

Looking at the raw logs for each instance, the HTTP Response Size and Status were the same at 948 and 500 respectively each log, an indication that the SQL Injection attack not being successful.

Then I made the decision to run each Request URL that I had discovered in each raw log through the URL Decoder. I discovered that they had all been probed numerous times, each time with a separate SQL Injection attack attempt.

As a result, we can conclude that the attack was not successful.