[German]Microsoft employee Mark Russinovich released his Sysinternals tool Sysmon in version 11.0 on April 28, 2020. Here is some information about it. And also a look how the whole thing looks like from a security point of view.
Advertising
The Sysinternals tools are a small collection of helpful tools for Windows (Windows 7 and later), which Microsoft employee Mark Russinovich offers for free and updates from time to time. An overview of all tools can be found on the Sysinternals tools website.
Sysmon v11.0, what's new?
Version 11.0 is, according to the changelog, a major update. File delete monitoring has been addes. The aim is to log such operations performed by malware or ransomware at least to help responders capture attacker tools.
In version 11.0 there is also an option to disable reverse DNS lockup). And empty fields are replaced by a '-' to avoid a WEF (Windows Event Forwarding Problem) error.
The new version also fixes an issue that caused some ProcessAccess events to be aborted. Furthermore, the new version of Sysmon no longer hashes the main data streams marked as stored in the cloud.
What do you need Sysmon for?
Sysmon does not have its own interface like Processmon, but it installs both a system service and a device driver under Windows. The necessary call options for installation are described in detail on the Sysmon page.
Advertising
After the installation the driver and the system service remain persistent on the system. The device driver then records the system activities that are logged by the service in the Event Viewer. This includes detailed information about creating processes and network connections as well as changes in file system object creation times.
Administrators can then use the Windows Event Viewer to view the entries in the event log. In addition, SIEM (Security information and event management) solutions can be used to capture and analyze the event viewer. The goal is to detect malicious or anomalous activities through subsequent analysis and to understand how intruders and malware act in the network in the event of an attack.
Where can I get details and download?
The Sysinternals Tools are available for free download from this website. On the Sysmon page you can download the tool. There you can also find extensive documentation on how to install and uninstall Sysmon. Furthermore the range of functions is described.
(Source: YouTube)
In the video above Marc Russionvich presents the April 2020 updates for the Sysinternals tools. Sysmon is also briefly discussed there.
The dark side: DLL-Hijacking on board
As ingenious as the Sysinternals tools are, there's a 'dark side' I like to mention. To say it with the words of security researcher Stefan Kanthak: Russinovich is resistant to suggestion and has beginner's mistakes with his stuff.
What we are talking about exactly?
For some time now I have started to run various tools advertised in blogs and websites in my security a testbed. The goal is to find out if these Windows programs are vulnerable to DLL hijacking. Executing the Sysmon program within my test bed produced a stack of warning dialogs – as shown below.
The program calls a number of required DLLs when it is started, without taking care about the path from where the library files are loaded. By default the required DLLs are located in the Windows subfolder system32 and should be loaded from there. However, if the programmer does not take this into account, Windows first searches the folder from which the main program was launched for DLLs with the appropriate name.
This is of course especially good for a tool like Sysmon, since its service and the device driver must be installed with administrator privileges under Windows. Malware that suspectedly stores DLL files with the same name in the program folder (in this case I the used my download folder), would thus receive administrative permissions when loading the DLLs in a piggyback manner.
Some more background information
Well, it's not rocket science to avoid DLL hijacking and it isn't completely unknown. Already in 2010 Microsoft has published the Security Advisory KB2269637 (Insecure Library Loading Could Allow Remote Code Execution) and the Advisory KB2533623, after security researchers pointed out the potential vulnerability.
And there is this article from Microsoft with recommendations on how developers can avoid this vulnerability in their code. This includes that when using API functions like LoadLibrary, LoadLibraryEx, CreateProcess or ShellExecute, a developer simply need to use a fully qualifying path (e.g. of the type %windir%/system32/) in the required DLL name. This forces Windows to disable the default search for loading a DLL and to load it cleanly from the desired target folder.
This doesn't bother Mark Russinovich at all, although German security researcher Stefan Kanthak – at least as far as I know – pointed this problem out to him several times. Just to mention: had pointed out the same vulnerability to the developer of the AdwCleaner offered by Malwarebytes. Within a few hours I received a corrected version that no longer had this DLL hijacking vulnerability (see AdwCleaner 8.0.1 closes a DLL Hijacking vulnerability).
The test bed is provided by German security researcher Stefan Kanthak, who deals with such security issues. You can download the file Forward.cab from his website and unzip it with Windows Explorer into a folder (I called it Test). There is also a Sentinel.exe which also moves into this folder.
If a virus raises an alarm visiting the Kanthak website: It's a test. Kanthak delivers the Eicar test virus in a data block attribute on its website to test whether browsers evaluate it and load it into memory for execution. A virus scanner should then be activated.
Copy the (portable) program to be tested into the testbed's folder instrumented with the DLL files and execute the application. If none of the messages shown above are present, the tested application most likely has no DLL hijacking vulnerabilities. If you got a warning, the tool comes with a DLL hijacking vulnerability and I would avoid using it anymore without additional measures. Unfortunately this isn't a single case I found in Microsoft software.
Similar articles:
Malwarebytes AdwCleaner 8.0
Malwarebytes AdwCleaner 8.0, a 2nd view
AdwCleaner 8.0.1 closes a DLL Hijacking vulnerability
DLL hijacking vulnerabilities in Nirsoft tools
Realtek closes a DLL Hijacking Vulnerability in HD Audio driver
Edge and its poor installer security
Microsoft Teams and it's security
McAfee patches vulnerability in antivirus products
Warning: Avoid NVTrimmer for Nvidia driver customization
Thanks for the review. The new event id 23 for file delete has a rather negative side impact due to the ArchiveDirectory being automatically activated, and if you aren't reading the doc's carefully and/or watching 'whats new' stuff like this, you can entirely miss. The ArchiveDirectory defaults to 'Sysmon' per-drive and every file that is deleted while Sysmon is running with Event ID 23 configured will preserve the deleted file in that ArchiveDirectory. This can lead to a file system DOS (denial-of-service) by filling the relevant drive mount. Russinovich shows how to delete the ACL protected folder w/ psexec BUT that has to be done only if you know your disk space depletion is due to Sysmon Event ID 23, and due to ACL's the folder is not readily identified. The configuration options 'CopyOnDelete…' don't seem to work, or are obfuscated enough so as to not readily be understood. The Event ID 23 function AND the ArchiveDirectory behavior need to be completely decoupled and well documented. Imagine a large SAN environment thin provisioned and then Sysmon Event ID 23 deployed — the SAN gets DOS'ed!