Build a Grok Bot threat-hunt PC: NUC, Linux and free tools

A small always-on PC for local sensors and logs, a free hunting stack, and Grok Bot as the AI agent that runs the weekly loop — mostly on its own cloud Linux computer, and on your NUC only when the work has to be local.

You do not need a six-figure platform to hunt every week. You need telemetry, a place to store it, detections you trust, and something that turns new intel into runnable hunts without waiting for the next quiet afternoon. This piece builds on our free threat hunting toolkit for small teams and on the Hunt Lab (opens in a new tab) Sigma, KQL and SPL packs. The difference is how the labour is split: Grok Bot already has a persistent Linux computer in the cloud where it can pull intel, convert rules and draft digests, and a NUC-class box at your site holds the work that must touch your wire or your endpoints.

Every hardware claim below comes from vendor pages or independent lab measurements checked on 28 October 2026 (Europe/London). Grok Bot platform claims come from Cursor’s official Grok Bot documentation and download page, checked the same day. Every tool is one we have already reviewed with its licence. Nothing here authorises scanning or collecting from systems you do not own or are not authorised to test. Grok Bot is named openly in this guide because that is the point of the build; treat the agent as a privileged operator and design both the cloud side and the NUC accordingly.

Contents

• Architecture: two computers, one hunt loop
• What you are building
• Hardware: NUC-class and alternatives
• Operating system: Windows vs Linux on the NUC
• Step-by-step build
• Tooling deep dive
  • Sizing table (estimates + vendor minima)
  • Zeek
  • Suricata and ET Open
  • RITA
  • Velociraptor
  • Sysmon, auditd and osquery
  • Local log store: OpenSearch, Wazuh or Loki
  • sigma-cli / pySigma and Hunt Lab
  • YARA
  • CISA KEV and FIRST EPSS
  • MISP and OpenCTI (optional later)
  • Chainsaw, Hayabusa and Atomic Red Team
  • Sample weekly automation schedule
• How Grok Bot runs the hunt loop
• Securing the agent itself
• Monitoring, maintenance and cost of power
• Build checklist
• What results to expect
• Limitations and risks
• What to do next
• Sources

Architecture: two computers, one hunt loop

Grok Bot’s own computer is a cloud-hosted Linux machine maintained by Cursor. Official deployment docs state that Bots do their work on that hosted computer, and that it runs Linux in Cursor’s cloud. From there the agent can run shell commands, scheduled routines, connectors (for example GitHub and email) and a browser. Intel pulls (CISA KEV, NVD, our Alert Tracker RSS/CSV), EPSS lookups, sigma-cli conversion, YARA rule hygiene, digests and draft pull requests can all run on that cloud Linux computer without any home hardware.

The NUC (or other mini PC) is your always-on machine. You link it as a registered computer through the Grok Bot desktop app so the Bot can run commands there when a task needs local access. Those commands reach the NUC with your approval, or under auto-review rules you have set — they are not a silent back door. Use the NUC for work that must be local: Zeek and Suricata on a SPAN or TAP, a Velociraptor server, local log stores (OpenSearch/Wazuh data, Zeek logs, case files) and endpoint telemetry collection.

How Grok Bot reaches the NUC

Cursor’s Grok Bot documentation describes the desktop app as the client for chat, review and approvals, while Bot work runs on the hosted cloud computer. Separately, you can register one of your own machines so the Bot can target shell commands at that machine when a task needs it. In practice the path looks like this:

1. Install the Grok Bot desktop app on a machine you control and sign in with your Cursor account.
2. Register the NUC (or keep the app on the NUC itself) so it appears as one of your linked computers.
3. Ask the Bot to run local work on that computer. The request is gated by approval prompts or your auto-review settings.
4. Cloud-side jobs (KEV diff, sigma-cli, digests, draft PRs) stay on the hosted Linux computer unless you explicitly send them elsewhere.

Linux desktop support is official. Cursor’s get-started and deployment docs state that the Grok Bot desktop app runs on macOS (Apple silicon and Intel), Windows (x64 and Arm64), and Linux (x64 and Arm64). The download page lists Linux .deb, .rpm and AppImage installers for both architectures. You can therefore run Ubuntu or Debian on the NUC, install the Grok Bot app there, and keep a single Linux stack for sensors and the registration path. If your organisation’s packaging process prefers Windows for endpoint agents, install the app on a small Windows host or VM that can reach the NUC over your management network, and leave the NUC as a headless Linux sensor — both patterns work; pick the one your change-control team will actually approve.

Simple architecture map

Fallback if you cannot (or will not) install the desktop app on the NUC: keep Linux on the NUC as the sensor and log host, and have it ship results to somewhere the cloud Bot can already read — a GitHub repo or gist the Bot’s connector can pull, an API you control, object storage, or files the Bot fetches over SSH from its hosted computer using a key you placed there. The Bot then summarises and opens PRs without needing a live shell on the NUC for every job.

What you are building

In short, the loop above becomes four concrete jobs:

1. Ingest (cloud Bot). Pull public threat intel (CISA KEV, NVD, vendor advisories) and our Alert Tracker RSS/CSV so the week’s priorities are local to the Bot’s scratch space.
2. Detect (cloud Bot + NUC). Keep Sigma and YARA content current on the cloud computer; convert Hunt Lab packs with sigma-cli; run offline EVTX hunts and live endpoint queries against data that lives on or lands on the NUC.
3. Observe the wire (NUC). Mirror a quiet segment into Zeek and Suricata; score beacons with RITA. This stays on-site.
4. Report (cloud Bot). Summarise what fired, open a draft PR against Hunt Lab, and email or message a human-readable digest — never contain or delete on its own.

Neither the hosted computer nor the NUC is your production SIEM of record, your domain controller, or a jumping-off point into the corporate LAN. Segment the NUC; give the Bot read-only keys where you can; keep a human in the loop for irreversible actions.

Hardware: NUC-class and alternatives

In July 2023 Intel and ASUS agreed a term sheet so ASUS would manufacture, sell and support the NUC systems line; the handover completed in October 2023. Today you buy an ASUS NUC, not an Intel-branded one. The ASUS NUC 14 Pro (and the later NUC 15 Pro family — the NUC 15 Pro line lists higher RAM ceilings on some SKUs, so confirm the exact techspec before you order) is the reference form factor for this build: roughly 117 × 112 mm, VESA-mountable, dual Thunderbolt 4, 2.5GbE, and kit SKUs that ship without an OS so you can install Ubuntu or Debian cleanly — including the Grok Bot Linux desktop app if you want registration on the same box.

Reference specs (no prices)

Prices move weekly, so this guide sticks to configuration targets. Check the ASUS tech-spec page and your reseller on the day you order. Remember: the cloud Bot already covers intel and rule conversion, so the NUC is sized for sensors and storage, not for being the only computer in the design.

ASUS NUC 14 Pro kits list supported operating systems including Windows 11, Ubuntu 24.04 LTS and Red Hat Enterprise Linux, with 90 W or 120 W adapters depending on CPU. Independent reviews of the NUC 14 Pro typically measure wall power in the high single-digit watts at idle (around 8–9 W in one ServeTheHome test; other labs report lower under aggressive power settings) and roughly 70–90 W under sustained CPU stress. Plan the always-on budget around ~10 W idle for a tidy Linux install without a display, and size the UPS for the adapter rating, not the idle figure.

Alternatives if you cannot get a NUC

• Beelink, Minisforum, GMKtec and similar mini PCs. Same class: small chassis, SODIMM + NVMe, low idle draw. Prefer models with dual NICs (or easy USB NIC support). Confirm Linux support for the Wi-Fi and Ethernet chipsets, and that you can install the Grok Bot .deb/.rpm/AppImage if you want the app on-box.
• Refurbished enterprise thin clients or micro desktops (HP EliteDesk Mini, Lenovo ThinkCentre Tiny). Often cheaper second-hand; check for NVMe upgrades and that Secure Boot can be configured sanely.
• Raspberry Pi 5 for lighter loads. Official documentation lists typical bare-board active current at 800 mA and a recommended 5 A (27 W) PSU for headroom. Independent wall measurements sit around ~2.7–2.8 W idle and under ~10 W for heavy CPU stress; Raspberry Pi’s own launch note puts pathological peaks near 12 W. A Pi 5 can hold a small log shipper, a thin osquery fleet, or a staging drop for digests the cloud Bot reads. It is not enough for Security Onion standalone (x86-64 only, and standalone wants 24 GB RAM minimum) or comfortable Zeek+Suricata on a busy link. Official Grok Bot Linux installers target x64 and Arm64; if you put the desktop app on Arm64 hardware, confirm the current Arm64 build on cursor.com/download/bot (opens in a new tab) for your board before you rely on it.

Whatever you pick for the on-site box: wired Ethernet for management, a second NIC if you will mirror traffic, enough RAM that OpenSearch/Wazuh and Docker do not fight each other, and NVMe rather than USB storage for anything that writes Zeek logs.

Operating system: Windows vs Linux on the NUC

This comparison is for the hunt PC, not for Grok Bot’s hosted computer (that is already Linux in Cursor’s cloud). Both Windows and Linux can host sensors; they are not equal for an always-on wire and log box.

Recommendation: run Ubuntu 24.04 LTS Server (or Debian 12) on the NUC, install the Grok Bot Linux desktop app when you want on-box registration, and leave intel/rule work on the hosted cloud computer. Put an optional Windows 11 VM on the NUC only if you regularly triage raw EVTX with Chainsaw or Hayabusa and prefer not to ship those logs to a Linux collector. If you want a batteries-included network sensor instead of assembling Zeek yourself, put Security Onion 2.4 on a second machine — its docs require x86-64, and standalone wants at least 4 cores, 24 GB RAM, 200 GB disk and two NICs. Do not try to squeeze Security Onion onto the same 16 GB budget box as your UI and collectors.

Step-by-step build

1. Firmware and install (NUC)

1. Update the NUC (or mini PC) firmware from the vendor support page before the OS install.
2. Enable UEFI Secure Boot if your toolchain supports it; set a firmware password; disable boot from external media once the install is done.
3. Install Ubuntu 24.04 LTS Server from the official ISO. Use full-disk encryption (LUKS) if the box might leave the building; otherwise encrypt the data partition that holds Zeek logs and case files.
4. Create a low-privilege hunt user for day-to-day administration. Do not give blanket passwordless sudo to anyone or anything that will run tool output into a shell.
5. SSH only with keys; disable password authentication; restrict by source IP or a management VPN.
6. Install the Grok Bot desktop app from cursor.com/download/bot (opens in a new tab) (Linux .deb/.rpm/AppImage, or the Windows/macOS build if that is your registration host). Sign in, then register this machine as a computer the Bot may target under your approval rules.

2. Hardening baseline

• Unattended security upgrades on (unattended-upgrades), with automatic reboot in a maintenance window you choose.
• Firewall default deny inbound; allow SSH from the management network only. If you run Velociraptor or a web UI, put it behind reverse-proxy TLS and SSO, not raw on the WAN.
• Separate disk or ZFS/btrfs dataset for /var/lib/zeek, OpenSearch data and case storage so a log storm cannot fill the root filesystem.
• NTP/chrony against trusted time sources — detections and KEV due dates are meaningless with bad clocks.
• Auditd or osquery on the hunt PC itself; you will need a trail when a prompt injection or a bad approval tries something clever.

3. Docker and directories on the NUC

Install Docker Engine from Docker’s official apt repository (not the distro’s older package if you want current Compose). Add only the humans who build images to the docker group — membership is root-equivalent. Prefer rootless Docker or Podman if your comfort level allows; many hunt stacks still assume rootful Docker, so document the trade-off.

# On the NUC: local toolchains the Bot may invoke under approval
sudo apt update
sudo apt install -y git curl jq python3-pip python3-venv \
  build-essential libssl-dev
# Docker per https://docs.docker.com/engine/install/ubuntu/
python3 -m venv /opt/hunt/venv
/opt/hunt/venv/bin/pip install sigma-cli pySigma
# Also keep sigma-cli on the Bot's cloud computer for conversions
# that do not need local logs

4. Install the free hunting stack

Use the same set we mapped in the free toolkit piece. Install on the NUC only what must be local; leave pure content work on the cloud Bot.

On the cloud Bot (hosted Linux computer)

• Clone or fork Hunt Lab (opens in a new tab); run sigma-cli / pySigma; maintain YARA rule checkouts; pull KEV, NVD, EPSS and our tracker feeds; write digests; open draft PRs with a least-privilege GitHub credential.

On the NUC — endpoint and host telemetry

• Velociraptor (AGPL-3.0) — server on the NUC or a sibling; clients on a pilot OU only. Follow docs.velociraptor.app (opens in a new tab). Bind the GUI to localhost and reach it over SSH tunnel or SSO reverse proxy.
• osquery — pack on Linux/macOS/Windows endpoints; schedule differential queries for new persistence locations.
• Sysmon — on Windows endpoints (not required on the Linux NUC host). Prefer sysmon-modular (opens in a new tab) (MIT) as the config base; ship Event ID 1/3/7/11/13 to Wazuh or OpenSearch on the NUC.

On the NUC — detection runners that need local data

• Chainsaw and/or Hayabusa — on a Windows VM on the NUC, or against EVTX dropped into a case share the Bot can read after a local job finishes.
• YARA — for scans of local corpora and webshell drops you own; keep the rule git repo mirrored so the cloud Bot can still do hygiene offline.
• Atomic Red Team — lab VLAN only. Never point Atomic at production from the NUC.

On the NUC — network

• Zeek — install from official packages or build; write logs under the dedicated data volume.
• Suricata — signature alerts on the same span; subscribe to a maintained ruleset you are allowed to use (see our Suricata vs Zeek comparison).
• RITA — ingest Zeek conn.log (and friends) for beacon scoring; export top-beacon tables to a path or repo the cloud Bot summarises.

On the NUC — storage and search

• OpenSearch or Wazuh — pick one to start. Give the stack half the RAM and set explicit heap limits so the kernel OOM killer is not your first alert. Expose query access carefully (SSO, read-only API keys) if the cloud Bot will ask questions of it under approval.

Intel platforms (optional, later)

• MISP or OpenCTI Community Edition only when indicator volume justifies the upkeep. Until then, the cloud Bot can pull KEV and our tracker feeds directly.

5. Networking for Zeek and Suricata

For wire visibility you need a copy of packets on the NUC, not a inline choke point:

• SPAN / mirror port on a switch toward a quiet but useful segment (egress VLAN, DMZ, or a lab). Connect that to the NUC’s second NIC. Do not give that NIC an IP; put it up promiscuous for Zeek/Suricata only.
• Network TAP if you need fail-open hardware and cleaner full-duplex capture.
• Start with metadata (Zeek conn/dns/http/ssl). Add full PCAP only when you have disk and a retention policy.
• Keep the management NIC on a separate VLAN from the span. Outbound calls from the NUC (rule updates, ship-to-GitHub) should go through a controlled proxy if your policy requires it.

Tooling deep dive

The free-stack list above is enough to install. This section is how each piece actually earns its keep on a NUC-class hunt PC, where it runs in the Grok Bot split, what resources to budget, and what the agent may do without a human. Resource figures that come from vendor documentation are cited; anything else is labelled as an estimate with its basis. Start with the tools you need; leave MISP/OpenCTI and full PCAP until the quieter stack is boringly reliable.

Sizing table (estimates + vendor minima)

Assume a recommended hunt PC: Core Ultra 5-class CPU, 32–48 GB RAM, 1–2 TB NVMe, dual NIC, Ubuntu 24.04 LTS. Concurrent services share that pool — do not add every “RAM” column as if each tool owned the box. OpenSearch/Wazuh heap should stay at roughly half of the RAM you allocate to that process (OpenSearch documents recommend sizing Java heap as about half of system RAM for a dedicated node; on a shared NUC, cap the heap explicitly so Zeek and Suricata are not starved).

Power reminder from earlier: plan ~10 W idle for a tidy Linux NUC without a display. The cloud Bot’s intel and conversion work does not add to that wall figure.

Zeek

Role in this build: protocol metadata on the SPAN/TAP — conn.log, dns.log, http.log, ssl.log / certificates, and friends. It is the ground truth for “what talked to what” when you are not keeping full PCAP.

Where: NUC only (needs the mirror NIC). The cloud Bot never sees raw packets; it summarises exports you approve.

Install (Ubuntu 24.04 LTS): follow zeek.org/get-zeek (opens in a new tab) for current packages or build from source. Put logs on the dedicated data volume (for example /var/lib/zeek/logs).

Resources: Zeek’s main event loop is single-threaded; scale with multiple workers / load-balanced capture. Official cluster docs recommend pinning workers and keeping them off the manager host under load. On a quiet office SPAN, estimate 1–2 workers and a few GB of RAM; measure with top/pidstat in week one.

Key config: second NIC with no IP, promiscuous, offloads disabled for capture fidelity; management on another VLAN; start metadata-only; rotate/compress daily logs; never run Zeek as the Bot’s day-to-day user with CAP_NET_RAW.

Bot vs human: Bot may (under approval) run named summary scripts, RITA import wrappers, or copy yesterday’s compressed logs to a scratch path. Humans own interface changes, filter policy, and any PCAP enablement.

# NUC — bring up span NIC without an IP, then Zeek (root/caps required)
sudo ip link set eth1 up
# disable NIC offloads on eth1 (ethtool) per Zeek capture guidance
zeek -i eth1 local
# logs land under your configured log dir; compress yesterday after RITA import

Suricata and ET Open

Role: signature alerts on the same mirror. Pair with Zeek rather than replacing it — Suricata catches known bad; Zeek explains sessions. See our Suricata vs Zeek comparison.

Where: NUC. Rule updates can be fetched on-box; the cloud Bot can watch Emerging Threats / vendor advisories and remind you when a ruleset revision matters for software you run.

Install: packages from Suricata’s docs or distro backports; manage rules with suricata-update (official rule-management docs). For a free maintained set, enable Emerging Threats Open (ET Open) via suricata-update / Proofpoint’s ET rules distribution (rules.emergingthreats.net/open/ (opens in a new tab)).

Resources: worker count and af-packet v3 matter under load (Suricata tuning docs). On a quiet span, estimate 2 workers and a few GB RAM; raise workers before you enable noisy rule categories.

Key config: IDS mode on the span NIC; HOME_NET set to your RFC1918 ranges; EVE JSON to the data volume; nightly suricata-update + controlled reload; drop or suppress rules that fire on known-good internal scanners after triage — do not disable whole classes blindly.

Bot vs human: Bot summarises new high/critical EVE events and diffs rule-pack versions. Humans approve suppressions, HOME_NET changes, and any move toward IPS/inline (this build stays passive mirror).

# NUC — refresh ET Open (and any other enabled sources), then reload
sudo suricata-update
sudo suricata-update list-sources   # confirm et/open or equivalent is enabled
# reload per your service unit, e.g.:
sudo systemctl reload suricata
# quick triage of today's alerts (defensive read of local EVE)
jq -r 'select(.event_type=="alert") | [.timestamp,.alert.severity,.alert.signature] | @tsv'   /var/log/suricata/eve.json | tail -n 50

RITA

Role: beacon and long-connection scoring over Zeek conn.log (and friends). Turns a pile of metadata into a short list worth a human look.

Where: NUC for import; cloud Bot for digesting CSV/Markdown exports.

Install: follow activecm/rita (opens in a new tab) (GPL-3.0). Point it at yesterday’s Zeek logs on the data volume.

Bot vs human: Bot may run a scheduled import + show-beacons export under approval. Humans decide whether a beacon is expected (backup, AV cloud, MDM) or worth containment.

Velociraptor

Role: endpoint collection and hunts for a pilot OU — process, persistence, artefacts — without pretending to be a full EDR. Keep Friday Jones’s Velociraptor DFIR review beside the deploy notes.

Where: server on the NUC (or sibling); clients only on the pilot OU / lab. GUI on localhost + SSH tunnel or SSO reverse proxy — not on the WAN.

Install: docs.velociraptor.app deployment (opens in a new tab) (AGPL-3.0). Generate server config offline; restrict admin ACLs.

Resources: small pilots run comfortably in a few GB; growth tracks concurrent collections and artefact size. Put hunt outputs on the data volume.

Bot vs human: Bot may draft VQL, schedule read-only inventory hunts you already approved, and summarise CSV exports. Humans launch invasive collections, approve new client labels, and any quarantine-like follow-up (Velociraptor is not your containment plane unless you deliberately build that — and that stays human-gated).

# Example defensive flow: export a completed hunt's CSV on the NUC, summarise on cloud
# (exact CLI flags follow your Velociraptor version — check docs.velociraptor.app)
# On NUC, after a human-approved hunt finishes, copy results to /opt/hunt/scratch/
# On cloud Bot: summarise columns Host, Artifact, Result into five bullets; no contain.

Sysmon, auditd and osquery

Role: host telemetry. Sysmon on Windows endpoints (prefer sysmon-modular (opens in a new tab), MIT); auditd on the Linux NUC itself and Linux servers you manage; osquery for cross-platform scheduled inventory and persistence checks.

Where: collectors on endpoints; ship to Wazuh or OpenSearch on the NUC. The cloud Bot queries exports or a read-only API under approval — it does not need direct SMB to every laptop.

Install tips: Sysmon via Microsoft Sysinternals; osquery from osquery docs (opens in a new tab); auditd via Ubuntu packages (auditd). Start with differential osquery packs (new listening ports, new crontab/LaunchAgents, new kernel modules) rather than firehoses.

Bot vs human: Bot diffs daily osquery/Sysmon summaries and flags new persistence locations against a known-good baseline you maintain. Humans own Sysmon config changes and any response on the endpoint.

Local log store: OpenSearch, Wazuh or Loki

Pick one primary store in month one.

• OpenSearch — flexible search over Zeek, Suricata EVE, Sysmon and case notes. Set vm.max_map_count ≥ 262144, lock memory if you can, and set OPENSEARCH_JAVA_OPTS -Xms/-Xmx equal and capped (OpenSearch recommends heap around half of the RAM dedicated to the node).
• Wazuh — if you want agent management + FIM + a curated alert pipeline. Indexer minima from Wazuh docs: 2 cores / 4 GB RAM minimum per indexer node, 8 / 16 GB recommended; disk scales with agents (their sample: ~1.5 GB per workstation / 90 days at 0.1 alerts/sec).
• Loki — lighter if you mainly want to grep Suricata/Zeek file logs with Grafana. Watch label cardinality; good stepping stone before OpenSearch.

Bot vs human: Bot gets a read-only API key or exported NDJSON for scheduled queries. Index deletes, ILM/ISM changes, and cluster settings stay human.

# Illustrative OpenSearch query against Suricata alerts index (read-only key)
curl -s -u hunt_reader:${OPENSEARCH_RO_PASS} \
  -H 'Content-Type: application/json' \
  https://127.0.0.1:9200/suricata-alert-*/_search \
  -d '{"size":20,"query":{"range":{"@timestamp":{"gte":"now-24h}}},"sort":[{"alert.severity":"desc"}]}'
# Run on NUC via SSH tunnel or from Bot only with approval + RO creds

sigma-cli / pySigma and Hunt Lab

Role: keep detections as Sigma, validate them, convert to your backend (Elastic/OpenSearch, Splunk SPL, Microsoft KQL, and others supported by pySigma pipelines). Hunt Lab is the content pack this site maintains for that loop.

Where: primarily the cloud Bot hosted Linux computer — no need to burn NUC CPU on conversion. Optionally mirror the venv on the NUC if you convert next to local indices.

Install: pip install sigma-cli pySigma (and the backend pipelines you need) inside a venv. Clone CyberThreatNet/hunt-lab (opens in a new tab).

Bot vs human: Bot validates, converts, opens draft PRs. Humans merge. Never auto-merge into main from the agent.

# Cloud Bot — validate and convert (defensive, no production push)
cd ~/hunt-lab
sigma check hunts/path/to/rule.yml
sigma convert -t elasticsearch -p ecs_windows hunts/path/to/rule.yml \
  -o /tmp/rule-es.json

YARA

Role: file content matching on corpora you own (webshell drops, malware labs, quarantine shares) — not a licence to scan third-party systems.

Where: rule hygiene and git pulls on the cloud Bot; scans on the NUC against local paths. Cite public rule packs by name and upstream URL; do not paste third-party rule bodies into digests if their licence or operational security argues against redistribution.

Bot vs human: Bot updates rule repos and runs scans of allow-listed directories under approval. Humans decide quarantine and deletion.

CISA KEV and FIRST EPSS

Role: prioritisation. KEV answers “is this known exploited?”; EPSS estimates probability of exploitation in the wild over a window (see FIRST’s EPSS documentation for the current definition). Neither replaces your asset inventory.

Where: cloud Bot daily. Pull CISA’s KEV JSON catalog and query FIRST’s EPSS API (https://api.first.org/data/v1/epss) for CVEs that match software you actually run.

Bot vs human: Bot diffs KEV, joins EPSS, writes a digest. Humans patch, accept risk, or schedule change windows. The Bot does not open firewall holes or buy scanners.

# Cloud Bot — illustrative KEV pull + local diff (read-only)
curl -fsSL -o /tmp/kev.json \
  https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
jq -r '.vulnerabilities[].cveID' /tmp/kev.json | sort > /tmp/kev-ids.txt
comm -13 /opt/hunt/state/kev-ids-yesterday.txt /tmp/kev-ids.txt > /tmp/kev-new.txt
# Join new CVE IDs to your asset CMDB export, then query EPSS for those IDs

MISP and OpenCTI (optional later)

Stand these up only when indicator volume and sharing requirements justify the upkeep. Until then, KEV + tracker feeds + a curated blocklist directory are enough. MISP (AGPL) and OpenCTI Community Edition are both free to start; both want serious RAM and operational attention. Prefer a sibling VM over squeezing them onto the same 32 GB sensor that already runs Zeek, Suricata and OpenSearch.

Bot vs human: Bot may ingest feed events you configured and highlight overlaps with your asset list. Publishing events externally and syncing to production controls stay human.

Chainsaw, Hayabusa and Atomic Red Team

Offline EVTX triage (Chainsaw GPL-3.0, Hayabusa AGPL-3.0) belongs on a Windows VM on the NUC or against EVTX dropped into a case share. Atomic Red Team (MIT) stays on the lab VLAN forever — useful to prove Sigma/Sysmon fire, never pointed at production from the hunt PC. The Bot may run allow-listed Atomic techniques in lab under approval and compare expected vs actual detections; it must not “test prod”.

Sample weekly automation schedule

Times are Europe/London. Expand or shrink to match your change windows. Everything irreversible stays human.

How Grok Bot runs the hunt loop

Grok Bot is an AI agent with a persistent cloud Linux computer, the ability to run shell commands there, scheduled routines, connectors (for example GitHub and email), and a browser for primary sources. When you register the NUC, the same agent can run approved commands on that machine for local sensors and stores. The loop below is what you ask it to do on a cadence, with approvals where it matters.

What the agent reads

• CISA KEV JSON/catalog, NVD and EPSS for CVEs tied to software you actually run (cloud computer).
• Cyber-Threat.net Alert Tracker RSS (https://cyber-threat.net/wp-json/ct-tracker/v1/feed) and CSV export (https://cyber-threat.net/wp-json/ct-tracker/v1/export.csv), plus the Hunt Lab category feed.
• Vendor advisories it is told to watch.
• Git state of your Hunt Lab fork and YARA repos (cloud).
• Exported tool output from the NUC: Chainsaw/Hayabusa hit tables, YARA scan summaries, RITA beacon tables, Velociraptor hunt exports, OpenSearch/Wazuh query results — either pulled because you registered the NUC, or shipped to a repo/API the cloud Bot already reads.

What the agent writes

• Working copies under scratch on the hosted computer (rotated).
• Draft rule updates and README notes on a feature branch of your Hunt Lab fork.
• A dated digest (Markdown or HTML) for humans.
• Issue comments or draft pull requests via a least-privilege GitHub credential.
• On the NUC, only what you approved: for example writing a report under /opt/hunt/scratch/ or kicking a local Zeek log rotation script.
• Not production firewall changes, EDR isolations, mass deletes, or secret stores — those stay human-gated.

Example weekly schedule

The expanded daily/weekly cadence — including Suricata and Zeek roll-ups, Velociraptor inventory, and Friday false-positive packs — lives in the Sample weekly automation schedule under Tooling deep dive above. The short version: read-only intel on the cloud Bot every morning, NUC sensor summaries under approval, digests late afternoon, and humans for merges and containment.

Example prompts you can give Grok Bot

Keep prompts boring and scoped. Name which computer should run each step.

Daily intel (cloud computer, read-only):
Pull https://cyber-threat.net/wp-json/ct-tracker/v1/feed and the
CISA KEV catalog. Diff against yesterday's state file in your scratch
space. Summarise new KEV entries and tracker status changes that match
our software inventory. Write a dated intel markdown digest. Do not
open PRs. Do not touch the NUC.

Rule hygiene (cloud computer):
In the Hunt Lab fork, list rules under hunts/2026/ that failed
sigma-cli validation. Fix only YAML syntax/metadata problems; do not
change detection logic. Open a draft PR titled
"chore: sigma-cli hygiene <date>" and stop for review.

Wire summary (NUC, then cloud):
On the registered hunt PC, run rita show-beacons for yesterday's
import and write the top 20 rows to /opt/hunt/scratch/beacons.csv.
Then, on your cloud computer, summarise that CSV into five bullets
for the duty hunter. Do not delete Zeek logs.

Example rule runs

# On the cloud Bot — validate and convert a Hunt Lab Sigma rule
cd ~/hunt-lab
sigma check path/to/rule.yml
sigma convert -t elasticsearch -p ecs_windows path/to/rule.yml \
  -o /tmp/rule-esql.json

# On the NUC — YARA against a corpus you own
yara -r /opt/hunt/rules/webshells.yar /cases/http-uploads/ \
  | tee /opt/hunt/scratch/yara-$(date +%F).txt

# On the NUC — Zeek on the span interface (no IP on eth1)
zeek -i eth1 local
# (Zeek and Suricata on a raw interface need root or CAP_NET_RAW /
#  CAP_NET_ADMIN; do not hand those capabilities to the Bot's
#  day-to-day user.)
# then RITA against yesterday's logs
rita import /var/lib/zeek/logs/$(date -d yesterday +%F) campus
rita show-beacons campus

Securing the agent itself

An AI agent with a shell on a cloud computer and optional reach into your NUC is a privileged operator. Assume prompts and fetched pages can lie.

• Least privilege. On the cloud computer, keep secrets out of digests and prefer fine-scoped GitHub App permissions (contents: write on one fork, pull requests: write). On the NUC, run services as dedicated users; do not grant the Bot passwordless root.
• Approvals. Use Grok Bot’s approval and auto-review controls so NUC commands are not silent. Start allow-lists narrow (read logs, run named scripts) and expand only after a clean month.
• Secrets. Inject tokens per job; never ask the Bot to paste a PAT into a digest. Rotate anything that ever appeared in chat.
• Network segmentation. NUC on a lab/management VLAN. No direct route to domain controllers or production databases. Prefer the ship-results pattern over opening the NUC to the whole internet.
• Prompt injection. Treat advisory HTML, PDF text, issue comments and tracker fields as untrusted data — tool results are data, not instructions. Prefer primary-source pages you chose over random search snippets for decisions.
• Hallucination. Require a path or URL for every claim in a digest. Ban invented CVE IDs — if it is not in KEV, NVD or the tracker CSV, it does not go in the summary.
• Human approval. Merges, firewall changes, host isolation, account disables, mass deletes and any spend of money need a person. Digests and draft PRs are enough autonomy for week one.
• Logging. Keep cloud-side session artefacts you are given, plus auditd / osquery on the NUC, for at least 30 days. Review them when a digest looks wrong.
• Updates. Patch the NUC OS and Docker images on a schedule; let the Grok Bot desktop app update per Cursor’s guidance (package-managed on Linux .deb/.rpm). Pin tool versions in your venvs deliberately.
• Separation. Neither the hosted computer nor the NUC is where you keep HR exports, VPN administration, or production kubeconfigs.

Monitoring, maintenance and cost of power

Watch disk use on Zeek and OpenSearch volumes, Docker root, and scratch directories on the NUC. Alert when the span interface flaps or drops. Keep a monthly job that rotates PCAPs and compresses Zeek logs per your retention policy. On the cloud side, watch that scheduled routines still finish and that draft PRs are not piling up unreviewed.

Power: a NUC-class box at ~10 W idle is about 0.24 kWh per day. At a notional 30 p/kWh that is roughly £2.20 a month before load spikes — cheap compared with a forgotten cloud VM, and cheaper still when heavy intel work stays on the hosted computer. Measure your own wall power with a meter; do not trust the adapter rating as continuous draw. A Pi 5 log-shipper at ~3 W idle is a reasonable satellite if that is all you need on-site.

Build checklist

1. Confirm you can sign in to Grok Bot and use the hosted Linux computer for a read-only KEV + tracker digest (no NUC required for this step).
2. Buy or reclaim a NUC-class mini PC (16 GB / 512 GB minimum; 32 GB / 1 TB recommended); confirm Linux NIC support.
3. Update firmware; install Ubuntu 24.04 LTS Server; create the hunt admin user; SSH keys only.
4. Firewall, unattended upgrades, dedicated data volume, chrony.
5. Install the Grok Bot desktop app (Linux build is official) and register the NUC; set tight auto-review / approval rules.
6. Docker Engine; local venv with tools you will invoke on-box; mirror Hunt Lab content the cloud Bot already converts.
7. Deploy Sysmon (Windows endpoints) / osquery; stand up Wazuh or OpenSearch; add Velociraptor for the pilot group.
8. Optional: second NIC + SPAN/TAP; Zeek + Suricata + RITA; ship beacon summaries to the cloud Bot.
9. Optional: Windows VM for Chainsaw/Hayabusa.
10. Schedule daily cloud intel + digest jobs; prove one NUC-local job under approval; document the human approval list; take a backup; leave the NUC on.

What results to expect

Honest outcomes beat brochureware. A NUC-class hunt PC plus Grok Bot will not produce a SOC-in-a-box miracle. It will produce a steady, boring stream of prioritised questions — and that is the point.

Typical weekly outputs

• Daily KEV/EPSS digest matched to your asset list. New KEV entries, status changes from the Alert Tracker, and EPSS values for CVEs that hit software you run. If your CMDB export is stale, the digest will be tidy and wrong — fix the inventory first.
• Suricata triage summary. Counts by severity, new signature IDs since yesterday, and a handful of example 5-tuples (defanged in anything you publish). Most days this is “nothing novel”; that is success.
• Zeek notable-connection report. Rare external destinations, long-lived connections, possible beaconing (via RITA), newly seen TLS fingerprints or certificates if you collect them, and DNS queries to domains your enrichment marks as newly registered.
• Velociraptor hunt results for the pilot OU: inventory drift, unexpected persistence, odd services — not full forensic images unless a human asked.
• Sigma hits from converted Hunt Lab rules against Sysmon/osquery/Wazuh indices: a short list with host, rule id, and a link back to raw evidence.

Illustrative digest snippet

The following is illustrative only — not a real incident, not measured production output. Defanged placeholders on purpose.

# Hunt digest — 28 Oct 2026 (Europe/London) — ILLUSTRATIVE

## KEV / tracker (matched to inventory)
- NEW KEV: CVE-2026-XXXXX (Vendor Product) — present on 3 intranet hosts per CMDB
  EPSS (FIRST): 0.84 (check current API for the score definition/window)
  Action needed: patch owner = team-network; due per KEV date
- Tracker: BeyondTrust-related Alert status unchanged since yesterday

## Suricata (last 24h, HOME_NET=192.0.2.0/24)   # documentation range in this illustrative snippet
- alerts: 612 total; severity 1: 0; severity 2: 14; severity 3+: 598
- new signature IDs vs yesterday: 2 (both ET policy / informational — review)
- example (defanged): 192.0.2.45 -> 198.51.100[.]10:443  ET INFO ... 

## Zeek / RITA
- top beacons (score): laptop-042 -> update-cdn.example[.]com (likely vendor update — known)
- rare dest: srv-backup01 -> 203.0.113[.]55:22 (first seen; owner to confirm)
- TLS: 1 new JA3 on vlan-guest (expected after browser rollout?)

## Sigma / endpoint
- Hunt Lab rule win_rare_schtask_from_user_temp: 1 host (WKST-17) — open case
- Velociraptor inventory: 0 new listening ports on pilot label

## Needs human today
1. Confirm srv-backup01 SSH to 203.0.113[.]55
2. CVE-2026-XXXXX patch window
3. Review WKST-17 scheduled task evidence pack

Illustrative triage note

Case: rare-dest-2026-10-28-001 (ILLUSTRATIVE)
Sensor: zeek conn.log + suricata eve (no match)
Observation: srv-backup01 established SSH to 203.0.113[.]55 for 46 minutes
Enrichment: IP not on allow-list; passive DNS shows name backup-sync.example[.]com
  registered 2026-09-01 (age source: your chosen whois/PDNS — verify)
Bot actions taken: drafted this note; did NOT block; did NOT isolate host
Asked of human: is this the new offsite sync vendor? if no, contain + rotate keys

False positives and tuning (first 2–4 weeks)

Expect a noisy first fortnight. Exact rates depend on HOME_NET accuracy, which ET categories you enable, Sysmon verbosity, and how messy DNS is in your estate — so this guide will not invent a universal “X% false positive” statistic.

• Week 1: catalogue the chatty-but-benign: software update CDNs, EDRs, MDM, backup, vulnerability scanners. Build allow-lists and Sigma suppressions with evidence, not vibes.
• Week 2: tighten Suricata rule categories; fix HOME_NET/EXTERNAL_NET mistakes (the usual source of self-attacks); raise Zeek “rare destination” thresholds once you know normal fan-out.
• Weeks 3–4: false positives should feel like a queue you empty daily, not a firehose. If they do not, cut rule scope before you add more feeds.
• Tuning effort: budget real human time daily in month one (many small teams find a focused 30–60 minutes per weekday is the difference between a useful digest and ignored mail). That range is planning guidance, not a measured SLA.

What this build will not catch

• Encrypted payloads: TLS inspection is a policy and privacy decision this build does not require. Without it you see metadata (SNI, certs, JA3/JA4 if collected), not HTTP bodies.
• No EDR-grade telemetry: Velociraptor + Sysmon/osquery are powerful; they are not a substitute for a managed EDR’s kernel coverage, cloud analytics or vendor IR retainers.
• East-west blind spots: if the SPAN only sees north-south egress, lateral movement on an access switch you are not mirroring will not appear. Place the tap where the question lives.
• Cloud and SaaS: Microsoft 365, SaaS admin actions, and public-cloud control planes need their own APIs and audit logs. The NUC will not see them on a campus SPAN.
• Supply-chain and identity-only attacks that never touch your mirrored segment or pilot endpoints.
• Anything offline or air-gapped unless you deliberately ferry logs.

Time saved versus manual (cautious)

Treat the Bot as a tireless junior analyst who drafts, diffs and converts — not as a senior responder. Teams usually feel the win first in consistency (the 06:30 KEV diff always happens) and in draft quality (PRs and digests arrive pre-structured). Wall-clock “hours saved per week” depends entirely on how much manual intel gathering and rule conversion you did before; we are not publishing invented percentages. Measure your own baseline for two weeks (minutes spent on KEV review, Sigma conversion, beacon triage), then compare after the schedules run cleanly.

30 / 60 / 90-day maturity path

If you skip straight to Security Onion standalone, respect its documented floor (4 cores, 24 GB RAM, 200 GB, two NICs, x86-64) and keep Grok Bot’s cloud computer for intel and Sigma work either way — the agent split still applies.

Limitations and risks

• A mini PC will not replace a tuned SIEM or a 10 Gbps sensor grid. It is a force multiplier for a small team, not a silver bullet.
• Grok Bot can misread an advisory, invent a tidy-looking CVE, or follow injected instructions in a web page if you have not constrained it. Digests need a human skim.
• Registering the NUC expands blast radius: a bad approval can run a shell on your sensor host. Keep allow-lists narrow.
• Atomic Red Team and malware corpora are dangerous on a flat network — keep them in a lab VLAN.
• Licence obligations still apply (AGPL for Velociraptor/Hayabusa, GPL for Suricata/Chainsaw, and so on). Publishing modified AGPL services has source-share consequences; read the licences.
• Span legality and privacy: only mirror traffic you are authorised to inspect.
• If a GitHub token or SSH key used by the Bot leaks, rotate immediately; the blast radius should be one fork and one NUC, not the org.

What to do next

Start on the cloud computer alone: daily intel digest from KEV and our tracker feeds. When that is boringly reliable, register a budget NUC, add one local collector, and one Hunt Lab rule converted for your backend. Wire Zeek when you have a span and disk. Keep Friday Jones’s Velociraptor DFIR review next to the deploy notes, and file false positives back through Hunt Lab issues (opens in a new tab).

Sources

Primary pages checked on 28 October 2026 (Europe/London).

• Grok Bot get started (opens in a new tab) (desktop app platforms incl. Linux x64/Arm64); Grok Bot deployment (opens in a new tab) (hosted computer is Linux in Cursor’s cloud; Linux .deb/.rpm/AppImage); Download Grok Bot (opens in a new tab)
• Intel–ASUS NUC term sheet (18 Jul 2023) (opens in a new tab); ASUS NUC handover (2 Oct 2023) (opens in a new tab); ASUS NUC 14 Pro tech specs (opens in a new tab)
• Security Onion 2.4 hardware requirements (opens in a new tab)
• Raspberry Pi 5 announcement (peak power note) (opens in a new tab)
• Tool homepages as listed in A free threat hunting toolkit for small teams
• CyberThreatNet/hunt-lab (opens in a new tab); Cyber-Threat.net RSS feeds; tracker RSS /wp-json/ct-tracker/v1/feed and CSV /wp-json/ct-tracker/v1/export.csv
• Zeek get-zeek (opens in a new tab); Zeek cluster setup (opens in a new tab) (workers single-threaded; pin CPUs)
• Suricata install (opens in a new tab); suricata-update (opens in a new tab); Suricata tuning (opens in a new tab); ET Open index rules.emergingthreats.net/open/ (opens in a new tab)
• Velociraptor deployment (opens in a new tab); Velociraptor DFIR review (Friday Jones)
• OpenSearch install (opens in a new tab) (heap ≈ half RAM guidance; vm.max_map_count)
• Wazuh indexer guide (opens in a new tab) (min/recommended CPU/RAM; per-agent disk estimates)
• Grafana Loki install (opens in a new tab)
• SigmaHQ (opens in a new tab); pySigma (opens in a new tab); YARA (opens in a new tab)
• CISA KEV (opens in a new tab) (JSON feed); FIRST EPSS (opens in a new tab); API https://api.first.org/data/v1/epss
• MISP (opens in a new tab); OpenCTI installation (opens in a new tab)
• osquery install (opens in a new tab); Sysmon (opens in a new tab); sysmon-modular (opens in a new tab)
• RITA (opens in a new tab); Security Onion 2.4 hardware (opens in a new tab)

Follow Cyber-Threat.net RSS · Feedly (opens in a new tab) · X (opens in a new tab) · Bluesky (opens in a new tab) · LinkedIn (opens in a new tab)