The Threat Hunter’s Sigma Playbook: 7 Hunts Every Modern SOC Must Run

If your SOC still treats threat intelligence as a feed subscription, you are losing the time race. This playbook closes the gap with seven battle-tested hunts — each shipped as a Sigma rule, mapped to MITRE ATT&CK, and benchmarked against real adversary telemetry observed in the first week of June 2026.

Threat hunting is the discipline of testing a hypothesis against telemetry before an alert fires. Sigma rules are the vendor-neutral grammar that makes those hypotheses portable across SIEMs, EDRs, and XDR platforms. Detection engineering is the production pipeline that turns a one-shot hunt into a maintained, version-controlled rule with a measured false-positive budget. This article unifies the three disciplines into a single playbook a working SOC analyst, threat hunter, or detection engineer can run this week.

We built the playbook from 55,729 indicator observations across 91 distinct adversary clusters cataloged between June 1 and June 7, 2026. Open-source command-and-control frameworks dominated the catalogue at 97 percent of observations. The remaining three percent — supply-chain worms, helpdesk-impersonation extortion, state-sponsored espionage, IoT botnet seeders — are small in volume and disproportionate in impact. Every hunt below targets a specific real-world adversary cluster and ships with the Sigma YAML you can drop into your detection-as-code repository today.

01 · All seven hunts at a glance

Each row maps a hunt to its adversary cluster, the MITRE techniques it covers, the telemetry sources it needs, and the Sigma rule that ships it. If you are scoping a hunt program for a quarterly review, this is the table to take to leadership.

The combined footprint of 55,729 indicator observations represents a single week of catalogue activity. Treat it as a baseline. Your environment will see a different distribution — smaller in absolute volume but with similar cluster proportions and the same hunt targets.

02 · MITRE ATT&CK coverage matrix

The seven hunt blocks collectively cover techniques across seven ATT&CK tactics. The matrix below shows which hunt block addresses which tactic. Amber cells indicate a single hunt covers the tactic; dark amber cells indicate multiple hunts converge on it — those are your highest-confidence tactical coverage points.

Read the matrix vertically to see how a hypothetical adversary traversing the kill chain would encounter your hunts at every stage; horizontally to see which tactics each individual hunt addresses.

Coverage read-out. Strongest coverage: Command & Control (3 hunts converging), Exfiltration and Credential Access (each with double-technique coverage). Tactical gaps: Execution (no dedicated hunt this week) and Discovery (no dedicated hunt). Use the gaps as your hunt backlog for next week — aim to leave no tactic uncovered over a rolling 90-day window.

Diagram note. For an interactive ATT&CK Navigator JSON of the coverage above, the platform exposes one-click export per hunt block. Layer the export over your existing detection coverage to find where the new hunts fill real gaps.

03 · Hunt 01 — Open-source C2 frameworks

Five open-source command-and-control frameworks accounted for 97 percent of this week’s catalogue: CobaltStrike, Sliver, VShell, AdaptixC2, and Havoc. They differ in implementation. They share an operational pattern: a small implant, periodic beaconing, an HTTP, HTTPS, DNS, or mTLS channel, and a malleable profile that disguises traffic as something legitimate. They also share a hunting weakness — their traffic is predictable when you watch the right plane.

Hunt 01.1 · Predictable beacon cadence on outbound HTTPS

Hypothesis

An internal host is establishing periodic outbound HTTPS connections to a new external destination with low-variance inter-arrival times. The destination is not in your known SaaS or update-traffic baseline, the TLS certificate is short-lived, and the connection volume is too low to be a real browser session.

Telemetry needed

• NetFlow or Zeek conn.log with timestamp, source, destination, byte counts
• TLS handshake metadata (JA3 / JA4 / JARM fingerprint, SNI, certificate validity period)
• DNS resolution log linking SNI to first-seen domain
• Process-to-network correlation from your EDR or Sysmon Event 3

Sigma rule

title: Suspicious Periodic HTTPS Beacon Cadence
id: 8a1f3b91-1f4e-4f2c-89d5-c1b2e7a04211
status: experimental
description: |
  Detects an internal host making periodic outbound HTTPS connections
  with low jitter, indicative of C2 beaconing from CobaltStrike, Sliver,
  AdaptixC2, or VShell.
author: HackForLab
date: 2026/06/08
references:
  - https://hackforlab.com/threat-hunting-playbook-early-june-2026/
tags:
  - attack.command_and_control
  - attack.t1071.001
  - attack.t1573.002
logsource:
  product: zeek
  service: conn
detection:
  selection:
    proto: 'tcp'
    service: 'ssl'
    'id.resp_p':
      - 443
      - 8443
      - 8084
  filter_known_saas:
    'ssl.server_name|contains':
      - 'cdn.'
      - 'update.'
      - 'cloudfront.net'
      - 'akamai'
  condition: selection and not filter_known_saas
  timeframe: 6h
  aggregation: |
    count() by id.orig_h, id.resp_h, ssl.server_name > 20
    and stddev(delta) / mean(delta) < 0.15
fields:
  - id.orig_h
  - id.resp_h
  - ssl.server_name
  - ja3
falsepositives:
  - Software-update channels not in the allowlist
  - SaaS push notifications with low jitter
level: medium

Ship-to-production path

Promote the rule when its precision exceeds 80 percent over a thirty-day backtest. Enrich every hit with the destination’s JA3 / JA4 fingerprint and reverse-look the SNI against passive DNS. Suppress on known software-update channels through an allowlist the rule owner curates weekly — never through a permanent exception.

Hunt 01.2 · Named-pipe lateral movement

Hypothesis

A workstation creates or connects to a named pipe with a predictable lexical pattern (a default base name plus a random four-to-eight character suffix) on a peer host where no legitimate service uses that pipe. The pipe was created by a process whose parent is not a normal shell — for example, a parent of rundll32.exe, regsvr32.exe, or an Office productivity binary.

Sigma rule

title: Suspicious Named Pipe Creation from Non-System Parent
id: 7b2e4c92-2f5a-4d6b-91d6-c2a8f3e5b322
status: experimental
description: |
  Detects creation of a Windows named pipe with a CobaltStrike-style
  random suffix from a non-system parent process. Common Beacon SMB
  lateral-movement pattern.
author: HackForLab
date: 2026/06/08
tags:
  - attack.lateral_movement
  - attack.t1021.002
  - attack.t1570
logsource:
  product: windows
  service: sysmon
  category: pipe_created
detection:
  selection:
    EventID: 17
    PipeName|re: '\\\\\\.\\\\pipe\\\\[A-Za-z]{4,8}_[a-f0-9]{4,8}$'
  filter_legitimate_parents:
    ParentImage|endswith:
      - '\services.exe'
      - '\svchost.exe'
      - '\lsass.exe'
  condition: selection and not filter_legitimate_parents
fields:
  - PipeName
  - Image
  - ParentImage
  - User
falsepositives:
  - Custom internal tooling using randomized pipe names
level: high

Hunt 01.3 · DNS-based C2 with abnormally long subdomains

Hypothesis

A host is issuing DNS queries with subdomains longer than thirty characters or with unusually high label entropy. The parent domain was registered within the last ninety days. Query volume to that parent domain is dramatically higher than the host’s baseline DNS volume.

Sigma rule

title: High-Entropy DNS Query to Recently Registered Domain
id: 9c3f5d93-3a6b-4e7c-a2e7-d3b9a4f6c433
status: experimental
description: |
  Detects DNS queries with long, high-entropy subdomains to recently
  registered parent domains. Indicative of DNS-based C2 channels used
  by Sliver, VShell, and DNS tunneling implants.
author: HackForLab
date: 2026/06/08
tags:
  - attack.command_and_control
  - attack.t1071.004
logsource:
  product: zeek
  service: dns
detection:
  selection:
    'qtype_name':
      - 'A'
      - 'AAAA'
      - 'TXT'
      - 'NULL'
    'query|re': '^[A-Za-z0-9]{30,}\\..*'
  enrichment_filter:
    parent_domain_age_days|lt: 90
  condition: selection and enrichment_filter
fields:
  - 'id.orig_h'
  - query
  - qtype_name
  - parent_domain_age_days
falsepositives:
  - Security-product DNS reputation lookups
  - DNS-based software-update channels
level: high

04 · Hunt 02 — Linux backdoors and BPF implants

BPF-family implants survive because they sit beneath the kernel-network boundary, do not bind to listening ports, and activate only when a magic packet arrives. They reach the host through legitimate services that are already exposed. The hunt has to happen in raw-socket and kernel-tracing telemetry, not in process-creation logs.

Hunt 02.1 · Long-lived raw socket on a server that should not have one

Hypothesis

A Linux server has a process holding a raw AF_PACKET or SOCK_RAW socket for more than twenty-four hours. The process is not a packet-capture utility, the firewall, or a known monitoring agent. The process binary name is innocuous (something kernel-thread-like or daemon-like) but the binary is not signed by the distribution package manager.

Telemetry needed

• Linux auditd or eBPF tracer recording socket() syscalls
• Process lifetime and image-hash data
• Package manager database (dpkg, rpm) for signed-binary verification
• Periodic snapshot of /proc/net/raw and /proc/net/packet

Sigma rule

title: Unsigned Binary Opens AF_PACKET Raw Socket
id: 1d4a6e94-4b7c-4f8d-b3f8-e4a0b5c7d544
status: experimental
description: |
  Detects creation of an AF_PACKET (17) raw socket by an unsigned Linux
  binary. Pattern used by BPFdoor and BPF-family implants for stealth
  packet capture without binding a port.
author: HackForLab
date: 2026/06/08
tags:
  - attack.persistence
  - attack.defense_evasion
  - attack.t1205.001
  - attack.t1574
logsource:
  product: linux
  service: auditd
detection:
  selection:
    type: SYSCALL
    syscall: socket
    a0: '17'
  filter_legitimate:
    exe|endswith:
      - '/tcpdump'
      - '/iftop'
      - '/dhclient'
      - '/wireshark'
      - '/nmap'
  filter_known_monitor_agents:
    exe|contains:
      - '/var/lib/agent/'
      - '/opt/monitor/'
  condition: selection and not (filter_legitimate or filter_known_monitor_agents)
fields:
  - exe
  - pid
  - comm
  - euid
falsepositives:
  - Custom network monitoring agents
  - Container runtime virtual network stack
level: high

Ship-to-production path

Build the detection in three tiers. Tier 1 (low noise, high confidence): unsigned binary opening a raw socket on a production server — alert immediately. Tier 2: signed binary in an unusual file path — hunt-grade. Tier 3: the raw-socket process spawns a shell — full incident. Chain the tiers into one rule mapped to T1205.001 and tracked in your detection-as-code repository.

05 · Hunt 03 — Helpdesk-impersonation extortion

The Silent Ransom cluster (also tracked as UNC3753) operates without malware. The intrusion arrives as a phone call. The “tools” are commercial remote-management products installed under the victim’s own credentials. Data exfiltration uses signed file-transfer utilities. There is no payload to hash, no C2 to block — only patterns in legitimate-tool usage that should never have happened.

Hunt 03.1 · New remote-management product on a non-IT endpoint

Hypothesis

A remote-management product was installed on a user endpoint within the last seven days. The user had never previously run that product. The install happened outside the corporate change window. The product was installed from a downloaded MSI rather than from the corporate software portal.

Sigma rule

title: New Remote Management Tool Installed on Non-IT Endpoint
id: 2e5b7f95-5c8d-4a9e-c4a9-f5b1c6d8e655
status: experimental
description: |
  Detects MSI install of remote management and monitoring tools on user
  endpoints outside the IT admin group. Matches the Silent Ransom Group
  (UNC3753) callback-phishing intrusion pattern.
author: HackForLab
date: 2026/06/08
tags:
  - attack.command_and_control
  - attack.t1219
  - attack.initial_access
  - attack.t1566.004
logsource:
  product: windows
  service: application
detection:
  selection_msi_install:
    EventID: 1033
  selection_rmm_product:
    ProductName|contains:
      - 'AnyDesk'
      - 'Atera'
      - 'Splashtop'
      - 'Syncro'
      - 'SuperOps'
      - 'ScreenConnect'
      - 'ConnectWise Control'
      - 'TeamViewer'
      - 'LogMeIn'
      - 'Zoho Assist'
  filter_it_admins:
    ComputerName|contains:
      - 'IT-'
      - 'ADMIN-'
      - 'HELPDESK-'
  condition: selection_msi_install and selection_rmm_product and not filter_it_admins
fields:
  - ProductName
  - ProductVersion
  - User
  - ComputerName
falsepositives:
  - IT-approved RMM deployments (allowlist by host group)
level: high

Hunt 03.2 · File-transfer utility staging to unfamiliar destination

Hypothesis

A signed file-transfer utility (a command-line copy-over-SSH tool, a renamed rclone-class binary) uploaded more than 250 MB to a destination outside the host’s 30-day baseline within a 24-hour window.

Sigma rule

title: File-Transfer Utility Staging to Unfamiliar Destination
id: 3f6c8a96-6d9e-4baf-d5ba-a6c2d7e9f766
status: experimental
description: |
  Detects large-volume outbound traffic from common file-transfer
  utilities to a destination outside the host's 30-day baseline.
  Helpdesk-impersonation extortion data-exfiltration pattern.
author: HackForLab
date: 2026/06/08
tags:
  - attack.exfiltration
  - attack.t1567.002
  - attack.t1567
logsource:
  category: process_creation
  product: windows
detection:
  selection_tool:
    Image|endswith:
      - '\WinSCP.exe'
      - '\rclone.exe'
      - '\pscp.exe'
      - '\sftp.exe'
  selection_command:
    CommandLine|contains:
      - ' sync '
      - ' copy '
      - ' put '
      - ' --transfers'
  condition: selection_tool and selection_command
fields:
  - Image
  - CommandLine
  - User
  - ParentImage
falsepositives:
  - DevOps automation jobs (allowlist by host or scheduled-task hash)
level: high

Ship-to-production path

Combine 03.1 and 03.2 into a chain rule that fires high-severity when both happen on the same host within 72 hours. Pair the technical rule with an awareness control: any inbound call asking the user to install a remote-control tool gets escalated by the user, not the helpdesk.

06 · Hunt 04 — State-sponsored espionage campaigns

Three espionage clusters appeared this week. A Russia-nexus cluster (Gamaredon family) targeting government and energy in eastern Europe. An Iran-nexus cluster (UNC1549) running social-engineering lures against defence and telecom. A regionally focused cluster (VerdantBamboo) operating against media and academia in east Asia. They share none of the same payloads. They share the same playbook: spear-phish, drop a small loader, persist in user-writable directories, beacon over normal ports.

Hunt 04.1 · HTML smuggling delivering archive payloads to startup paths

Hypothesis

A web browser child process wrote a file matching *.rar, *.zip, *.7z, *.iso, or *.xhtml to the user’s Downloads path. Within ten minutes an archive utility or shell extracted from that file into the user’s Startup folder (or an autostart registry key). The originating browser tab loaded the XHTML or HTML attachment from email rather than from a typed URL.

Sigma rule

title: HTML-Smuggled Archive Landing in Startup Directory
id: 4a7d9b97-7e0f-4cb0-e6cb-b7d3e8f0a877
status: experimental
description: |
  Detects an archive file (rar, zip, 7z, iso, xhtml) written by a browser
  process followed within ten minutes by file creation in a user-writable
  autostart path. Matches the Gamaredon, UNC1549, and VerdantBamboo
  delivery-and-persistence chain.
author: HackForLab
date: 2026/06/08
tags:
  - attack.initial_access
  - attack.t1566.001
  - attack.persistence
  - attack.t1547.001
  - attack.defense_evasion
  - attack.t1027.006
logsource:
  product: windows
  category: file_event
detection:
  selection_archive_write:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
    TargetFilename|endswith:
      - '.rar'
      - '.zip'
      - '.7z'
      - '.iso'
      - '.xhtml'
    TargetFilename|contains: '\Downloads\'
  selection_persistence_path:
    TargetFilename|contains:
      - '\Startup\'
      - '\CurrentVersion\Run'
      - '\Microsoft\Windows\Start Menu\Programs\Startup\'
  condition: selection_archive_write and selection_persistence_path
  timeframe: 10m
fields:
  - Image
  - TargetFilename
  - User
falsepositives:
  - User installing portable software from a downloaded archive
level: high

Hunt 04.2 · Recruiting-adjacent domain spear-phish lure

Hypothesis

A user received an email from a sender whose domain matches a careers- or recruiting-adjacent lexical pattern and was registered within the last sixty days. The user clicked a link in the email or downloaded its attachment.

Sigma rule

title: Recently-Registered Recruiting-Adjacent Domain Email Interaction
id: 5b8e0c98-8f10-4dc1-f7dc-c8e4f9a1b988
status: experimental
description: |
  Detects user interaction with an email from a sender whose domain
  matches recruiting-related lexical patterns and was registered in the
  last 60 days. Matches the UNC1549 LinkedIn-derived spear-phishing
  pattern.
author: HackForLab
date: 2026/06/08
tags:
  - attack.initial_access
  - attack.t1566.002
  - attack.resource_development
  - attack.t1583.001
logsource:
  product: email
  service: gateway
detection:
  selection_lexical:
    SenderDomain|re: '^(careers|jobs|talent|hiring|opportunit[iy]|recruit)[\\-a-z0-9]*\\..*'
  selection_age:
    SenderDomainAgeDays|lt: 60
  selection_interaction:
    UserClickedLink: true
  condition: selection_lexical and selection_age and selection_interaction
fields:
  - SenderDomain
  - SenderDomainAgeDays
  - Recipient
  - Subject
falsepositives:
  - Legitimate recruiting agency outreach
level: medium

07 · Hunt 05 — Software-supply-chain compromise

The Mini Shai-Hulud cluster propagates through package-manager install hooks. The compromise lands on a developer’s workstation or in a build agent. The visible blast radius — the production application — comes minutes later. The hunt has to happen upstream of the production deploy.

Hunt 05.1 · Package install script reaching cloud metadata or webhook

Hypothesis

A package-manager install or preinstall script executed and produced an outbound HTTP request to the cloud-instance metadata endpoint (the link-local IPv4 reserved for instance metadata), to a webhook collector, or to a public paste site. The same process tree scanned the user’s home directory for files matching a secret-pattern set (private keys, dotfile environment files, cloud config).

Sigma rule

title: Package Manager Install Script Reaches Cloud Metadata Endpoint
id: 6c9f1d99-9021-4ed2-08ed-d9f5a0b2ca99
status: experimental
description: |
  Detects an npm, yarn, pnpm, pip, or python process generating an
  outbound HTTP request to the cloud instance metadata endpoint
  (169.254.169.254), a webhook collector, or a public paste site.
  Matches the Shai-Hulud npm worm exfiltration pattern.
author: HackForLab
date: 2026/06/08
tags:
  - attack.initial_access
  - attack.t1195.002
  - attack.credential_access
  - attack.t1552.005
logsource:
  product: linux
  category: network_connection
detection:
  selection_parent:
    ParentImage|endswith:
      - '/node'
      - '/npm'
      - '/npx'
      - '/pnpm'
      - '/yarn'
      - '/pip'
      - '/pip3'
      - '/python'
      - '/python3'
  selection_destination:
    DestinationIp: '169.254.169.254'
  selection_destination_webhook:
    DestinationHostname|contains:
      - 'webhook.'
      - 'paste.'
      - 'pastebin.'
      - 'discord.com/api/webhooks'
      - 'ngrok'
      - 'requestbin'
  condition: selection_parent and (selection_destination or selection_destination_webhook)
fields:
  - ParentImage
  - Image
  - DestinationIp
  - DestinationHostname
  - CommandLine
falsepositives:
  - Legitimate CI runners that intentionally query metadata
level: critical

Ship-to-production path

This detection is high-fidelity. There is essentially no legitimate reason for an install script to query the cloud metadata endpoint or a webhook collector. Ship as a real-time alert, attach the install-script source for forensic review, and trigger automatic revocation of any cloud credentials accessible from that build agent.

08 · Hunt 06 — Commodity stealers and RATs

Seven commodity remote-access trojans and information stealers appeared in the catalogue this week: xenoRAT, Remcos, AsyncRAT, DCRat, Quasar RAT, Vidar, and ValleyRAT. They differ in implementation. They share an information-stealing behaviour that is observable: every one of them reads the browser-data directories, the password-manager files, the cryptocurrency wallet store, and the file-transfer-client configuration. The hunt is on the behaviour, not on the malware brand.

Hunt 06.1 · Non-browser process reads the browser credential store

Hypothesis

A non-browser process opened, for read, one of: the major-browser credential SQLite store (the “Login Data” file under the user profile), the alternative-browser credential JSON or key database (typical names logins.json and key4.db), the password-manager export path, or the cryptocurrency wallet directory. The reading process was not signed by the browser publisher, the password-manager publisher, or the operating-system distribution.

Sigma rule

title: Non-Browser Process Reads Browser Credential Store
id: 7da02ea0-a132-4fe3-19fe-eaa6b1c3db00
status: stable
description: |
  Detects a non-browser process opening a browser credential store
  (Login Data SQLite, logins.json, key4.db) or a cryptocurrency wallet
  directory. Universal stealer-class detection covering xenoRAT,
  Remcos, AsyncRAT, DCRat, Quasar, Vidar, ValleyRAT.
author: HackForLab
date: 2026/06/08
tags:
  - attack.credential_access
  - attack.t1555.003
  - attack.t1539
logsource:
  product: windows
  category: file_event
detection:
  selection_target:
    TargetFilename|contains:
      - '\User Data\Default\Login Data'
      - '\User Data\Default\Cookies'
      - '\Profiles\'
      - '\logins.json'
      - '\key4.db'
      - '\Wallets\wallet.dat'
      - '\Ethereum\keystore\'
  filter_legit_browsers:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
      - '\opera.exe'
  filter_av_scanners:
    Image|contains:
      - '\Antivirus\'
      - '\Defender\'
  condition: selection_target and not (filter_legit_browsers or filter_av_scanners)
fields:
  - Image
  - TargetFilename
  - User
  - ProcessGuid
falsepositives:
  - Backup utilities scanning user profile
  - Browser-profile migration tools
level: critical

Ship-to-production path

This rule has been productized many times and still works because the behaviour is invariant. Ship to every endpoint detection stack. Tag the alert with a recovery playbook that rotates the impacted credentials at incident detection, not at incident resolution.

09 · Hunt 07 — IoT botnets and worm-class infrastructure

The IoT botnet families catalogued this week — Mirai-class, Mozi-class, Phorpiex-class, Tofsee-class — share a single inbound footprint: brute-force authentication attempts against router admin interfaces, IP-camera consoles, and unpatched edge appliances. The hunt is the inbound side; the prize is identifying which of your assets is one credential away from being conscripted.

Hunt 07.1 · Inbound credential brute force on management-plane ports

Hypothesis

An internet-facing asset is receiving more than fifty distinct failed-authentication events per hour on a management-plane port (22, 23, 80, 443, 2323, 7547, 8080, 8443). The source IPs are heterogeneous. The same source IPs are also hitting other organisations — the asset is being scanned by a botnet seeder rather than by a targeted operator.

Sigma rule

title: Inbound Brute Force Against Edge Appliance Management Port
id: 8eb13fb1-b243-4014-2a0f-fbb7c2d4ec11
status: experimental
description: |
  Detects high-volume failed-authentication events from heterogeneous
  source IPs on management-plane ports of internet-facing assets.
  Mirai, Mozi, Phorpiex, Tofsee scanner-seeder pattern.
author: HackForLab
date: 2026/06/08
tags:
  - attack.initial_access
  - attack.t1190
  - attack.credential_access
  - attack.t1110.001
logsource:
  product: linux
  service: auth
detection:
  selection:
    type:
      - 'ssh_failed_password'
      - 'http_basic_auth_failed'
      - 'telnet_login_failed'
    dst_port:
      - 22
      - 23
      - 80
      - 443
      - 2323
      - 7547
      - 8080
      - 8443
  condition: selection
  timeframe: 1h
  aggregation: |
    count(distinct src_ip) by dst_ip > 50
fields:
  - dst_ip
  - dst_port
  - src_ip
  - username_attempted
falsepositives:
  - Authorized vulnerability scanner sweeps (allowlist source IPs)
level: medium

Ship-to-production path

The detection is straightforward; the value is in the response. Promote the rule, but pair it with an asset-hardening workflow: every asset that triggers the rule gets MFA enforcement, default-credential audit, and exposure review as a single ticket.

10 · Best practices — running a hunt program that ships

Hunting without an operating model produces clever notebooks that nobody else can rerun. The practices below turn ad-hoc hunts into a production capability your detection engineering team can compound on.

10.1 · Treat every hunt as detection-as-code

Hunt brief, Sigma rule, validation harness output, false-positive notes, ATT&CK technique mapping — all of it lives in version control. A new detection engineer should be able to clone the repository and rerun every hunt without asking anyone what is going on.

10.2 · Map every hunt to ATT&CK before you build it

If you cannot name the techniques the hunt covers, you cannot measure coverage. Tag each Sigma rule with at least one technique ID. Track aggregate coverage as a leading indicator of program maturity.

10.3 · Define a false-positive budget

Every production rule gets a target precision (true positives divided by total alerts). Common targets: critical-severity 95 percent, high 85 percent, medium 70 percent. Rules that fall below their budget get a tuning sprint or get retired — never permanently muted.

10.4 · Backfill before promotion

Run a candidate rule over the last 30 days of historical telemetry before promoting it to production. The hits are your tuning input. The misses tell you whether the rule is too tight.

10.5 · Couple every detection with a response playbook

A rule that fires without a documented action is noise that an on-call analyst learns to suppress. Even the most precise rule needs: who gets paged, what to check first, what to escalate, and what evidence to preserve.

10.6 · Operate on a rolling 90-day coverage horizon

ATT&CK techniques evolve. Adversary tradecraft evolves. A rule shipped six months ago may be detecting a behaviour no current adversary uses. Audit your coverage quarterly: which techniques have new public reporting, which of your rules are stale, which gaps appeared in the last quarter.

11 · Success metrics — what a hunt program is measured on

A leadership-grade hunt program reports on the same dashboard every quarter. The five KPIs below are the minimum reporting set. Track each metric monthly; report at-a-glance quarterly.

Reporting cadence. Monthly for the operations team (with tuning actions for any out-of-budget rule). Quarterly for security leadership (with technique-coverage trend over four quarters). Annually for the board (one slide: coverage percentage, MTTD trend, top-three threat clusters detected).

Practitioner tip. Pair the technical metrics with one human metric: hunt-author rotation. If the same engineer has authored 80 percent of the production rules, the program has a bus factor of one. Cross-train explicitly — every detection engineer should ship at least one production rule per quarter.

12 · Conclusion — what to do tomorrow

Threat hunting is a discipline of compounding wins. One rule shipped, well-tuned, well-tagged, becomes the template for the next ten. The seven hunts above are not the entire universe of what you should hunt this quarter — they are the entry point. Here is how to operationalise them inside the next two weeks.

Step 01 · Pick one hunt and run it

Choose the cluster most relevant to your environment. If you are a cloud-heavy organisation, start with Hunt 05 (supply chain). If you handle high-value identity data, start with Hunt 06 (commodity RATs). If you are public-sector or critical-infrastructure, start with Hunt 04 (state-sponsored APT). Run the Sigma rule against the last 30 days of telemetry. Triage every hit.

Step 02 · Map the gap to your detection coverage

Compare the rule’s ATT&CK technique tags against your existing production coverage. Any technique the new rule covers that no existing rule covers is a coverage gain. Track it on the dashboard you report to leadership.

Step 03 · Pair the rule with a response playbook

Before promoting the rule to production, write the one-page playbook: who gets paged, what evidence to collect, what to escalate. A rule without a playbook is noise.

Step 04 · Sign in to the platform and export the catalogue

The seven hunts in this playbook come from a single week of catalogue activity. The platform exposes the full catalogue — every IOC, every cluster, every TTP — with one-click export to Sigma, STIX, or CSV. Use it as the live input to your hunt backlog.

13 · FAQ — questions practitioners keep asking