Worked Example: Detecting whoami Recon Across 4688, Sysmon 1, and ETW

Putting it all together: here’s a real recon scenario — an adversary runs whoami and whoami /all after initial access via a web shell. We’ll analyze what appears in each telemetry source, why the differences matter, and how to write detections that actually fire.

Scenario: An adversary exploits a vulnerable web application running on IIS (w3wp.exe) and drops a web shell. They then run:

whoami
whoami /all
systeminfo
net localgroup administrators

Source 1: Windows Security Event 4688

With the default audit policy (process creation enabled, command line auditing OFF):

<EventData>
  <Data Name="NewProcessId">0x2f8c</Data>
  <Data Name="NewProcessName">C:\Windows\System32\whoami.exe</Data>
  <Data Name="TokenElevationType">%%1938</Data>
  <Data Name="ProcessId">0x4a3c</Data>
  <Data Name="CommandLine"></Data>  <!-- EMPTY without command line auditing -->
  <Data Name="ParentProcessName">C:\Windows\System32\cmd.exe</Data>
</EventData>

You can see whoami.exe ran. Parent is cmd.exe. But:

No command line — you can’t see /all flag
No file hash — can’t verify this is the real whoami.exe
Parent chain stops at cmd.exe — you can’t see that cmd.exe was spawned by w3wp.exe (that requires another 4688 for cmd.exe itself)

With command line auditing ON:

<Data Name="CommandLine">whoami /all</Data>

Now you see the flag. Still no hash, still need to manually chain parent-child events.

Source 2: Sysmon Event ID 1

<EventData>
  <Data Name="UtcTime">2024-03-15 09:23:14.882</Data>
  <Data Name="ProcessGuid">{abc-001}</Data>
  <Data Name="Image">C:\Windows\System32\whoami.exe</Data>
  <Data Name="CommandLine">whoami /all</Data>
  <Data Name="Hashes">MD5=...,SHA256=6D8EE7D8...,IMPHASH=...</Data>
  <Data Name="ParentProcessGuid">{abc-000}</Data>
  <Data Name="ParentProcessId">19004</Data>
  <Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data>
  <Data Name="ParentCommandLine">cmd.exe</Data>
  <Data Name="IntegrityLevel">Medium</Data>
  <Data Name="User">IIS APPPOOL\DefaultAppPool</Data>
</EventData>

Much richer. Now you have:

Command line always — whoami /all
File hash — can compare against known-good whoami.exe hash
User context — IIS APPPOOL\DefaultAppPool is a red flag (web server pool account running whoami)
ProcessGuid — enables forward-chaining to all subsequent events from this cmd.exe session
ParentProcessGuid — enables backward-chaining to see what spawned cmd.exe

Now look up the parent (ParentProcessGuid = {abc-000}):

<!-- Sysmon Event 1 for cmd.exe -->
<Data Name="ProcessGuid">{abc-000}</Data>
<Data Name="Image">C:\Windows\System32\cmd.exe</Data>
<Data Name="ParentImage">C:\Windows\System32\inetsrv\w3wp.exe</Data>
<Data Name="ParentCommandLine">c:\windows\system32\inetsrv\w3wp.exe -ap "DefaultAppPool"</Data>
<Data Name="User">IIS APPPOOL\DefaultAppPool</Data>

The full chain: w3wp.exe → cmd.exe → whoami.exe /all. This is textbook web shell execution.

Worked Example

Writing the detection: web server spawning a shell

Detection goal: Alert when a web server process spawns cmd.exe or powershell.exe.

title: Web Server Spawning Shell Process
id: c4d2f2a1-5b3e-4f6d-9c7a-8e0f1b2c3d4e
status: stable
logsource:
  product: windows
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '\w3wp.exe'
      - '\httpd.exe'
      - '\apache.exe'
      - '\nginx.exe'
      - '\tomcat.exe'
      - '\java.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Some legitimate Java applications spawn cmd.exe for internal operations
  - IIS Application Initialization feature can spawn processes at startup
level: high
tags:
  - attack.execution
  - attack.t1059.003
  - attack.t1505.003

Why this works: Normal web servers do not spawn interactive shells. The parent-child relationship is the detection anchor — the specific command (whoami) is irrelevant. An attacker running ipconfig or net localgroup would trigger the same rule.

Why it has FPs: Java applications (particularly legacy enterprise apps) sometimes spawn subprocesses via Runtime.exec(). The java.exe parent creates noise. Tune by adding an exclusion for the specific Java application’s working directory or specific known-good command patterns.

Source 3: ETW (Kernel-Process Provider)

At the ETW level, the same event is available with sub-millisecond timing and thread-level detail — but this only matters if you have an EDR or custom ETW consumer:

{
  "provider": "Microsoft-Windows-Kernel-Process",
  "event_name": "ProcessStart",
  "timestamp_ns": 1710491994882341200,
  "process_id": 12172,
  "parent_process_id": 19004,
  "image_file_name": "whoami.exe",
  "command_line": "whoami /all",
  "user_sid": "S-1-5-82-3006700770-...",
  "thread_id": 7844
}

ETW adds: nanosecond timestamps (enables precise sequencing), thread ID (useful for multi-threaded process analysis), and it fires before the process is fully initialized — microseconds ahead of the EVTX event.

The Full Comparison

Feature	4688 (no cmd line)	4688 (with cmd line)	Sysmon Event 1	ETW
Command line	✗	✓	✓	✓
File hash	✗	✗	✓	✗
Parent command line	✗	✗	✓	✗
ProcessGuid	✗	✗	✓	✗
Sub-millisecond timing	✗	✗	✗	✓
Tamper-resistant delivery	Depends on forwarder	Depends on forwarder	Depends on forwarder	Yes (real-time)
Required config	Audit policy	Audit policy + cmd line	Sysmon install + config	EDR / ETW consumer

T1033 — System Owner/User Discovery— MITRE ATT&CK EVTX-ATTACK-SAMPLES— GitHub (sbousseaden)

Retrieval Practice

Your Sigma rule for web server spawning shells is generating false positives from a Java-based application that legitimately spawns cmd.exe for database backup operations. The backup command always contains 'sqlcmd.exe' as the first argument. How do you tune the rule without losing coverage for real web shells?

Reveal answer

Add an exclude condition for the known-good pattern: `CommandLine|contains: 'sqlcmd.exe'` combined with `ParentImage|endswith: '\\java.exe'`. More safely, scope the exclusion to the specific working directory of the backup process: `CurrentDirectory|contains: '\\backup\\'`. Avoid excluding all java.exe-spawned cmd.exe processes — that's too broad and would suppress legitimate attack detection. Document the exclusion in the rule's falsepositives section and the business justification, so future engineers understand why it's there.