When investigating an intrusion, it is often said "Visibility is king". In my experience, I couldn't agree more. Far too often are users unaware of what is being logged by default and what needs extended or more verbose logging. Take Command Lines for example. Did you know that unless enabled by default, if an end-user types within a Command Prompt, the commands will not be logged? Sure, using evidence of execution such as UserAssist, Prefetch, JumpLists, etc. will show us that CMD.exe was executed, but how do we know what was typed within the prompt? This is where Command Line visibility is key, and an easy way to achieve this is to utilize Windows System Monitor or more commonly known as Sysmon from the SysInternals suite. Not only can you achieve visibility within command line auditing, you can identify suspicious process spawning, potential process injection, process creation, DNS requests and more! The best part of this is... ITS FREE!
The Rundown
Unless enabled, Windows OS will not log commands typed within an interpreter, such as Command Prompt (CMD)
Without process tracking and command line auditing, a gap in what commands are being leveraged and Living off the land techniques can exist
There are commonly three "quick wins" to achieve command line auditing. Endpoint Detection and Response (EDR), Enabling Command Line Auditing and Process Tracking within Group Policy or Local Security Policy, Sysmon
Sysmon can be installed across the environment utilizing Group Policy Objects (GPO)
There are many useful configurations for Sysmon to ensure proper logging is enabled
Windows Event Logs are not intended for forensics or intrusion analysis. Sysmon is specifically designed for forensics and enhanced logging
Sysmon can record - process creation and command line, file hashes, process GUID, session GUID, loaded drivers and DLLs, raw disk reads, network connections, file creation, and more Source: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
Sysmon will require a configuration. A common configuration file is SwiftOnSecurity's config found here: https://github.com/SwiftOnSecurity/sysmon-config
There are 30 Sysmon Event IDs
Sysmon events can be viewed within Windows Event Viewer once installed
Sysmon event log can be cleared by a Threat Actor (TA)
Review the retention rate of your Event Logs and ensure a large enough storage is set to go back at least 90 days, though if possible, farther back is preferred. This will largely depend on the amount of activity being logged and available storage
Alright alright, lets get into the good stuff here. As mentioned earlier, Windows OS does not currently log command line parameters by default. Open the Command Prompt and type "whoami" and see if you can find it. Go ahead... I'll wait a minute. YOU CAN'T! At least not by default. Typically, this would be find within the Security Event log under the Event ID '4688'. Though unless enabled, this Event ID will not exist. Although this post won't expand on configuring your system for logging, just note that without some sort of visibility within Command Line auditing and Process Creation, there can be a large gap in visibility for forensics and overall analysis. If you're looking on more information on how to enable Command Line Auditing and Process Tracking through GPO or Local Security Policy, check out this post: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing . Please note that enabling Process Tracking and Command Line auditing is only one piece of the puzzle and will not log as much as Sysmon can. We're looking for an easy button, right?!
Keep in mind that the Windows Event Logs were not created for forensics purposes. These were originally created to notify system administrators of "events" that require attention, solely surrounding technical issues and troubleshooting.
Lets take a look at an example of this. Shown below, we can see that with visibility using Sysmon, we can see the process spawned and the command line parameters supplied.
Now without visibility into Command Line auditing, we'd only see that a TA opened 'cmd.exe' using artifacts of execution, such as Prefetch, but would have no insight into what was executed within it.
Obviously there are many other command line interpreters, such as PowerShell. If you're not familiar with enhanced PowerShell logging such as transcript, module and scriptblock logging, check out this article https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.3
However, Sysmon will also provide visibility into PowerShell! As shown below, we can see that Sysmon recorded me using PowerShell to execute the command "whoami". By the way, if you're looking for quick win to alert on in your SIEM, create a rule for execution of "whoami" once you have Command Line visibility. You'd be surprised how often TAs use this command.
Now imagine how Powerful this can be enabled on all systems across your network and forwarded to a log collector/aggregator! Even better, to a SIEM with custom rules that will alert you of suspicious process execution, command line parameters or unexpected parent process and locations! Talk about incredible visibility for free.
In my experience, I often work cases that involve some sort of credential theft. Whether this is from dumping LSASS from memory Pass-the-Hash (PTH), kerberoasting, etc. During my analysis, I can say what "likely" occurred and how password's are typically extracted and cracked, but what if we can clearly see what happened? For example, utilizing comsvcs.dll to dump LSASS.
Let's step away from specifically command line logging and process creation. How about network visibility? Do you have DNS logging enabled and are able to track down a suspicious DNS request and which host initiated that request? If so, kudos to you! If not, Sysmon can also help with this. Lets browse to Google[.]com and see if we can get a DNS request recorded with Sysmon!
As you can imagine, this can provide great visibility into suspicious or malicious network traffic. Such as Command and Control (C2) beaconing or connections. Again, forward this to a SIEM and you have some great monitoring and hunting capabilities! Too often do DFIR analysts step into a case only to find that network logs rolled over or do not exist. Again, other artifacts may help us "suggest" what occurred, but if we can have visibility with a tool such as Sysmon, it can help confirm unanswered questions. If you're considering installing Sysmon and forwarding logs to a SIEM, ask yourself these questions to determine what to create your custom signatures around, there tuning a SIEM can take quite a bit of time:
What is unexpected within my environment
What are commonly abused Living off the Land techniques and how can I detect unexpected process spawning and command lines
What are commonly abused tools
A quick note, like a lot of artifacts, the Sysmon event log can be cleared. Be sure to consider restricting access on log clearing. Remember, clearing an event log often creates an event in of itself. If you're forwarding these logs, they may have been cleared on the local system, but will still exist on your log collector. You can also monitor Event IDs such as 104 within the 'System' Event log for clearing of event logs.
Reasons why you need Sysmon
Enhanced visibility
Better threat hunting capabilities
More detailed forensics logging
Better SIEM rules
Windows Event Logs were not designed for forensics
Sysmon is specifically designed for forensics
IT'S FREE
Resources:
Sysmon - https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
Sysinternals - https://learn.microsoft.com/en-us/sysinternals/
SwiftonSecurity Configuration - https://github.com/SwiftOnSecurity/sysmon-config