--- analysis: A single rule on WMI execution or proxy DNS queries often generates high noise from administrative tools or browser extensions. This hunt uses a funnel flow to combine these signals, utilizing an agent to confirm the relationship between the execution lineage and the networking behavior before a decision is reached. blind_spots: - id: no-dns-process-correlation question: Which process initiated the proxy DNS query? requires: process context in hb_dns_activity risk: If the DNS source does not attribute queries to a PID, correlating the C2 traffic to the WMI-spawned shell requires manual alignment of timestamps. stage: command-and-control-proxy - id: dns-over-https-bypass question: Are proxy domains being resolved via DoH? requires: TLS inspection or endpoint DoH monitoring risk: Standard DNS logging cannot see proxy resolutions performed over encrypted HTTPS tunnels, leaving a gap in the network-side evidence. stage: command-and-control-proxy coverage: - stage: lateral-movement-wmi status: covered steps: - identify-windows-hosts - wmi-activity-search - stage: command-and-control-proxy status: covered steps: - proxy-dns-search guardrails: claims: no_unsupported evidence: citation_required missing_data: not_benign telemetry: untrusted hunt: applicability: campaign-specific handoff: promote-to-detection justification: WMI lateral movement is a core technique for internal propagation, and multi-hop proxies are used to bypass perimeter C2 blocks. Coordinating these independent signals across process and network surfaces provides a high-confidence indicator of an active intruder. methodology: model-assisted trigger: intel-report hypothesis: An intruder has moved laterally using WMI to execute code on internal Windows hosts and is maintaining command-and-control through multi-hop proxies or Tor to obfuscate traffic. labels: - hunt - attack.t1047 - attack.t1090.003 name: WMI Lateral Movement and Proxy-based C2 parameters: lookback_days: default: '14' description: Days of history to examine. from: kind: manual observed: '2025-01-01' ref: default-retention type: number proxy_indicators: default: - hiddenservice.net - onion.link - onion.cab - onion.casa description: Known domains associated with Tor or multi-hop proxy infrastructure. from: kind: article observed: '2026-07-31' ref: elastic-security-labs-agentic-soc type: list[domain] scope_hosts: default: [] description: Optional list of hosts to narrow the behavioral queries; empty checks all Windows hosts. from: kind: manual observed: '2025-01-01' ref: analyst-input type: list[host] suspicious_wmi_apps: default: - cmd.exe - powershell.exe - pwsh.exe - scrcons.exe - cscript.exe - wscript.exe description: Standard shells or script engines often used by attackers via WMI. from: kind: article observed: '2026-07-31' ref: elastic-security-labs-agentic-soc type: list[string] provenance: authors: - name: Huntbase hunt generation org: huntbase.io generated: by: huntbase-hunt-generation from: https://www.elastic.co/security-labs/blog/agentic-soc-alert-triage-alertzero gates: - dry-run - lint model: hb_google/gemini-3-flash-preview rationale: The hunt scopes every Windows host because WMI lateral movement can target any system with RPC or WinRM enabled. The behavioral queries focus on the WMI provider (wmiprvse.exe), which is the standard host for remote-triggered execution. references: - name: 'Alert Zero: AI-driven alert triage and attack investigation for the agentic SOC' url: https://www.elastic.co/security-labs/blog/agentic-soc-alert-triage-alertzero related: - hunt: wmi-event-consumer-persistence reason: WMI event consumers represent a related persistence technique that uses the same infrastructure as this lateral movement hunt. relation: sibling scenario: stages: - name: Lateral Movement via WMI observables: - wmic.exe - wmiprvse.exe - Process creation with parent wmiprvse.exe - Network connections on port 135, 5985, or 5986 slug: lateral-movement-wmi tactic: execution techniques: - T1047 - name: Multi-hop Proxy Command and Control observables: - DNS queries for .onion domains - DNS queries for hiddenservice.net - Traffic to known Tor entry/exit nodes - Chained proxy connection attempts slug: command-and-control-proxy tactic: command-and-control techniques: - T1090.003 summary: This report details the implementation of AI-driven alert triage and attack investigation within a security operations center. It uses a scenario where an attacker leverages Windows Management Instrumentation (WMI) for lateral movement and multi-hop proxies for command and control to illustrate how automated agents can correlate disparate alerts into a single attack narrative. severity: medium targets: analyst: name: Tier-2 analyst role: analyst endpoint: category: endpoint name: Endpoint telemetry (hb_ surfaces) telemetry: - endpoint hunter: agent: true name: Hunt agent tlp: clear type: investigation --- # WMI Lateral Movement and Proxy-based C2 This hunt identifies the dual behavior of internal lateral movement via Windows Management Instrumentation (WMI) and external command-and-control (C2) obfuscation via multi-hop proxies. It begins by scoping the environment for Windows-based systems that could be targets of WMI execution. A fan-out investigation then searches for suspicious child processes of the legitimate WMI provider (wmiprvse.exe) while simultaneously identifying DNS resolutions for known proxy and Tor infrastructure. An agent weighs these signals together to identify the complete attack chain described in the Alert Zero research, specifically looking for process-level relationships between WMI execution and proxy networking. ## identify-windows-hosts Identify every Windows system reporting inventory to focus the lateral movement search. ```sqlite target=endpoint role=scoping params=(lookback_days=lookback_days) ~~~yaml expected: A list of hostnames. Silence indicates no Windows systems are reporting in the window. reads: - hostname - platform - time silence: not_evidence_of_absence source: hb_devices verified: dry-run verified_at: '2026-09-20' ~~~ SELECT DISTINCT hostname AS device_hostname FROM hb_devices WHERE LOWER(platform) = 'windows' AND time >= datetime('now', '-{{lookback_days}} days') ``` ## parallel-behavior-hunt parallel: - → wmi-activity-search - → proxy-dns-search join: → triage-findings ## wmi-activity-search Identify instances where the WMI provider process (wmiprvse.exe) spawns shells, scripts, or binaries from non-system paths. ```sqlite target=endpoint role=detection-candidate params=(lookback_days=lookback_days, suspicious_wmi_apps=suspicious_wmi_apps, scope_hosts=scope_hosts) ~~~yaml expected: Processes spawned by WMI. Legitimate administrative tools may appear; rarity and command context are the primary signals. reads: - device_hostname - process_name - process_cmd_line - parent_process_name - pid - user_name - time - process_path silence: not_evidence_of_absence source: hb_process_activity verified: dry-run verified_at: '2026-09-20' ~~~ SELECT device_hostname, process_name, process_cmd_line, parent_process_name, pid, user_name, time FROM hb_process_activity WHERE LOWER(parent_process_name) LIKE '%\\wmiprvse.exe' AND (instr(',' || '{{suspicious_wmi_apps}}' || ',', ',' || LOWER(process_name) || ',') > 0 OR LOWER(process_path) NOT LIKE 'c:\\windows\\system32\\%') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') ``` ## proxy-dns-search Find DNS resolutions for .onion domains or known proxy gateways and stack-count them to isolate rare outliers. ```sqlite target=endpoint role=baseline params=(lookback_days=lookback_days, proxy_indicators=proxy_indicators, scope_hosts=scope_hosts) ~~~yaml baseline: compare: first_seen window: '{{lookback_days}}d' expected: DNS queries to proxy domains. Any hit on a host that also shows suspicious WMI activity is the primary indicator of the attack chain. prevalence: by: device_hostname key: - query_hostname rare_below: 3 reads: - device_hostname - query_hostname - process_name - pid - time silence: not_evidence_of_absence source: hb_dns_activity verified: dry-run verified_at: '2026-09-20' ~~~ SELECT query_hostname, device_hostname, process_name, pid, COUNT(*) as query_count, MIN(time) as first_seen FROM hb_dns_activity WHERE (query_hostname LIKE '%.onion' OR query_hostname LIKE '%.hiddenservice.net' OR instr(',' || '{{proxy_indicators}}' || ',', ',' || LOWER(query_hostname) || ',') > 0) AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY query_hostname, device_hostname, process_name, pid ``` ## triage-findings ```agent target=hunter cite: required context: - wmi-activity-search - proxy-dns-search max_iterations: 4 objective: Correlate the process identity (PID or process name) from the DNS findings with the WMI child process tree to determine if the same lineage or user context is performing both lateral movement and external C2. success_criteria: A verdict of malicious | suspicious | benign per host, citing matching PIDs or process names. tools: - endpoint ``` ## verdict-decision if~: "the triage verdict is malicious for at least one host involving suspicious WMI execution and proxy DNS activity" (confidence: high, judge=hunter) then: → isolate-host indeterminate: → analyst-review unavailable: → analyst-review (blind_spot: no-dns-process-correlation) else: → close-out-task ## isolate-host ```action target=endpoint ~~~yaml approval: required ~~~ Isolate the host identified as malicious and terminate the PIDs associated with the suspicious WMI activity and proxy connections. ``` → analyst-review ## analyst-review ```manual target=analyst Review the cited rows from the triage step. Pivot to hb_network_connection to identify the source IP address that initiated the RPC (port 135) or WinRM (5985/5986) connection to the target host to find the upstream beachhead. ``` → close-out-task ## close-out-task ```manual target=analyst Document whether the activity represented a true positive intrusion. If the activity was legitimate administrative WMI use, record the specific process command lines to tune the detection candidate. ``` → end