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:
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()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.
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.
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 (C) 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
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 (C) 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:\> 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 OriginalFilename: 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
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.
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:
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.
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.
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" True PS C:\> Test-Path -PathType Container -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Sysmon/Operational True
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##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
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.
Update 11/27/17
Click to Open Code Editor