Event ID 4688: A new process has been created

Event 4688 comes from the Detailed Tracking audit subcategory, specifically Audit Process Creation, one of the ten subcategories under the Advanced Audit Policy Configuration node (Security Settings > Advanced Audit Policy Configuration > Detailed Tracking). It is not on by default in a stock Windows install. An administrator has to enable Success auditing for Process Creation, either through Group Policy or secpol.msc, before the Security log starts filling with these records.

Once enabled, the event fires for every process the OS creates, from a scheduled task spinning up conhost.exe to a user double-clicking Notepad, which means volume is the first problem any analyst runs into with this event ID. A single domain controller or a busy application server can produce tens of thousands of 4688 events a day, so most SOCs forward this event to a SIEM rather than reading it from Event Viewer directly.

The event lands in the Security channel with source Microsoft-Windows-Security-Auditing, and the schema changed twice as Windows versions progressed. On Windows Server 2008 and Vista the event only carried a bare Subject block. Windows 8.1 and Server 2012 R2 added the Process Command Line field, though it ships empty unless a second, separate policy is turned on: Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events, commonly referenced by its registry-backed name ProcessCreationIncludeCmdLine_Enabled.

Windows 10 renamed the original Subject section to Creator Subject, added a Target Subject block for cases where the process runs under a different account than the one that launched it (a runas or scheduled task scenario), and added the Mandatory Label field showing the integrity level assigned to the new process.

This GPO distinction matters more than most analysts initially assume. Without ProcessCreationIncludeCmdLine_Enabled turned on, 4688 tells you a binary launched, its full path, its PID, and the PID and path of whatever spawned it, but nothing about what arguments were passed to it. An analyst looking at a bare 4688 for powershell.exe has no way to tell if that PowerShell invocation ran a signed internal script or piped a base64-encoded payload through -EncodedCommand.

A SOC running 4688 without command-line capture is effectively running process-creation auditing half blind: it can see the shape of an attack chain (parent spawned child) but not the content of the attack (what the child was told to do). Turning the GPO on is a cheap, high-value change and should be one of the first things a new SOC checks when 4688 shows up in scope.

The fields that carry the actual forensic weight are New Process Name (the full path to the executable that just started), New Process ID (a hex PID, convertible to decimal to cross-reference Task Manager or EDR telemetry), Creator Process Name and Creator Process ID (the parent that spawned the new process), Process Command Line (when the GPO above is enabled), Token Elevation Type, and Mandatory Label.

Token Elevation Type takes one of three values, encoded as %%1936, %%1937, or %%1938 in the raw event, and it tells you how UAC handled the launch. %%1936 (Type 1) is a full, unrestricted token, normal for SYSTEM, service accounts, or the built-in Administrator (which has UAC disabled by default), but worth investigating when it shows up against a regular named user account, since that usually means UAC has been disabled for that account.

%%1937 (Type 2) is an elevated token, meaning the user consented to a UAC prompt or the app was configured to always require admin rights; seeing this on a standard workstation for a user who shouldn't have local admin is a real flag. %%1938 (Type 3) is the common case: a limited, non-elevated token, which is what most day-to-day process creation looks like on a properly locked-down endpoint.

A SOC analyst typically sees 4688 in one of a few realistic contexts. During patch or software deployment, 4688 shows a predictable chain: msiexec.exe or a deployment agent as the parent, spawning setup binaries under SYSTEM or a service account. During normal user activity, explorer.exe is almost always the Creator Process Name, since that's the shell that launches whatever a user double-clicks.

When that chain breaks, when winword.exe or outlook.exe shows up as Creator Process Name for cmd.exe, powershell.exe, wscript.exe, or mshta.exe, that's a parent-child relationship that essentially never happens in benign use and is one of the highest-signal indicators available from this single event.

4688 pairs closely with 4689 (a process has exited), which closes the loop on the same PID, letting an analyst compute dwell time for a process and correlate against other activity that happened while it was running. It also complements 4624/4625 logon events (correlated via Logon ID) to tie a process launch back to the specific interactive or network logon session that triggered it, and 5156 (Windows Filtering Platform connection permitted) to see what a suspicious process actually talked to on the network.

What lights this event up for an attacker is, functionally, every step of execution. Living-off-the-land binaries like certutil.exe (abused to download or decode payloads), rundll32.exe (used to execute arbitrary DLL exports, and shown as the default example process in Microsoft's own event schema), regsvr32.exe, and mshta.exe all generate 4688 the same way a legitimate process would; the event itself doesn't flag maliciousness, the analyst has to infer it from the command line, the parent, and the location the binary ran from.

Fileless and LOLBin-heavy intrusions specifically try to stay inside this normal noise, since spawning a built-in Windows binary from a normal-looking parent draws far less attention than dropping a custom executable that antivirus might catch on disk.

The overwhelming majority of 4688 events in any environment are benign, which is exactly why triage discipline on this event ID matters. Scheduled tasks, software updaters, backup agents, monitoring agents, and print spooler helper processes all generate constant 4688 traffic with SYSTEM or a service account as Creator Subject, running from Program Files or System32, with Token Elevation Type %%1938 or %%1936 depending on the account. None of that needs an analyst's attention on its own; it needs to be baselined once per host role so it can be excluded from active hunting queries.

The judgment call starts with the parent-child pair. Office applications (winword.exe, excel.exe, powerpnt.exe) or Outlook spawning cmd.exe, powershell.exe, wscript.exe, cscript.exe, or mshta.exe is a textbook macro-execution indicator; legitimate business workflows essentially never do this, which is why SigmaHQ ships a dedicated rule (proc_creation_win_office_susp_child_processes) purely for this pattern. The same logic extends to browsers: a browser process spawning a script interpreter usually means a drive-by download or a malicious HTA got clicked through. Contrast that against explorer.exe spawning almost anything, which is the normal, expected chain for interactive user activity and rarely worth a second look by itself.

Command-line content, when the GPO is enabled, is the next layer of judgment. A short, readable PowerShell command line running a known internal script from a signed path is benign. A PowerShell command line carrying -EncodedCommand or -enc followed by a long base64 blob, or one using -WindowStyle Hidden, -NoProfile, and -ExecutionPolicy Bypass together, is a pattern attackers use constantly and legitimate admin scripts rarely combine all at once; unusually long command-line strings are themselves a useful triage signal even before decoding the payload.

The same applies to LOLBins: certutil.exe with -urlcache or -decode switches, rundll32.exe called with a DLL path outside System32 or a function export that isn't a standard Windows API, or regsvr32.exe pointed at a remote scriptlet (the classic Squiblydoo pattern) all separate cleanly from routine admin use once an analyst knows what routine use of those binaries looks like on a given host.

Process location is a third axis. New Process Name pointing into user-writable paths, AppData\Local\Temp, Downloads, ProgramData, or a user's Desktop, is unusual for anything that isn't an installer staging a temp file mid-install. Malware frequently drops and executes from these locations specifically because they don't require elevated permissions to write to, and a legitimate signed application almost never runs its primary binary from Temp on an ongoing basis.

Token Elevation Type adds a final check: %%1937 showing up against a named user account on a workstation that user shouldn't have admin rights on, or %%1936 appearing against an account that isn't a service account or the built-in Administrator, both mean UAC behaved in a way that doesn't match that host's expected posture, and both are worth confirming against the account's actual entitlements rather than assuming misconfiguration.

The practical triage sequence an analyst uses is: check the parent-child pair against known-bad combinations first, since that's the cheapest and highest-signal check; then read the command line (if captured) for obfuscation, encoding, or download/exec syntax; then check the executable's path for anything outside the expected install locations; then check Token Elevation Type against the account's normal privilege level. Any one of these alone can have an innocent explanation. Two or more together, especially an Office parent spawning an encoded PowerShell command line running from a Temp directory, is close to unambiguous and should escalate immediately rather than wait for further corroboration.