HackBlue

Tools · Windows security and Event Logs · 03 / 27

Windows Event ID 4688: enable process creation logging with command lines

Turn on process creation auditing and command-line capture, read parent and child process fields, and spot suspicious command lines.

10 min read · practice only with authorization

Two settings, not one

Event 4688 “A new process has been created” requires the Audit Process Creation subcategory under Detailed Tracking. By default it does not include the command line. A second Group Policy setting, “Include command line in process creation events” under Administrative Templates, System, Audit Process Creation, adds it.

Without the command line you know powershell.exe ran. With it you know what it ran, which is the difference between a useless and a useful event.

Snippet
auditpol /set /subcategory:"Process Creation" /success:enable
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
auditpol /get /subcategory:"Process Creation"

Fields to read

New Process Name is the full path of the executable. Process Command Line is the arguments. Creator Process Name is the parent. Token Elevation Type shows whether it ran elevated: %%1936 full token (elevated or UAC off), %%1937 elevated, %%1938 limited. Subject shows the account.

Parent-child relationships are the strongest signal. winword.exe starting powershell.exe, or w3wp.exe (IIS) starting cmd.exe, should not happen in normal work.

Lab: capture and filter

Enable both settings on a lab VM. Open a command prompt and run whoami /all, then start PowerShell with an encoded command that just writes “hello”. Query 4688 and print parent, child, and command line. Find the encoded command and decode it.

Then count child processes by parent for the last day to see what normal looks like on that machine.

Snippet
$cmd = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes('Write-Output hello'))
powershell -NoProfile -EncodedCommand $cmd

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddMinutes(-30)} |
  % { $x=[xml]$_.ToXml(); $d=@{}; $x.Event.EventData.Data | % { $d[$_.Name]=$_.'#text' }
      [pscustomobject]@{Parent=$d.ParentProcessName; Child=$d.NewProcessName; Cmd=$d.CommandLine} } |
  Where-Object Cmd -match 'EncodedCommand|whoami' | Format-List

Command lines worth alerting on

PowerShell with -EncodedCommand or -enc, especially from Office or a browser. certutil with -urlcache or -decode. rundll32 or regsvr32 loading from a URL or from a user-writable path. vssadmin delete shadows or wmic shadowcopy delete, often run just before ransomware encrypts files. bcdedit changing recovery settings.

Sysmon Event ID 1 records similar data with hashes and more context. Many teams run both; 4688 is the built-in baseline.

Diagram

A suspicious 4688 event

Parent, child, and command line together.

Security4688

Event 4688

Creator Process Name: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
New Process Name:     C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Process Command Line: powershell -nop -w hidden -enc SQBFAFgAIAAoA...
  • Word should not start PowerShell in normal use.
  • Hidden window and an encoded command hide intent.
  • Decode the base64 (UTF-16LE) to read it, then scope the host.

Check yourself

1. 4688 events show no command line. What is missing?

2. Which field gives the parent process?

3. Which command line is most commonly seen right before ransomware encryption?