Advanced Topics

Threat Actor Profiling for Hunt Targeting

Not all threat actors are relevant to your organization. Hunting based on irrelevant actor groups wastes time and produces false confidence in the form of No-Find results that mean nothing because the actor was never going to target you anyway. Actor profiling is how you focus the hunt backlog on threats that actually matter for your environment.

Four dimensions of actor profiling:

• Industry targeting: Which groups have targeted your industry sector in the past 24 months? Filter MITRE ATT&CK Groups by sector. A group targeting financial services has different TTPs than one targeting government or healthcare.
• Geographic alignment: State-sponsored actors often target based on geopolitical context. Match your organization's countries of operation against known targeting patterns. A US-based company with operations in Eastern Europe faces a different actor profile than one operating only domestically.
• Technology alignment: Actors use techniques that match their targets' technology stacks. If your environment is primarily Azure AD and Microsoft 365, actors exploiting Azure AD token theft are more relevant than actors exploiting legacy on-premises-only infrastructure.
• Business event triggers: M&A activity attracts espionage-motivated actors targeting intellectual property. Public company announcements attract financially-motivated actors. Post-breach periods attract follow-on actors who acquire access from initial-access brokers. Match recent business events to actor motivation profiles.

// Hunt: Cobalt Strike default and common C2 beacon patterns
// Used by multiple actor groups. Beacon pattern: periodic connections,
// consistent byte sizes, specific URI patterns.
DeviceNetworkEvents
| where ActionType == "ConnectionSuccess"
| where RemoteIPType != "Private"
| where RemotePort in (80, 443, 8080, 8443)
| summarize
    ConnectionCount = count(),
    BytesSent = sum(SentBytes),
    BytesReceived = sum(ReceivedBytes),
    UniqueRemoteIPs = dcount(RemoteIP),
    HoursActive = dcount(bin(Timestamp, 1h))
    by DeviceName, InitiatingProcessFileName, RemoteIP, bin(Timestamp, 1d)
| where ConnectionCount between (48 .. 1440)  // ~every 1-30 min over 24 hours
| where UniqueRemoteIPs == 1  // single C2 target: not browsing behavior
| extend AvgMinutesBetweenConnections = round((1440.0 / ConnectionCount), 2)
| where AvgMinutesBetweenConnections between (1.0 .. 30.0)
| order by ConnectionCount desc

Campaign-Based Hunting

Intel-driven, time-boxed hunts focused on a specific threat campaign rather than a single technique. When a major threat report drops, when CISA issues a sector-specific alert, or when a CVE is being actively exploited by a documented actor, a campaign hunt is faster and more thorough than hunting each technique individually.

Campaign hunt structure:

1. Collect the full campaign intel: all TTPs used (not just the headline technique), IOCs as starting points, infrastructure patterns, and victim profile.
2. Map every TTP to an ABLE hypothesis. A typical ransomware campaign has 6 to 8 technique stages, each requiring its own hypothesis.
3. Build a hunt pack: bundle all hypotheses for the campaign with a shared scope and time window.
4. Execute in order of confidence (highest data availability first). Starting with the technique where you have the most reliable telemetry gives you early results that may guide the remaining stages.
5. Results feed into a single campaign report rather than individual hunt reports.

TRACEPULSE at h3ad-sec.github.io/TRACEPULSE/ provides campaign-tied query packs. When a new campaign is reported, start there before writing queries from scratch.

ML-Assisted Hunting (M-ATH)

PEAK's third hunt type: Model-Assisted Threat Hunting. Machine learning does not replace the hunter. It surfaces anomalies that are too subtle or too voluminous for manual statistical review. The hunter's job is to interpret the ML output and separate genuine anomalies from model noise.

Three ML Methods Relevant to Hunting

Clustering (unsupervised): Group entities by behavioral similarity. Identify entities that do not fit any cluster as outliers. Use case: process behavior clustering. Every legitimate svchost.exe on 5,000 endpoints should cluster together by parent process, command-line pattern, and network destination. One svchost.exe that is a statistical outlier from the cluster is the anomaly to investigate. Manual frequency analysis alone would miss this because the process name is common.

Anomaly detection: Establish a normal behavior model over a time baseline, then flag deviations. Use case: user behavior baseline. Alert when a user's login pattern, data access volume, or system usage deviates significantly from their 30-day behavioral baseline. This approach catches insider threats and account compromises that do not match any known TTP pattern.

Classification (supervised): Train on labeled known-good and known-bad examples. Classify new events by probability. Use case: command-line classification. Train a model on malicious vs. benign PowerShell command strings. Flag any new PowerShell command scoring above a confidence threshold for analyst review. Reduces analyst time spent on obvious benign commands while surfacing subtle obfuscation patterns.

SIEM and EDR tools with built-in ML: Microsoft Sentinel anomaly rules and BehaviorAnalytics, Elastic ML jobs (anomaly detection on log fields), Splunk MLTK (machine learning toolkit with pre-built anomaly detection algorithms).

// ML-assisted hunt: Microsoft Sentinel BehaviorAnalytics for anomalous user activity
// BehaviorAnalytics applies ML to sign-in patterns, access behavior, and location data.
// InvestigationPriority is a composite score from multiple ML models.
BehaviorAnalytics
| where ActivityType == "LogOn"
| where ActivityInsights has "UnusualLocation"
    or ActivityInsights has "UnusualTime"
    or ActivityInsights has "MassDownload"
    or ActivityInsights has "ImpossibleTravel"
| where InvestigationPriority > 5
| project
    TimeGenerated,
    UserPrincipalName,
    ActivityType,
    ActivityInsights,
    InvestigationPriority,
    SourceIPAddress,
    SourceDevice
| order by InvestigationPriority desc

The hunter's role with M-ATH output: triage the flagged anomalies. Determine which are genuine behavioral deviations requiring investigation vs. model noise (user traveled for a conference, hence "UnusualLocation"). The ML surfaces the candidates. The hunter applies context and makes the call.

Threat Emulation and Hunt Validation

The most direct way to know whether your hunt capability works: simulate the attack and see if you find it. A hunt team that has never validated its detection against actual technique execution is operating on the assumption that the detection works. Assumptions are not security controls.

Purple teaming pairs red team (offense) and blue team (defense) working together rather than against each other. The goal is not to compromise the organization; it is to generate artifacts, validate detection, and close gaps.

Hunt validation workflow:

1. Select a TTP to validate, for example T1003.001 (LSASS credential dumping).
2. Red team executes the technique in a controlled lab environment, or in production with explicit written approval and a defined rollback plan.
3. Hunt team hunts for evidence using their standard methodology, without advance knowledge of exactly when or where the technique was executed.
4. Compare: what evidence was generated by the execution vs. what evidence was found by the hunt. Every artifact generated but not found is a detection gap.
5. Gap analysis: document each gap, identify whether it is a data source gap, a query logic gap, or a retention gap, then remediate.

Tools for threat emulation: Atomic Red Team (open source, github.com/redcanaryco/atomic-red-team), MITRE Caldera (open source adversary emulation platform), MITRE ATT&CK Evaluations public data (use as reference for expected artifacts per technique).

# Atomic Red Team T1003.001 — LSASS credential dumping
# NOTE: Execute ONLY in an isolated lab environment with explicit written approval.
# This documents the expected artifacts so hunters know what to validate detection against.

# Technique: Task Manager UI dump of LSASS (basic — well-known to defenders)
# To simulate: In Task Manager, right-click lsass.exe, select "Create dump file"

# Expected artifacts to validate detection against:
#   Sysmon Event 10 (ProcessAccess): lsass.exe accessed by taskmgr.exe
#     - GrantedAccess: 0x1FFFFF (full access) or 0x001FFFFF
#   Windows Security Event 4656: Handle request to lsass.exe
#   File creation: C:\Users\[user]\AppData\Local\Temp\lsass.DMP

# Hunt query to validate detection coverage:
# DeviceEvents
# | where ActionType == "OpenProcessApiCall"
# | where FileName =~ "lsass.exe"
# | where not(InitiatingProcessFileName in~ ("MsMpEng.exe","csrss.exe","werfault.exe"))
# | project Timestamp, DeviceName, InitiatingProcessFileName,
#           InitiatingProcessCommandLine, GrantedAccess

CrowdStrike OverWatch's SEARCH methodology includes a "Hone" phase that specifically incorporates adversary emulation findings to update hunt techniques. Their approach: run emulation, identify what the hunt team missed, update the hypothesis backlog and query library, repeat quarterly.

Building a Hunt Program

An individual hunter is valuable. A structured program is scalable, measurable, and institutional. The program survives when analysts change roles, when the team grows, and when management asks for evidence of value.

Hunt Program Maturity Levels

Hunt Cadence Recommendations

• Weekly: 1-2 quick hunts under 2 hours each, based on current threat intel reports or new CVE exploitation activity.
• Monthly: 2-4 medium hunts of 2 to 8 hours each, covering priority ATT&CK techniques from the hypothesis backlog.
• Quarterly: 1-2 deep hunts spanning multiple days, covering complex techniques or full campaign reconstructions. Include purple team validation of one or two previous hunt detections.

Team Structure for a Mature Program

• Hunt Lead: Owns strategy, manages the hypothesis backlog, coordinates with CTI and detection engineering, delivers KPI reporting to management.
• Hunters (2-4): Execute hunt sprints, run queries, perform analysis and iteration, generate hypotheses from execution findings.
• Detection Engineer: Converts confirmed hunt findings into tuned, production-ready detection rules. Owns the TRACERULES library.
• CTI Analyst: Feeds the hypothesis backlog from threat intelligence. Maintains actor profiles, tracks emerging campaigns, maps intel to ABLE hypotheses.

AI-Assisted Threat Hunting

AI changes the speed and scale of certain hunt tasks. It does not change the fundamental methodology. A hunter who understands the methodology will use AI well. A hunter who treats AI as a replacement for methodology will produce AI-confident, methodologically unsound hunts.

Where AI Adds Value

• Hypothesis generation: Give an LLM a threat report excerpt and ask for ABLE-formatted hypotheses. Dramatically speeds up the intel-to-hypothesis conversion step. Still requires analyst review for environment relevance and data source feasibility.
• Query drafting: Describe what you want to find, receive a KQL or SPL draft. Saves time on syntax and table name lookup. Requires validation before running against production data.
• Result interpretation: Give a query result set to an LLM and ask whether any entries look suspicious. Useful for triaging large result sets where most entries are clearly benign. The LLM surfaces candidates; the analyst makes the final call.
• Report generation: Provide the execution log and findings to an LLM to draft the after-action report structure. Saves formatting time; analyst must verify accuracy of every claim.
• ATT&CK mapping: Describe an observed artifact or behavior, ask for ATT&CK technique mapping. Faster than manual ATT&CK Navigator navigation for initial mapping. Verify against the actual ATT&CK entry.

Where AI Fails

• AI does not know your environment. It cannot tell you what is normal for your organization's specific processes, tools, or users. Only you know that.
• AI hallucinates table names, field names, and KQL operator syntax. Every query it generates must be tested against a small time window on non-critical data before running on production.
• AI cannot pivot in real time. Pivoting requires interactive data queries on live data. AI operates on static text inputs. The pivot chain is entirely the analyst's work.
• AI context windows have a limit. A large SIEM result set will not fit, and AI will summarize or truncate in ways that may miss exactly the anomaly you are looking for.

H3AD-SEC AI tools integrated into the hunt workflow:

• QUERYCRAFT-AI: AI-assisted query generation for KQL, SPL, and Sigma from plain-language descriptions.
• ATTMAP-AI: Maps observed behaviors and artifacts to ATT&CK techniques.
• INSIGHT-AI: Runbook and hypothesis generation from threat intel input.

SYSTEM: You are an L3 threat hunting analyst. Generate structured hunt hypotheses
based on threat report input. Be precise. Use only techniques documented in MITRE
ATT&CK. Do not invent techniques or artifact names.

USER: Based on the following threat report excerpt, generate 3 hunt hypotheses
in ABLE format. Each hypothesis must be testable with Windows endpoint telemetry.

Report: [paste threat report excerpt here]

Format each hypothesis as:
Actor: [who, if known, or 'Unknown financially-motivated actor']
Behavior: [ATT&CK technique ID and full name]
Location: [system type, platform, and environment]
Evidence: [specific log sources, event IDs, field names, or observable artifacts]
Confidence basis: [why this technique is worth hunting based on the report]
Data sources required: [specific tables or log sources in your environment]

Where to Go from Here

You have completed the Threat Hunting module. The 8 chapters have covered the full arc from what threat hunting is and why it matters, through hypothesis construction and ABLE format, through PEAK lifecycle and frameworks, through data sources and telemetry, through query execution and statistical methods, through evidence scoring and the Diamond Model, through documentation and KPIs, and into advanced topics. That is the knowledge layer.

The practice layer is what matters next. The gap between knowing threat hunting and doing threat hunting is closed by running one hunt with full structure. Not reading about one. Running one.

Immediate next steps:

1. Open HYPOS at h3ad-sec.github.io/HYPOS/ and pick one ATT&CK technique from your industry's relevant actor profile. Write an ABLE hypothesis for it.
2. Confirm the data sources needed for that hypothesis are available in your SIEM. Check for quality using the methods from Chapter 4.
3. Write a hunt query in KQL or SPL. Run it against a 14-day window. Classify every result as TP, FP, or Gap.
4. Fill out the after-action report template from Chapter 7. All fields. Even if the result is No-Find.

Resources to continue learning:

• MITRE ATT&CK: attack.mitre.org
• ThreatHunter-Playbook (OTRF): github.com/OTRF/ThreatHunter-Playbook
• PEAK Framework: github.com/splunk/PEAK
• Red Canary Threat Detection Report: redcanary.com/threat-detection-report
• HEARTH hypothesis library (THORCollective): github.com/THORCollective/HEARTH
• Atomic Red Team: github.com/redcanaryco/atomic-red-team

H3AD-SEC Tools in Your Hunt Workflow