Sysinternals New Tool Sysmon (System Monitor)
The new tool in the Sysinternal Suite released recently by Mark Russinovich and Thomas Garnier both from Microsoft is called Sysmon (System Monitor) http://technet.microsoft.com/en-us/sysinternals/dn798348 . The tool installs a service and a driver that allows for logging of activity of a system in to the Windows event log. The activity it monitors are:
- Process Creation with full command line for both current and parent processes. In addition it will record the hash of the process image using either MD5, SHA1 or SHA256. In addition it will record the process GUID when it is created for better correlation since Windows may reuse a process PID.
- Network connection from the host to another. It records source process, IP addresses, port numbers, hostnames and port names for TCP/UDP connections.
- Changes to the file creation time of a file.
- Generates events from early in the boot process to capture activity made by even sophisticated kernel-mode malware.
Installing the Service and Driver Manually
Once the utility is downloaded and unblocked one just needs to open a command prompt or PowerShell and navigate to it to execute the tool and be able to see the output of the operation. If we run the utility with no options we can see it provides a help message with the options and recommendations.
PS > .\Sysmon.exe Sysinternals Sysmon v1.0 - System activity monitor Copyright (C) 2014 Mark Russinovich and Thomas Garnier Sysinternals - www.sysinternals.com Usage: Install:C:\Users\Administrator\Desktop\Sysmon.exe -i [-h [sha1|md5|sha256]] [-n] Configure:C:\Users\Administrator\Desktop\Sysmon.exe -c [[-h [sha1|md5|sha256]] [-n]|--] Uninstall:C:\Users\Administrator\Desktop\Sysmon.exe -u -c Update configuration of an installed Sysmon driver or dump the current configuration if no other argument is provided. -h Specify the hash algorithm used for image identification (default is SHA1). -i Install service and driver. -m Install the event manifest (done on service install as well). -n Log network connections. -u Uninstall service and driver. The service logs events immediately and the driver installs as a boot-start driver to capture activity from early in the boot that the service will write to the event log when it starts. On Vista and higher, events are stored in "Applications and Services Logs/Microsoft/Windows/Sysmon/Operational" On older systems events write to the System event log. Specify -accepteula to automatically accept the EULA on installation, otherwise you will be interactively prompted to accept it. Neither install nor uninstall require a reboot.
Let’s take a look at the options we have. We are given 3 different parameter sets we can run:
- Install
- Configure
- Uninstall
The first parameter set is installation and that is what we will do first. In the installation parameter set we can select the hashing algorithms from MD5, SHA1 and SHA256 and if we want to enable logging network connections. The default for hashing is SHA1, this is a good balance since it is known that even do rare collision may happen with MD5.
When installing in an automated way, through a WinRM or PowerShell remote session it is recommended to use the ‘-accepteula’ option so it does not prompt with a message box asking to accept the license.
Here is an example where we will install the service and driver accepting the default hashing algorithm and enabling network connection logging.
PS > sysmon -i -n -accepteula Sysinternals Sysmon v1.0 - System activity monitor Copyright (C) 2014 Mark Russinovich and Thomas Garnier Sysinternals - www.sysinternals.com Sysmon installed. ysmonDrv installed. Starting SysmonDrv. SysmonDrv started. Starting Sysmon. Sysmon started.
Once installed we can confirm the service is installed and started by using the PowerShell cmdlet of Get-Service
PS > PS > Get-Service -Name sysmon Status Name DisplayName ------ ---- ----------- RunningSysmon sysmon PS >
It will start to collect events immediately as it started and they will be saved in the Windows event log under Applications and Services Logs -> Microsoft -> Windows -> Sysmon -> Operational. We can also use PowerShell to query the events locally or remotely with the cmdlet Get-WinEvent. By querying using the log name of Microsoft-Windows-Sysmon/Operational
PS > Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational";}
TimeCreated ProviderName Id Message
----------- ------------ -- -------
8/9/2014 8:27:37 AM Microsoft-Windows-Sysmon3 Network connection detected
8/9/2014 8:26:36 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:36 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:36 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:35 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:35 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:30 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:14 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:14 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:14 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:14 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:26:14 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:25:00 AM Microsoft-Windows-Sysmon3 Network connection detected
8/9/2014 8:23:12 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:22:39 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:21:34 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:17:44 AM Microsoft-Windows-Sysmon1 Process Create
8/9/2014 8:17:44 AM Microsoft-Windows-Sysmon1 Process Create
The events we see are:
- Event ID 1: Process creation. A new process is created.
- Event ID 2: A process changed a file creation time.
- Event ID 3: Network connection.
Modifying the Settings
Depending on your environment and use of the host you may need to modify the settings of Sysmon. In my case I noticed that for a desktop system the monitoring of network connections can cause quite a large number of events do the amount of web browsers tabs and constant searching I do on the web.
To list the current configuration we just give the sysmon.exe the “-c” option
PS > .\Sysmon.exe -c Sysinternals Sysmon v1.0 - System activity monitor Copyright (C) 2014 Mark Russinovich and Thomas Garnier Sysinternals - www.sysinternals.com Current configuration: - Service name:Sysmon - Driver name: SysmonDrv - HashingAlgorithm:SHA1 - Network connection:enabled
Let’s change the hashing algorithm to MD5 and disable network connection logging by giving the options “sysmon.exe -c –h md5”
PS > PS > sysmon -c -h md5 Sysinternals Sysmon v1.0 - System activity monitor Copyright (C) 2014 Mark Russinovich and Thomas Garnier Sysinternals - www.sysinternals.com Configuration updated. PS > sysmon -c Sysinternals Sysmon v1.0 - System activity monitor Copyright (C) 2014 Mark Russinovich and Thomas Garnier Sysinternals - www.sysinternals.com Current configuration: - Service name:Sysmon - Driver name: SysmonDrv - HashingAlgorithm:MD5 - Network connection:disabled PS >
We can disable network connection monitoring by using the “sysmon.exe –c - -“ option so as to reset to default, this will not change the hashing algorithm back to SHA1 for some reason in this version.
PS > sysmon -c -- Sysinternals Sysmon v1.0 - System activity monitor Copyright (C) 2014 Mark Russinovich and Thomas Garnier Sysinternals - www.sysinternals.com Current configuration: - Service name:Sysmon - Driver name: SysmonDrv - HashingAlgorithm:MD5 - Network connection:disabled PS >
Update 8/11/14: The reason that the configuration was not being updated properly is in the way PowerShell parses the '--' option here is an example where it works properly on cmd.exe and not on PowerShell
The settings are currently saved in the registry under the driver service settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SysmonDrv\Parameters There are 2 REG_DWORD values the first one is HashingAlgorithm that controls the hashing algorithm used with the following values:
- 1 – SHA1
- 2– MD5
- 3 – SHA256
The next value is called Options and it controls network connection logging using the following values:
- 0 – Disabled
- 1 – Enabled
This values can be controlled and modified using Group Policy. I created my own ADML and ADMX files to control configuration of Sysmon.
Comparison to Process Auditing
Currently Windows support process auditing and can be set through Group Policy. It varies depending on the versions of Windows one is running. For Windows 2003 hosts in our domain and XPwe would go in to a Group Policy Object and enable it by going to Computer Configuration -> Policies -> Windows Settings -> Local Policies -> Audit Policy and selecting Audit process tracking.
Once in Audit process tracking we can select success and failure as the actions to audit.
By enabling this it will be logged in to the Security event log:
- Process Creation
- Process Termination
- Handle Duplication
- Indirect Object Access
So as we can see in addition to process creation and termination it will audit other tasks that Sysmon does not.
If we have Windows 2008, Windows 7 or higher versions you can enable Detailed Tracking by going to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Detailed Tracking
Let’s compare what is logged by Windows 7 with a detailed process audit enabled when a process is created.
It gives us the SID of the user and the PID and PPID in hexadecimal value, we also get token elevation information and the process full path.
Now let’s take a look at what we get from Sysmon when a process is created:
As we can see the process ID information is in decimal value, the SID is resolved to the user, we get the command line for the command and the command line of the parent process, we get a hash value for the process image and we get a GUID for the process since a PID may be reused by the system. As we can see the level of information is much higher.
One problem is that Sysmon does not record process termination but by using process auditing we can mitigate this.
Another area of advantage as already mentioned is the ability to log network connections and to log file time creation changes something not possible by default in current versions of Windows.
Here is an event for time creation change:
Here is a connection being logged:
In the case of Windows 2012 R2 and Windows 8.1 Microsoft added the capability to enable command line logging for these systems. To enable them one would go to Computer Configuration -> Policies -> Administrative Templates -> System-> Audit Process Creation
But still the information is limited and unless we also enable AppLocker we would not get a SHA1 of the process image to also complement the information we get from the standard capabilities of Windows.
Using Sysmon Events to Track and Attack
Let’s look at a simple example of a system where a system is exploited using Metasploit as the attackers platform and PowerShell to deliver the payload.
Before we begin in my lab domain I enabled the predefined rules on the hosts for Remote Event Log Management via GPO so as to able to query the hosts in my domain using Get-WinEvent remotely.
Lest start by loading the exploit module web_delivery and set it to use PowerShell, Meterpreter and use SSL so as to hide the traffic from and IPS/IDS in the network.
Once configure we can launch it using the exploit command
It will give me the command to launch the attack on the victim machine but the command misses one very important fact, PowerShell by default will not trust self-signed certificates. For this we need to add another command that will disable certificate checking. The command is:
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
I added this and turned the command in to an encoded command so as to bypass PowerShell execution policy and run it in the victim’s machine.
This will generate an event in Sysmon that will include the command line of the process. All child processes will also contain the command line of them and the parent process including the GUID for it making tracking the chain of execution easier.
Here we can see the initial process being launched:
If we follow the chain of events we will see PowerShell executing another instance of PowerShell and we can see it is decompressing and executing a secondary script:
Here we can see the initial connection to download the malicious script:
And here is the event when Meterpreter connects back to the attacker:
One of the very first actions an attacker will take is to create a secondary session to the target in case an actions destroys the current one. In this case I will use the Payload Inject module I wrote so as to not touch disk and inject a Meterpreter payload in to the explorer.exe process.
This happened all in memory so no process is created so the regular Windows process auditing will not report anything for the action. When we look at the sysmon logs we can see it caught the connection from the explorer.exe process allowing an investigator to notice that a process that is not supposed to have any connection to the outside world just did.
Persistence remains one of those things that would proper auditing most instances and techniques can be caught and alerted on. Since Command and Control structures change a lot let’s look a case where persistence is not in memory by on disk so as to survive reboots by running a custom script I wrote for my own use:
When we look inside the Sysmon events we can see the execution of the file and the connection:
One great use of the data in this case is the SHA1 hash since I can now search either centrally or on all my hosts with processes that have been started and have the same hash. This allows me to find other hosts compromised either by lateral movement or as part of the overall attack.
The best way for this is with a SIEM or using the Windows Event Collector (http://msdn.microsoft.com/en-us/library/windows/desktop/bb427443(v=vs.85).aspx) since this will allow for a centralized more efficient search and removes the possibility of the logs being cleared by the attacker.
Here is a function I wrote to help with searching for events on different hosts. Remember to use it the proper firewall rules must be in place.
<# .Synopsis Search Windows Event Log that match a Hash Filter .DESCRIPTION Searches one or more computer Windows Event Log with a given hash filter returning the events. When querying a remote host the Windows Firewall inbound rule for "Remote Event Log Management" must be enabled so as to be able to connect to the computer RPC service to perform the search. .EXAMPLE Example of how to use this cmdlet #> function Get-FilteredEvent { [CmdletBinding()] [OutputType([System.Diagnostics.Eventing.Reader.EventLogRecord])] Param ( # Computer or list of computer to query. [Parameter(Mandatory=$false, ValueFromPipelineByPropertyName=$true, Position=0)] [Alias('Name', 'DNSHostName', 'Host', 'Computer', 'IP')] [string[]] $ComputerName = $env:COMPUTERNAME, # HashtableFilter to use for filtering events. [Parameter(Mandatory=$true, ValueFromPipelineByPropertyName=$true, Position=1)] [hashtable] $FilterHashtable, [Parameter(Mandatory=$false)] [System.Management.Automation.PSCredential] [System.Management.Automation.Credential()]$Credential = [System.Management.Automation.PSCredential]::Empty ) Begin{} Process{ foreach ($computer in $ComputerName) { try { Write-Verbose -Message "Reatriving events from $($computer)." $CommandParams = @{ ComputerName= $computer FilterHashtable = $FilterHashtable ErrorAction = 'Stop' Credential = $Credential } if ($MaxEvents) { $CommandParams.Add($MaxEvents,$MaxEvents) | Out-Null } Get-WinEvent @CommandParams } catch [System.Diagnostics.Eventing.Reader.EventLogException]{ Write-Verbose -Message "Could not connect to computer $($computer)." } catch { Write-Verbose -Message "Record not found in computer $($computer)" } } } End{} }
I can use this function to search across a domain for records showing the hosts where a process started with a given hash. Again this is not the most effective method since we have to go to each hosts and query each.
PS C:\> $HashFilter = @{ logname='Microsoft-Windows-Sysmon/Operational' Id=1 data='DD49F115E1688F4407FA789EDED3BA46DBB49C0F' } PS C:\> Get-ADComputer -Filter * |% { Get-FilteredEvent -ComputerName $_.name -FilterHashtable $HashFilter} | ft Id,Timecreated,machinename -AutoSize Id TimeCreated MachineName -- ----------- ----------- 1 8/9/2014 9:25:56 PM win7-clien1.acmelabs.com 1 8/9/2014 9:32:53 PM ALAB-Win81-02.acmelabs.com
Conclusion
As we can see the information being in one single log and requiring little conversion allows for a less time consuming effort in tracking malicious activity. When Sysmon is used with a centralized SIEM or Windows Event Collector the possibilities for quick tracking and alerting are greatly enhanced. Since the data is in a format easy to parse and leverage it lends its self for automating and scripting the data returned.
One very important note if the system is a client system where the user is allowed to browse the internet from this system the amount of network connection logs will be a very high one. Just opening a page and depending how the content of it is handled it could mean several entries per visited page and this can add up very quickly. The lack of control on what processes to ignore for this limits this feature in my opinion and may limit it to only on servers. If using Windows Event Collector one can filter what events are forwarded and with what criteria mitigating this possible problem in some environments. Test and monitor the amounts of logs generated before deploying.