Threat Hunting After the Initial Alert

An alert fires. An analyst confirms it, isolates the host and closes the ticket. That is a successful investigation and, sometimes, a failed response. The alert described what one sensor saw about one entity at one moment. It said nothing about what the same actor did earlier on systems that were not instrumented to complain, or later through access the containment step did not remove.

Hunting after an alert is a different job from investigating it. Investigation asks whether this alert is real and what happened on this host. The hunt asks what else resembles this across the entities the alert never touched. Treat the alert as a lead into an intrusion you have not yet seen.

The situation

Consider a hypothetical case. A detection fires on a service account logging on interactively from a workstation it has never used, followed by an encoded PowerShell command. The analyst isolates the workstation and resets the account password. The alert is handled. The hunt is only starting, because three questions remain open: where else has that account been, what did the actor set up to survive the reset, and who else ran the same behavior?

Scope the hunt on three axes

Working the hunt

1. State the hypothesis as something that can be disproved. For example: if the actor used this account to move laterally, we should see remote or interactive logons by it to servers where it has no history. The PEAK framework from Splunk SURGe describes hypothesis-driven, baseline and model-assisted hunts. After an alert you will usually start hypothesis-driven, then use a baseline hunt to learn what normal looks like for that account and host class.

2. Check that the telemetry exists before you run the query. An empty result from a source that was not collecting is not a negative. If your coverage record shows telemetry-only or not covered for the behavior in question, say so in the hunt record.

3. Set the window and the time box. Start from the earliest evidence, extend backward by a margin you can justify, and run to the present. A first pass within one working day is a reasonable target. That is a working recommendation, and the real constraint is how quickly new evidence changes the scope.

4. Record every query, window and result, including the empty ones. PEAK places documentation, automation and communication in its Act phase for this reason. A hunt you cannot reproduce cannot be reviewed, and cannot become a detection.

5. Pivot only on what the data supports. Each new indicator should come from a result, not a hunch. Hunts that wander are hard to close.

Hypotheses worth running first

CISA’s ransomware response checklist names what to hunt for when looking for further compromise. The items below are drawn from it and apply to any intrusion that could be heading toward extortion:

• New privileged accounts, or unexpected additions to privileged groups.

• Misuse of built-in operating system tools.

• Cobalt Strike activity.

• Remote monitoring and management software that nobody deployed.

• Signs of data exfiltration.

Built-in tools and legitimate remote access software are hard to separate from administration. Joint CISA guidance on living-off-the-land techniques says as much. Baselines by account and by host class are what make these hunts answerable.

When a hunt becomes an incident. The first confirmed activity outside the entity that raised the alert changes the work. Stop treating it as exploratory. Preserve evidence before further queries touch live systems, widen the circle of people informed, and open a decision log. Quiet hunting beside an open incident is how scope gets lost.

What a finished hunt hands back

Common traps

• Hunting only the host that alerted. The host is the least interesting part of the picture once it is isolated.

• Resetting a credential and calling it contained. Depending on the environment, existing sessions, tokens and tickets can outlive a password change. Check what your platform revokes.

• Reading a null as clean. Absence is meaningful only where the data was present.

• Letting the hunt run after the ticket closes. If the work is not tracked, its findings never reach the people who need them.

• Not writing down the negatives. The next hunter, and the next incident, benefit from knowing what was ruled out and on what evidence.

Next step

**** Take the last alert your team closed and run the three axes against it. Record where the telemetry could not answer the question; those gaps are your next engineering backlog. Cybrilliant supports hunting programs and can help structure hunts, records and hand-offs.

Sources

1. CISA, #StopRansomware Guide. https://www.cisa.gov/stopransomware/ransomware-guide

2. CISA and partner agencies, Identifying and Mitigating Living Off the Land Techniques. https://cisa.gov/resources-tools/resources/identifying-and-mitigating-living-land-techniques

3. Splunk SURGe, Introducing the PEAK Threat Hunting Framework. https://www.splunk.com/en_us/blog/security/peak-threat-hunting-framework