Is there a way to run all queries in a JSON pack file via stdin or arbitrary path? I'm looking for the spiritual equivalent of

echo query | osqueryi

today. I found https://github.com/osquery/osquery/pull/2093 which added

--pack

, but it appears to only run ones that are already defined as part of your config. As a workaround I was considering dynamically generating a JSON config file and passing it in via

--config_path

, but it seems pretty hacky & the sort of thing that someone probably found a better solution for.

I’m not sure anything exists that you didn’t already find.

Thanks for the confirmation! I was able to use it and conclude that Kolide's frontend ingester is the source of JSON deserialization divergence 😞 I'm going to work on open-sourcing this tool & generating a reduced test case to open a bug w/ support.

Which kolide front end ingester? (I’m heading off for the day, but that sounds odd)

FWIW, I ended up reporting it via support, but the main problem appears to be how Kolide's web frontend handles importing packs that include queries with double quotes in them. Here's a reduced example pack:

{
  "queries": {
    "waldo": {
      "query": "SELECT * FROM chrome_extensions WHERE name IN (\"Where's waldo?\", \"Google Docs Offline\");",
      "interval": "3600"
    }
  }
}

Reporting through support is :thumbsup_all:

I tried, but wasn't able to figure out how to handle queries referencing fields with single quotes in them. I know there's got to be a way to escape them, but I failed. I'll look into it again 😞

Nesting quotes is such a hassle 😕

Hmm, that's true - I did do that elsewhere already for double quotes. Let me see if that passes the JSON importer. It does break the ability to cut and paste strings (like Chrome Extension extensions) into SQL, but there's only an apostrophe in about 1 out of 100 of those, so I can just deal with that.

I agree it’s imperfect, the double quote thing ought work. But I don’t know how quickly that will get tracked down and fixed.

Thanks so much @seph - this workaround appears to work fantastically! I'll work on adjusting our queries back to single quotes. Here's a sneak peak at what I've been up to: https://github.com/chainguard-dev/osquery-defense-kit

I’d say leave the support note open, since I think there’s a bug somewhere. But I’m glad you’re not blocked

I personally like that there is some sort of reference pool to pull from, but that could easily be moved into it's own repo (

osquery/packs

). Both as an idea of best practices, and as an idea of what data sources are relevant. didn't find the detection queries to be that useful, but the

incident-response

gave me additional ideas I hadn't considerde.

Exactly — there’s a lot of value there as ideas, and possibility, and historic interest. But shipping in the official osquery packages is a stronger endorsement than they merit. (Though if you’re using Kolide packages, you don’t get them shipped anyhow)

I had seen that repo, and took some inspiration from it. The main difference in our approach is that the queries in

detect/

are designed to be usable as a source of alerts. In fact, we use them that way. It does mean an insane amount of false-positive management though.

The thing I liked about the attck stuff, was that it used the common MITRE ATT&CK language. I always feel like there’s a couple axis of categorization. Or tags. Or something like that

I read over on Stack Exchange that RFC7159 or maybe RFC8259 does not allow any control characters in JSON texts and requires they be escaped. Maybe these packs are not valid JSON? But they pass as valid in a JSON linter I tried...