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

It’s unfortunate that the Windows Command Prompt, the descendant of the prehistoric from MS-DOS, has no persistent storage of command execution. It does, however, support temporary storage of commands executed in an active session. So, if an attacker proceeds to enumerate other hosts or ex-filtrate data using a console window, does a defender have no means of identifying the execution of a binary? Well, it’s not entirely true.

Auditing Process Creations

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.

Here’s how you can enable ‘process creation’ auditing using the Local Security Policy. The settings are under “Advanced Audit Policy Configuration”, followed by “Detailed Tracking”, and then under “Audit Process Creation”. Based on your system’s log storage capabilities, enable the “Success” and “Failure” of process creation logs.

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

This isn’t all. Process creation is not enough on its own to decide the usage of an executable. It’s why you should also log its command line usage and arguments. Though it should be noted that the logging can enable any and all sorts of data including passwords or personal information. To proceed with command line logging in process creations: Open up “Local Computer Policy” or the “Group Policy Editor”, head to “Computer Configuration, then to “Administrative Templates”, then to “System”, and finally under “Audit Process Creation”, double click “Include command line in process creation events”. Enable the setting and press “OK” to continue.

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

The “Process Command Line” attribute has the data you required initially. This can be incredibly helpful for defenders to monitor and identify possibly malicious activity. Secondly, process creation logging can help them identify the execution of binaries which shouldn’t exist on a particular system. For example, most modern ransomware initially remove Shadow copies using the tool ‘vssadmin.exe’. If you forward your logs to a SIEM or ingest it in a data search engine like ElasticSearch, you can easily look for vssadmin — a tool a normal user would seldom use in day-to-day activities.

Command line logging shows the command “vssadmin list shadows” being executed

Here’s a generic command (PowerShell) to display all spawned processes along with their command line arguments:

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

Initial Investigation

Credits: JPCERT


Credits: JPCERT

Spread of Infection

Credits: JPCERT

Using commands like ‘at’ and ‘wmic’, attackers can do much more than local execution. With proper access rights, the adversary can easily execute anything on remote hosts.

Restricting Execution of Blacklisted Commands

AppLocker Configuration

To start configuring AppLocker rules, visit the Local Security Policy again. Under Application Control Policies, head to AppLocker. Under Executable Rules, let’s create a new rule to deny the usage of a sample command — ‘whoami’ (completely harmless).

Applying a path-based rule to ‘whoami.exe’

Before the selection of the executable, you can also select the entities you wish to apply this rule to. Also, apart from path-based execution blockage, you can also apply it based on hashes or the sign status of the executable.

An even more devastating move would be to block the command prompt — even though this will only partially contribute to halting a malware’s execution. Secondly, a few casual users are also Windows-savvy and can make use of the console to perform an operation or two. Should you really block the command prompt? That’s up to you. How to do it? Here’s that:

  • Open up the Group Policy Editor again
  • 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.


Hi, I’m Syed. Explore my articles as I embark on this journey of learning more about Forensics, Threat Hunting, and Cyber-threat Intelligence.