Sysmon 14.0 — FileBlockExecutable
The Sysinternals team has released a new version of Sysmon. This brings the version number to 14.0 and raises the schema to 4.82.
Other than some fixes for several memory leaks that occurred in certain edge cases in the driver or between the driver and the service, there is a new event type! The new event has the ID of 27 and is called FileBlockExecutable.
Sysmon now impedes executables, based on the file header from being written to the filesystem according to the filtering criteria. This can be a very powerful feature into blocking certain programs writing malicious files to disk. As a simple example, I’ve created this configuration that will not allow PE files from being written to the downloads directory.
When this configuration has been loaded and I attempt to download a file it will not work.
The resulting event log item looks like this:
The same is true for an DLL/XLL/WLL file since that will share the same MZ header.
Obviously doing this to the downloads folder is not something most people will use. Something more useful would for instance be writing executable files from Office processes, where a Macro might download a secondary payload and execute it.
Other considerations could be to prevent certain scripting tools, certain temp folders to write files or be written to. Do make sure to test this really well! In a simple example I prevented cmd.exe, powershell.exe and cscript.exe to not let it write files.
While there is no error on the command line, the file is not written to disk. Sysmon prevented this, as the event below will show.
The information from this event is quite nice, we can see
- my favourite field the ProcessGuid,
- the ProcessId,
- the user who performed the action,
- which image/binary was used,
- the TargetFilename
- and the Hashes of the TargetFilename.
Sadly we do not have the OriginalFileName of the initiating Image (yet), which would make it even more robust in creating configurations as they are harder to change than the file name.
The application of this feature will differ per organisation, and will have different value to various usage goals. It can certainly help in the hardening of a workstation or function as an additional step in making it a bit more challenging for malicious actors.
With all being said, this is an interesting move into not only logging but also acting here. I’m very keen to see what other features are considered for development by the SysInternals team. Obviously this requires a lot more testing, since you can impact operations significantly. And as always don’t test this in production, let it run for a while in a lab, then on a set of reference machines and then after some validation roll it out into prod.
Additionally, with new feature versions like this, there might be unkown issues. Rolling this into production is not recommended for a while.
