suspicious-powershell-hunt_skill

Overview

This skill builds a hypothesis-driven hunt plan for suspicious PowerShell activity that is useful across operating systems and telemetry stacks. It produces prioritized hypotheses, concrete queries, expected true/false positives, and recommended investigation pivots. The goal is fast, repeatable detection and triage using common fields available in most logs.

How this skill works

The skill inspects common telemetry fields such as process name, parent process, command line, user, host, network destination, and timestamps to surface indicators of PowerShell abuse. It generates 3–7 top hypotheses and, for each, supplies query snippets (generic regex/strings and a mapped example for a named stack), expected true positives, common false positives, and next investigation pivots. It emphasizes queries that survive across tool stacks and explains field mapping when a stack-specific example is proposed.

When to use it

• You suspect a downloader or remote execution delivered via PowerShell.
• You are triaging alerts that include EncodedCommand, IEX, FromBase64String, or similar strings.
• You need a structured hunt for post-execution artifacts like downloads, file writes, or persistence created after PowerShell runs.
• You want cross-platform queries that work across endpoint agents, SIEMs, and EDRs.

Best practices

• Limit exposure: avoid copying full scripts; hash script blocks or extract short substrings for sharing.
• Start broad, then narrow: use time windows and parent-process filters to reduce noise before deep pivots.
• Prioritize fields present in most stacks: process, parent process, command line, user, host, network dest, and file write events.
• Document each hypothesis outcome and pivot actions so hunts are reproducible and audit-ready.
• Tune thresholds and whitelist common corporate automation tools (e.g., management scripts) to reduce false positives.

Example use cases

• Hunt for fileless downloader attempts using EncodedCommand and FromBase64String patterns and then pivot to network destinations and DNS queries.
• Investigate Office-initiated PowerShell (winword.exe->powershell) by filtering parent process equals Office binary and examining child network I/O and file writes.
• Detect IEX or Invoke-Expression usage and pivot to command artifact hashing, subsequent scheduled task creation, and persistence locations.
• Search for PowerShell with -ExecutionPolicy Bypass and hidden window flags, then look for spawned suspicious child processes and outbound connections.
• Respond to an alert showing DownloadString by correlating with process network events and newly written files within a short time window.