Threat Hunting Playbook · Early June 2026 — Hunt Hypotheses, Detection Rules, and the Telemetry You Actually Need

A threat-intelligence report tells you the adversary exists. A hunt playbook tells you where the adversary is in your environment, what telemetry reveals them, and which detection engineering pipeline turns the finding into a production rule before the next campaign lands. Seven hunt blocks, built from 55,729 indicator observations cataloged this week.

This week’s catalogue, at a glance

Between June 1 and June 7, 2026, we cataloged 55,729 indicator observations across 91 distinct adversary clusters. Ninety-eight percent of the observations were command-and-control traffic. Two percent were payload-delivery infrastructure, ransomware staging, supply-chain compromise, or social-engineering lures — small in volume, but disproportionate in impact.

The hunt blocks below are ordered by adversary footprint, but you do not have to read them in order. Each block is self-contained: a hypothesis, the telemetry needed, a query pattern, and a path to production. Pick the cluster most relevant to your environment and start there.

The IOC type mix tells you where the visible signal lives: 54,719 IPs, 574 domains, 295 file hashes, 61 URLs, and a small handful of email and “other” indicators. If your hunting program reads only the file-hash column, you are seeing less than one percent of the available signal.

Block 01 · Open-source C2 frameworks

Five open-source command-and-control frameworks accounted for 97 percent of the catalogue this week: CobaltStrike, Sliver, VShell, AdaptixC2, and Havoc. They differ in implementation. They share an operational pattern: a small implant, periodic beaconing, an HTTP / HTTPS / DNS / 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 connection 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

Vendor-neutral query pattern

SELECT src_ip, dst_ip, dst_port, sni,
       COUNT(*) AS hits,
       AVG(delta_sec) AS mean_gap,
       STDDEV(delta_sec) AS jitter_sd
FROM   tls_conn_with_gaps
WHERE  ts BETWEEN '2026-06-01' AND '2026-06-07'
  AND  dst_port IN (443, 8443, 8084)
  AND  sni NOT IN (SELECT sni FROM known_saas)
GROUP BY src_ip, dst_ip, dst_port, sni
HAVING hits > 20
   AND jitter_sd / mean_gap < 0.15
ORDER BY jitter_sd / mean_gap ASC;

Ship-to-production path

Promote the query to a scheduled detection that fires when a host produces twenty or more outbound HTTPS connections to a non-baseline destination within a six-hour window with a jitter-to-mean ratio under 0.15. Enrich every hit with the destination’s JA3 / JA4 fingerprint and reverse-look the SNI. 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 is creating or connecting 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.

Telemetry needed

• Sysmon Event 17 (named pipe created)
• Sysmon Event 18 (named pipe connected)
• Process creation (Event 1) for the parent-child chain
• SMB session logs identifying the account that opened the pipe

Vendor-neutral query pattern

SELECT p17.host, p17.pipe_name, p17.image, p17.parent_image, p17.user
FROM   sysmon_17_pipe_create p17
WHERE  ts BETWEEN '2026-06-01' AND '2026-06-07'
  AND  p17.parent_image NOT IN
       ('C:\\Windows\\System32\\services.exe',
        'C:\\Windows\\System32\\svchost.exe')
  AND  REGEXP_MATCH(p17.pipe_name,
        '\\\\\\.\\\\pipe\\\\[A-Za-z]{4,8}_[a-f0-9]{4,8}');

Ship-to-production path

Build the rule in two passes. Pass one alerts on any named-pipe creation matching the regex AND a non-system parent process AND a concurrent SMB session from another host. Pass two backfills 30 days of historical telemetry; the surviving anomalies become the high-confidence detection. Map to T1021.002 and version-control alongside its false-positive budget.

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.

Telemetry needed

• Full DNS query log (Zeek dns.log, Windows DNS analytical channel, or resolver flow)
• Domain registration age via passive DNS or WHOIS enrichment
• Per-host DNS volume baseline for the last thirty days
• Query-type distribution (A / AAAA / TXT / NULL mix)

Vendor-neutral query pattern

SELECT src_ip, query, parent_domain, query_type,
       LENGTH(SPLIT_PART(query, '.', 1)) AS first_label_len,
       SHANNON_ENTROPY(SPLIT_PART(query, '.', 1)) AS entropy
FROM   dns_with_enrichment
WHERE  ts BETWEEN '2026-06-01' AND '2026-06-07'
  AND  first_label_len > 30
  AND  entropy > 3.5
  AND  parent_domain_age_days < 90
  AND  query_type IN ('A', 'AAAA', 'TXT', 'NULL');

Ship-to-production path

Convert to a streaming detection with a sliding window: alert when a single source IP issues one hundred or more high-entropy long-subdomain DNS queries to the same young parent domain within ten minutes. False-positive sources include security-product DNS reputation lookups and legitimate DNS-tunneled software-update channels — both are enumerable and belong in a maintained allowlist.

Block 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() calls
• 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

Vendor-neutral query pattern

SELECT host, pid, process_name, image_path,
       socket_age_hours, last_seen
FROM   raw_socket_snapshot
WHERE  ts BETWEEN '2026-06-01' AND '2026-06-07'
  AND  socket_age_hours > 24
  AND  package_manager_signed = FALSE
  AND  process_name NOT IN ('tcpdump', 'iftop', 'dhclient');

Ship-to-production path

This is a multi-tier detection. Tier one is low noise, high confidence: an unsigned binary opening a raw socket on a production server — alert immediately. Tier two is signed binary in an unusual file path — hunt-grade. Tier three is the process executes a shell whose parent is the raw-socket process — a full incident. Chain all three tiers into one rule mapped to T1205.001 and tracked in your detection-as-code repository.

Block 03 · Helpdesk-impersonation extortion

The Silent Ransom cluster 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 · Unauthorized remote-management installation on a finance or legal 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.

Telemetry needed

• Software inventory comparison (current state versus 30-day baseline)
• Process creation logs with full image path
• MSI install events (Windows event log 1033)
• Outbound TLS to remote-management product domains

Vendor-neutral query pattern

SELECT host, user, product_name, install_source, install_ts
FROM   software_inventory_diff
WHERE  install_ts BETWEEN '2026-06-01' AND '2026-06-07'
  AND  product_category = 'remote_management'
  AND  host NOT IN (SELECT host FROM it_admin_endpoints)
  AND  install_source NOT LIKE '%corp_software_portal%';

Ship-to-production path

Two detections together. First, net-new remote-management install outside IT — alert. Second, signed file-transfer utility used to upload more than 250 MB to an unfamiliar destination — alert. Combine 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.

Hunt 03.2 · Large outbound staging to file-sharing or storage providers

Hypothesis

An endpoint uploaded more than one gigabyte of cumulative data to a file-sharing or object-storage destination over a 24-hour window. The user’s 30-day baseline is under 50 megabytes per day. The source files came from the user’s documents and downloads folders, not from a system or application path.

Ship-to-production path

Rather than rate-limiting destinations, build a per-user upload baseline (median plus three standard deviations) and alert on the deviation. Storage destinations get a stricter threshold than collaboration platforms. The same rule catches extortion exfiltration, insider data theft, and accidental confidential-document upload — three problems, one detection.

Block 04 · State-sponsored espionage campaigns

Three espionage clusters appeared this week. A Russia-nexus cluster targeting government and energy in eastern Europe. An Iran-nexus cluster running social-engineering lures against defence and telecom. A regionally focused cluster 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 into user-writable 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.

Telemetry needed

• Browser process file-write events
• Archive utility command-line history
• Persistence-path file write (Startup folder, Run keys, scheduled task creation)
• Mail gateway attachment type and content-disposition header

Vendor-neutral query pattern

WITH downloaded AS (
  SELECT host, user, file_path, ts AS dl_ts
  FROM   process_file_write
  WHERE  parent_image LIKE '%browser_process%'
    AND  file_path    LIKE '%\\Downloads\\%'
    AND  REGEXP_MATCH(file_path, '\\.(rar|zip|7z|iso|xhtml)$')
)
SELECT d.host, d.user, d.file_path,
       p.persisted_path, p.ts AS persist_ts
FROM   downloaded d
JOIN   persistence_create p
  ON   p.host = d.host
  AND  p.ts BETWEEN d.dl_ts AND d.dl_ts + INTERVAL '10 minutes'
  AND  (p.persisted_path LIKE '%\\Startup\\%'
       OR p.persisted_path LIKE '%\\CurrentVersion\\Run%');

Ship-to-production path

This is a high-fidelity correlation rule. Ship as a scheduled query (one-minute window over the last ten minutes) and feed alerts directly into the SOAR enrichment lane — pull the originating email attachment, the sender-domain age, the file hash, the persistence-path content. Map to T1547.001 plus T1566.001. Track its false-positive rate weekly; the legitimate use of XHTML email attachments is nearly zero in enterprise traffic, so noise indicates a misconfigured rule, not real-world ambiguity.

Hunt 04.2 · Spear-phish from a recently registered recruiting-adjacent domain

Hypothesis

A user received an email from a sender whose domain matches a careers- or recruiting-adjacent lexical pattern (career-portal, jobs-, talent-, hiring-, opportunity-) and which was registered within the last sixty days. The email contained an attachment or a link, and the user clicked or downloaded it.

Ship-to-production path

Build a domain-age and lexical-pattern enrichment service that scores every inbound email at ingest. Emails scoring above a defined threshold get the user a banner (“This domain was registered last week”) and a copy of the message routes to the hunting queue. The detection is the enrichment; the action is education at the moment of decision.

Block 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 secret-scanning behaviour

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).

Telemetry needed

• Process creation on developer endpoints and on build agents
• Outbound HTTP from node, npm, pnpm, yarn, pip
• File-read audit on dotfiles and key directories
• CI runner logs for the install phase of every job

Vendor-neutral query pattern

SELECT host, user, parent_image, image, command_line, dst_ip
FROM   process_network_outbound
WHERE  ts BETWEEN '2026-06-01' AND '2026-06-07'
  AND  parent_image IN ('node', 'npm', 'pnpm', 'yarn', 'pip', 'python')
  AND  (dst_ip = '169.254.169.254'
       OR dst_host LIKE '%webhook.%'
       OR dst_host LIKE '%paste.%');

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. The same rule covers every future variant of the same pattern, because the pattern is the technique, not the package.

Block 06 · Commodity stealers and remote-access trojans

Seven commodity remote-access trojans and information stealers appeared in the catalogue this week. 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 reading 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.

Telemetry needed

• File access audit on the secret-store paths
• Process signing-status field
• Process parent → child → grandchild chain
• Outbound network destination of the reading process

Ship-to-production path

This rule has been productized many times and still works because the behaviour is invariant. Build it with the file paths as parameters, ship to every endpoint detection stack, and use the platform’s TTP-to-IOC mapping to enrich every alert with the cluster the process most likely belongs to. Map to T1555.003. Tag the alert with a recovery playbook that rotates the impacted credentials at incident detection, not at incident resolution.

Block 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 against 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 set of source IPs is also hitting other organisations — the asset is being scanned by a botnet seeder rather than by a targeted operator.

Telemetry needed

• Edge appliance authentication log
• NetFlow on management-plane ports
• Asset inventory with a public-IP flag
• Cross-organisation correlated indicator (a catalogue lookup)

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. The rule is the trigger; the lifecycle is the win.

From hunt to production rule — the five-stage pipeline

Every hunt in this playbook follows the same lifecycle. Track the stage of each hunt explicitly so the program ships detections, not heroics.

Treat the pipeline as code. Version every hunt brief, every query, every tuning note. The artefact trail is what lets a new detection engineer pick up the rule six months later without losing context.

FAQ — the questions hunt teams keep asking