Eoin Miller02/18/2020, 7:21 PM
table when doing JOIN's against other tables such as
When joining, we get an empty set response:
osquery> SELECT count(*) FROM scheduled_tasks; | 162 |
I'll capture it in a GitHub issue, just wondering if this is know or others have encountered similiar?
osquery> SELECT count(*) FROM scheduled_tasks JOIN file USING (path); | 0 | osquery> SELECT count(*) FROM scheduled_tasks JOIN hash USING (path); | 0 |
path does not seem to be a filesystem path
Eoin Miller02/18/2020, 7:40 PM
A bit confusing, but also maybe more importantly, if it can't hash/file with a JOIN, should that create an empty set?
osquery> SELECT path FROM scheduled_tasks WHERE path LIKE "%testing%"; +----------+ | path | +----------+ | \testing | +----------+
Eoin Miller02/18/2020, 7:41 PM
Eoin Miller02/18/2020, 7:48 PM
that is misleading or incorrect? The location of the task is what is being set to
but the docs say: > Path to the executable to be run If
were the path to the executable for this task, then it should be reporting back the value of "C:\Windows\System32\cmd.exe"
is the (relative) path to the task definition. A query like
may be what you want.
select * from scheduled_tasks s JOIN file f ON (f.path = '\Windows\System32\Tasks' || s.path);
column, but that is more tricky.
may not be a simple path. Here's a value from running on my VM:
%windir%\system32\ProvTool.exe /turn 5 /source LogonIdleTask
to ensure you aren't dropping results.
It would seem that doing a join should hopefully never cause you to lose data you would be collecting otherwise and all that.That doesn’t seem write. JOIN is a sql pragma. It does what join does. You might want a LEFT JOIN, or a JOIN, but fundamentally permuting data changes it.
Eoin Miller02/19/2020, 1:09 AM