Hypothesis Discipline in a Resource-Constrained Hospital Hunt
A regional hospital has 4,000 endpoints, but only 3,200 run EDR; 800 infusion pumps and imaging systems are unmanaged. The three-person threat analysis team receives about 60 EDR alerts per day and can triage only 2% of them manually. The CISO has asked for an 'APT hunt' after an industry peer reported a breach. EDR shows recurring PowerShell alerts, mostly from IT automation, but 14 events in the last week involved encoded commands on clinical workstations. The SIEM retains 45 days of proxy and DNS logs, but no PowerShell script-block logging is enabled. The team has no dedicated threat intelligence subscription and one analyst has basic ATT&CK training. Leadership wants a hunt plan in two weeks and expects measurable results. The SOC manager worries that any hunt will become alert triage and distract from incident response.
1. Formulate one testable hunt hypothesis for the encoded PowerShell activity. Explain why 'hunt for APT' is not an executable hypothesis and what makes your hypothesis measurable.
Read the worked answer
A workable hypothesis is: 'If an adversary is using encoded PowerShell for execution or discovery on EDR-managed clinical workstations, then within a 14-day window we will observe a process chain where a non-IT parent such as Office, a browser, or a service spawns powershell.exe with -enc, -nop, or -w hidden, followed by outbound DNS or proxy traffic to a domain registered in the last 30 days, on hosts outside the known IT automation group.' This is measurable because it defines the population, time window, process parent-child relationship, command-line features, network follow-on, and an explicit exclusion. It can return a true, false, or inconclusive result.
'Hunt for APT' is not executable: APT is an actor label, not an observable. It gives no scope, data source, success criterion, or stopping condition. With 60 alerts per day and only 2% manual triage capacity, an unbounded APT hunt would collapse into alert triage and starve incident response. The hypothesis also respects the data problem: without script-block logging, endpoint evidence is weaker, so the network follow-on and parent-process evidence carry more weight. A null result is still useful if the query logic and gaps are documented. That is the judgment the exam expects: convert a vague leadership request into a bounded, falsifiable test that fits the team's actual telemetry and capacity.
2. How should the team separate this hunt from alert triage and monitoring, and which data sources should they prioritize given the blind spots?
Read the worked answer
Threat hunting is proactive and hypothesis-driven; it does not start from an alert queue. Triage is reactive work on the existing 60 alerts per day. Monitoring is continuous rule execution and dashboarding. The team should therefore run a time-boxed hunt sprint with a written hypothesis, predefined queries, an analyst log, and a stop date, not work the EDR queue under a different name. Because only three analysts exist, the sprint should be five working days and should sample the IT automation baseline first so that benign encoded PowerShell is not rediscovered as a finding.
Prioritized data sources are EDR process creation with command lines, proxy and DNS logs for the 45-day window, authentication logs for the involved hosts, and network flow data for the 800 unmanaged devices. PowerShell script-block logging would be valuable, but it is not enabled; the team should not pretend the hypothesis is fully testable on endpoints without it. A practical split is to test endpoint behavior on the 3,200 managed hosts and network-observable behavior for the unmanaged estate. If a pilot GPO can enable script-block logging on a small clinical workstation ring without disrupting care, that becomes a preparation action, not a hunt shortcut. The reasoning matters: a hunt that ignores the 800-device blind spot overstates coverage, while a hunt that waits for perfect telemetry never starts.