Principle: C2 Threat hunting

Deploying threat hunting as part of business as usual

Your threat hunting should be planned into normal cyber security operations, rather than only being arranged in response to a specific incident, tip-off or alert.

Threat hunt frequency matching risks

Your organisation should decide how often to deploy threat hunting resources based on the risk to the systems supporting your essential functions. 

Higher-risk or more critical systems may require more frequent scheduled hunts, while lower-risk systems may be hunted less often or in response to specific intelligence.

Turning threat hunts into automated detections and alerting

Your organisation should use the findings from threat hunts to improve automated detections and alerting where it is appropriate to do so.

After each threat hunt, you should review whether any of the behaviours, indicators or search logic used during the hunt should be converted into routine monitoring.

For example, this could include:

• creating new alerts for behaviours identified during the hunt, such as unusual privilege escalation, suspicious remote access, abnormal service account use or unexpected system-to-system communication
• tuning existing alert rules where the hunt showed they were too broad, too narrow or creating false positives
• adding missing log sources or fields where the hunt showed that useful data was not available

Driving improvements in threat hunting

Your organisation should use records of previous threat hunts to improve both your threat hunting approach and wider security posture.

For example, you might use the outcomes of a threat hunt to:

• create or tune automated detections and alert rules
• add missing log sources or improve log quality
• update threat hunting playbooks, queries or hypotheses
• improve triage criteria, escalation routes or incident response procedures
• prioritise remediation of vulnerable systems or weak controls
• update baselines of normal user and system behaviour
• adjust the frequency or scope of future hunts based on risk
• provide further training or supplier assurance where gaps were identified

Justified confidence in threat hunting process

Your organisation should have justified confidence that its threat hunts are effective and that the threat hunting process remains aligned with the risks posed to your essential functions.

The threat hunting process should be reviewed and updated on a scheduled basis, and after significant triggers such as new threat intelligence, incidents, near misses, major system changes, new suppliers, changes to essential functions, or findings from previous hunts.

This review should consider whether the frequency, scope, methods, data sources, skills and tooling remain appropriate for the risks faced by the organisation. Where gaps are identified, the organisation should make improvements such as: 

• updating hunt hypotheses
• adding log sources
• changing hunt frequency
• improving playbooks
• providing training

Leveraging automation

Your organisation should use automation to improve threat hunting where it is appropriate and safe to do so. This does not mean that the whole threat hunting process should be automated. It means that suitable stages of the process are automated to make hunts more consistent, timely and effective.

This could include automating parts of the process such as:

• collecting relevant logs and telemetry from agreed data sources
• running scheduled hunt queries across security information and event management (SIEM) platform logs, endpoint detection and response (EDR) logs, identity logs, network logs or cloud logs
• enriching hunt results with asset, user, device, vulnerability or threat intelligence information
• comparing activity against known indicators of compromise (IoCs), suspicious behaviours or baselines of normal activity
• prioritising results based on severity, affected asset, criticality, confidence level or link to known threats
• creating tickets or investigation cases when hunt results meet agreed criteria
• notifying responsible teams or suppliers when follow-up action is required
• converting successful hunt queries into automated detections or alert rules
• producing standard reports or dashboards showing hunt outcomes, false positives, gaps and improvement actions

Automation should be used carefully. You should test automated queries and workflows, monitor false positives, and ensure that findings are still reviewed by suitably skilled people before significant decisions are made.

Focusing on tactics, techniques and procedures of threats

Your organisation should ensure that threat hunts focus primarily on attacker tactics, techniques and procedures, rather than only searching for atomic IoCs such as hashes, IP addresses, domain names or URLs.

This means designing threat hunts around how an attacker is likely to operate, for example:

• initial access, such as phishing, exploitation of a vulnerability or use of compromised credentials
• privilege escalation, such as unusual creation of admin accounts or changes to permissions
• lateral movement, such as unexpected remote access between systems
• persistence, such as new scheduled tasks, services or registry changes
• defence evasion, such as disabled logging, deleted logs or security tools being stopped
• command and control, such as unusual outbound connections or repeated beaconing patterns
• data access or exfiltration, such as abnormal access to sensitive datasets or large data transfers

You should identify the attacker tactics, techniques and procedures being hunted for and the reason those are relevant to your organisation. Atomic IoCs can still be useful, but they should support the hunt rather than define it.