However OSQuery only allows a recursive wildcard at the end of a LIKE string (see discussion here), so we need to break up the condition into a more complex query with two conditions. This time the query took 2 seconds and returned 4090 rows. In VQL we can use ** to denote recursive glob wildcard. While 6 seconds is not too bad, this gets worse when we try to fetch more dlls from the disk…
If you tried this you would immediately see a difference in performance - the VQL example took less than a second to return 3384 rows while OSQuery took over 6 sec to return the same data. You can also test OSQuery in the notebook cell by simply invoking the () artifact (In this case Velociraptor will shell out to OSQuery and collect the results). Click on the top cell and add a new VQL cell where you can write arbitrary queries. Simply select Notebooks from the sidebar and add a new notebook. You can test the VQL in the Velociraptor notebook right in the GUI. The equivalent VQL is SELECT * FROM glob(globs=”C:\\Windows\\System32\\*.dll”) For example to return all dlls in the system32 directory: SELECT * FROM file WHERE path like “C:\Windows\system32\%.dll” OSQuery allows us to specify a wildcard for filenames as well, however it uses the SQL like syntax. So far both queries simply return a single row for a specific file. (Note also that VQL does not use a semicolon “ ” as a statement separator - it is not needed, just string multiple statements together). wildcards) to search the filesystem directly. The VQL equivalent to the file table is the glob() plugin, which accepts a glob expression (i.e. Therefore VQL’s syntax requires “tables” to take arguments (in VQL these are termed plugins): SELECT * FROM glob(globs=”C:\\Windows
Osquery manager code#
The main realization in VQL was that unlike in a relational database, tables are implemented by code, the code must be able to accept arguments. It is therefore required that a WHERE clause is provided and the path or directory be restricted in some way.Ĭompare this to VQL.
Osquery manager full#
To avoid a full scan of the filesystem, OSQuery peeks at the WHERE clause to figure out what it needs to do. For example we can see information about a file: SELECT * FROM file WHERE path = “C:\Windows\notepad.exe” īecause OSQuery uses SQL as its underlying implementation, there is no way to tell the query that it is only interested in a single file (A naive implementation would scan all files on disk and compare the path by the condition eliminating all but one - a very expensive approach!). One of the most often used OSQuery table is the file table. This post does not compare the scalability, ease of deployment and management GUI of OSQuery‘s various fleet implementations with Velociraptor’s - we only look at the query language itself. This side by side comparison hopefully sheds some light on VQL and will encourage you to start writing new VQL artifacts. This post aims to help this migration by comparing typical OSQuery queries with native VQL Velociraptor queries. It is much better to write VQL queries within Velociraptor, since VQL is much more powerful and also much faster. This integration, however, is simply a stopgap measure during migration. I have written previously about Velociraptor’s OSQuery integration, allowing OSQuery queries to run directly inside Velociraptor. Many new Velociraptor users have existing OSQuery queries and installations and are migrating to Velociraptor for powerful and efficient endpoint visibility. OSQuery was historically a proof that a powerful query language was the way forward, and VQL was designed to improve on OSQuery and push the state of the art.
Back in the day, it became clear to me that the way to provide unprecedented flexibility for endpoint visibility was to have a flexible and powerful query language. OSQuery has been around for a while now, and was actually the initial inspiration for Velociraptor. Photo by Heidi Fin on Unsplash Photo by Heidi Fin on Unsplash Migrating from OSQuery to Velociraptor Tips for the journey
0 kommentar(er)
