8.2 Threat Hunting Techniques with PowerShell and Scripting

Threat Hunting Techniques with PowerShell and Scripting

Effective threat hunting requires transitioning from abstract conceptual frameworks to programmatic interrogation of endpoint and network telemetry. In Windows enterprise environments, PowerShell represents both an adversary's preferred post-exploitation tool and a threat hunter's most powerful native investigative utility. By mastering native PowerShell cmdlets, Common Information Model (CIM) queries, high-performance event log filtering, and data science scripting in Python, SOC analysts can rapidly uncover stealthy footholds, persistence mechanisms, and lateral movement across thousands of endpoints.

---

Threat Hunting Telemetry: Host vs. Network Requirements

A comprehensive threat hunting campaign requires balancing two distinct telemetry domains: host-level telemetry and network-level telemetry. Each provides unique visibility into different phases of the MITRE ATT&CK matrix.

Host Telemetry

Host telemetry captures the internal operational state of endpoints, hypervisors, and servers. Because modern attackers frequently encrypt network communications (via TLS 1.3 or proprietary obfuscation), host-level visibility is essential for inspecting process execution, memory allocation, and operating system API calls prior to encryption.

• Process Execution Tracking: Process creation events containing full command-line arguments, parent process names, execution directory, user security identifiers (SIDs), and cryptographic hashes (SHA-256). Captured via Sysmon Event ID 1 or Windows Security Event ID 4688 (with command-line process auditing enabled via Group Policy).
• Process Network Connections: Correlating network sockets with the specific process ID (PID) and executable image that initiated the connection. Captured via Sysmon Event ID 3.
• Module and DLL Loading: Identifying dynamic link libraries loaded into process memory spaces to detect DLL sideloading and DLL search order hijacking. Captured via Sysmon Event ID 7.
• Persistence Stores: Monitoring registry modifications (Sysmon IDs 12, 13, 14), file creation in startup folders (Sysmon ID 11), scheduled task registrations (Security Event ID 4698 / TaskScheduler Operational ID 106), and WMI event consumer bindings (Sysmon IDs 19, 20, 21).
• Authentication and Privilege Escalation: Tracking interactive, network, and service logons via Security Event ID 4624 (specifically Logon Types 2, 3, 9, and 10), explicit credential delegations (Event ID 4648), and special privilege assignments (Event ID 4672).

Network Telemetry

Network telemetry captures communications visible to sensors across internal subnets, boundaries, and egress points. Out-of-band sensors can retain observations when an endpoint agent is impaired, but only for traffic that crosses the monitored path and survives sampling, encryption, packet loss, filtering, and retention.

• Network Flow Data (NetFlow v9 / IPFIX): High-level session metadata providing IP 5-tuples (Source IP, Destination IP, Source Port, Destination Port, Protocol), packet counts, byte volumes, and flow duration. Ideal for identifying large-scale data exfiltration and beaconing cadence.
• Protocol-Aware Transaction Logs (Zeek / Bro): Deep protocol inspection yielding structured logs such as dns.log (query domains, record types, response codes, TTLs), http.log (URIs, user-agent headers, response sizes), ssl.log (SNI hostnames, TLS cipher suites, certificate subjects, JA3/JA4 fingerprint hashes), and conn.log.
• Perimeter and Proxy Telemetry: Egress firewall logs, web proxy authentication records, and VPN connection logs tracking external IP origins and geographic coordinates.

Host vs. Network Telemetry Comparison

---

Frequency Analysis & Stack Counting (Least Frequency of Occurrence - LFO)

The fundamental challenge of threat hunting is data volume. In an enterprise of 10,000 workstations, standard operational tasks occur millions of times every day. Sophisticated adversaries understand this and attempt to blend their activities into normal system noise. Stack Counting, also known as Frequency Analysis or Least Frequency of Occurrence (LFO), is the mathematical technique used by threat hunters to filter out the noise and expose hidden threats.

The Mathematical Principle of LFO

Stack counting relies on an inverse probability distribution: legitimate system operations and standardized administrative management tools occur with high frequency across an enterprise fleet. In contrast, tailored adversary attacks, custom staging scripts, unique backdoor binaries, and novel persistence mechanisms appear with extremely low frequency—often on only a single host or across two endpoints in the entire enterprise.

To execute LFO, a hunter selects a combination of key attributes (e.g., ProcessName + ParentProcess + CommandLine + SHA256), groups the fleet-wide telemetry by these attributes, counts the total occurrences across all endpoints, and sorts the results in ascending order (lowest count first). The items residing at the absolute bottom of the stack—the 1-of-10,000 occurrences—represent high-priority candidates for human investigation.

Worked Stack Counting / LFO Numerical Example

Consider a threat hunt across 10,000 Windows workstations analyzing process execution telemetry over a 7-day window. Fleet-wide data is stacked by Process Name, Parent Process, and Command Line Arguments:

Rare-event ranking helps surface unusual parent-child relationships for investigation, but rarity alone is not maliciousness. The cutoff should be tuned to the environment, and analysts must validate signer, path, account, asset role, prevalence history, and surrounding behavior.

---

Hunting with PowerShell on Windows: WMI/CIM, Sockets, and Event Logs

PowerShell provides deep, agentless inspection capabilities across Windows operating systems. To hunt effectively, analysts must master three core primitives: querying the Common Information Model (CIM), inspecting active network sockets, and executing high-performance event log searches.

Querying WMI/CIM via Get-CimInstance

While legacy administration relied on Get-WmiObject, modern threat hunting utilizes Get-CimInstance. Get-CimInstance communicates over WS-Management (WS-Man / WinRM) on ports 5985/5986 (HTTP/HTTPS), bypassing restrictive DCOM/RPC firewall barriers and providing faster binary object serialization.

# Inspect all running processes with their Process ID, Parent PID, and full Command Line
Get-CimInstance -ClassName Win32_Process | 
    Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine | 
    Format-Table -AutoSize

# Audit all installed services executing out of non-standard directories using path wildcards
Get-CimInstance -ClassName Win32_Service | 
    Where-Object { $_.PathName -notlike "C:\Windows\System32*" -and $_.PathName -notlike "C:\Program Files*" } | 
    Select-Object Name, DisplayName, State, StartMode, PathName

Inspecting Network Sockets via Get-NetTCPConnection

Adversaries maintaining interactive command-and-control (C2) channels leave active TCP sockets. Hunters can query the network stack directly and correlate socket owners with the underlying process:

# Query active established TCP connections and correlate with Process Image Names
Get-NetTCPConnection -State Established | 
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess, @{
        Name = "ProcessName"
        Expression = { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).Name }
    }, @{
        Name = "Path"
        Expression = { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).Path }
    } | Format-Table -AutoSize

High-Performance Event Log Querying: Get-WinEvent XML XPath Filtering

A common operational pitfall in SOC threat hunting is retrieving event logs using client-side pipeline filtering: Get-WinEvent -LogName Security | Where-Object { $_.Id -eq 4688 }. This approach forces Windows to deserialize hundreds of thousands of events from disk into PowerShell memory before filtering, causing severe memory bloat, high CPU utilization, and query runtimes exceeding hours.

To reduce client-side work across large event sets, hunters should use supported source-side filtering through -FilterXPath or -FilterHashtable where practical. The Windows Event Log service applies supported criteria before PowerShell materializes returned event objects; speed still depends on source, indexing, selectivity, transport, and resources:

# High-Performance XPath Filter for Process Creation (Event ID 4688) targeting LOLBins
$XPathFilter = @"
*[System[(EventID=4688) and TimeCreated[timediff(@SystemTime) <= 604800000]]]
and
*[EventData[
    Data[@Name='NewProcessName'] and (
        contains(Data[@Name='NewProcessName'], 'powershell.exe') or 
        contains(Data[@Name='NewProcessName'], 'certutil.exe') or 
        contains(Data[@Name='NewProcessName'], 'mshta.exe') or 
        contains(Data[@Name='NewProcessName'], 'rundll32.exe')
    )
]]
"@

Get-WinEvent -LogName Security -FilterXPath $XPathFilter | ForEach-Object {
    $xml = [xml]$_.ToXml()
    [PSCustomObject]@{
        TimeCreated    = $_.TimeCreated
        ComputerName   = $_.MachineName
        ProcessName    = $xml.Event.EventData.Data | Where-Object { $_.Name -eq 'NewProcessName' } | Select-Object -ExpandProperty '#text'
        CommandLine    = $xml.Event.EventData.Data | Where-Object { $_.Name -eq 'CommandLine' } | Select-Object -ExpandProperty '#text'
        ParentProcess  = $xml.Event.EventData.Data | Where-Object { $_.Name -eq 'ParentProcessName' } | Select-Object -ExpandProperty '#text'
        AccountName    = $xml.Event.EventData.Data | Where-Object { $_.Name -eq 'SubjectUserName' } | Select-Object -ExpandProperty '#text'
    }
} | Format-Table -AutoSize

---

Comprehensive PowerShell Threat Hunting Cmdlets Reference

---

Production-Ready PowerShell Hunting Scripts

Threat hunters deploy specialized, production-ready hunting scripts to interrogate endpoints for specific adversary tradecraft.

Script 1: Detecting Anomalous Process Parentage

Adversaries exploiting document macros, web servers, or print spoolers force benign parent processes to spawn command shells. This script scans running processes and identifies high-risk parent-child anomalies:

<#
.SYNOPSIS
    Hunts for anomalous parent-child process relationships across running processes.
.DESCRIPTION
    Identifies office applications, web servers, and spooler services spawning command shells.
#>
$AnomalousPairs = @(
    @{ Parent = "winword.exe";  Children = @("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe") },
    @{ Parent = "excel.exe";    Children = @("cmd.exe", "powershell.exe", "mshta.exe", "certutil.exe") },
    @{ Parent = "w3wp.exe";     Children = @("cmd.exe", "powershell.exe", "whoami.exe", "net.exe") },
    @{ Parent = "spoolsv.exe";  Children = @("cmd.exe", "powershell.exe", "rundll32.exe") },
    @{ Parent = "sqlservr.exe"; Children = @("cmd.exe", "powershell.exe", "bitsadmin.exe") }
)

$AllProcesses = Get-CimInstance -ClassName Win32_Process
$ProcessLookup = @{}
$AllProcesses | ForEach-Object { $ProcessLookup[$_.ProcessId] = $_ }

$Findings = foreach ($proc in $AllProcesses) {
    if ($ProcessLookup.ContainsKey($proc.ParentProcessId)) {
        $parent = $ProcessLookup[$proc.ParentProcessId]
        $parentName = $parent.Name.ToLower()
        $childName = $proc.Name.ToLower()

        foreach ($rule in $AnomalousPairs) {
            if ($parentName -eq $rule.Parent -and $rule.Children -contains $childName) {
                [PSCustomObject]@{
                    AnomalyType       = "Suspicious Parent-Child Process"
                    ParentProcessName = $parent.Name
                    ParentPID         = $parent.ProcessId
                    ParentPath        = $parent.ExecutablePath
                    ChildProcessName  = $proc.Name
                    ChildPID          = $proc.ProcessId
                    ChildCommandLine  = $proc.CommandLine
                    CreationDate      = $proc.CreationDate
                }
            }
        }
    }
}

$Findings | Format-List

Script 2: Hunting for C2 Network Beaconing Connections

Threat actors establish outbound C2 connections to external IP addresses on non-standard ports. This script inspects active sockets, excludes private RFC 1918 subnets, and identifies external connections initiated by suspicious LOLBins:

<#
.SYNOPSIS
    Hunts for active outbound network connections initiated by native Windows utilities.
#>
$SuspiciousBinaries = @("powershell", "cmd", "rundll32", "regsvr32", "certutil", "mshta", "bitsadmin", "cscript", "wscript")
$PrivatePrefixes = @("10.", "172.16.", "172.17.", "172.18.", "172.19.", "172.20.", "172.21.", "172.22.", "172.23.", "172.24.", "172.25.", "172.26.", "172.27.", "172.28.", "172.29.", "172.30.", "172.31.", "192.168.", "127.", "169.254.")

Get-NetTCPConnection -State Established | ForEach-Object {
    $socket = $_
    $remoteIP = $socket.RemoteAddress
    
    # Check if destination IP is private
    $isPrivate = $false
    foreach ($prefix in $PrivatePrefixes) {
        if ($remoteIP.StartsWith($prefix)) { $isPrivate = $true; break }
    }

    if (-not $isPrivate -and $remoteIP -ne "::1") {
        $proc = Get-Process -Id $socket.OwningProcess -ErrorAction SilentlyContinue
        if ($proc -and ($SuspiciousBinaries -contains $proc.Name.ToLower())) {
            [PSCustomObject]@{
                Timestamp        = (Get-Date).ToString("yyyy-MM-dd HH:mm:ss")
                ProcessName      = $proc.Name
                PID              = $proc.Id
                ProcessPath      = $proc.Path
                LocalSocket      = "$($socket.LocalAddress):$($socket.LocalPort)"
                RemoteSocket     = "$($socket.RemoteAddress):$($socket.RemotePort)"
                NonStandardPort  = ($socket.RemotePort -notin @(80, 443, 8080, 8443))
            }
        }
    }
} | Format-Table -AutoSize

Script 3: Autorun, Scheduled Task, and WMI Persistence Hunter

Adversaries establish persistence across system reboots via registry Run keys, scheduled tasks, and WMI event subscriptions. This script audits all three persistence vectors simultaneously:

<#
.SYNOPSIS
    Comprehensive persistence hunter auditing Registry Run keys, Scheduled Tasks, and WMI Subscriptions.
#>
Write-Host "[+] Auditing Registry Run / RunOnce Keys..." -ForegroundColor Cyan
$RegPaths = @(
    "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run",
    "HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce",
    "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run",
    "HKCU:\Software\Microsoft\Windows\CurrentVersion\RunOnce"
)

foreach ($path in $RegPaths) {
    if (Test-Path $path) {
        $key = Get-ItemProperty -Path $path
        $key.PSObject.Properties | Where-Object { $_.Name -notmatch "^PS" } | ForEach-Object {
            if ($_.Value -match "powershell|cmd|AppData|Temp|Public|rundll32|wscript") {
                [PSCustomObject]@{
                    Vector      = "Registry Run Key"
                    Location    = $path
                    Name        = $_.Name
                    Payload     = $_.Value
                    Suspicious  = $true
                }
            }
        }
    }
}

Write-Host "[+] Auditing Non-Standard Scheduled Tasks..." -ForegroundColor Cyan
Get-ScheduledTask | Where-Object { $_.State -ne "Disabled" } | ForEach-Object {
    $task = $_
    $action = $task.Actions | Select-Object -First 1
    if ($action.Execute -match "powershell|cmd|mshta|cscript|wscript" -or 
        $action.Arguments -match "AppData|Temp|Public|-enc|-w hidden") {
        [PSCustomObject]@{
            Vector      = "Scheduled Task"
            Location    = $task.TaskPath
            Name        = $task.TaskName
            Payload     = "$($action.Execute) $($action.Arguments)"
            Suspicious  = $true
        }
    }
}

Write-Host "[+] Auditing Permanent WMI Event Subscriptions..." -ForegroundColor Cyan
$Consumers = Get-CimInstance -Namespace "root\subscription" -ClassName CommandLineEventConsumer -ErrorAction SilentlyContinue
$Filters   = Get-CimInstance -Namespace "root\subscription" -ClassName __EventFilter -ErrorAction SilentlyContinue
$Bindings  = Get-CimInstance -Namespace "root\subscription" -ClassName __FilterToConsumerBinding -ErrorAction SilentlyContinue

if ($Bindings) {
    foreach ($binding in $Bindings) {
        [PSCustomObject]@{
            Vector      = "WMI Persistence"
            Location    = "root\subscription"
            Name        = $binding.Consumer
            Payload     = $binding.Filter
            Suspicious  = $true
        }
    }
}

---

Hunting for Lateral Movement: Named Pipes, Admin Shares, and Remote Services

Once an adversary establishes an initial foothold, they propagate across the internal network to compromise secondary systems. Hunters focus on three primary Windows lateral movement mechanisms:

Named Pipes Inspection

Named pipes provide inter-process communication (IPC) locally and across SMB (port 445). Attack frameworks like Cobalt Strike, Metasploit, and Empire utilize named pipes for pivot listeners, lateral execution, and token impersonation.

• Default Cobalt Strike Pipes: Default configurations frequently generate distinct pipe naming structures, such as \pipe\msagent_*, \pipe\status_*, \pipe\mypipe_*, or randomized GUID formats like \pipe\mojo.5688.8033.34892485.
• Auditing Named Pipes: Threat hunters inspect named pipes using Sysmon Event ID 17 (Pipe Created) and Sysmon Event ID 18 (Pipe Connected). A rare named pipe created by a non-system binary in C:\Users\Public\ or C:\ProgramData\ indicates active lateral pivot communication.

Administrative Shares (ADMIN$, C$, IPC$)

Adversaries map network drives and stage payloads across administrative shares:

• Detection Telemetry: Windows Security Event ID 5140 (A network share object was accessed) and Event ID 5145 (A network share object was checked to see whether client can be granted desired access).
• Hunting Logic: Stack network share accesses by client IP address, target share name (ADMIN$, C$), and accessed relative target name (RelativeTargetName: *.exe, *.dll, *.bat). Legitimate users rarely access ADMIN$ directly.

Remote Service Installation

Tools such as PsExec, Cobalt Strike's jump psexec, and native administrative tools stage an executable on ADMIN$ and subsequently interact with the Service Control Manager (SCM) via RPC over SMB to create a remote service:

• Detection Telemetry: Windows System Event ID 7045 (A new service was installed in the system) and Security Event ID 4697.
• PsExec Artifacts: Default PsExec installs a service named PSEXESVC with binary path %SystemRoot%\PSEXESVC.exe. Threat actors frequently rename the service to mimic legitimate drivers (e.g., WindowsDefenderUpdateSvc) but execute out of C:\Windows\Temp\ under the NT AUTHORITY\SYSTEM account.

---

Python and Jupyter Notebooks for SOC Threat Hunting

When dataset sizes exceed the memory handling limits of PowerShell or when complex statistical distributions must be evaluated, threat hunters leverage Python within Jupyter Notebooks. Python provides access to the pandas library for high-speed data manipulation and matplotlib/seaborn for mathematical visualization.

Hunting Network Beaconing with pandas

Network beaconing is characterized by automated, programmatic callbacks initiated by an agent to a C2 listener at regular intervals (e.g., every 60 seconds). While attackers introduce jitter (randomized variation, such as +/- 20%) to defeat naive threshold alerts, statistical analysis reveals the underlying cadence.

In a Jupyter Notebook, a hunter loads 1,000,000 firewall/proxy connection records and computes the inter-arrival time (Delta T) between consecutive connections to identical destination IP addresses:

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
import seaborn as sns

# Load connection telemetry
df = pd.read_csv('proxy_connections.csv')
df['timestamp'] = pd.to_datetime(df['timestamp'])

# Filter for outbound external connections and sort temporally
df = df.sort_values(by=['source_ip', 'dest_ip', 'timestamp'])

# Calculate inter-arrival time (Delta T) in seconds between successive callbacks
df['delta_t'] = df.groupby(['source_ip', 'dest_ip'])['timestamp'].diff().dt.total_seconds()

# Compute statistical metrics per destination: Count, Mean Delta T, and Standard Deviation (Jitter)
beacon_stats = df.groupby(['source_ip', 'dest_ip']).agg(
    connection_count=('delta_t', 'count'),
    mean_interval=('delta_t', 'mean'),
    std_dev=('delta_t', 'std'),
    median_interval=('delta_t', 'median')
).reset_index()

# Identify beaconing candidates: High connection count and low coefficient of variation (std_dev / mean)
beacon_stats['cv'] = beacon_stats['std_dev'] / beacon_stats['mean_interval']
beacon_candidates = beacon_stats[
    (beacon_stats['connection_count'] > 100) & 
    (beacon_stats['cv'] < 0.25)
].sort_values(by='cv', ascending=True)

print(beacon_candidates.head(10))

# Visualize Delta T distribution for top beaconing suspect
top_suspect = beacon_candidates.iloc[0]
suspect_data = df[
    (df['source_ip'] == top_suspect['source_ip']) & 
    (df['dest_ip'] == top_suspect['dest_ip'])
]

plt.figure(figsize=(10, 4))
sns.histplot(suspect_data['delta_t'].dropna(), bins=50, kde=True, color='crimson')
plt.title(f"C2 Beaconing Heartbeat Analysis: {top_suspect['source_ip']} -> {top_suspect['dest_ip']}")
plt.xlabel("Inter-Arrival Time (Seconds)")
plt.ylabel("Connection Frequency")
plt.grid(True, linestyle='--', alpha=0.6)
plt.show()

If the histogram displays a sharp, concentrated Gaussian peak centered around 60 seconds (even with jitter distributed between 48 and 72 seconds), the analyst has statistically proven the presence of an automated C2 beacon rather than human web browsing.