Three Intelligence Items, Three Analysts, One Week
Sable Grid runs 200 legacy Linux servers with no EDR agent and 1,800 endpoints with EDR. The SIEM keeps 30 days of searchable data; full packet capture exists only at the internet edge for 72 hours. Three analysts can spend roughly eight hours each per week on hunting. This week's intelligence feed gives three items. (1) A vendor report, high confidence, stating that a group targeting Sable Grid's sector uses signed Windows utilities for proxy execution - no named indicators. (2) An ISAC alert, medium confidence, listing 14 file hashes from a campaign six months old in another region. (3) A dark-web post, unverified, offering access to "a European energy firm". Sable Grid has no internet-exposed RDP and none of the VPN appliances named in item 2.
1. Rank the three items for action this week and justify each ranking, including what you would do with the ones you deprioritise.
Read the worked answer
Item 1 first. It is high confidence, sector-relevant, and describes a technique rather than atomic indicators, so it survives infrastructure changes and is testable against telemetry Sable Grid already collects - process creation and EDR data on 1,800 endpoints. Its weakness is the mirror image of its strength: signed-utility proxy execution is common and frequently legitimate, so the hunt will generate candidates requiring triage, and a negative result is weak evidence.
Item 2 second, as a cheap sweep. Fourteen hashes are trivial to query against 30 days of proxy, DNS, and EDR data - perhaps fifteen minutes. But the expected value is low: the campaign is six months old, in another region, and the entry vector it names does not exist here. Do the sweep, document the null result, close it. Do not spend analyst hours on it simply because it is concrete; concreteness is not relevance.
Item 3 last, and not as a hunt. An unverified post naming no victim is not actionable intelligence about Sable Grid. Its value is contextual early warning. Log it, note the sector overlap, set a re-evaluation trigger (the post names energy, Sable Grid's sector, or a victim appears), and move on. Hunting on an unattributed claim consumes the week's only capacity.
Distinguish source from subject. "High confidence" describes the vendor's confidence in its own reporting; it says nothing about Sable Grid's exposure. The ranking should combine confidence, relevance to this estate, and testability against this telemetry - item 1 scores highest on all three.
2. For item 1, write a falsifiable hypothesis and a test plan that fits the data constraints.
Read the worked answer
Hypothesis (stated so it can fail): "Between days 1 and 30, at least one of the 1,800 EDR-covered endpoints executed a signed Windows system binary in a manner inconsistent with its normal prevalence in this estate - specifically, spawning an unsigned or rarely-seen child process, or loading a script or payload from a user-writable path."
Scope, stated honestly: the 200 legacy Linux servers are outside this hypothesis. Say so in the report rather than implying estate-wide coverage; a Linux variant of the same campaign would be invisible to this hunt.
Data: EDR process-tree telemetry (process creation with command line, parent, user, and image signature) over 30 days. Packet capture is useless here - 72 hours at the edge will not hold a 30-day window, and this technique is internal.
Method:
- Compute prevalence for each candidate binary across the estate. A utility running on 1,400 hosts is background noise; one running on four hosts is a candidate.
- For rare binaries, inspect parent-child relationships and command lines for script hosting, encoded arguments, or execution from temp and user-profile paths.
- Cross-reference candidates against user context and business function - a developer workstation running an unusual utility is a different risk from a finance laptop doing it.
- Triage survivors through normal investigation, not by writing an alert first.
Time box: eight hours, with the query and prevalence baseline written down so the hunt is repeatable next quarter.
Output: named candidates for investigation, or a documented coverage gap. "No matches" is only a finding if you state what would have been visible.
3. The hunt finds nothing. How do you report that, and what do you do about the 200 servers you cannot see?
Read the worked answer
Report the null result with its boundary attached. The correct statement is: "No evidence of technique T1218-consistent activity was found across 1,800 EDR-covered endpoints over 30 days." The incorrect statement - and the one that gets organisations into trouble - is "we are not affected". Those are different claims, and only the first is supported.
State the blind spots explicitly in the report: 200 unmonitored Linux servers; 30-day retention against a campaign that may have begun 90 days ago; no visibility into encrypted or internal traffic beyond endpoint telemetry. A null result from insufficient data is not reassurance, and the report should say which of the two it is.
Then treat the gap as the finding. For the 200 legacy servers: instrument what can be instrumented (auditd or a lightweight agent), restrict egress to a documented allowlist, and require the system owner to accept the residual risk in writing if neither is possible. Unmonitored is a decision; undocumented unmonitored is negligence.
Convert the hunt into a detection. If the technique is plausible for this sector and the telemetry supports it, write a rule with a prevalence baseline rather than repeating the manual hunt every quarter. Manual hunting for a known, testable behaviour is a detection-engineering backlog item, not a permanent activity.
Feed the cycle. Tell the ISAC what you tested and what you found, including the null result - that is how the shared feed improves, and it buys standing when you next need something from them.