Threat Hunting & Proactive Detection Questions

Understand threat hunting methodology: developing hypotheses about attacker behavior, using tools and queries to search for indicators of compromise, and validating findings. Know how to hunt across logs, endpoint data, network traffic, and cloud environments. Discuss automated threat hunting vs. manual investigation. Understand threat intelligence feeds and how to operationalize them.

HardTechnical

61 practiced

Design a statistical detection and query to identify low-and-slow DNS exfiltration or tunneling. Specify features to compute (subdomain entropy, average query length, queries per minute per host, unique subdomain count per second-level domain), thresholds or anomaly scores, and how to profile normal behavior to reduce false positives.

Sample Answer

**Approach (brief)** Detect low-and-slow DNS exfiltration by computing per-host/time-window statistical features, scoring them with a composite anomaly score, and suppressing alerts via baselining and adaptive thresholds.

**Features to compute**- Subdomain Shannon entropy (per query): entropy of label characters.

text

H = - sum( p_i * log2(p_i) )  for i over character distribution

- Average query length (chars) per minute per host- Queries per minute (QPM) per host to a given second-level domain (SLD)- Unique subdomain count per SLD per time window (e.g., 1m, 1h)- Ratio of numeric/base32/base64-like tokens (regex frequency) in labels- NXDOMAIN / unusual response rate

**Example implementation snippets**- Entropy in Python:

python

import math, collections
def entropy(s):
    cnt = collections.Counter(s)
    L = len(s)
    return -sum((v/L)*math.log2(v/L) for v in cnt.values())

- ElasticSearch/Zeek aggregation: count distinct subdomains per SLD per host per minute; compute avg length and entropy using scripted metric.

**Thresholds / anomaly scoring**- Per-feature z-score against baseline; composite score = weighted sum (weights: entropy 0.4, unique-subdomains 0.3, QPM 0.2, avg-length 0.1). - Example thresholds: alert if composite > 4 (i.e., >4 sigma) OR entropy > 3.5 AND unique-subdomains/min > 20 AND QPM > 5 (tunable).- For low-and-slow: flag persistent small anomalies (score 2–4) sustained >24 hours.

**Profiling normal behavior to reduce false positives**- Build baseline per host, per SLD, per time-of-day/week using rolling windows (14–30 days). Use seasonal decomposition to capture business-hour patterns.- Whitelist known dynamic DNS/CDN providers (e.g., akamai, cloudfront) and internal services; maintain allowlist of legitimate high-entropy domains (e.g., UUIDs from telemetry).- Use clustering to separate typical high-cardinality services: cluster SLDs by historical unique-subdomain rate; only apply strict thresholds to low-cardinality clusters.- Add enrichment (whois, passive DNS, reputation) and require corroborating indicators (data exfil size estimate, C2 IPs) before escalating.

**Validation & Tuning**- Evaluate on labeled traffic (benign + synthetic exfil tests) to tune weights/thresholds; measure precision/recall. Implement alert suppression for known maintenance windows and rate-limit noisy alerts.

MediumTechnical

59 practiced

Write a Sigma rule (YAML) that detects processes launching PowerShell with base64-encoded commands (i.e., contains '-EncodedCommand' or '-enc'). Include fields for title, description, detection selection, false-positive notes, and a mapping to an ATT&CK technique.

Sample Answer

**Brief approach**- Match process creation events where the command line for PowerShell contains base64 flags (-EncodedCommand or -enc). Use case-insensitive regex and require PowerShell executable to reduce false positives.

yaml

title: Detect PowerShell Invocations with Base64 Encoded Commands
id: d1a4f2a2-9b6e-4c3b-8f4e-1234567890ab
description: Detects PowerShell processes launched with base64-encoded commands (flags -EncodedCommand or -enc), commonly used to obfuscate and execute malicious payloads.
status: experimental
author: InfoSec Analyst
date: 2026-03-02
logsource:
  product: windows
  service: security
  category: process_creation
detection:
  selection_process:
    Image|endswith: 
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_cmd:
    CommandLine|re: '(\-encodedcommand|\-enc)\s+[A-Za-z0-9\+/=]{20,}'
  detection_condition: selection_process and selection_cmd
falsepositives:
  - Legitimate automation or management tooling that uses encoded commands (scripts, config management, scheduled tasks).
  - Inline base64 used by admins for short encoded data (rare).
level: high
tags:
  - attack.execution
  - attack.t1059.001
  - attack.t1059
  - attack.persistence
fields:
  - CommandLine
  - ParentImage
  - Image
  - User

**Explanation & tuning**- Why: EncodedCommand is frequently used to hide malicious payloads. Combining Image check reduces noise from other binaries.- Tuning: exclude known management tool parents (e.g., SCCM) or add allowlist for automation service accounts. Increase base64 length threshold if spurious matches occur.

**Alternatives**- Add behavioral enrichments (process parent chain, network activity) and score with multi-condition rules to reduce false positives.

HardTechnical

54 practiced

Design a scoring and operational model to reconcile multiple threat intel feeds of varying quality. Include deduplication logic, TTL/expiration, confidence scoring, source reputation, automated versus manual actions (alerting vs blocking), and feedback loops to improve feed reliability over time.

Sample Answer

**Situation & goal (brief)** I’d design a unified scoring and ops model that ingests multiple threat feeds, deduplicates indicators, assigns confidence and actionability scores, enforces TTLs, and drives automated or manual responses with feedback to improve feed reliability.

**Architecture & flow** - Central ingestion pipeline tags feed metadata (source, timestamp, feed-type). - Normalizer converts indicators to canonical schema (IOC type, value, first/last seen). - Deduplication: exact-match on normalized IOC; fuzzy-match for variants (IP + port, URL path normalization, hash family). Merge records keeping earliest first-seen and union of attributes.

**Scoring model** - Source Reputation SR (0–1): historical true-positive rate, freshness, vendor pedigree. - Indicator Confidence IC (0–1): based on corroboration count, recency, context (malicious ASN, passive DNS). - Actionability A (0–1): presence of tactics (C2), exploitability, asset exposure. - Final Score FS = 0.5 * SR + 0.3 * IC + 0.2 * A (example weights adjustable).

**TTL / expiration** - Default TTL by IOC type (IP: 7 days unless persistent; domain: 30 days; hash: infinite). - TTL decay: score decays exponentially; if FS < 0.2 -> archive. Manual override for threat hunts.

**Automation vs manual** - Blocking threshold: FS >= 0.85 and corroborated by >=2 high-rep sources -> automated block + alert. - Alert-only: 0.5 <= FS < 0.85 -> create SIEM alert, SOC analyst triage. - Monitor-only: 0.2 <= FS < 0.5 -> tag for hunting, passive enrichment. - Human review required for high-impact assets regardless of FS.

**Feedback loops** - Enrichment outcomes (true/false positive) from SOC investigations update source reputation and indicator confidence via Bayesian update. - Automated telemetry (blocked connections, IDS hits) feeds back as corroboration signals. - Periodic retraining of SR scores and weight tuning from labeled incidents; SLA: weekly quality report (FP/TP rates), quarterly feed pruning.

**Operational controls & metrics** - Guardrails: change control for blocking rules, emergency revoke. - Metrics: FP rate, MTTR, feed precision/recall, percent automated blocks. - Example: if a feed’s precision < 60% over 30 days, quarantine and require manual approval.

I would implement this in the SIEM/MISP/lookup service, instrument everything for observability, and iterate with SOC to balance risk vs noise.

MediumTechnical

54 practiced

Design a purple-team exercise to test detection coverage for lateral movement and credential theft. Outline scenarios, attack stories mapped to ATT&CK techniques, scoring metrics to evaluate defenders, telemetry to collect, and how to convert findings into prioritized detection improvements.

Sample Answer

**Overview (goal)** I would run a week-long purple-team focused on lateral movement and credential theft to validate detection coverage, reduce blind spots, and produce prioritized remediation tasks.

**Scenarios & attack stories (examples mapped to MITRE ATT&CK)** - Scenario A — Pass-the-Hash: compromise a workstation, extract NTLM hashes with Mimikatz, use wmiexec/Pass-the-Hash to access a domain host. (T1550.002, T1003.002, T1021.001) - Scenario B — Kerberoasting: request service tickets for SPNs, crack offline to obtain service account creds. (T1558.003, T1552) - Scenario C — Lateral RDP + Credential Dumping: enable RDP, move laterally using RDP and dump LSASS via comsvcs/syscalls. (T1021.001, T1003.001) - Scenario D — Silver Ticket / Golden Ticket simulation (lab-only): forged Kerberos tickets to access resources. (T1558.003, T1098.001)

**Telemetry to collect** - Host: Sysmon (process create, network connect, driver loads, image loaded, LSASS access), EDR alerts, Windows Security (4624/4625/4648/4672), PowerShell/Script Block logging. - Network: Netflow/Zeek, DNS logs (suspicious lookups), SMB/authentication attempts, RDP session metadata. - Identity: DC logs (Kerberos TGS requests, SPN requests), AD logs for replication and account privilege changes. - Central: SIEM-normalized events, packet captures for high-fidelity traces.

**Scoring metrics for defenders** - Detection Rate (%) = alerts generated for each scenario / total scenario steps. - Mean Time to Detect (MTTD) per technique. - Investigation Quality Score (0–5): alert contains TTP context, affected host/user, recommended response. - False Positive Rate. - Coverage Index: percent of ATT&CK techniques instrumented with reliable telemetry and rule set.

**Runbooks & validation** - Execute each step with red and blue collaborating; blue responds using normal processes. Record timestamps, alerts, analyst actions, escalation quality.

**Converting findings into prioritized improvements** - Triage findings into three buckets: Telemetry Gaps (no logs), Detection Gaps (logs but no rule), Quality Gaps (noisy or low-context alerts). - Prioritize by risk × detectability: critical assets first, techniques with high impact (credential theft) and low coverage get top priority. - Remediations: enable Sysmon/EDR on gaps, add correlation rules (e.g., LSASS read + remote process create), tune thresholds, enrich alerts with identity context, and create automated containment playbooks for proven detections. - Deliverable: executive dashboard (coverage index, MTTD, top 5 detections to implement), and 30/60/90-day remediation roadmap with owners and validation tests.

I would close the engagement with replay tests of implemented fixes and a knowledge-transfer session for analysts (playbooks + example alerts).

HardTechnical

57 practiced

Outline a memory forensics plan to detect process hollowing and reflective DLL injection on Windows endpoints. Include the capture steps for volatile memory across multiple hosts, signatures/artifacts you would search for (PE headers in remote processes, unusual memory protections, thread injection), and legal or operational constraints to consider.

Sample Answer

**Plan summary (goal)** I would establish a repeatable memory-forensics playbook to detect process hollowing and reflective DLL injection across Windows endpoints, minimize evidence loss, and satisfy legal/operational constraints.

**Capture steps (volatile memory)** - Triage: isolate host from network (air-gap or remove from domain) when possible, document chain-of-custody. - Live capture order: kernel memory and full RAM image using validated tools (Magnet ACQUIRE, Belkasoft Live RAM, FTK Imager, or DumpIt). Capture pagefile and hibernation files if present. - Process list + handles: use Sysinternals (procdump, procexp) and Windows APIs to dump process memory and list handles (Handle.exe). - Supplementary: record live netstat, autoruns, running services, threads, and registry hives. Timestamp everything (UTC).

**Artifacts & signatures to search** - PE headers in remote process memory: search for "MZ" and "PE\0\0" sequences inside process address spaces where no loaded module matches (indicates reflective loads). - Unusual memory protections: RWX (read-write-execute) or executable pages without corresponding module on disk. - Thread injection indicators: suspended threads created in foreign processes, CreateRemoteThread/QueueUserAPC patterns, thread start addresses pointing into anonymous memory. - Detached sections: module sections mapped with IMAGE_SCN_CNT_CODE but no backing file. - IAT/Export inconsistencies: in-memory imports that don't match on-disk DLLs (API hashing/mapping used by shells). - Stolen entry point / hollowed PE: process image on disk differs from in-memory image; large gaps or overwritten headers. - Artifacts: suspicious allocations (VirtualAllocEx/WriteProcessMemory sequences in ETW traces), abnormal parent-child relations, unusual fileless persistence keys.

**Detection techniques & tools** - Automated scanning: Volatility3/Plaso/Redline plugins to enumerate mapped modules, detect RWX pages, scan for PE signatures, list suspicious threads. - YARA rules: signatures for reflective loader patterns, known injector stubs, and packed PE in memory. - Correlation: SIEM alerts for process creation events with abnormal memory protections, EDR telemetry (process hollowing ILLEGAL API combos).

**Legal & operational constraints** - Authorization: ensure legal/IR approval before live response; follow corporate incident response policy. - Privacy: minimize exfiltration of user data; filter captures to necessary scope when possible. - Business continuity: balance isolation vs. uptime; use live triage when full shutdown unacceptable. - Chain-of-custody & reproducibility: cryptographic hashes of captures, documented steps, and secure storage for evidence.

**Outcome & follow-up** - Produce indicators (hashes, YARA rules, IOC lists), remediation steps (terminate, patch, hunt for C2), and update detection rules in EDR/SIEM. Continuous tuning based on findings.

Unlock Full Question Bank

Get access to hundreds of Threat Hunting & Proactive Detection interview questions and detailed answers.

Join thousands of developers preparing for their dream job.