Cyber Threat Intelligence and Threat Hunting

Introduction and Context

Cybersecurity operations increasingly depend on the ability to understand adversaries before, during and after an attack. Security controls generate enormous volumes of alerts, logs and indicators, but raw data is not intelligence. Intelligence is processed, evaluated and contextualised information that supports a decision. Cyber threat intelligence (CTI) therefore connects technical observation with operational action: blocking infrastructure, prioritising vulnerabilities, protecting high-value assets, investigating an intrusion or changing a security strategy.

Threat hunting complements intelligence. Whereas conventional monitoring often waits for a detection rule or alert, hunting begins with a reasoned hypothesis that an adversary may be present despite the absence of a confirmed alert. Hunters use intelligence, behavioural analytics, endpoint telemetry, network evidence and investigative reasoning to search for suspicious activity.

At advanced-diploma level, practitioners must understand both disciplines as managed processes. Effective CTI requires requirements, collection, processing, analysis, dissemination and feedback. Effective hunting requires a defensible hypothesis, relevant data, repeatable investigative methods, careful handling of uncertainty and a mechanism for converting findings into improved controls.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain the purpose, levels and lifecycle of cyber threat intelligence.
2. Translate stakeholder concerns into intelligence requirements and priority intelligence requirements.
3. Evaluate indicators of compromise (IoCs), tactics, techniques and procedures (TTPs), sources and confidence levels.
4. Distinguish data, information, intelligence and actionable intelligence.
5. Develop and test threat-hunting hypotheses using behavioural evidence.
6. Apply structured analytical, governance and dissemination practices.
7. Critically evaluate limitations, ethical risks and emerging developments in CTI and hunting.

1. From Security Data to Actionable Intelligence

Security data is an unprocessed observation: an IP address, process event, authentication record or malware sample. Information is data organised with descriptive context, such as the fact that an address contacted ten internal hosts. Intelligence adds interpretation, confidence and relevance to a decision. Actionable intelligence specifies what should be done, by whom, within what time and with what expected effect.

A useful distinction is:

CTI is commonly divided into four overlapping levels:

• Strategic intelligence: long-term assessments for executives, risk owners and policy makers; it addresses adversary trends, geopolitical developments, business risk and investment priorities.
• Operational intelligence: information about campaigns, actors, targeting and likely objectives; it supports incident planning and defensive prioritisation.
• Tactical intelligence: adversary TTPs and behavioural patterns used by defenders, architects and detection engineers.
• Technical intelligence: time-sensitive technical artefacts such as domains, hashes, certificates, malware configurations and IP addresses.

These levels should not be treated as isolated products. A technical indicator may be useful only when linked to a campaign, technique, affected business process and recommended response. Conversely, strategic assessments must ultimately influence technical controls if they are to reduce risk.

2. The Intelligence Lifecycle

The intelligence lifecycle is a feedback-driven management process rather than a strictly linear pipeline. A common model contains six activities: direction, collection, processing, analysis, dissemination and feedback.

Figure: The CTI lifecycle is iterative; feedback changes future requirements and collection priorities.

2.1 Direction: Requirements and Priorities

Direction defines why intelligence is needed. Stakeholders may include a chief information security officer, incident response team, vulnerability-management team, fraud unit, legal counsel or business owner. A vague request such as “tell us about threats” is not an effective requirement. A well-formed requirement identifies the decision, consumer, scope, time horizon and desired confidence.

A priority intelligence requirement (PIR) is a question whose answer is important to a decision. Examples include:

• Which adversaries are targeting the organisation’s payment systems?
• Is a newly disclosed vulnerability being exploited against our externally exposed services?
• What behaviours would indicate that a compromised administrator account is being used for lateral movement?

Requirements should be ranked according to business impact, urgency, decision value and collection feasibility. Requirements must also be reviewed: obsolete questions waste analyst time and encourage indiscriminate collection.

2.2 Collection

Collection identifies and obtains relevant sources. Internal sources include endpoint detection and response (EDR), identity logs, DNS, proxy, email, cloud audit logs, vulnerability scanners, firewall telemetry, incident reports and malware analysis. External sources include government advisories, industry information-sharing groups, vendor reports, open-source research, dark-web monitoring and commercial intelligence feeds.

Collection is not equivalent to acquisition of every available feed. Each source should be assessed for relevance, timeliness, technical quality, provenance, licensing, coverage and possible bias. Collection should comply with privacy, employment, interception, data-protection and contractual requirements.

2.3 Processing

Processing makes collected material usable. Typical activities include parsing, normalising timestamps, deduplicating indicators, extracting malware artefacts, resolving domains, enriching IP addresses, mapping behaviours to ATT&CK techniques and assigning source metadata. Processing should preserve the original evidence and maintain chain of custody where material may support disciplinary, regulatory or legal action.

2.4 Analysis

Analysis transforms processed material into an assessment. Analysts should separate observed facts, assumptions, inferences and judgements. Useful methods include structured analytic techniques, timeline reconstruction, link analysis, competing hypotheses, trend analysis, malware reverse engineering and ATT&CK-based behavioural mapping.

A sound assessment answers four questions: What happened or may happen? How confident are we? Why does it matter to this organisation? What should the consumer do next? Analysts should actively test alternative explanations and avoid treating correlation as proof of attribution.

2.5 Dissemination

Dissemination delivers the right product to the right audience in a usable format. A SOC analyst may need a detection query and technical artefacts; an executive may need a concise risk judgement and decision options. Products should state classification, handling restrictions, production time, confidence, affected sectors or technologies, recommended actions and sources.

2.6 Feedback

Feedback measures whether the product was understood and useful. Consumers may report that an indicator was stale, a recommendation was impractical or a collection gap remains. Metrics should include action completion, detection improvement, time to disseminate, false-positive rate and consumer satisfaction; volume of reports alone is not a meaningful success measure.

3. Evaluating Indicators, TTPs and Sources

3.1 Indicators of Compromise

An IoC is an artefact associated with malicious or suspicious activity. Common examples are file hashes, malicious domains, IP addresses, URLs, email sender infrastructure, registry keys, mutexes, certificates and unusual user-agent strings. IoCs are useful for rapid searching and blocking, but many are fragile. A hash changes when a binary is rebuilt; an IP address may be shared by legitimate tenants; a domain may be benign today and malicious tomorrow.

Indicators should be evaluated using:

• Specificity: how strongly the indicator distinguishes malicious from legitimate activity.
• Context: associated malware, campaign, time period, victimology and observed behaviour.
• Timeliness: whether the indicator remains relevant.
• Provenance: who observed it and how.
• Confidence: how strongly the evidence supports the judgement.
• Actionability: whether a practical control or investigation can use it.

Behavioural indicators are often more durable than atomic indicators. For example, “a signed system utility launched an encoded script that contacted a rare external domain shortly after a new privileged login” may detect variants that do not share a hash or IP address.

3.2 Tactics, Techniques and Procedures

Tactics describe an adversary’s objective, such as credential access or discovery. Techniques describe how that objective is pursued, while procedures describe the concrete implementation observed in a campaign. The distinction supports detection engineering: a procedure may change, but the underlying technique or tactic may persist.

ATT&CK is widely used as a knowledge base for organising adversary behaviour. It should not be treated as proof that an actor performed a technique. Mapping is an analytical representation that must be supported by evidence. Coverage matrices can expose blind spots, but a large number of mapped techniques does not automatically mean strong security.

3.3 Source Evaluation and Confidence

Sources vary in reliability and independence. A directly collected endpoint event may have high relevance for a local incident, whereas an anonymous post may provide an early warning but require corroboration. Analysts should document source reliability separately from the credibility of a specific claim.

A practical confidence scale might be:

Confidence is not the same as probability, and labels must be defined consistently within an organisation. Where quantitative probabilities are used, analysts must explain the evidence model and avoid false precision. A confidence statement should identify what would increase or decrease confidence.

4. Producing Actionable Intelligence

An intelligence product should be designed around a decision, not around the quantity of collected information. A practical product structure is:

1. Judgement: the principal assessment in clear language.
2. Business relevance: assets, services, users or regulatory obligations affected.
3. Evidence: observations and source references.
4. Confidence and caveats: uncertainty, gaps and alternative explanations.
5. Implications: likely consequences if the assessment is correct.
6. Actions: specific tasks, owners, priorities and deadlines.
7. Technical annex: IoCs, queries, ATT&CK mappings and handling guidance.

For example, “Block this IP” is incomplete intelligence. A better product might state that the address was observed in a campaign targeting the organisation’s sector, that it contacted three hosts after suspicious PowerShell activity, that confidence is moderate because external corroboration is limited, and that the SOC should search historical DNS and proxy logs, isolate confirmed hosts and monitor related domains.

Intelligence must be proportionate. Blocking every indicator can disrupt legitimate business, while refusing to act until certainty is achieved can increase harm. A risk-based decision considers impact, reversibility, confidence and the cost of delay.

5. Threat Hunting

Threat hunting is a proactive, human-led and often analytics-assisted search for adversary activity that existing controls may have missed. It is not random searching and it is not merely incident response without an alert. Hunting normally follows a cycle:

1. Establish a hypothesis.
2. Identify required data and expected observations.
3. Query and investigate.
4. Validate or reject the hypothesis.
5. Scope affected systems and contain confirmed activity.
6. Convert findings into detections, controls, intelligence and lessons learned.

5.1 Constructing a Hypothesis

A useful hypothesis is specific, falsifiable and connected to a threat model. It identifies an adversary behaviour, environment and expected evidence. For example: “If an attacker has obtained a privileged cloud token, then unusual token use will appear from a new location or device, followed by access to sensitive storage and changes to identity permissions.”

The hypothesis should not assume the conclusion. “The attacker used malware X” is weak if no evidence supports the specific malware. A behaviour-based hypothesis is more resilient: “An unauthorised process may be using a trusted utility to establish persistence.”

Each hypothesis should define:

• the population to search, such as endpoints or cloud accounts;
• a time window;
• relevant telemetry;
• expected benign explanations;
• evidence that would support or weaken it;
• a stopping rule and escalation path.

5.2 Data and Hunt Design

A hunt is only as good as its visibility. Endpoint process creation, command-line data, authentication events, DNS, network flows, cloud control-plane logs and email telemetry may be required. Analysts must account for clock drift, retention periods, missing sensors, encryption and inconsistent schemas.

Queries should begin broadly enough to avoid premature exclusion, then narrow through contextual enrichment. Useful enrichments include asset criticality, user role, software inventory, known administrative tools, vulnerability state, geolocation and threat-intelligence references. Every exclusion should be documented because aggressive tuning can hide the behaviour being sought.

A hunt result may be:

• Confirmed malicious: evidence supports unauthorised activity.
• Suspicious but unresolved: activity requires further investigation.
• Benign: a documented legitimate explanation exists.
• Inconclusive: data quality or visibility is insufficient.

“Inconclusive” is a valid analytical outcome; it should generate a visibility improvement rather than an unjustified conclusion.

5.3 Hypothesis Example

Suppose an organisation suspects credential theft followed by lateral movement. The hunt hypothesis is: “A compromised workstation may show credential-access tooling followed by unusual remote service authentication to multiple servers.” The team searches EDR process events, authentication logs and administrative-share activity over the previous 30 days.

A workstation launches an unsigned executable from a user-writable directory. Within ten minutes, the same account authenticates to six servers, three of which the user never previously accessed. The evidence is not automatically proof of credential theft: software deployment, help-desk activity or a maintenance script could explain it. Analysts therefore compare change tickets, software inventory, parent-child processes, logon types and peer-group behaviour. If no legitimate explanation exists, the team isolates the workstation, resets credentials, investigates the servers and creates a detection for the behavioural sequence.

The important result is not merely finding one host. The hunt improves understanding of the intrusion path, identifies telemetry gaps and produces a repeatable analytic.

6. Integrated Illustrative Case: Northbridge Health Services

This is a fictional illustrative case.

Background

Northbridge Health Services operates hospitals, outpatient clinics and a cloud-hosted patient portal. Its CTI function receives a vendor report describing a campaign against healthcare organisations involving stolen credentials, remote access tools and cloud data theft. The report includes several domains but provides moderate confidence and limited victim-specific evidence.

Problem

The security team must decide whether to block the domains, determine whether Northbridge has been targeted and prioritise a limited number of hunting hours. A blanket block could affect a legitimate shared hosting service, while ignoring the report could permit an intrusion.

Analysis

The CTI analyst converts the concern into three PIRs:

1. Have Northbridge accounts or systems interacted with the campaign infrastructure?
2. What behaviours would indicate credential misuse or cloud data theft?
3. Which patient-care services would be affected by a compromise?

The analyst validates the vendor report against government advisories, passive DNS information and internal telemetry. One domain resolves to changing infrastructure and has a low-specificity hosting relationship; it is not suitable for unconditional blocking. A related URL, however, appears in two phishing messages delivered to finance users.

The hunt team searches email telemetry, identity logs and cloud audit records. One user clicked the link but entered no credentials according to the available identity-provider events. A second account authenticated from an unusual country and created a new application consent grant. The evidence is suspicious but not conclusive because the employee was travelling and the log lacks device context.

Approach and Solution

The incident commander requires immediate multifactor-authentication review, revocation of active sessions and verification of the consent grant. The SOC searches for the same grant pattern across tenants and monitors related domains rather than blocking the entire hosting provider. The identity team confirms that the consent was unauthorised, removes it and resets the affected credentials. Cloud audit logs show no confirmed access to patient data, but retention is insufficient for one earlier period.

The CTI team issues a tactical report with moderate-to-high confidence for unauthorised identity activity, low confidence for data theft and explicit visibility limitations. It supplies detection logic based on unusual consent grants, impossible travel only as a triage signal, new device registration and abnormal access to sensitive repositories.

Outcome

Northbridge contains the affected account before evidence of patient-data access is found. The organisation improves cloud-log retention, adds an approval workflow for application consent, updates its phishing-hunting playbook and informs executives that the campaign report was valuable but required local corroboration.

Learning Points

The case demonstrates that intelligence is not a feed of permanent truth. Source confidence, local context and business impact determined the response. Behavioural hunting provided more value than relying solely on domains. Explicit uncertainty prevented an unsupported claim of data exfiltration, while decisive containment addressed the risk of delay.

7. Governance, Ethics and Legal Responsibilities

CTI and hunting involve personal data, employee activity, customer records and potentially sensitive intelligence. Organisations should define lawful purpose, access controls, retention periods, minimisation practices and auditability. Analysts should collect only what is necessary, restrict use to legitimate security purposes and protect intelligence from unauthorised disclosure.

Attribution requires special care. Publicly naming an actor or state based on weak evidence can create legal, diplomatic and reputational harm. Analysts should distinguish technical observations from assessments of identity, capability and intent. Intelligence sharing should follow classification and handling rules, such as appropriate sector-sharing protocols, and should remove unnecessary personal information.

Automated blocking also creates ethical risk. A feed may contain false positives, poisoned data or indicators associated with shared infrastructure. High-impact actions should use approval thresholds, rollback procedures and human review. Security teams must document decisions so that affected users and regulators can understand the basis of action.

8. Technology, Automation and Contemporary Developments

Modern CTI platforms use structured formats, enrichment services, graph databases, detection-as-code and automated orchestration. Standards such as STIX and TAXII can improve machine-readable exchange, although interoperability depends on consistent semantics and governance. Security data lakes enable retrospective hunting across endpoint, identity, network and cloud sources.

Machine learning can assist anomaly detection, clustering, entity resolution and prioritisation. It does not remove the need for analysts: models inherit data bias, may be evaded, can produce opaque scores and often confuse unusual activity with malicious activity. Generative AI can summarise reports or draft queries, but outputs require validation, data-protection controls and provenance checks. Sensitive intelligence should not be entered into an external service without explicit authorisation.

Contemporary practice is moving toward identity-centric detection, cloud and software-supply-chain intelligence, adversary emulation, exposure management and continuous validation. The strongest programmes combine intelligence with engineering: every important assessment should lead, where appropriate, to a detection, control change, hunt, risk decision or collection improvement.

9. Challenges and Limitations

CTI programmes commonly fail through poor requirements, excessive feed subscriptions, duplicated indicators, inadequate telemetry, unclear ownership and dissemination to audiences that cannot act. Attribution and forecasting remain uncertain because adversaries deceive, reuse infrastructure and deliberately create misleading evidence.

Threat hunting is constrained by retention costs, incomplete logging, encrypted traffic, endpoint tampering, cloud-provider limitations and analyst bias. A successful hunt does not prove that an organisation is clean; it demonstrates that a defined hypothesis was tested against available evidence. Negative results should therefore be expressed carefully: “No supporting evidence was found in the searched data and period,” not “No compromise occurred.”

Programme evaluation should combine outcome measures and quality measures. Examples include the proportion of PIRs answered, time from collection to action, confirmed detection rate, false-positive burden, percentage of hunts producing improved detections, coverage of critical assets and closure of visibility gaps. Metrics should inform improvement rather than encourage analysts to maximise report counts.

Best-Practice Checklist

• Begin with decisions and intelligence requirements, not feeds.
• Record provenance, timestamps, handling restrictions and confidence.
• Prefer contextual and behavioural indicators over isolated atomic indicators.
• Corroborate important claims and document alternative explanations.
• Design hunts around falsifiable hypotheses and explicit stopping rules.
• Validate data quality, retention and clock synchronisation before interpreting absence.
• Separate observed facts from inference and attribution.
• Disseminate concise, audience-specific products with owners and deadlines.
• Convert findings into detections, controls, lessons and revised requirements.
• Apply privacy, legal, ethical and human-review safeguards.

Chapter Summary

Cyber threat intelligence transforms security observations into assessed information that supports decisions. Its lifecycle comprises direction, collection, processing, analysis, dissemination and feedback, and it must remain iterative. Requirements should be framed as decision-oriented questions, prioritised according to business risk and reviewed as circumstances change.

IoCs provide useful but often fragile technical evidence. TTPs and behavioural patterns can provide more durable detection value. Source provenance, timeliness, specificity, corroboration and confidence must be recorded, while attribution should be separated from observation. Actionable intelligence states what is known, how confidently it is known, why it matters and what should happen next.

Threat hunting is a proactive investigation based on a specific, falsifiable hypothesis. It depends on suitable telemetry, structured queries, contextual enrichment and careful treatment of benign explanations and inconclusive results. Hunting should produce organisational value beyond a single finding by improving detections, controls, visibility and intelligence requirements.

Effective CTI and hunting are governed disciplines. Privacy, lawful processing, information handling, automation risk and the consequences of false positives must be addressed. The mature practitioner combines technical skill with analytical reasoning, communication, uncertainty management and responsible decision-making.

Key Terms

Actionable intelligence: Intelligence that enables a specific, feasible decision or action.

Analysis: Interpretation of processed evidence to produce an assessment.

Confidence: A stated level of support for an analytical judgement.

Cyber threat intelligence (CTI): Evidence-based knowledge about threats that supports cybersecurity decisions.

Dissemination: Delivery of intelligence to an appropriate consumer in a usable form.

Feedback: Information about the usefulness, accuracy and effects of an intelligence product.

Indicator of compromise (IoC): An artefact associated with suspected or confirmed malicious activity.

Intelligence requirement: A defined question whose answer supports a decision.

Intelligence lifecycle: The iterative process of direction, collection, processing, analysis, dissemination and feedback.

Operational intelligence: Intelligence about campaigns, targeting and adversary activity that supports operational planning.

Priority intelligence requirement (PIR): An intelligence requirement ranked as especially important to a decision.

Processing: Organising, normalising, extracting and enriching collected data.

Strategic intelligence: Long-term threat knowledge used for organisational strategy and investment decisions.

Tactical intelligence: Knowledge of adversary methods and behaviours used to improve defensive operations.

Tactics, techniques and procedures (TTPs): Adversary objectives, methods and concrete implementations.

Technical intelligence: Time-sensitive technical artefacts such as hashes, domains, addresses and malware configurations.

Threat hunting: Proactive investigation for adversary activity that existing detections may have missed.

Threat hypothesis: A specific, testable proposition about possible adversary activity.

Review Questions

Short Answer Questions

1. Distinguish data, information, intelligence and actionable intelligence.
2. What is the purpose of a priority intelligence requirement?
3. Why can an IP address be a weak standalone indicator of compromise?
4. State two characteristics of a good threat-hunting hypothesis.
5. Why should an analyst record an inconclusive hunt result?

Long Answer Questions

1. Explain the intelligence lifecycle and discuss how feedback improves future collection and analysis.
2. Compare strategic, operational, tactical and technical intelligence, giving an appropriate consumer and product for each.
3. Explain how source provenance, corroboration and confidence should influence an intelligence assessment.
4. Discuss the advantages and limitations of IoCs compared with TTP-based detection.
5. Describe the governance and ethical issues involved in automated intelligence sharing and blocking.

Analytical / Application Questions

1. A threat feed reports a malicious domain that uses shared cloud hosting and has low confidence. Design a defensible process for deciding whether to block, monitor or investigate it.
2. Develop a threat-hunting hypothesis for suspected misuse of privileged cloud accounts. Specify the data sources, expected evidence, benign explanations and possible outcomes.
3. An organisation finds no evidence of ransomware in its endpoint logs, but logging was disabled for two weeks on several critical servers. Write an appropriate analytical conclusion and recommend follow-up actions.

Multiple Choice Questions with Answers

Question 1

Which statement best defines actionable cyber threat intelligence?

A. A large collection of unprocessed security logs

B. A list of every IP address observed on the internet

C. Assessed information linked to a feasible decision or action

D. A report containing only strategic geopolitical analysis

Correct Answer: C. Assessed information linked to a feasible decision or action

Question 2

What is the primary purpose of a priority intelligence requirement?

A. To identify a question that is especially important to a decision

B. To replace all technical security monitoring

C. To guarantee that an attribution is correct

D. To specify the format of every firewall log

Correct Answer: A. To identify a question that is especially important to a decision

Question 3

Which characteristic generally makes a behavioural indicator more durable than a file hash?

A. It is always easier to calculate

B. It can describe activity across changing tools or infrastructure

C. It cannot produce false positives

D. It requires no telemetry

Correct Answer: B. It can describe activity across changing tools or infrastructure

Question 4

Which activity belongs primarily to the processing stage of the intelligence lifecycle?

A. Ranking executive investment priorities

B. Normalising timestamps and deduplicating indicators

C. Approving a new privacy policy

D. Presenting a final risk decision to the board

Correct Answer: B. Normalising timestamps and deduplicating indicators

Question 5

Which is the strongest threat-hunting hypothesis?

A. Attackers are bad and may be somewhere in the network

B. Malware X definitely compromised the finance department

C. A stolen privileged token may produce unusual access from a new device followed by sensitive-resource access

D. Search every log for anything unusual without a time limit

Correct Answer: C. A stolen privileged token may produce unusual access from a new device followed by sensitive-resource access

Question 6

What does moderate confidence normally communicate?

A. The judgement is certain and needs no further evidence

B. The evidence is credible but incomplete, indirect or not fully corroborated

C. The source is known to be fraudulent

D. No evidence exists for the judgement

Correct Answer: B. The evidence is credible but incomplete, indirect or not fully corroborated

Question 7

Why is attribution especially sensitive in CTI?

A. Attribution never uses technical evidence

B. Incorrect attribution can create legal, diplomatic and reputational harm

C. Attribution is required for every firewall rule

D. Attribution eliminates the need for containment

Correct Answer: B. Incorrect attribution can create legal, diplomatic and reputational harm

Question 8

Which outcome is valid after a threat hunt?

A. Inconclusive, when visibility or data quality prevents a defensible conclusion

B. Confirmed malicious, regardless of the evidence

C. Benign, whenever no alert was generated

D. Successful, only when an attacker is identified by name

Correct Answer: A. Inconclusive, when visibility or data quality prevents a defensible conclusion

Question 9

What should usually follow a confirmed useful hunting discovery?

A. Deletion of the supporting evidence

B. Conversion of the finding into improved detections or controls

C. Removal of all related telemetry to reduce costs

D. Automatic public attribution

Correct Answer: B. Conversion of the finding into improved detections or controls

Question 10

Which statement about machine learning in CTI is most accurate?

A. It removes the need for analyst judgement

B. Its outputs are always explainable and unbiased

C. It can assist prioritisation and anomaly detection but requires validation

D. It guarantees that false positives will not occur

Correct Answer: C. It can assist prioritisation and anomaly detection but requires validation