Investigating web attacks as a SOC Analyst - Possible SQL Injection

In this writeup we will be investigating a security alert related to SQL Injection on LetsDefend plateform. Let’s start 🎯

Security Alert

Alert

The case we’ve been assigned is an SQL Injection alert with some details such as event ID, source and destination IP address, the URL requested and much more as shown in the screenshot below :


incident details

Understand Why the Alert Was Triggered

In order to perform a better analysis and to determine whether the triggered alert is false positive, it is first necessary to understand why the rule was triggered. We can examine the rule name to identify the attack we’re facing and understand the direction of traffic, the IP addresses,etc.

From the incident details we can extract some key information like the requested URL that contains some strings related to SQL Injection, the attacker IP address (source IP) which is 167.99.169.17 and the victim IP address (destination IP) which is 172.16.17.18

It’s time to start the analysis and detection phase !

Detection and Analysis

Examine Logs

In the log management pane I searched for all the events related to this case trough the following query :


Log Search Query

I found 6 events. Let’s analyze all of them :
🚩 First event:


First event

Here the attacker has accessed directly the victim URL and the response was 200 (OK).
🚩 Second event:


Second event

The attacker requested a sub-page of the same URL but it seems to be suspicious.
🚩 Third event:


Third event

Another sub-page with another string characters. I used the online URL decoder urldecoder.org to decode these URLs :


decoded URL

It’s an SQL Injection payload !

🚩 Fourth event:


Fourth event

Server response is 500 => Injection was unsuccessful.

🚩 Fifth event:


Fifth event


decoded URL

Server response is 500 => Injection was unsuccessful.

🚩 Sixth event:


Sixth event


Sixth event

Server response is 500 => Injection was unsuccessful.

📌 Summary of requested URLs:

Reuested URL	Reuested URL After Decoding
172.16.17.18/search/?q=%27	172.16.17.18/search/?q='
172.16.17.18/search/?q=%27%20OR%20%271	172.16.17.18/search/?q='OR '1
172.16.17.18/search/?q=%27%20OR%20%27x%27%3D%27x	172.16.17.18/search/?q=' OR 'x'='x
172.16.17.18/search/?q=1%27%20ORDER%20BY%203--%2B	172.16.17.18/search/?q=1' ORDER BY 3--+
172.16.17.18/search/?q=%22%20OR%201%20%3D%201%20--%20-	172.16.17.18/search/?q=" OR 1 = 1 -- -

After URL Decoding, it’s confirmed that it is SQL Injection

IP Reputation

I will check the source IP reputaion on ViruTotal and AbuseIPDB:


IP Reputation on ViruTotal


IP Reputation on AbuseIPDB

The source IP address is definitely malicious !

Further Investigation

As we can conclude from previous log analysis that the HTTP response is 500 essentially meaning that the server side could not fulfill the request. Thus, the SQL injection did not work. But we can conduct some further investigations by looking at the “Command History” of the relevant device via Endpoint Security. In SQL Injection attacks, attackers can run commands on the device with the help of functions such as "xp_cmdshell".
Let’s check the Command History of the target IP:


Target Endpoint Information


Terminal History

The Command History of the target IP is clean. From all the previous analysis and investigations we can confirm that the SQL Injection attack was unsuccessful.

Do We Need Tier 2 Escalation?

Tier 2 escalation should be performed in the following situations:

In cases where the attack succeeds,
When the attacker compromises a device in the internal network (in cases where the direction of harmful traffic is from inside → inside)

Tier 2 escalation is not required in the following cases:

In cases where attacks from the Internet do not succeed

Institutions may have their own escalation procedure. Professional analysts should learn about the escalation procedure in their institution.

In our case No Tier 2 Escalation is needed to be performed.

Artifacts

I will add the attacker IP address (source IP) as an artifact to our EDR (Endpoint Detection and Response) tool.


Adding artifacts

Playbook

A security playbook is a list of required steps and actions needed to successfully respond to any incident or threat.
We will answer the following questions :

Is Traffic Malicious? Yes, Malicious
What is the attack vector in the malicious traffic you have detected as a result of your investigations? SQL Injection
Is the malicious traffic caused by a planned test? Not Planned
What Is the Direction of Traffic? (Format: Source -> Destination) Internet -> Company Network
Was the Attack Successful? No
Do You Need Tier 2 Escalation? No