The latest release of Sysmon brings a bunch of improvements and introduces EventID 23. Great thanks to Mark for allowing me access to the beta builds.
Please have a look at his video talking about this new release. A great new way of Mark to talk about all new Sysinternals features
An overview of all improvements;
- Empty strings are replaced with “-“ to work around a WEF bug
- Adds DnsLookup configuration entry to support disabling of reverse DNS lookups
- Adds copy-on-delete support to preserve files specified by SID of deleting account, file extension, executables, or specific processes, including logic to preserve files that are shredded (overwritten before delete)
- Avoids hashing main data stream when it’s marked with FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS, which is used by cloud storage services like OneDrive and Dropbox
- Synchronously processes ProcessAccess events to ensure that it occurs before the responsible process terminates
- Sysmon now uses non-executable non-paged pool
- Several bug fixes addressing configuration parsing issues
Due to the changes the schema has been upgraded to version 4.30.
A copy of the new schema is available here
DnsLookup configuration option
This new configuration option allows you to disable reverse DNS lookup events. This is configured at the root of the configuration by a Boolean value, which is set to True by default. To disable it, add the following line below the opening <Sysmon>
You can validate its setting with Sysmon.exe -c
New: FileDelete Events
This is the latest event type that can be generated. There are several options of enabling this, depending on your use case.
When installing the new Sysmon version you can enable the Archive folder, this is a directory where all files will be saved.
-a sets the Archive Directory, this will be placed in the c:\ root. By default this folder is set to Sysmon, you can also configure this in the config file with the <ArchiveDirectory> setting.
Recover deleted files
I didn’t have to do a lot of testing to see whether it worked. As part of the install process it copies itself to a Temp folder which then gets deleted, and now archived as can be seen below.
Obviously I now was curious to see what was archived in my folder, so I fired up PowerShell and looked at my C:\
While it seemed the falconforce folder was not there, it also wasn’t tagged with the hidden attribute, I tried to access it anyway.
There we go, it is there it’s just not accessible by my user, it is protected by a System ACL.
There are multiple options now to move on. On a live system I would not change the access rights to this folder, since there might be valuable information there an attacker might not be aware of. On top of that you might inadvertently prevent Sysmon from writing to the folder.
What you could do for instance is spawn a SYSTEM command prompt and copy the required files. This can be done for instance by using PsExec, just run
PsExec.exe -sid cmd
From this command prompt you can browse your directory without touching the ACLs and retrieve any file you’re after.
As you can see the file names are identical to the hashes that are logged in the event log sample above.
Archived files naming
Basically the filename is what you have configured as <HashAlgorithms> in your loaded configuration.
In my case all are enabled so the archived files are built up by SHA1,MD5,SHA256,IMPHASH joined together followed by the original extension. Should you be using only the SHA1 for instance this hash will then be your file name.
If you enable the archival of all deleted files, prepare for a lot of internally handles files. These range from loads of dlls, rbf, etl, xml, prefetch and other files that are processed by for example svchost.exe.
This can provide great value from a research perspective into Windows internals but there is no added value in a production environment.
While I am a fan of the “include all, exclude the noise” principle, in this case an alternative method might be more beneficial and will not flood the disk space, especially in a production environment. It eventually all comes down to risk, what are you most interested in capturing in case of malicious activity.
There are several ways to configure these new features. Mark and the team have added several root configuration options, for which I’ve included some examples:
# Disables lookup behaviour, default is True (Boolean)<ArchiveDirectory>FalconForce</ArchiveDirectory>
# Sets the name of the directory in the C;\ root where preserved files will be saved (String)<FileDelete onmatch=”include”> and <FileDelete onmatch=”exclude”>
# You can use the following items to configure these in-/excludes
User - UnicodeString
Image - UnicodeString
TargetFilename - UnicodeString
Hashes - UnicodeString
IsExecutable - Boolean#Obviously you can use all filter conditions to mark file extensions, folders etc as to be archived
is Default, values are equals.
is not Values are different.
contains The field contains this value.
contains any The field contains any of the ; delimited values.
contains all The field contains all of the ; delimited values.
excludes The field does not contain this value.
excludes any The field does not contain one or more of the ; delimited values.
excludes all The field does not contain any of the ; delimited values.
begin with The field begins with this value.
end with The field ends with this value.
less than Lexicographical comparison is less than zero.
more than Lexicographical comparison is more than zero.
image Match an image path (full path or only image name).#For example
<TargetFilename condition="contains any">.exe;.ps1;.js;.xls;.xlsm</TargetFileName>
<TargetFilename condition="begin with">C:\Windows\Temp</TargetFileName>
Obviously you can utilise my modular configuration as well, which is available on my Github page.
Obviously new features are nearly always exciting but why would I start using this one you might ask? I’ve listed some scenarios in which this new feature might be appreciated. Mind you, this list is not exhaustive by far.
Scenario 1: Dropper / stager that removes itself after execution (T1193 or T1064 and loads more) or attackers doing it manually
Loads of malware delete themselves after execution to leave as little trace as possible, attackers often do the same after the use of that system is done. Now you’ll have an opportunity to investigate this file after you’ve detected suspicious behaviour on this machine
Certain wipers will attack the Master Boot Record (MBR) or other parts of the disk, in these cases Sysmon will not be able to save you. However there are loads of examples which target files instead of the file system, in this case all impacted files you’ve configured to preserve will be available in the ArchiveDirectory.
Scenario 3: Ransomware (T1486)
Let’s imagine I’ve downloaded a tool from one of the first hits on my default search engine or open an email that peeks my curiosity, get the attached file and run this. This tool targets all my files, including my binaries and renders them useless.
Sysmon recognised the change to this binary and captured the state and preserved the file in the ArchiveDirectory.
Scenario 4: Rudimentary local versioning backups
Configurations are required by loads of applications, adding these files to the include section of your Sysmon configuration will make sure once someone changes or deletes the file its previous state will be saved to the ArchiveDirectory.
Obviously there are better ways of doing this but not all systems can or will be equipped with software to do this. Besides that there’s always the possibility of an admin not following procedure while testing some things or an intruder tampering with a certain parameter.
This new feature is a great addition to one of my most beloved tools as a defender. It provides the means to capture files otherwise quite hard to come by. Additionally you will be able to preserve files otherwise possibly lost forever.
One of the important questions for you the user/admin will be: what files are not to be missed and will not swamp your disk in case of normal behaviour of your workstation(s) and server(s).
Tuning, like with a lot of the Sysmon configuration options, will be a vital part in implementing this in a production environment. Make sure not to skip this step.
Start out by only preserving files from a few well known locations malware likes to write and expand it from there.