HomeDocumentationAPI Reference
Log In
Documentation

Triage Hosts

The Host triage page is where a triage session starts. It shows every host in bands by priority, worst first, with the one finding that matters most about each host. From it you decide which host to open next, and you can close the simple cases without opening anything.

To open it, select Host triage in the sidebar. The bands, the columns, the Finding column, the Host triage summary card, and the actions of the page are described in Host Triage; this page is about how to use them.

Procedure

This is one pass through the fleet. Repeat it on a schedule, and whenever a notification or the Dashboard shows a new SEV 4 or SEV 5 host.

Step 1: Start at the Top

  1. Open Host triage.
  2. Read the High priority band from the top. The first row is the worst host in the fleet.
  3. If the Flagged band holds hosts that a colleague flagged for you, read it next.

Step 2: Read the Finding

For each host in the band, read Sev, Finding, and Tags before you open anything:

  • A SEV 5 host with Likely compromised or Likely malicious goes first.
  • A SEV 4 or SEV 5 host with no verdict and N alerts needs you to look. If AI triage is available, request a verdict for it while you look at the next host.
  • A host with Likely false positive and the same tags as many other hosts (for example, a new monitoring agent rolled out everywhere) is a candidate for a whitelist from this page.
  • A host with Needs attention has a weakness to fix, not an intruder. It can wait behind the hosts above it, but it should not wait forever.
  • A host with Stale in front of its verdict changed after the verdict. Treat it as a host with no verdict until a new one lands.

Step 3: Preview in the Card

  1. Click the row. The Host triage summary card shows the host.
  2. Read the AI brief and the Top detections. Ask: what kind of artifacts are alerting (processes, files, users, scheduled tasks), and do they look like one incident?
  3. Check the status dots. A host with Auth failing or Scan error may have stale evidence; a host that an attacker locked Sandfly out of looks exactly like a host with a rotated credential.

Step 4: Decide

What you seeDo this
Signs of intrusion, or anything you cannot explainClick Triage host and continue with Triage Host Detail.
A known-good artifact that alerts on many hostsWhitelist it. See Closing a false positive.
Something you must come back to, or hand to someone elseClick Flag. The host moves to the Flagged band for everyone.
Evidence that is old, or a host that just changedSelect the host and click Scan, or use Full scan group. Come back when the scan has finished.
No AI verdict yet, and you want one before you open the hostSelect the host and click AI triage, or click Run AI triage on the card.
A host that cannot be scanned (Never connected, Auth failing)Fix the credential or the connectivity. A host that Sandfly cannot scan is a blind spot, not a clean host.

Step 5: Work Down the Bands

When the High priority band is clear, read the Low priority band the same way. Most of it is hygiene, but a SEV 2 artifact on one host out of five hundred is still worth a look. The Clean band needs no triage, but check its Finding column for operational problems that stop Sandfly from scanning.

Closing a False Positive

A false positive is an alert on something that is legitimate and expected on that host, such as an administrator's own tool, a monitoring agent, or a package manager. The right response is to whitelist it so that it stops alerting, not to delete it.

From the Host triage summary card:

  1. In Top detections, select the artifacts that are false positives, or select none to act on all of them.
  2. Open the whitelist menu and select Whitelist selected or Whitelist all artifacts.
  3. In the Whitelist dialog, select where the whitelist applies: All hosts, Hosts by tag, or Selected hosts (this host is already filled in).
  4. Select the match strictness: Permissive Hash Match or Moderate Hash Match.
  5. Click Whitelist.

Whitelist on this host and Whitelist on all hosts do the same with Permissive Hash Match and only a confirmation. For the rules behind the dialog, see Using the Whitelist Dialog for Artifacts and Hosts.

⚠️

WARNING: Whitelisting Converts Existing Alerts into Passes

The Whitelist dialog and the quick whitelist menu convert the matching alerts into pass results on the hosts in scope. If you delete the whitelist later, those results do not change back into alerts. Whitelist only what you have identified. When in doubt, open the host first.

🚧

CAUTION: Ubiquity Is Not Innocence

An artifact present on hundreds of hosts is part of how those hosts were built. That makes it unlikely to be an intrusion, but it does not make it harmless: a default password shared by hundreds of hosts is a weakness on every one of them. Whitelist the false positives; fix the weaknesses.

Examples

A Host at the Top of High Priority

The first row reads SEV 5, Likely compromised, with tags cryptominer and persistence. The card's brief says that a process running from /tmp with a deleted binary has a high ML score and a matching cron entry. Top detections shows a process, a file, and a scheduled task.

This is one incident. Click Triage host and go to Triage Host Detail. Do not whitelist, and do not scan again first: scanning changes nothing on the host, and the evidence is already in front of you.

A Rollout That Alerted Everywhere

Twenty hosts in High priority all read SEV 4 with Likely false positive and the same tag monitoring-agent. The card for each shows the same binary under Top detections, and the AI brief says it is a vendor agent that was installed last night.

Confirm on one host that the binary is the agent you expect. Then whitelist the artifact with Whitelist on all hosts, or use the Whitelist dialog with Hosts by tag when the agent belongs only to one group of hosts. The twenty hosts drop to Clean or Low priority on the next refresh.

A Flagged Host From Another Shift

A host in the Flagged band reads SEV 3 with Needs attention. The brief says that the root account has a password that is easy to guess, and the host tag shows who flagged it. There is no sign of a login with it.

This is a weakness to fix, not an intrusion. Hand it to whoever owns the host, keep the flag until the password is changed, and then click Unflag.

Tips

  • Keyboard - The up and down arrow keys move the focus; Enter opens the focused host on its Details page.
  • Narrow pages - When the browser window is too narrow for the card, a single click opens the host instead of focusing it.
  • The All hosts tab - For operational columns such as the credential, the CPU load, the schedules, and the authentication status, switch to All hosts. Triage stays focused on severity.
  • Verdicts travel - When several hosts have the identical set of alerting findings on the same distribution family, Sandfly forms one AI triage verdict and gives it to all of them. A rollout of the same agent to two hundred hosts costs one submission, not two hundred.
  • The queue - Requests made by hand are worked before automatic ones. If a request does not move, open the queue from the AI triage queue module and read its state, for example Daily limit or Triage retrying.

What is Next

Did this page help you?