Script Execution — Detection Telemetry

Collection and providers

Collect PowerShell 4104 with script-block ID and fragment sequence; instrument other engines separately rather than assigning them the same event ID.

• PowerShell Script Block Logging: Script content via event 4104 when configured; channel depends on PowerShell edition.
• Sysmon process events: Interpreter launch and parent context, not full script content.
• Linux Audit: execve-family execution context; shell built-ins need additional instrumentation.

Configuration

• Enable Script Block Logging through the policy/configuration for the installed edition. Forward Microsoft-Windows-PowerShell/Operational for Windows PowerShell, or PowerShellCore/Operational for PowerShell 7.
• Retain script-block ID and fragment ordering alongside process creation. Protect access to collected script text; secrets may be included.
• On Linux, use narrowly scoped Audit execution rules for the lab account and supported architectures, and retain joined SYSCALL/EXECVE/PATH records.

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-PowerShell/Operational'
  Id = 4104
} -MaxEvents 5

Read-only check after Script Block Logging is configured. For PowerShell 7 use its registered PowerShellCore/Operational channel. Missing events are not proof of no execution; check policy, channel and permissions.

Synthetic event example

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0029",
  "collector": "illustrative-lab-collector",
  "observation": {
    "engine": "PowerShell",
    "script_block_id": "lab-script-1",
    "fragment": 1,
    "fragments_total": 1,
    "script_text": "Write-Output \"LAB_TELEMETRY_CHECK\""
  }
}

Visibility and validation

Script content and process command lines are different signals. Logging may be partial, fragmented, filtered or disabled; never assume a command line reveals everything executed.

• Record the lab scope, collector version, effective configuration and expected source fields before testing.
• Use an approved benign action or read-only snapshot appropriate to this type. For destructive, privileged or physical effects, use a reviewed fixture or existing authorized evidence instead of causing the effect.
• Verify the native source record locally and at the collector; compare timestamps, identity, object, action/result and the type-specific fields listed below. Save a redacted real capture separately from the synthetic example.
• Check a normal baseline and collector-loss case. Fixture parsing proves parser behavior only; it does not prove sensor coverage or malicious-behavior detection.

Primary sources

• Microsoft PowerShell logging on Windows
• Microsoft Sysmon events and configuration
• Linux Audit rule configuration