playbooks

home / skills / tsale / awesome-dfir-skills / suspicious-powershell-hunt

suspicious-powershell-hunt skill

/skills/hunting/suspicious-powershell-hunt

This skill helps threat hunters generate a cross-platform PowerShell abuse hunt plan with queries, telemetries, and pivots for rapid investigation.

npx playbooks add skill tsale/awesome-dfir-skills --skill suspicious-powershell-hunt

Review the files below or copy the command above to add this skill to your agents.

Files (1)
skill.md
2.7 KB
---
id: "hunting.suspicious-powershell-hunt"
name: "Suspicious PowerShell hunt (cross-platform ideas)"
description: "Hypothesis-driven hunt plan for suspicious PowerShell, plus query snippets for common telemetry."
version: "0.1.0"
author: "awesome-dfir-skills contributors"
license: "Apache-2.0"
tags: ["powershell", "hunting", "lolbas", "defense-evasion"]
category: "hunting"
platforms: ["windows", "any"]
inputs:
  - name: "telemetry_stack"
    description: "What you want to query (EDR, Sysmon, Windows Event Logs, MDE, Splunk, Sentinel, Elastic)."
    required: true
  - name: "time_window"
    description: "Start/end time and timezone."
    required: true
outputs:
  - name: "hunt_plan"
    description: "Prioritized hypotheses + what to query + what to pivot to next."
  - name: "query_snippets"
    description: "Query fragments (generic + some platform-specific)."
---

# Suspicious PowerShell hunt (cross-platform ideas)

## What this skill does

- Generates a structured hunt plan for PowerShell abuse.
- Focuses on signals that stay useful across tool stacks.

## When to use

- You suspect downloader/execution via PowerShell.
- You’re responding to alerts like “EncodedCommand”, “IEX”, “FromBase64String”.

## Safety / privacy notes

- Don’t paste full script blocks from production unless permitted.
- Prefer hashing script blocks or sharing key substrings.

## Skill instructions

> **Role**: You are a detection engineer / threat hunter.
>
> **Task**: Build a PowerShell abuse hunt plan for the given environment and time window.
>
> **Telem stack**:
> {{telemetry_stack}}
>
> **Time window**:
> {{time_window}}
>
> **Deliverables**:
> 1) **Top hypotheses** (3–7) for PowerShell abuse in this environment
> 2) For each: **what to query**, **expected true positives**, **common false positives**, and **next pivots**
> 3) **Query snippets** (generic string/regex and, if possible, one version for the named stack)
>
> **Constraints**:
> - Prefer fields commonly present: process name, parent process, command line, parent command line, user, host, network dest.
> - If you propose a platform-specific query, explain field mapping.

## Common suspicious patterns (generic)

- `-enc` / `-encodedcommand`
- `IEX` / `Invoke-Expression`
- `FromBase64String`
- `DownloadString` / `DownloadFile`
- Hidden window: `-w hidden`
- Bypass: `-ExecutionPolicy Bypass`
- LOLBIN parents: `winword.exe`, `excel.exe`, `outlook.exe`, `mshta.exe`, `rundll32.exe`, `wscript.exe`, `cscript.exe`

## Pivots

- Process tree around the suspicious PowerShell
- PowerShell downloading things from the internet
- Network connections from that PID (destinations, SNI, URL paths)
- File writes shortly after execution
- Persistence artifacts (scheduled tasks, services, Run keys)

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.

FAQ

What telemetry fields are most important?

Process name, parent process, command line, user, host, network destination, and file write/create events provide the best signal for PowerShell hunts.

How do I reduce false positives from admin automation?

Maintain a whitelist of known automation binaries and runbooks; add contextual filters like expected parent processes, time-of-day, and known service accounts to reduce noise.