To make sure the release is actually generating all event types as expected, which in the past has not always been the case prompted me to create a pipeline that validates the functionality of the new binary and publishes its results to Sysmon works. The output of the latest build shows all events to be generated.
The new event type FileDeleteDetected gets the Event ID 26. This event is very similar to the FileDelete (23) event with one big difference: this new event will not intercept and write deleted files to the configured Archive Directory, but the generated events in the EventLog will contain nearly the same information.
As you can see from the above screenshot the information is almost identical — with the exception of the Archived field. One of the immediately apparent benefits of this new event type is obviously that it will not clog up the system and fill the hard drive.
You could pose the question why this warranted a new event type. From my view this is primarily to avoid confusion whether archiving is on or not; and therefore a lot easier to configure and to quickly enable for specific files/folders whenever there is a good reason to do this. You could even build a SOAR playbook to do this in case of certain alerts. The chance of configuration errors due to confusion is likely to be less than in the case of having to enable/disable archiving for individual config lines on the original event. Also, the new Event ID 26 provides an opportunity to capture additional malicious behavior that earlier was too complicated to record due to the potential filling up of the disk.
The configuration of the new event type works exactly the same way as the FileDelete event described in this blog post. The only distinction obviously is the event name is FileDeleteDetected and the archive directory does not need to be specified.
A very basic start to a configuration for the new event type could be:
<User condition="contains any">NETWORK SERVICE; LOCAL SERVICE</User>
<Image condition="contains all">\appdata\local\google\chrome\user data\swreporter\;software_reporter_tool.exe</Image>
<Image condition="is">C:\Program Files (x86)\Google\Chrome\Application\chrome.exe</Image>
Additional noteworthy improvements
Sysmon also has a new XML parser that was introduced in version 13.02, eagle-eyed users might already have spotted it there.
With the new parser there also is a bit more verbose output upon loading a new configuration. There is mention of the Byte-Order-Mark and the file format. The Byte-Order-Mark (or BOM) is a special marker added at the very beginning of a Unicode file encoded in UTF-8, UTF-16 or UTF-32. It is used to indicate whether the file uses the big-endian or little-endian byte order. The BOM is mandatory for UTF-16 and UTF-32, but it is optional for UTF-8.
Additionally, the new parser provides somewhat more descriptive and verbose error outputs when loading a configuration that has mistakes or errors in it.
One of the issues that also has been addressed is where the ClipboardChange event would still write files to disk in case the <CaptureClipboard /> was set in the root of the configuration, but nothing was configured to be logged on the EventFiltering section of the configuration.