Hunting suspicious powershell execution

Skill meltedinhex/analyst-ai-pack/skills/hunting-suspicious-powershell-execution

An open agent-skills library for malware analysis, reverse engineering, and threat hunting - 118 curated, runnable skills mapped to MITRE ATT&CK, D3FEND, and CAR.

Install

npx -y skills add meltedinhex/analyst-ai-pack --skill hunting-suspicious-powershell-execution

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Hunts malicious PowerShell using script-block (EID 4104) and module logging: scoring encoded commands, download cradles, AMSI/logging bypass, and in-memory execution, then decoding payloads for triage. Activates for requests to hunt malicious PowerShell, analyze script-block logs, or detect encoded command abuse.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.2 KB, as published. Nobody here has run it

Hunting Suspicious PowerShell Execution

When to Use

You have PowerShell script-block (Event ID 4104) and/or module logging and want to hunt abuse.
You are testing a hypothesis that attackers use encoded commands, download cradles, or AMSI/logging bypasses.
You need to score and decode a large volume of PowerShell events into a triage queue.

Do not use simple keyword blocklists as the sole method — admins legitimately use many of the same cmdlets; score combinations and decode before judging.

Prerequisites

Script-block logging enabled (Event ID 4104) and exported to a queryable store.
A baseline of normal administrative PowerShell for your environment.

Workflow

Step 1: Collect script-block events

Pull EID 4104 script-block text (and EID 4103 module logging) over the hunt window. Reassemble multi-part script blocks before analysis.

Step 2: Score suspicious constructs

Weight combinations rather than single keywords: -EncodedCommand, IEX/Invoke-Expression with Net.WebClient/Invoke-WebRequest, FromBase64String, -w hidden -nop, AMSI strings, and [Ref].Assembly reflection.

python scripts/analyst.py score events.json

Step 3: Decode payloads

Base64-decode -EncodedCommand (UTF-16LE) and recover layered encodings to read the real intent (download URLs, in-memory loaders).

Step 4: Baseline and pivot

Compare against normal admin activity; for survivors, pull the parent process, user, host, and network connections to confirm.

Step 5: Confirm and operationalize

Validate true positives, escalate to IR, and convert the scoring logic into a detection rule.

Validation

High-score events decode to coherent malicious intent, not benign admin scripts.
Multi-part script blocks are reassembled before scoring (no truncated false negatives).
Confirmed cases tie to a parent process and user consistent with intrusion.

Pitfalls

Flagging single keywords (IEX alone) and drowning in admin noise.
Forgetting -EncodedCommand is UTF-16LE, producing garbled decodes.
Ignoring AMSI/logging-bypass attempts that precede the real payload.

References

See references/api-reference.md for the scorer/decoder.
Script-block logging docs and ATT&CK T1059.001 (linked in frontmatter).