I need to createa hunting query for SQL injection to search in google Security Operation SIEM, what parameter should I use when searching?
Hunting for SQL injection
+2Depending on how the logs are parsed in the UDM fields, you should be able to filter the data. Are you currently ingesting logs that capture this activity?
+23The bigger question may be the field that this resides in but I suspect it might look something like this. If it is the target.URL field, you could do a regex statement like this and look for both options in a single line by separating them with a pipe. The nocase modifier helps insulate against case changes though you could use (?i) as well. The .* between the items helps handle spaces but we don't need leading or trailing .* as re2 will work its way through looking for substrings automatically.
If you need to look in a different field or event_type, then we can modify this as needed.
metadata.event_type = "NETWORK_HTTP"
target.url = /('1'.*=.*'1'|UNION.*SELECT)/ nocaseIf you don't have these logs ingested, you will not be able to threat hunt for those parameters unless you're collecting the logs somewhere else.
The bigger question may be the field that this resides in but I suspect it might look something like this. If it is the target.URL field, you could do a regex statement like this and look for both options in a single line by separating them with a pipe. The nocase modifier helps insulate against case changes though you could use (?i) as well. The .* between the items helps handle spaces but we don't need leading or trailing .* as re2 will work its way through looking for substrings automatically.
If you need to look in a different field or event_type, then we can modify this as needed.
metadata.event_type = "NETWORK_HTTP"
target.url = /('1'.*=.*'1'|UNION.*SELECT)/ nocaseCould this also work to capture any digit
target.url =/('?\\d+'\\s*=\\s*'\\d+'|UNION.+*SELECT)/
+6- Bronze 2
SQL Injection can occur anywhere that data is passed through to a DB. Data that is passed through to a DB is not restricted only to a URL (i.e. get params). It can also be in post data, user agents, various headers, etc. You can't securely bring full requests into the SIEM to parse their contents for SQL injection.
It might make more sense to have a WAF or similar in place that can detect certain SQL injection payloads. This will not provide 100% protection, but can be used to generate an alert when someone is either scanning or trying to manually create a payload to bypass your WAF. You can then use this alert to investigate logs surrounding these types of events.
Does that make sense?
+14- Bronze 5
As mentioned by @ion_ I would say the recommended approach would be to utilise a WAF, and to feed logs into your SIEM and to detect this sort of activity.
Alternatively, if you are directly ingesting logs into your SIEM from these cloud platforms, and need a temporary solution, you could curate a list of SQLI statements in a reference list, use re.capture to capture out the URI parameter which is passed into the UDM field which contains the URL (likely target.url), and then look for SQLI statements within the re.capture. For example:
rule Recapture_SQLI_From_TargetURL {
meta:
author = "Ayman C"
description = "Using Re.capture, regex reference list to capture SQLI"
events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$URIParam = re.capture($e.target.url, "http[s].*/(.*?)$")
$URIParam in regex %ABCD1
outcome:
$risk_score = 0
$URL = $e.target.url
$URIParamater = $URIParam
condition:
$e
}+2SQL Injection can occur anywhere that data is passed through to a DB. Data that is passed through to a DB is not restricted only to a URL (i.e. get params). It can also be in post data, user agents, various headers, etc. You can't securely bring full requests into the SIEM to parse their contents for SQL injection.
It might make more sense to have a WAF or similar in place that can detect certain SQL injection payloads. This will not provide 100% protection, but can be used to generate an alert when someone is either scanning or trying to manually create a payload to bypass your WAF. You can then use this alert to investigate logs surrounding these types of events.
Does that make sense?
Good morning, I already have a WAF in our environment, from which I created some data exfiltration rules, SQL Injection and CSS (cross-site-scripting)
+2As mentioned by @ion_ I would say the recommended approach would be to utilise a WAF, and to feed logs into your SIEM and to detect this sort of activity.
Alternatively, if you are directly ingesting logs into your SIEM from these cloud platforms, and need a temporary solution, you could curate a list of SQLI statements in a reference list, use re.capture to capture out the URI parameter which is passed into the UDM field which contains the URL (likely target.url), and then look for SQLI statements within the re.capture. For example:
rule Recapture_SQLI_From_TargetURL {
meta:
author = "Ayman C"
description = "Using Re.capture, regex reference list to capture SQLI"
events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$URIParam = re.capture($e.target.url, "http[s].*/(.*?)$")
$URIParam in regex %ABCD1
outcome:
$risk_score = 0
$URL = $e.target.url
$URIParamater = $URIParam
condition:
$e
}Thank you very much for you response. All this help me
+6SQL Injection has been around for a long time and over the years the attacks have become varied and complex. Most attackers are not going to send an easy to detect test string like " '1 or 1=1' " injection. The type of database you are targeting will affect your testing methods too. There are many resources online that have compiled examples. rSnake had some great cheatsheets but I could not find one. So, I'd start with these resources:
pentestmonkey :https://pentestmonkey.net/category/cheat-sheet/sql-injection
Invicti: https://www.invicti.com/blog/web-security/sql-injection-cheat-sheet/
+4- Bronze 3
Hi
Please provide a YARA-L rule to detect Boolean-based Blind SQL Injection attempts in query statements Example 1=1.
Thanks
Login to the community
Login with SSO
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.