Operational Look at Sysinternals Sysmon 6.20 Update

Sysmon has been a game changer for many organizations allowing their teams to fine tune their detection of malicious activity when combined with tools that aggregate and correlate events.  

A new version of Symon was recently released. Version 6.20 fixes bugs and adds new features. Some the of the note worthy changes for me are:

  • Enhancements in WMI Logging. 
  • Ability to change driver name. 
  • Ability to change service name and service executable name.

Changes in WMI Logging

Lets start by taking a look at WMI Logging that was introduced in version 6.10 and I covered in a recent blog post. In the recent blog post I mentioned that one of the TTPs not covered when creating permanent events was the modification of the component classes of an existing permantern event , I was contacted by some developers at Microsoft and after some brief messages they told me this would be addressed in this version. Lets test the fix. I will start by creating a configuration file to catch all permanent event activity to configure Sysmon with.

<Sysmon schemaversion="3.4"> <HashAlgorithms>SHA256</HashAlgorithms> <EventFiltering> <WmiEvent onmatch='exclude'> </WmiEvent> </EventFiltering></Sysmon>

Once the configuration is applied to Sysmon I will create an Event Filter class from a PowerShell window running as administrator with the code bellow. 

#Creating a new event filter$ServiceFilter = ([wmiclass]"\\.\root\subscription:__EventFilter").CreateInstance()
# Set the properties of the instance$ServiceFilter.QueryLanguage = 'WQL'$ServiceFilter.Query = "select * from __instanceModificationEvent within 5 where targetInstance isa 'win32_Service'"$ServiceFilter.Name = "ServiceFilter"$ServiceFilter.EventNamespace = 'root\cimv2'
# Sets the intance in the namespace$FilterResult = $ServiceFilter.Put()$ServiceFilterObj = $FilterResult.Path

We now take that instance that was created and we modify the query it uses and using the Put() method we apply the change as shown bellow.

$ServiceFilter.Query = "select DisplayName from __instanceModificationEvent within 5 where targetInstance isa 'win32_Service'"$FilterResult = $ServiceFilter.Put()

Now when we look at then EventData element we see that modifications are now logged properly. This a technique used by some Eastern European groups where they look for existing permanent events and modify them to stay under the radar of more sofisticated defenders. 

          <img alt="modifiedwmi.png" src="https://static1.squarespace.com/static/52ad1d91e4b00a98a27ba20e/t/5a18d92171c10b644b76c9d4/1511577894754/modifiedwmi.png?format=1000w" />

By detecting modification of the classes that make up a permanent event this will allow defenders to cover a TTP currently used and provide even more insight to this known persistence technique. 

Change the Driver Name

Sysmon uses a minifilter driver attached to the system volumes to obtain all information of what happens on that volume from file hashes to attempts to force copy data from files. This driver is key for most of the logging done by Sysmon and it has a unique name of SysmonDrv. 

Some advanced attackers have automated the unloading of this driver so as to break Sysmon logging. we ca list drivers using the fltmc.exe tool. Bellow is a list of the drivers on a system without the driver being renamed.

PS C:\WINDOWS\system32> fltmc

Filter Name Num Instances Altitude Frame

SysmonDrv 3 385201 0
WdFilter 4 328010 0
storqosflt 0 244000 0
wcifs 1 189900 0
FileCrypt 0 141100 0
luafv 1 135000 0
npsvctrig 1 46000 0
Wof 2 40700 0
FileInfo 4 40500 0

The driver can be renamed only during install, if you wish to modify it you would need to uninstall Sysmon and re-install using a configuration file with the DriverName element as shown bellow or use the -d switch. 

<Sysmon schemaversion=“3.4”> <DriverName>NotReal</DriverName> <HashAlgorithms>SHA256</HashAlgorithms> <EventFiltering> <WmiEvent onmatch=‘exclude’> </WmiEvent> </EventFiltering></Sysmon>

Here we are installing Sysmon and modifying the name of the driver using the -d switch and we can see in the output that the name we gave was used.

PS C:\Users\Carlos\Desktop\Sysmon 6.20> .\Sysmon.exe -i -d notreal

System Monitor v6.20 - System activity monitor
Copyright © 2014-2017 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Sysmon installed.
notreal installed.
Starting notreal.
notreal started.
Starting Sysmon…
Sysmon started.

If we check with fltmc.exe we can see the name we specified was used. This should break most automated tools used by attackers to unload the driver. 

PS C:\Users\Carlos\Desktop\Sysmon 6.20> fltmc

Filter Name Num Instances Altitude Frame

notreal 2 385201 0
WdFilter 4 328010 0
storqosflt 0 244000 0
wcifs 1 189900 0
CldFlt 0 180451 0
FileCrypt 0 141100 0
luafv 1 135000 0
npsvctrig 1 46000 0
Wof 2 40700 0
FileInfo 4 40500 0

Change the Service Name

Sysmon also added the ability to rename the service. The service controls the driver so disabling this service allows to unload the driver and make sure it is not loaded again. To rename the service the sysmon.exe needs to be renamed to the name you want the service to be and use that executable for the installation of Sysmon as shown bellow. 

PS C:\Users\Carlos\Desktop\Sysmon 6.20> .\NotWhatItLooks.exe -i

System Monitor v6.20 - System activity monitor
Copyright © 2014-2017 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

NotWhatItLooks installed.
SysmonDrv installed.
Starting SysmonDrv.
SysmonDrv started.
Starting NotWhatItLooks…
NotWhatItLooks started.

We can list the services and see the path the service executable is using WMI.

PS C:&gt; Get-WmiObject win32_service | ?{$_.Name -like ‘NotWhatItLooks’} | select Name, D
isplayName, pathname

Name DisplayName pathname

NotWhatItLooks NotWhatItLooks C:\Windows\NotWhatItLooks.exe

If we take a look and the file information we can see it still referenced as Sysinternals Sysmon, this information can not be changed given that the file is a signed one and modifying this would break the signature validation.

PS C:\Users\Carlos\Desktop\Sysmon 6.20> Get-ItemProperty C:\Windows\NotWhatItLooks.exe | fl *

PSPath : Microsoft.PowerShell.Core\FileSystem::C:\Windows\NotWhatItLooks.exe
PSParentPath : Microsoft.PowerShell.Core\FileSystem::C:\Windows
PSChildName : NotWhatItLooks.exe
PSDrive : C
PSProvider : Microsoft.PowerShell.Core\FileSystem
Mode : -a----
VersionInfo : File: C:\Windows\NotWhatItLooks.exe
InternalName: System Monitor
FileVersion: 6.20
FileDescription: System activity monitor
Product: Sysinternals Sysmon
ProductVersion: 6.20
Debug: False
Patched: False
PreRelease: False
PrivateBuild: False
SpecialBuild: False
Language: English (United States)

BaseName : NotWhatItLooks
Target : {}
LinkType :
Name : NotWhatItLooks.exe
Length : 1373840
DirectoryName : C:\Windows
Directory : C:\Windows
IsReadOnly : False
Exists : True
FullName : C:\Windows\NotWhatItLooks.exe
Extension : .exe
CreationTime : 11/24/2017 10:44:33 PM
CreationTimeUtc : 11/25/2017 3:44:33 AM
LastAccessTime : 11/24/2017 10:44:33 PM
LastAccessTimeUtc : 11/25/2017 3:44:33 AM
LastWriteTime : 11/24/2017 10:44:33 PM
LastWriteTimeUtc : 11/25/2017 3:44:33 AM
Attributes : Archive

Adapting TTP's

Now that we know that the new version of Sysmon takes steps to hide it self form most automated post-exploitation analysis tools out there lets take a look at how a red team would adapt to this by looking at the possibility of a knowledgeable defender with the knowledge, buy in and resources to deploy Sysmon in this manner. 

I always like starting by on a clean system launch Process Monitor in capture mode. Run the tool install with the proper parameters.   

Once the tool is finished installing, pause capture and hot the key combination of Ctrl-T to get a process tree. Bellow you will see me select the renamed copy of Sysmon and all of its sub processes. I will select it and then click on Include Subtree this will automatically create a initial filter for only those processes I can start looking at. 

          <img alt="procmon_sysmon_tree.png" src="https://static1.squarespace.com/static/52ad1d91e4b00a98a27ba20e/t/5a1a16c8085229dccc973ead/1511663450098/procmon_sysmon_tree.png?format=1000w" />

Now I will add filters for those operations that create files and registry keys and values. The reason is that I only want to see those operations that would create values I can later enumerate and trigger on. Ctrl-L will bring the filter window. So I set a filter for:

  • RegCreateKey - This operation is for when a Registry is Created.
  • RegSetValue - This operation is for when a Registry Value is created or set.
  • CreateFile - This operation corresponds to when a file is created and also when one is opened. 
          <img alt="procsysmon_filters.png" src="https://static1.squarespace.com/static/52ad1d91e4b00a98a27ba20e/t/5a1a16e64192021369fab52c/1511663438421/procsysmon_filters.png?format=1000w" />

After clicking OK I now have only the actions I need to look at.

One of the first things to notice is the creation and setting of a value for the acceptance of the EULA for Sysmon in the registry. 

          <img alt="Procmon_registry_set.png" src="https://static1.squarespace.com/static/52ad1d91e4b00a98a27ba20e/t/5a1a170e24a694106d799a6a/1511663429374/Procmon_registry_set.png?format=1000w" />

Next another clear indicator of Sysmon on the target box is the creation of the Event Log Channel for Sysmon Operational log, this is also in the registry. 

          <img alt="procmon_sysmon_create_evtwchannle.png" src="https://static1.squarespace.com/static/52ad1d91e4b00a98a27ba20e/t/5a1a17394192021369fac0b1/1511663407103/procmon_sysmon_create_evtwchannle.png?format=1000w" />

We can easily test in PowerShell for these keys if we want to write a simple script for use in Cobalt Strike or in Empire. 

PS C:\> Test-Path -PathType Container -Path HKCU:\Software\Sysinternals\"System Monitor"
PS C:\> Test-Path -PathType Container -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Sysmon/Operational

A more general and multi-use tool would be to enumerate all Sysinternal tools ran on the target box. This would provide a better information to gain situational awareness on the target network and host. An example of this is the Metasploit Post-Exploitation module bellow that I wrote several years before.

### This module requires Metasploit: http://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##
require 'msf/core'require 'rex'require 'msf/core/auxiliary/report'
class MetasploitModule < Msf::Post
include Msf::Post::Windows::UserProfiles include Msf::Post::Windows::Registry include Msf::Auxiliary::Report
def initialize(info={}) super( update_info( info, 'Name' => 'Windows checks if Sysinternal Tools have run on the host.', 'Description' => %q{ This module checks if Sysinternal Tools have run on the host.. }, 'License' => BSD_LICENSE, 'Author' => [ 'Carlos Perez <carlos_perez[at]darkoperator.com>' ], 'Platform' => [ 'win' ], 'SessionTypes' => [ 'meterpreter' ] )) end
def run() print_status("Running post module against #{sysinfo['Computer']}") current_user = session.sys.config.getuid() if current_user =~ /SYSTEM/ print_status("Running as SYSTEM, loading user registry hives for parsing.") hives = hives = load_missing_hives if hives.length > 0 print_status("#{hives.length} are currently loaded") hives.each do |hive| user_info = resolve_sid(hive['SID']) print_status("Checking existence of Sysinternal Tools being used for user #{user_info[:name]}") check_accepteula(hive['HKU']) end end else print_status("Running as #{current_user}") check_accepteula("HKCU") end end
def check_accepteula(hku_root) if registry_enumkeys("#{hku_root}\\Software").include?('Sysinternals') tool_keys = registry_enumkeys("#{hku_root}\\Software\\Sysinternals") print_status("The following tools have been ran:") tool_keys.each do |tk| print_good("\t#{tk}") end else print_status("No Sysinternal tool appears to have been ran by the user.") end endend

Another interesting thing is that under the service key it also creates a key named Sysmon Instance, this can be used to find the service and enumerate its settings. Depending on the RAT/Implant it may 

          <img alt="sysmon_instance.png" src="https://static1.squarespace.com/static/52ad1d91e4b00a98a27ba20e/t/5a1a176653450a9c54390631/1511659375319/sysmon_instance.png?format=1000w" />

Thankfully when looking at the details when using WMI we can see a unique description for the service we can use to trigger-on. 

PS C:\> Get-WmiObject win32_service | ?{$_.description -eq 'System Monitor service'}

ExitCode : 0
Name : NotSysmon
ProcessId : 6312
StartMode : Auto
State : Running
Status : OK

In the case of the driver rename the best advice would be to keep a list of known filter drivers and flag those unknown ones for further inspection and removal. 

We have found several ways to detect Sysmon on a system. Some of these a Blue Team can further obscure by hand. Many attackers do not look at these type of solutions in detail. Many do not even take a look at the footprint of their own tools. I do believe this will have an impact on the TTPs of attackers and it will confuse many automated tools that look for Sysmon. Valuable? yes, but only for the majority of actors, there is always that small advanced group. 

If this is found in a pentest or in a Red Team engagement either internal or external it should be commended, this shows active steps taken by defenders that do yield some value against none sophisticated attackers. Defenders do take a look at this and do not take the changes as a stealth way to run Sysmon. Like any defensive step it should be analysed and looked at in a adversarial mindset to see its values and shortcomings. 

Article Link: https://www.darkoperator.com/blog/2017/11/24/operational-look-at-sysinternals-sysmon-620-update