Command-line Auditing on Windows: Why You Need It!

Auditing Process Creations

Windows does support command-line auditing or process creation auditing to some extent.

The event ID, 4688, is widely recognized on Windows operating systems for “Process Creation”.

Although the auditing for process creation is disabled by default, it can be easily enabled through the Local Security Policy (including a few other means). Along with the creation of processes, these events can also be tweaked to include command line arguments. These events are great to identify the source of hideous command prompt launches, identify executables run on an endpoint, or track an adversary’s activities.

Enabling “Process Creation” auditing via the “Local Security Policy”

Now that you’re done enabling process auditing for your system — it’s time to monitor what sort of data it logs.

Here’s an example log:

Process Creation Log with Command Line
Command line logging shows the command “vssadmin list shadows” being executed
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
ID = 4688
} | Select-Object TimeCreated,@{name='NewProcessName';expression={ $_.Properties[5].Value }}, @{name='CommandLine';expression={ $_.Properties[8].Value }}

Commands Mostly Abused by Attackers

Based on a report released by Shusei Tomonaga from the Analysis Center at JPCERT, attackers commonly utilize a specific set of commands from the initial stages of recon to the final stages of impact.

Initial Investigation

Firstly, an attacker usually goes through the ‘sniffing’ phase. This is where the attacker would query the system for more information, seek information about processes, services, time, IP configurations, etc. Here’s a list of commands most commonly utilized in the Initial Investigation phase:

Credits: JPCERT


Next, the attackers would begin snooping on other machines and resources on the network, seek confidential information, and more information relevant to the compromises host and its neighbors. Here’s a list of commands most commonly utilized during the Recon phase:

Credits: JPCERT

Spread of Infection

This is where the attacker would decide to use the collected information and begin spreading malware within the network. For that purpose, the following commands are used most commonly:

Credits: JPCERT

Restricting Execution of Blacklisted Commands

If you take a closer look at the list above, these are highly technical commands. It’s obvious an oblivious end-user would never make use of them. It’s fairly easy to restrict these applications on endpoints to avoid mass-scale damage. AppLocker configurations can work perfectly in such cases.

AppLocker Configuration

AppLocker can help allow or deny the execution of executables based on defined rules. Using these simple rules, we can do two things — deny the execution of malware and record the failure of execution for commands in the event log (AppLocker has its own channel which we’ll explore later).

Applying a path-based rule to ‘whoami.exe’
  • Shift to User Configuration
  • Then to Administrative Templates
  • Finally, under ‘System’, look for the “Prevent access to the command prompt” setting. Enable or disable it based on your need.


That’s it for this article. Process creation and command-line auditing is definitely a mandatory for all environments. Though the decision to do so comes with its own issues — the most significant being the size and nature of these logs (abundant in nature). If it’s viable for you to do so, the decision will be fruitful in case of incidents or investigations.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store