Command Execution — Detection Telemetry

Collection and providers

Collect process command lines and relevant shell/interpreter audit; shell history alone is neither complete nor tamper-resistant.

• 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.

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": "DC0064",
  "collector": "illustrative-lab-collector",
  "observation": {
    "interpreter": "/bin/sh",
    "command_line": "printf LAB_TELEMETRY_CHECK",
    "actor_uid": 1000,
    "session_id": "lab-session-1"
  }
}

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