Threat Intelligence for Threat Hunting

// THREAT INTELLIGENCE FOR THREAT HUNTING

Use intelligence to hunt the adversary, not the alert.

Threat hunting without intelligence is fishing in the dark. Threat intelligence without hunting is a wall full of unused indicators. This page is about how the two combine — and how the HACKFORLAB platform makes that combination operational.

// AT A GLANCE
4
Classes of TI input
6 stages
Continuous hunt cycle
Live
IOC refresh cadence
MITRE-aligned
Every hunt artefact

Every observation feeds back into intelligence scoring — the loop refines itself.

// THE GAP

Most security teams have threat intelligence. Few use it to hunt.

Indicator feeds get ingested into SIEMs and forgotten. Adversary reports get read once. The platform-and-process connection between intelligence and hunting is missing — so intelligence becomes a compliance line item rather than a capability.

The pattern is everywhere. A security team subscribes to a threat-intelligence feed. The feed lands in a SIEM as a watchlist. Matches generate alerts. Alerts get triaged. Most resolve to false positives. The signal that the original intelligence carried — adversary attribution, MITRE technique mapping, infrastructure relationships, campaign context — is lost in translation between source and SIEM.

Hunting fails the same way from the other side. A hunter forms a hypothesis. Without intelligence, the hypothesis is anchored in personal experience or recent incidents — narrow, undocumented, hard to scale. With intelligence, the hypothesis can be anchored in observed adversary behaviour: “this operator cluster has been ramping initial-access exploitation against our industry for three weeks; we should hunt the specific TTPs they use”.

The fix is closing the loop. Intelligence becomes hunt input; hunt output becomes intelligence enrichment. Every confirmed hit refines confidence scoring on the originating indicator. Every false positive informs threshold tuning. The platform that closes this loop is the platform a SOC needs.

The six-stage threat-intelligence to threat-hunting cycle: input, hypothesis, scoped hunt, triage, detection, feedback
Six stages — intelligence in, refined intelligence out. The continuous-refinement core means every cycle improves the next one.
// THE INTELLIGENCE PYRAMID

Higher-altitude intelligence inflicts more cost on adversaries.

Hunting at the bottom of the pyramid (IPs, hashes) catches yesterday’s attack. Hunting at the top (TTPs, intent) catches the next one — and forces operators to retool, not just rotate hostnames.

Intelligence pyramid showing seven tiers from hash values at the base to adversary intent at the top, with the relative cost-to-adversary of each tier
The lower tiers are operationally easier but catch less. The upper tiers are harder to hunt but produce permanent uplift — adversaries must change their tradecraft, not just their infrastructure.

This pyramid is the single most useful mental model for threat hunting. Hash-based blocking is trivial for an adversary to defeat — recompile the payload, get a new hash, you are clean. IP-based blocking is annoying but cheap to defeat — rotate hosting providers. Domain-based blocking is more annoying — domains have provisioning lead times. Network-artefact hunting (JA3 fingerprints, beacon timing patterns, DGA structures) requires the adversary to reconfigure tooling. TTP-level detection forces them to change their playbook — the most expensive change possible.

HACKFORLAB intelligence covers every tier. The atomic indicators (IPs, domains, hashes) are the easiest to operationalise — drop into your blocking lists today. The TTP catalogue (MITRE-mapped, frequency-ranked) drives hunts that survive infrastructure rotation. The adversary profiles bridge the tiers — they tell you which operator clusters are active and what their preferred TTPs look like, so your hunts target the right corner of the matrix.

// FOUR CLASSES OF TI INPUT

Each enables a different style of threat hunt.

Hunters who only consume one class of intelligence are limited to one class of hunt. The platform exposes all four — and the hunt library is built to take advantage of every class.

Four classes of threat intelligence input that feed hunting: IOC atoms, adversary profiles, TTP intelligence, and campaign reports
Each column feeds the hunt-execution layer at the bottom. A mature hunting practice uses all four — selectively, for each hypothesis.
CLASS 01

IOC atoms

IPs, domains, URLs, file hashes, email addresses, processes — each scored for confidence, tagged with MITRE techniques, attributed to adversaries when possible. Use for: indicator-driven hunts that look for known-bad in your telemetry.

Browse the catalogue

CLASS 02

Adversary profiles

Named operator clusters with TTP-frequency histograms, target geography, target industry, and campaign lineage. Use for: hunting the specific tradecraft of a named adversary against your environment.

See profiles

CLASS 03

TTP intelligence

MITRE ATT&CK technique catalogue with current-cycle observation density, per-technique hunt recipes, and sub-technique detail. Use for: technique-driven hunts that work even when adversaries rotate infrastructure.

See MITRE coverage

CLASS 04

Campaign reports

Multi-IOC patterns tied to a coordinated operation — staging infrastructure, lure documents, kill-chain timing. Use for: hunting an entire campaign in your environment rather than chasing individual indicators.

Read advisories

// THE WORKFLOW

Same alert, two timelines.

A side-by-side comparison of how the same starting alert resolves in a SOC without operational threat intelligence versus one with it. The time-to-resolution difference is real; the durability difference is the bigger story.

Comparison of SOC alert handling without operational threat intelligence versus with operational threat intelligence — five-step numbered timelines side by side
Same alert handled two ways. The difference compounds across hundreds of alerts per week.
// PRACTICAL HUNT EXAMPLE

A walkthrough of one TI-driven hunt, end to end.

A hypothesis born from a weekly threat advisory, scoped against VPC Flow Logs, triaged in the analyst console, promoted to a continuous detection. Real workflow, real time costs.

Monday 09:00 — Advisory lands. The HACKFORLAB weekly threat advisory reports that an actor cluster has accelerated public-facing exploitation against unpatched edge devices in our industry. The advisory lists the operator\’s preferred MITRE techniques: T1190 (Public-Facing Exploit), T1071 (Application Layer Protocol C2), T1041 (Exfiltration over C2).

Monday 09:30 — Hypothesis formed. The hunter\’s hypothesis: “If this operator has been active against organisations like ours, we should see post-exploit C2 beacons emerging from our edge-device network segments in the last 30 days.” The hypothesis is testable against telemetry we already collect.

Monday 09:45 — Hunt scoped. The hunter opens the platform\’s VPC Flow Log Hunting library. The “Adaptive C2 Beacon Detection (FFT + DBSCAN)” playbook fits the hypothesis exactly. The hunter attaches the relevant S3 VPC Flow Log bucket as a query source, scopes the time window to the past 30 days, and restricts source IPs to the edge-device subnets.

Monday 10:30 — Hits triaged. The playbook surfaces 14 candidate beacons. Eight are easily dismissed as benign (legitimate update channels). Six warrant investigation. Three resolve to confirmed C2 — two on edge devices that had not tripped the SIEM\’s signature rules. The hunter opens an incident, contains the affected devices, and pivots to graph traversal to find sibling infrastructure.

Monday 13:00 — Detection shipped. The hunt proved useful enough to become a continuous detection. The hunter opens a pull request that promotes the playbook configuration, includes the 90-day backtest (12 historical hits, 0 false positives at the chosen threshold), and assigns a reviewer. By end of day, the detection is live in production and the operator cluster\’s preferred initial-access technique now has continuous coverage.

What just happened. An advisory became a hypothesis. A hypothesis became a scoped query. A query became confirmed hits. Confirmed hits became a continuous detection. The starting intelligence was operational — every step had inputs ready to use. That is what closing the loop looks like.

// INTEGRATION WITH YOUR EXISTING STACK

TI-for-hunting works with the tools you already have.

SIEM ingest

Streaming indicator deltas in STIX 2.1, JSON, or CSV. Watchlists and correlation rules drive on-publish alerts. Source provenance and MITRE tagging preserved across the wire.

SOAR enrichment

Webhook on every published indicator. SOAR playbooks pivot from alert to verdict in milliseconds, with full actor / cluster / technique context attached.

Hunting console

Run platform hunts against attached log sources without moving raw telemetry. Athena-backed query plane stays in your AWS account.

Detection-as-code

Promote a successful hunt to a continuous rule via pull request. Backtests, FP curves, and runbooks attach automatically.

// OUTCOMES

What changes in a SOC that operationalises TI for hunting.

Mean enrichment time drops. What previously took an analyst fifteen minutes of manual lookups now takes sixty seconds in the platform. Across a SOC handling several hundred alerts per shift, that is an order-of-magnitude reduction in time spent on triage triage versus investigation.

False-positive rate drops. Indicator scoring filters the long tail of low-confidence atoms that would otherwise flood the SIEM. Watchlists become smaller and higher-fidelity. Alert fatigue measurably decreases.

Detection coverage grows. Every promoted hunt is permanent uplift. The portfolio compounds over time — each cycle ships rules that catch tomorrow\’s incidents without re-running yesterday\’s investigation.

Analyst experience improves. Junior analysts get the same context that senior ones used to spend years accumulating in their heads. Skill ramp-up shortens. Retention improves.