Designing Intelligence-Led Hunts and Detections

Design bounded searches and analytics that connect a proposition to expected observations, required telemetry, benign alternatives, validation criteria, triage guidance, review dates, and feedback.

Turn intelligence judgments into testable hunt hypotheses

An intelligence-led hunt tests a proposition against organizational evidence. It is not an unbounded search for anything unusual, and it is not a detection rule deployed before its assumptions and data requirements are understood.

A complete hunt hypothesis states:

If [assessed behavior or relationship] occurred within [scope and period], then [specific sources] should contain [expected observations and sequence], unless [visibility or evasion limitation] applies. Finding or not finding those observations will change [judgment or decision] in a defined way.

Project Lantern example:

If related Lantern activity affected additional finance endpoints between 08:30 and 13:00 UTC, endpoint telemetry should show an archive, browser, or signed utility spawning the observed interpreter or script pattern, followed within ten minutes by related task creation or credential-store access. Full matches will expand incident scope; no matches will narrow scope only for endpoints with adequate process, command, task, and file-access coverage.

Begin with the intelligence judgment

Trace the hunt to:

• requirement and decision;
• current assessment version and information cutoff;
• proposition and confidence;
• defining evidence;
• likely alternatives;
• entities and time window;
• operational effect of positive, negative, and ambiguous results.

Weak hunt request:

Search for the campaign.

Stronger hunt request:

Test whether the validated delivery-to-script sequence appears on additional payment-connected endpoints and identities, and report coverage and benign explanations so the incident commander can decide whether to widen containment.

Define expected observations

Break behavior into observable relationships:

Do not hunt only for framework labels. Translate the model into source-specific observable evidence.

State telemetry and coverage requirements

For every expected observation, record:

• source system;
• required fields;
• event semantics;
• collection and ingestion status;
• entity and period coverage;
• retention;
• timestamp precision and alignment;
• known parsing or normalization issues;
• evasion or tampering risk;
• access and handling constraints.

Example coverage record:

Hunt results are inseparable from coverage.

Define benign and alternative explanations

Before searching, identify likely benign matches:

• authorized software deployment;
• administration tools;
• support scripts;
• security testing;
• software updaters;
• developer activity;
• backup or browser-management tools;
• expected new-device sessions;
• telemetry duplication or parsing defects.

Write distinguishing evidence:

This prepares triage and reduces confirmation bias.

Choose hunt scope deliberately

Define:

• population;
• time window;
• behavior sequence;
• query depth;
• source requirements;
• exclusions;
• privacy and handling;
• stopping conditions;
• result categories;
• decision deadline.

A bounded scope might be:

Search 104 finance and payment-connected endpoints from 08:30–13:00 UTC. Include archive, browser, office, interpreter, signed-utility, script, task, and browser-store relationships. Exclude known software distribution systems only after validating signed package and owner. Stop the initial pass at 13:15 and report full matches, partial matches, known benign matches, unavailable entities, and query limitations.

Use result categories

Do not label every partial match “suspicious” without its missing and contradictory evidence.

Build a hunt plan

Translate campaign indicators cautiously

Campaign-derived features may be:

• seed artifacts: known hashes, domains, or paths used to find initial evidence;
• behavior features: process, file, identity, or network relationships;
• context features: target role, timing, service path, or infrastructure pattern;
• warning combinations: several observations whose conjunction is more diagnostic.

Avoid including every campaign-associated value. Use evidence and intended action to select features.

Interpret negative hunt results

A negative result supports narrowing only if:

• the expected behavior was defined;
• the query represented it correctly;
• relevant telemetry existed;
• coverage included the entity and period;
• retention and ingestion were healthy;
• likely evasion did not invalidate the search;
• the behavior should have produced the signal.

Write:

No additional full-sequence matches were found on 92 endpoints with adequate process and command coverage. Twelve endpoints remain unknown for the full sequence; alternate collection is underway.

Not:

No other endpoints were compromised.

Use positive results to update intelligence

A match is evidence, not automatic confirmation. Triage should collect:

• raw event references;
• process and file ancestry;
• relevant messages or retrieval events;
• user and device context;
• identity and service relationships;
• software ownership and change evidence;
• source coverage and timestamp limitations;
• related infrastructure in the event period;
• preservation status.

The result should update:

• entity scope;
• competing hypotheses;
• campaign membership;
• likelihood and confidence;
• warning indicators;
• containment or restoration options.

Preserve hunt reproducibility

Record:

• query or notebook version;
• logic and parameters;
• source schemas and tool versions;
• population and time bounds;
• exclusions and allowlists;
• execution time;
• result count and categories;
• coverage and failures;
• analyst triage decisions;
• changes between runs;
• expiration and owner.

A screenshot of a search interface is not a reproducible hunt record.

Hunt quality checklist

• The hunt traces to an assessment, requirement, and decision.
• The hypothesis predicts observable evidence and interpretable negative results.
• Required sources, fields, semantics, coverage, and limitations are documented.
• Benign, mixed, and data-quality alternatives are defined before results.
• Population, period, sequence, exclusions, handling, deadline, and stopping rules are bounded.
• Full, partial, benign, processing, negative, limited, and unavailable results are distinguished.
• Negative results are limited to adequate visibility.
• Matches feed back into scope, hypotheses, campaign membership, and action.
• Query logic and execution are reproducible and versioned.

Key takeaways

• An intelligence-led hunt tests a proposition against organizational evidence.
• Translate assessments and behavior models into source-specific expected observations.
• Treat telemetry coverage as part of the result.
• Define benign and data-quality alternatives before searching.
• Bound population, time, logic, and stopping conditions.
• A match requires triage; a non-match supports narrowing only under adequate visibility.
• Version hunt logic and feed results back into intelligence and decisions.

Analyst habit: Before running a hunt, complete two sentences: A positive result will change… and A negative result is meaningful only if…

Validate, deploy, and maintain detection analytics

A detection analytic operationalizes a testable behavior or relationship for repeated use. It must preserve the intelligence proposition, data assumptions, benign alternatives, triage path, intended response, and lifecycle controls. A query that runs successfully is not necessarily a valid detection.

Progress through deployment modes

Use staged deployment:

1. Offline test: Validate logic against preserved known-positive and benign data.
2. Retrospective search: Measure historical prevalence, coverage, and unexpected matches.
3. Monitor-only: Run prospectively without creating operational alerts.
4. Alerting: Send qualified matches to a defined triage process.
5. Automated action: Apply blocking, isolation, or revocation only when evidence, impact analysis, authority, and rollback support it.
6. Retirement or redesign: Remove stale, redundant, harmful, or invalid analytics.

Do not jump from a campaign report to automated blocking.

Write an analytic specification

Define logic at the right abstraction

Project Lantern analytic candidates:

Artifact rule

Match Script S-1 hash.

• High specificity for the exact file
• Low durability against modification
• Suitable for retrospective search and short-lived control

Process behavior rule

Match an archive, browser, or office process spawning an interpreter or signed utility that launches a script from a user-writable extracted path.

• Broader variant coverage
• More legitimate administrative matches
• Requires process, command, path, and parent data

Sequence rule

Match the process behavior followed within ten minutes by task creation, browser-store access, or a related new-device identity event.

• Stronger context and specificity
• Requires cross-source correlation and reliable time alignment
• Can miss operations where telemetry or behavior differs

Use several layers rather than expecting one rule to cover every need.

Validate against positive and benign evidence

Validation should include:

• preserved Project Lantern events;
• partner events with compatible behavior and permitted use;
• authorized deployment and administration cases;
• common software updaters;
• expected browser or credential-management activity;
• security testing;
• partial sequences;
• missing-field and delayed-ingestion cases;
• time-zone and clock-offset conditions.

Ask:

• Does the analytic detect the known-positive behavior?
• Which required features are absent in some sources?
• Which legitimate workflows match?
• Which conditions distinguish them?
• Does the analytic rely on fields that are normalized inconsistently?
• How would a modest behavior change evade it?
• What would happen operationally if every match triggered action?

Measure more than precision

Useful measures include:

An analytic with perfect precision but extremely narrow coverage may miss most variants. One with broad coverage may be worthwhile in monitor-only mode despite lower precision.

Design triage before alerting

A triage guide should state:

1. Confirm source health, field semantics, and raw event identity.
2. Reconstruct parent-child and file relationships.
3. Identify user, host, account, service, and time context.
4. Check authorized software, change records, and owner confirmation.
5. Look for message, retrieval, task, credential, identity, and infrastructure context.
6. Preserve volatile evidence where required.
7. Categorize full, partial, benign, processing-error, or unknown result.
8. Apply escalation and handling rules.
9. Feed the outcome to the intelligence and detection owners.

Do not tell analysts only to “investigate suspicious activity.”

Establish action thresholds

Suppression should preserve visibility into changes. A broad allowlist can hide malicious use of a legitimate tool.

Use contextual suppression

Prefer conditions such as:

• signed package plus expected hash and publisher;
• approved deployment system and window;
• known parent process and service account;
• expected path and command pattern;
• valid change identifier;
• owner-confirmed asset role.

Avoid suppressing all activity from one tool name, account, or directory when attackers could reuse it.

Deploy with ownership and rollback

Record:

• deployment mode;
• affected population;
• start time;
• owner and on-call route;
• expected match volume;
• response service level;
• monitoring for data failure;
• rollback procedure;
• decision authority for automated action;
• initial review time;
• expiration or renewal.

Example:

Deploy Analytic L-3 in monitor-only mode to finance endpoints at 15:00. Review matches and source health after four hours. Move to alerting only if full-sequence known-positive cases are detected and benign-match volume is manageable. Roll back on service impact or parser defect.

Monitor data health

Detection failure can look like no threat activity. Track:

• event volume changes;
• missing fields;
• delayed ingestion;
• parser errors;
• source disablement;
• population coverage;
• schema changes;
• time alignment;
• rule execution failures.

A zero-match dashboard without data-health context can create false reassurance.

Feed results back into intelligence

A detection outcome can:

• expand or narrow incident scope;
• strengthen or weaken a campaign hypothesis;
• identify benign alternatives;
• reveal behavior evolution;
• expose source gaps;
• change confidence;
• invalidate infrastructure or identity relationships;
• generate new warning indicators;
• justify a durable control.

Create a feedback record:

Manage analytic lifecycle

Review when:

• campaign behavior changes;
• data sources or schemas change;
• false positives rise;
• known-positive activity is missed;
• source coverage improves or declines;
• temporary incident use ends;
• infrastructure expires;
• legal, privacy, or operational conditions change;
• another analytic provides better coverage;
• the supported requirement closes.

Lifecycle states can include:

• draft;
• test;
• monitor;
• alert;
• enforce;
• tuned;
• deprecated;
• retired;
• superseded.

Every state change should have a reason and owner.

Project Lantern deployment

The detection team creates three analytics:

• L-1: Exact script and related artifact search, expiring after seven days.
• L-2: Process relationship search for archive or browser to interpreter or signed utility to script.
• L-3: Cross-source sequence adding task, credential-store, or identity behavior.

L-2 begins in monitor-only mode and identifies a common approved deployment. The team adds contextual validation rather than excluding the administration tool entirely. L-3 finds one new full match and triggers preservation and identity review. Results raise campaign confidence and refine the warning model.

Detection review checklist

• The analytic traces to an intelligence proposition, version, and decision.
• Logic is specified at artifact, behavior, or sequence level appropriately.
• Required sources, fields, semantics, coverage, and health are explicit.
• Known-positive and benign cases validate the logic.
• Coverage, sensitivity, precision, latency, cost, consequence, and durability are considered.
• Triage distinguishes full, partial, benign, error, and unknown outcomes.
• Action thresholds match evidence and operational authority.
• Suppression uses context rather than broad allowlists.
• Deployment mode, owner, rollback, review, and expiration are defined.
• Results feed back into intelligence and lifecycle decisions.

Key takeaways

• Progress from offline testing to search, monitoring, alerting, and enforcement deliberately.
• Preserve the intelligence proposition and data assumptions in the analytic specification.
• Use artifact, behavior, and sequence analytics as complementary layers.
• Validate with known-positive, benign, partial, and data-quality cases.
• Measure coverage, sensitivity, precision, latency, triage cost, consequence, durability, and learning.
• Design triage and action thresholds before operational alerting.
• Monitor source health so missing data does not appear as safety.
• Version, review, tune, and retire analytics as campaigns and environments change.

Analyst habit: Before promoting an analytic to a more consequential mode, ask: What evidence shows the logic works, what benign workflow can still match, and how quickly can we reverse the action?