Act on a hunt finding

The Continuous Threat Hunt Worker in the Hunt Watch searches your data for activity that matches recent threat reports. When the Worker confirms a match, it adds a hunt finding to the threat report's investigation and proposes response actions for the hosts and processes involved. The Worker offers only Manual autonomy, so every action it proposes waits for you.

To learn what the Worker searches and which sources it draws on, refer to Watches and Workers.

Each threat report has one investigation in each space, named after the report. The result of the hunt decides what happens to that investigation:

  • No confirmed match: The Worker closes the investigation as benign without asking you.
  • Confirmed match: The investigation stays open with the hunt finding and the proposed actions that come from it.
  • Hunt didn't finish: The investigation stays open, and a note in it explains which part of the hunt didn't run.

If a later hunt of the same threat report confirms more activity, the Worker reopens the investigation and adds the new hunt finding to it.

After every hunt, the Worker passes the attack techniques it searched for to the Rule Coverage Worker in the Detection Watch, which proposes rules for any techniques your detection rules don't cover.

The Worker proposes response actions only for hosts that run Elastic Defend. It picks one response action for each process that the hunt implicates, and decides separately whether to isolate each host.

Response action When the Worker proposes it
Kill a process The hunt confirms that the process used a destructive technique, such as encrypting or deleting data. Or the finding is critical and the process matched an indicator of compromise (IOC) from the threat report.
Suspend a process The process is running, and the rules for killing it don't apply.
Dump a process's memory The Worker proposes suspending the process, and the host supports memory dumps. A memory dump keeps evidence for analysis.
Isolate a host The hunt confirms lateral movement, command and control, or data exfiltration on the host. Or the hunt finds two or more suspicious processes on the host. Or the finding is critical and the host has a suspicious process.

The Worker doesn't propose any action for these processes:

  • A protected system process, such as lsass.exe. The Worker never kills or suspends one, but might propose a memory dump.
  • A process that has exited.
  • A process that the hunt last saw outside the period it searched, or more than seven days before the end of that period.

If another investigation already has the same response action waiting for the same host, the Worker doesn't propose it again. Instead, it adds this investigation to the waiting proposed action, and you decide the action once, in the other investigation.

On the Proposed actions page, response actions from a hunt belong to the investigation named after the threat report. If containing hosts isn't your role, assign the investigation to an incident responder.

Before you decide any response action, check that the hunt finding holds up. Along with the finding's severity and the Worker's confidence, check these:

  • What matched: IOCs from the threat report, such as file hashes or IP addresses, or activity that matches one of the report's attack techniques.
  • Which hosts and users are involved: Activity that's normal on those hosts, such as an admin tool that uses the same technique, points to a false match.
  • How the evidence balances: The evidence for the match, weighed against the evidence against it.

To dig deeper, open the matching events in Discover, or ask follow-up questions in the investigation's chat. If the evidence doesn't show a real threat, decline the hunt's response actions.

For each response action, check what it does and why the Worker picked it. Make sure the hunt finding implicates the host or process it targets, and consider what stops working when you act on it. For example, isolating a server also cuts off the people and services that depend on it. Then approve or decline the action:

  • If you approve: The action runs under your account, through Elastic Defend, so you need the privileges to run it. If you don't have them, or the host doesn't respond within 10 minutes, the action fails, and AlertZero offers it again as a new proposed action with the same deadline. The Elastic Defend action might still run when the host comes back online, so check the response actions history before you approve it again.
  • If you decline: The action doesn't run. The same happens if the proposed action expires before anyone decides.

If you isolate a host, AlertZero doesn't propose releasing it later. When it's safe to reconnect the host, release it yourself. You can't undo the other response actions.

Some findings need work that no response action covers. For these findings, the Worker also proposes an Analyst recommendation. For example, it proposes one in these cases:

  • The evidence involves user accounts, services, or IOCs such as IP addresses, which acting on a host doesn't contain.
  • A host in the finding doesn't run Elastic Defend.
  • The Worker held back a response action, such as isolating a host that doesn't support isolation.

The recommendation explains what the response actions don't cover and why. When the Worker has them, it also lists steps to take by hand. Do the follow-up yourself, or hand it to the person who owns it. Then approve the recommendation to record that you followed up, or decline it to record that you don't need to. Neither runs anything.

After you decide every proposed action in the investigation, or they expire, the Worker closes the investigation. The exception is an investigation whose finding joined a waiting proposed action in another investigation. To close it, select Close investigation on its card.

To work on the finding with other people instead, escalate the investigation.