DetectionHunter
back to roadmap
Phase 3·T1620·Advanced

Detecting .NET Reflection Loading in PowerShell

Catch [Reflection.Assembly]::Load and friends used to run in-memory .NET.

#PowerShell#Advanced

Detection Objective

Alert on reflective assembly loading patterns in script blocks.

Real-World Attack Scenario

Loader uses [Reflection.Assembly]::Load([Convert]::FromBase64String($a)) to run an embedded .NET tool.

Why This Detection Matters

Memory-only .NET execution is the modern offensive standard.

ATT&CK Mapping

T1620 · Reflective Code Loading
Tactic: Defense Evasion

Required Telemetry

  • PowerShell4104
Windows Event IDs
4104
Sysmon Event IDs
—
Wazuh Log Source
PowerShell/Operational

Setup Steps

  1. 4104 enabled and forwarded.

Safe Validation Command

Reference the API in a comment for a safe match.
powershell.exe -c "Write-Host 'detection-test: [Reflection.Assembly]::Load reference'"
⚠ lab use only · this project does not execute real malware

Expected Log Output

4104 ScriptBlockText contains '[Reflection.Assembly]::Load'

Detection Logic (Wazuh rule concept)

ScriptBlockText matches /(?i)\[Reflection\.Assembly\]::Load|System\.Reflection\.Assembly|LoadWithPartialName/

False Positives

  • Some sysadmin tooling

Tuning Recommendations

  • Allowlist known internal modules by hash.

Analyst Triage Notes

  • Extract the assembly bytes and analyze offline.

Detection Improvement Ideas

  • Correlate with CLR ETW for actual load events.

log analysis layer

Detection is not complete until the logs prove what happened. The sections below show the telemetry produced by the validation above, how to read it like an analyst, and why this pattern matters.

siem · log evidence
rule 100146
Detecting .NET Reflection Loading in PowerShell
PowerShell/Operational
Event ID
Windows EID 4104
Image
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Parent
C:\Windows\explorer.exe
CommandLine
powershell.exe -c "Write-Host 'detection-test: [Reflection.Assembly]::Load reference'"
User
CORP\j.doe
Agent
WIN10-LAB-01
Timestamp
2026-05-26T14:32:11Z
analyst note
Extract the assembly bytes and analyze offline.

Parent → Child Analysis

explorer.exe → powershell.exe — review whether this lineage is expected for WIN10-LAB-01 and user CORP\j.doe.

Command-Line Flags Observed

  • (no high-risk flags in this test)
    Signal value comes from context (parent, network, persistence) rather than flags.

Parsed Fields the Analyst Reads

  • Image — Process binary that executed — confirms PowerShell.
    C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • ParentImage — Who launched it — context for legitimacy.
    C:\Windows\explorer.exe
  • CommandLine — Arguments — where attacker intent shows up.
    powershell.exe -c "Write-Host 'detection-test: [Reflection.Assembly]::Load reference'"
  • User — Account context — service vs interactive vs SYSTEM.
    CORP\j.doe
  • EventID — Telemetry channel and event type.
    Windows EID 4104
  • Wazuh Rule ID — Rule that matched and produced this alert.
    100146
  • Agent — Endpoint that produced the telemetry.
    WIN10-LAB-01
  • Timestamp — When it happened — anchor for correlation.
    2026-05-26T14:32:11Z

Malicious Pattern

pattern
.NET Reflection Loading in PowerShell
description
Loader uses [Reflection.Assembly]::Load([Convert]::FromBase64String($a)) to run an embedded .NET tool.
analyst takeaway
Memory-only .NET execution is the modern offensive standard. Treat this signal as higher-risk when combined with suspicious parents, hidden windows, download cradles, or unusual user context.

proof the detection worked

test command
powershell.exe -c "Write-Host 'detection-test: [Reflection.Assembly]::Load reference'"
expected event
Windows EID 4104 on WIN10-LAB-01 with Image=powershell.exe and the validation command above in CommandLine.
expected wazuh alert
Wazuh rule 100146 — "Detecting .NET Reflection Loading in PowerShell" fires at a level matching severity=high.
confirming log fields
ImageParentImageCommandLineUserEventID
analyst interpretation
The recorded fields satisfy every clause of the detection logic. Parent process, user context, and command-line arguments together prove the behavior was observed end to end.
conclusion
Detection succeeded: telemetry was captured, the rule matched, and the alert reached the analyst with enough context to triage.