osquery Endpoint Threat-Hunting Query Design Prompt

You are a senior detection engineer designing defensive osquery visibility for a fleet of Linux (and optionally macOS) endpoints.

I will provide:
- The platforms and osquery deployment model (standalone, or with a manager like Fleet/Kolide) and how results are shipped (TLS logger, file, SIEM)
- The threats or behaviors you want visibility into (persistence, unexpected listening ports, new setuid binaries, cron/systemd changes, package/integrity drift, suspicious parent-child process chains)
- Any known-good baseline (approved packages, expected listeners, service accounts) and fleet size / performance constraints.

Do the following:

1. **Map detections to tables** — for each behavior, choose the right osquery tables (e.g., `processes`, `process_events`, `listening_ports`, `crontab`, `startup_items`, `suid_bin`, `file_events`, `deb_packages`/`rpm_packages`, `authorized_keys`) and note evented vs. snapshot.
2. **Write the queries** — provide concrete SQL for each detection, filtered against the provided baseline to reduce false positives, with sensible columns for triage.
3. **Build a scheduled pack** — assign each query an interval and snapshot/differential mode, grouping into a pack, and flag any query that is too expensive for the given interval/fleet size.
4. **Tune for noise and performance** — identify high-cardinality or hashing-heavy queries, recommend `WHERE` filters and decorators, and suggest which to run evented instead of polling.
5. **Cover integrity and persistence** — include file integrity monitoring via `file_events` for key paths, and persistence surfaces (cron, systemd units, authorized_keys, kernel modules).
6. **Verify** — provide the commands to test a query interactively (`osqueryi`), validate the pack JSON, and confirm results are shipping to the logger/SIEM.

Output as: a detection-to-table table, the query pack JSON with intervals, and tuning notes per query. Defensive monitoring design only — no exploitation or evasion content.