I have been hardening my incident response skills lately and completed parts of the incident response coursework on LetsDefend. As of right now, I’m still working through the course– it’s a pretty comprehensive course! But based on my answer to the questions posed by the subject, a curator reached out to me and asked me to write a blog on the subject of detecting SQL injection during a Linux incident. So let’s walk through the incident posed by the challenge.

If we URL-decode the query in the ticket, we can see a clear attempt at the classic SQL injection technique: “’ OR 1=1 –”. The single quote terminates what the attacker assumes to be in the query. In this exercise, we don’t have direct access to the logs, but what we do have is a simulated SIEM solution! So go over to the Log Management tab and search for the web server address. At the top is the SQL injection attempt.

The log entry from the simulated SIEM

The SQL injection attempt returned a 500 error, an “Internal Server” error. So, the attacker’s injection test failed. That doesn’t necessarily mean they failed to find injection– a server can return a 500 error on a bunk SQL statement, it just doesn’t produce a useful error to the attacker. They have to ultimately “guess” if the server is susceptible to SQL injection. More tests from the attacker are likely to follow. In this case, it didn’t. At this point, we have what we need for the report. Time to create a case!

We step through the prompts teaching us proper alert triage practices and come across our first question: is the traffic malicious?

Mark the report as malicious

The traffic is malicious– it’s a clear SQL injection test. The next prompt asks you to classify the attack. We’ve verified it’s SQL injection, so mark that. The next prompt is a training prompt to teach you to be aware of penetration testers and company testers. We can see back in Log Management that the IP address was external, not internal, so it clearly wasn’t a planned test.

The next prompt asks us the direction of the traffic. We can see from the SIEM that it came from the Internet onto company network, so mark that. Finally, you are asked if the attack was successful. Because the server returned a 500 error, it was not successful, so mark this prompt as “no.”

The next prompt teaches you about doing due dilligence in reporting– mark the IP address as an artifact and move on to the next prompt, which asks if you need tier 2 escalation. The attack was unsuccessful, so mark “no” for this answer. Finally, you are prompted to write a brief report on your task. It’s optional, but it’s good practice!

That concludes the incident. It’s a simple task ultimately! You just gotta use what’s available to you in the simulation.