I'm getting an error when I try to use this query. It works in advanced search tab in log activity. But when I write it into the rule wizard AQL filter query area, it prompts AQL no viable alternative at input SELECT warning. I got this query from Sigma Translater btw.
SELECT UTF8(payload) as search_payload from events where (((LOGSOURCETYPENAME(devicetype) ilike 'Microsoft Windows Security Event Log')) and ((("EventID"='1' and search_payload ilike 'C:\Windows\SysWOW64\cmd.exe' and search_payload ilike '%\Windows\Caches\NavShExt.dll %')) or (("EventID"='1' and search_payload ilike '%\AppData\Roaming\MICROS~1\Windows\Caches\NavShExt.dll,Setting'))))
When creating rules in QRadar based on AQL you only put the statements that come after the WHERE
In your case:
(((LOGSOURCETYPENAME(devicetype) ilike 'Microsoft Windows Security Event Log')) and ((("EventID"='1' and search_payload ilike 'C:\Windows\SysWOW64\cmd.exe' and search_payload ilike '%\Windows\Caches\NavShExt.dll %')) or (("EventID"='1' and search_payload ilike '%\AppData\Roaming\MICROS~1\Windows\Caches\NavShExt.dll,Setting'))))
It will then run that statement against the logs and trigger offenses.
Related
I'm using the Looker Dashboarding software (see: looker.com). It creates temporary tables in your database's looker_scratch schema with long names, each containing a dollar symbol.
These are straightforward to query using the "SQL Runner" in Looker itself, which somehow is able to escape the dollar symbol, but I can't query them using a 3rd-party SQL client.
I'm trying to query this table:
SELECT *
FROM looker_scratch.LR$5UA5D3XQDBPAYU0Q9FLFE_test
but get the error:
the # of binded parameters < the # of parameter markers
How can I query the table?
I've tried:
...FROM looker_scratch."LR$5UA5D3XQDBPAYU0Q9FLFE_test" - says the relation does not exist
...FROM looker_scratch."LR\$5UA5D3XQDBPAYU0Q9FLFE_test" - says the relation does not exist
...FROM looker_scratch.$LR\$5UA5D3XQDBPAYU0Q9FLFE_test$ - says syntax error
...FROM looker_scratch.$$LR\$5UA5D3XQDBPAYU0Q9FLFE_test$$ - says syntax error
...FROM looker_scratch.E'LR\$5UA5D3XQDBPAYU0Q9FLFE_test' - says syntax error
try selecting exact identifier by pattern:
select oid::regclass from pg_class where relname ilike '%5ua5d%';
E.g:
so=# create table t."WeirdMix$" ();
CREATE TABLE
Time: 55.750 ms
so=# select oid::regclass from pg_class where relname ilike '%mix%';
oid
---------------
t."WeirdMix$"
(1 row)
Time: 90.814 ms
In PostgreSQL, we can get the current user and database by
select current_user;
select current_database();
Is select in both statements the same select in a SQL query?
Are current_user and current_database() both column names?
What are the tables they are selected from?
Thanks.
select is the very same select as used in any select query
current_database() is a "System Information Function"
current_user is also a "System Information Function" (see note below)
A function typically takes parameters and therefore are used with parentheses to hold those parameters, but some system functions, such as current_database() don't require any parameters, but the empty parentheses remain.
System Information Functions "extract session and system information" see: https://www.postgresql.org/docs/current/static/functions-info.html
Note
current_catalog, current_role, current_schema, current_user,
session_user, and user have special syntactic status in SQL: they must
be called without trailing parentheses.
column_name is of type int[]
SELECT unnest(column_name) FROM table_name
The above query works on postgresql but not on hsqldb, even with sql.syntax_pgs=true
Hsqldb versions tried : 2.2.9 and 2.3.0
The sql that works in hsqldb is
SELECT x FROM table_name, unnest(column_name) y(x)
x and y are NOT columns of this table.
HSQLDB tries to emulate PostgreSQL's syntax and features, but like most emulations it is imperfect.
IIRC, one of the things it has a hard time with is PostgreSQL's quirky use of set-returning functions in the SELECT clause.
Use of SRFs in the SELECT clause is a weird PostgreSQL extension that's deprecated in favour of SQL-standard LATERAL queries anyway. The alternate formulation you showed:
SELECT x FROM table_name, unnest(column_name) y(x);
is the correct and preferred form. So just use that.
In general, testing on one DB then deploying to another is a recipe for pain. I strongly suggest just setting up a local PostgreSQL instance for testing instead.
In postgresql, I have mangaged to add wildcard pattern (*) to the query using SIMILAR TO option. So my query will be,
SELECT * FROM table WHERE columnName SIMILAR TO 'R*'
This query would return all entities starting from 'R' and not 'r'. I want to make it case insensitive.
Use ILIKE:
SELECT * FROM table WHERE columnName ILIKE 'R%';
or a case-insensitive regular expression:
SELECT * FROM table WHERE columnName ~* '^R.*';
Both are PostgreSQL extensions. Sanjaya has already outlined the standards-compliant approaches - filtering both sides with lower(...) or using a two-branch SIMILAR TO expression.
SIMILAR TO is less than lovely and best avoided. See this earlier answer.
You could write:
SELECT * FROM table WHERE columnName SIMILAR TO '(R|r)%'
but I don't particularly recommend using SIMILAR TO.
try
SELECT * FROM table WHERE columnName SIMILAR TO 'R%|r%'
Which is the fastest way to search within string in PostgreSQL (case insensivity):
SELECT col FROM table WHERE another_col ILIKE '%typed%'
or
SELECT col FROM table WHERE another_col ~* 'typed'
How can I turn on showing the time which query need to return results? Something like is on default in mySQL (I am thinking about CLI client).
Both queries are the same, PostgreSQL rewrites ILIKE to ~*. Check the results from EXPLAIN to see this behaviour.
I'm not sure about your question, but the psql-client can show you some timing of the query, using \timing.
Regarding the timing:
One solution is to use the switch for psql that Frank has already mentioned.
When you use EXPLAIN ANALZYE it also includes the total runtime of the query on the server.
I prefer this when comparing the runtime for different versions of a query as it removes the network from the equation.