Scripts

Library › Scripts holds the scripts Scout can run on your endpoints. A script is reviewed and signed before any endpoint will run it. Each run is tied to the exact bytes and arguments that were approved, so a changed script, or a script someone swapped on the way, is refused.

People don't usually run scripts directly. They run Actions, which wrap a script with a parameter form, an approval policy and a rollout. The Scripts page is where the content behind those Actions is uploaded, reviewed and published.

Beta

This feature is currently rolling out and may not be enabled for your organization.

Two kinds of script

Kind	What it does	Where it's used
Action script	Changes something on the endpoint: isolates it, patches a package, disables an account.	Wrapped in an Action and run from the Library, an endpoint's Respond menu, or a Scout proposal.
Query script	Reads data no osquery table has, such as browser extensions per profile, and returns one row per line.	Called from a query or Collection through the scout_exec table. Results are cached for the script's result window (15 minutes by default), so a frequent schedule doesn't rerun it.

The Huntbase pack

Every organization gets the built-in Huntbase pack. It shows on the list with a Huntbase pack chip and is read-only.

Script	Kind	Platforms	What it does
isolate-host	Action	Linux, macOS, Windows	Blocks all network traffic except what Scout needs to reach Huntbase. See Isolate an endpoint.
release-host	Action	Linux, macOS, Windows	Removes exactly what isolate-host added.
isolation-status	Query	Linux, macOS, Windows	Reports whether isolation is applied and actually enforced.
patch-package	Action	Linux (apt, dnf, yum, zypper); best effort on macOS and Windows	Upgrades one package to a minimum version, optionally rebooting.
triage-bundle	Action	Linux, macOS, Windows	Collects processes, connections, logged-in users, autoruns and recent authentication logs into one archive.
disable-local-user	Action	Linux, macOS, Windows	Locks a local account. It refuses root, Administrator and the account Scout runs as.
browser-extension-inventory	Query	Linux, macOS, Windows	Chrome, Edge, Firefox and Brave extensions per profile.
persistence-inventory	Query	Linux, macOS, Windows	Cron, systemd units, launchd, Run keys and scheduled tasks.

Add a script

1. Open Library › Scripts and click New script.
2. Give it a slug (lowercase, for example collect-browser-history), a name, a kind and a risk level: Low, Medium or High.
3. Add one variant per platform. Drop a file, pick one or paste the text. The platform and interpreter are guessed from the file extension; check them.
4. Describe the arguments in Arguments, in order. Each argument has a name, a type (text, number, yes/no or a fixed list), whether it's required, and an optional default and pattern. Scripts receive them as --name value pairs, never through a shell.
5. Set the timeout and output cap. For a query script, set the result window.
6. Click Save draft.

To change a script later, open it and click Upload new version. The new version starts from the latest version's arguments and settings.

Review and publish

A version goes from Draft to In review to Published. Endpoints only run published versions.

1. The uploader clicks Submit for review.
2. A reviewer opens the script. The review panel shows the change against the published version.
3. The reviewer clicks Sign and publish, with an optional note, or Request changes with a required note.

For a High risk script, the person who uploaded a version can't publish it. A second person with publish access must sign it. Publishing a new version replaces the previous one; Actions pinned to Latest published pick it up on their next run.

The Versions, Content and Compare tabs show every version with its checksum per platform, the content of any version, and a line diff between any two versions.

Deprecate hides a script from new Actions. Existing Actions keep working until you change them.

Who can do what

To	You need
See a script	Membership of the organization, unless the script is restricted.
Upload or edit	Editor on the script, or organization admin.
Sign and publish	Publisher on the script, or organization admin.
Run it ad hoc on an endpoint	Runner on the script and response access on the endpoint.
Create or edit an Action that wraps it	Runner on the script.

Running a saved Action doesn't need access to the script inside it. That's how a help-desk group can use Kill process by name without being able to run arbitrary scripts.

Set these on the script's Access tab.

How signing protects endpoints

• Huntbase signs a manifest for each published version, per platform, naming the script's checksum, interpreter, arguments, timeout and output cap.
• Every run carries a single-use grant naming the script checksum, the checksum of the exact arguments, the run, and when it expires.
• The endpoint checks both signatures, checks the content it fetched against the checksum, and checks the arguments against the manifest before it runs anything. A mismatch is refused and recorded with its reason.
• Content is fetched once per checksum and cached on the endpoint.