Threat Hunter

Role Overview

Threat hunters proactively search for adversary activity that evades automated detection. They form hypotheses based on intelligence, craft detection logic, sweep the environment, and refine rules based on results. Fleet accelerates every stage of this cycle by handling the research, rule generation, validation, and deployment while the hunter focuses on strategy.

Workflow: Hypothesis-Driven Hunt

The hunter suspects an APT group is targeting the organization based on a recent industry advisory. They need to research the threat, build detection, and sweep the environment.

Step 1: Research the Threat

Search for the latest advisories and technical reports on APT41 activity targeting the financial sector. Summarize TTPs, known infrastructure, and recommended detection approaches.

Fleet searches the web for current intelligence, retrieves relevant reports, and produces a consolidated briefing.

Result: Summary of APT41 TTPs, known IOCs, infrastructure patterns, and detection recommendations from multiple sources.

Step 2: Process a Threat Report

Upload a detailed threat report for deeper analysis.

Process this APT41 report into a full intelligence package. Extract all observables, enrich them, map TTPs to MITRE ATT&CK, and generate detection rules for each attack stage.

Fleet extracts every observable, enriches with reputation data, maps techniques to ATT&CK, and generates Sigma rules per attack stage plus YARA rules for known file indicators.

Result: Enriched IOC table, ATT&CK mapping, Sigma rules (with Splunk SPL and Sentinel KQL conversions), YARA rules, and STIX 2.1 bundle.

Step 3: Validate Detection Rules

Before deployment, test the rules against sample data.

Test these Sigma rules against the attached Windows event logs. Show which rules trigger and on which events.

Fleet runs the rules against the provided EVTX or JSONL logs and reports matches, false positives, and coverage gaps.

Step 4: Deploy and Sweep

Deploy all validated YARA and Sigma rules to all managed endpoints. Also deploy the osquery queries to check for the persistence mechanisms described in the report.

Fleet deploys through AIR triage and monitors results.

Step 5: Analyze Results

Show me the triage results. Which endpoints had matches? Summarize the findings by rule and endpoint.

Fleet retrieves and summarizes the scan results, highlighting confirmed detections and recommending next steps for each finding.

Workflow: Proactive Endpoint Sweep

The hunter wants to check the environment for living-off-the-land techniques without a specific threat report as input.

Step 1: Generate Detection Queries

Generate osquery queries to detect the following across all endpoints:
1. Scheduled tasks created in the last 7 days
2. Services with unusual binary paths (temp directories, user profiles)
3. PowerShell execution policy overrides
4. WMI event subscriptions
5. Startup folder modifications

Fleet generates five validated osquery queries, each targeting a specific persistence or execution technique.

Step 2: Deploy the Queries

Deploy all five queries to all Windows endpoints.

Fleet deploys through AIR triage.

Step 3: Review and Triage Results

Show the triage results for all five queries. Flag any findings that look suspicious and explain why.

Fleet retrieves results, filters noise (known-good scheduled tasks, legitimate services), and highlights anomalies with context.

Step 4: Deep-Dive on Findings

For any suspicious finding, pivot into deeper analysis.

Download the binary at C:\Users\admin\AppData\Local\Temp\updater.exe from WORKSTATION-119 and perform full static analysis.

Fleet retrieves the file via interACT and runs comprehensive analysis.

Step 5: Build Targeted Detection

Based on this analysis, generate a YARA rule for the binary and a Sigma rule for the process creation pattern. Deploy both to all endpoints.

The hunt cycle closes with new detection rules deployed from the findings.

Workflow: Intelligence Operationalization

The hunter receives a batch of IOCs from an ISAC or partner organization and needs to operationalize them.

Step 1: Ingest and Enrich

Upload the IOC list or advisory document.

Extract all observables from this ISAC advisory. Enrich them and produce a scored report. Filter out known-good hashes and popular domains.

Fleet processes the input, enriches every indicator, applies NSRL and domain popularity filtering, and produces a prioritized list.

Result: Scored IOC table with high-confidence malicious indicators separated from noise.

Step 2: Generate Multi-Format Detection

For the top 10 highest-risk indicators, generate:
- YARA rules for file-based indicators
- Sigma rules for network and process indicators
- osquery queries for persistence indicators

Fleet generates all three rule types, validates each, and converts Sigma rules to SIEM query languages.

Step 3: Deploy Across the Environment

Deploy all generated rules to all managed endpoints.

Step 4: Produce the Intelligence Package

Export the full intelligence package: STIX 2.1 bundle with all enriched IOCs, all detection rules, ATT&CK mapping, and a summary suitable for sharing with the SOC team.

Result: A complete, distributable package that the SOC team can use for ongoing monitoring.

Workflow: Detection Rule Maintenance

The hunter maintains a library of custom detection rules and needs to update them based on new intelligence.

Step 1: Validate Existing Rules

Upload the current rule set.

Validate these 15 YARA rules. Identify any that have syntax errors, and suggest improvements for rules that are too broad or too narrow.

Fleet validates each rule, reports errors, and provides specific improvement suggestions.

Step 2: Update Rules from New Intelligence

Update the YARA rule "APT41_Loader" to also detect the new variant described in this report. Keep the existing detection logic and add patterns for the new variant.

Fleet modifies the rule, validates compilation, and tests against any provided samples.

Step 3: Convert Detection Formats

Convert these 5 Sigma rules to Splunk SPL and Microsoft Sentinel KQL. Verify that the conversions preserve the original detection logic.

Fleet converts each rule and highlights any detection features that do not have direct equivalents in the target query language.

Hunt Cycle Summary

Phase	Fleet Capability
Research	Web search, report finder, threat intelligence enrichment
Hypothesis	ATT&CK mapping, observable extraction, intelligence processing
Detection	YARA, Sigma, osquery generation with validation and conversion
Deployment	AIR triage rule deployment to targeted or all endpoints
Analysis	Triage result retrieval, artifact analysis, endpoint assessment
Refinement	Rule validation, improvement suggestions, format conversion
Documentation	STIX 2.1 export, structured reports, intelligence packages