Then, fire up osqueryi as your user or as a superuser, and try some of the concepts below. This shell is designed for ad-hoc exploration of your OS and SQL query prototyping. See Tables with arguments for more information.īefore diving into osquery's specific implementation of SQL, please familiarize yourself with the osquery development shell. NOTICE: Several tables, file for example, require a predicate for one of the columns, and will not work without it. Mutation-based verbs are allowed in extensions, if the extension supports them. SELECT only! All mutation-based verbs exist, like INSERT, UPDATE, DELETE, and ALTER, but they do nothing - unless you're fancy and creating run-time tables or VIEWs, or using an extension. This is a great starting place if coming from MySQL, PostgreSQL, or MSSQL. Please read SQL as understood by SQLite for reference. The osquery SQL language is a superset of SQLite's. Continue reading our deployment and development guides for a deep-dive into how SQL can power intrusion detection, incident response, process auditing, file integrity monitoring and more. Everything is SQL, and hopefully as expressive as possible. The world of osquery is centered around SQL: decorating, scheduling, differentials, eventing, targeting. Actions use primary keys as input and generate rows as output, and are best used when JOINing. Consider stat-ing a file, hashing a blob of data, parsing JSON, reading a SQLite database, traversing a directory, or requesting a user's list of installed browser plugins. We do not inspect event-time data in real-time, but rather buffer the events as they occur and represent that buffer as a table! Concept 'actions' can be represented too, you perform an action and generate tabular data. These are the same concepts with an 'event-like' twist. Now consider event streams: each event is a row, like a new USB device connection, or file attribute modification. When you want to inspect a concept, you SELECT the data, and the associated OS APIs are called in real-time.
OSQUERY JOIN NSLOOKUP SERIES
We can represent this type of data as a table with a single row and many columns, or a series of key/value rows. There are several informational things - like OS version, CPU features, memory details, UEFI platform vendor details - that are not tabular but rather a body of details with labeled data. Each concept becomes a SQL table, like processes, or sockets, the filesystem, a host alias, a running kernel module, etc. We’ll call the column we are creating sid.It may seem weird at first, but try to think of your operating system as a series of tabular concepts. Then, we need to map this to the user table, on the uuid field. Therefore, we will use split(path, ‘\’, 1), to obtain the first value located between backslashes in path.
In this case, we want the first value, returned after a backslash, to be its own column. The registry, like many things in Windows, is separated by backslashes. Split allows us to specify that a column be separated, and to create a new column with only that part of the value. Osquery supports SQL additions, including split. So while the registry table doesn’t have a column with the SID, the path column does contain the SID. The SID is exactly what is used to separate users in the registry.
OSQUERY JOIN NSLOOKUP WINDOWS
Generic accounts and groups on Windows have the same SID on every installation, but each account created has a random SID. If you are not familiar with SIDs, they are unique identifiers for users, groups and logon sessions. The users table contains none of these, but contains uuid, which, on Windows, returns the SID(Security Identifier). The registry table contains: key, path, name, type, data, mtime To join tables, we need a row with common data. The results are there, but, as someone trying to understand what user is impacted by what setting, they are not very readable.įortunately, using SQL, we can easily join tables together, and the users table contains the data we are looking for. This query returns the Sticky Keys configuration values found for every user. Unless a user needs sticky keys, that value should actually be set to 506, to prevent abuse to elevate privileges, as it is the value that gets written when sticky keys are disabled completely.
0 kommentar(er)
