Sysmon File Block Execution — How we can use Sysmon to block Hermetic Wiper, RMM Tools and Malicious Driver
As backup for EDR systems also in ICS environments
With the Sysmon EID such as File Block Execution you can not only prevent suspicious executable being blocked from the download folder, but you can also prevent malicious drivers, remote desktop tools and the execution of macros.
At ICS Atlanta, I talked about different wipers, which MITRE ATT&CK techniques are involved, and which precursors can be detected in systems for wipers like those for ransomware.
While I was testing the latest Sysmon Modular version in a customer project, I wanted to block the malicious drivers of the LOLdrivers community project with the EID 27. Then I also came up with the idea that a wipers used in the Ukrainian war is based on drivers that could be blocked, too. I remembered an article from Crowdstrike about DriveSlayer, also known as Hermetic Wiper. With the help of the hash, I quickly found an example for Hermetic Wiper to test it with Sysmon. And I highly recommend to NOT doing it in the own environment before making sure, that nothing could happen.
Why Sysmon, why Wiper?
My reasoning is: what if an attacker tries to disable the EDR and Sysmon kicks in? Or what if, as in the Ukrainian war, you are attacked with a wiper in an emergency, you know the hash and want to take countermeasures as quickly as possible? You could block the hash via a threat intelligence solution or an EDR solution, but what if these features are disabled or no longer work? Or simply, you are a small local government, school, etc. and don’t have any EDR or MISP?! With the help of Sysmon, you could roll out the configuration with the necessary hashes and executable free of charge within a few minutes and block attacks with the simplest means during an attack (at least on a Windows machine and with some research maybe also with Sysmonn for Linux). Not every authority has an EDR system like we see in Ukraine and not every company has a high-end solution EDR system or an AI Heuristic. And what about the older Builds in the OT Environment? Even if the companies have it, to what extent can the solutions be used in the ICS environment, and wouldn’t it be an effective backup in the ICS environment to have a Sysmon configuration with specific IDs that blocks malware, ransomware, malicious drivers or remote desktop tools in addition to backups? (I don’t know if the latest Sysmon version would run on older Windows OS, that’s something I haven’t tested, yet. But it would run on Windows 10).
Of course, such scenarios have to be tested in advance and I recommend at this point in time to limit yourself to certain RMM tools, malicious drivers and hashes for wipers, because ransomware can continue to work despite blocked executable via sub-processes or renaming the process, as I experienced in the test with 8Base Faust with Fast.exe, despite blocking the initial executable, then continuing to delete the VSS and other processes like netsh (disabling the firewall). That means, it has to be tested, if the Ransomware is starting or renaming the process to successfully block it otherwise it would encrypt the system even if the — I call it initial — hash was blocking the initial process.
Therefore, under no circumstances do I recommend trying to block ransomware only by trusting it would be blocked with the hash without first testing it with Sysmon.
In the following article, I will give some examples of how to block files with the Sysmon Modular configuration in an (ICS) environment, if you exclude certain EIDs and focus on the action on lenses such as stealing credentials, blocking malicious drivers, as well as remote access tools and wipers.
For this purpose, it is advisable to familiarize yourself with EID 27. You can find a very good article by Olaf Hartong regarding the download and blocking of unwanted processes on Medium.
Or I highly recommend the documentation of TrustedSec with my favorite Sysmon expert Carloz Perez and Director of Security Intelligence at TrustedSec, who imparts a profound knowledge documented in GitHub as well as can be found on the legendary youtube Trusted Sec channel.
Like mentioned before, you can now use the Sysmon configuration from the LOLDriver project for blocking malicious drivers and integrate it into Olaf Hartong’s Sysmon Modular configuration or your own developed configuration.
If you want to test the Sysmon configuration if it works, you can download and run the test drivers from the LOLDriver HTA Generator webpage.
Hermetic Wiper
Next, you can take drivers like Hermetic Wiper out of real Ukrainian war scenarios and put the hashes into the configuration for blocking files. I have disabled all EID that would generate too much traffic and have focused on essential EID for action on objectives. You could also build your own configuration and then choose a single EID focus. However, out of the holistic aspect and the experience value of Olaf Hartong’s research, I stick to his configuration and rebuild it according to the customer’s needs. Thanks again Olaf Hartong for your excellent work and community sharing!
To be able to realistically recreate Hermetic Wiper, I have taken the hashes from two research reports and downloaded and executed the samples accordingly after I have changed my config adding the hashes for blocking in Sysmon. The first hash is from the report CrowdStrike Falcon® Protects from New Wiper Malware Used in Ukraine Cyberattacks with the SHA256 1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591 for DriveSlayer and the second one is Symantec and the SHA256 0385eeab00e946a302b24a91dea4187c1210597b8e17cd9e2230450f5ece21d.
It turned out that Sysmon uses the driver to check the program for MZ and blocks it, but until the time of blocking, various call traces can be opened, and registry entries can also be executed successfully.
We find in the Sysmon Community Guide of TrustedSec following information:
The minidriver inspect the header of the file for the MZ DOS Executable header. The file can be identified by the ASCII string “MZ” (hexadecimal: 4D 5A) at the beginning of the file (the “magic number”). “MZ” are the initials of Mark Zbikowski, one of the leading developers of MS-DOS. This header is included in DLLs, PE Files, COM executables and other executable types.
Sysmon will not generate any alert on screen for the user once it takes the action.
Event information
The file delete event fields are:
RuleName: Name of rule that triggered the event
UtcTime: Time in UTC when event was created
ProcessGuid: Process Guid of the process that attempted to create the file
ProcessId: Process ID used by the OS to identify the process that attempted to create the file.
Image: File path of the process that attempted to create the file
TargetFilename: Name of the file that is being created.
Hashes: Full hash of the file with the algorithms in the HashType field. This is also the filename of the saved file in the ArchiveDirectory
Given the potential for this specific rule set to cause friction between a security team with users and other groups in the organization it is recommended to test before deploying. One recommendation is to use a file creation rule set to build a baseline of what executables are create where as part of normal day to day operations and then take that data to build a rule set that will minimize impact.
So, it’s important to understand that while Sysmon can block Hermetic Wiper based on the hash, it can successfully execute other call traces, as well as set registry entries such as disabling crash dumps before Sysmon’s driver recognizes the MZ header and blocks the execution. Such artifacts could then serve as VIP detections that an attacker tried to attack the systems, but ultimately failed because of Sysmon. You could write for example a detection for:
HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl\CrashDumpEnabled 0 is set what means it disables crash dump!!!
For robust hunting and analytics you will find the Sigma Rule here:
I’ve also witnessed, that the new created driver will be shown in the telemetry as file created, but you won’t find the driver and the service will not run.
A check with the voidtool everything in another Hermetic Wiper test shows, that there is definitely no driver created.
We see some call traces and the crash dump disabling was successful, but the wiper was stopped, because it couldn’t create a driver.
Why Sysmon if we have EDR and automated AI solutions?
Why would you need Sysmon in times of AI and EDR solutions? Many attackers try to disable EDR solutions, and not every company uses solutions with AI heuristics. On the one hand, Sysmon can act as a backup for AI solutions and EDR, but also as a free variant to deflect attacks on the critical infrastructure as quickly as possible in the event of a serious or ongoing incident. You could then roll out Sysmon on Windows machines relatively quickly and free of charge and roll out the current Sysmon configuration with the latest IOCs via Windows Forwarder, SCCM or other solutions to prevent the worst such as further machines that would be affected by Wiper or ransomware. A fast and easy solution to block malicious files within a short time and it cost you NOTHING!!!
Furthermore, you can prevent remote tools such as AnyDesk from being installed. But beware during the test, it turned out that artifacts are visible in the system. Nevertheless, the installation was successfully prevented. This applies to both RMM tools such as AnyDesk and MEGASync, I’ve tested.
But creating the \adprinterpipe
It also executes the — crash-handler and it means, that you can’t install AnyDesk, but it executed several call traces and PIPE routine before it was stopped by Sysmon. Again, the reason is that the driver is checking the MZ header, but not the API Calls of Windows.
A search with the “godmode tool for forensics” everything shows, that the executable AnyDesk for the application was actually created in the Program Files (x86) folder.
From hero to zero:
For MEGAsync you will find a folder with icons but no executable as artifact
Sysmon blocks it with the error message that the installer is for Windows 7 or above:
Can we always trust Sysmon and if not why?
There are some caveats that the block file execution has and you should really test it before you use the EID 27.
There is of course the probability that Sysmon could also be disabled or manipulated. And there are several way of bypassing Sysmon especially for the FileBlockExecutable. Several bypasses are described in the blog post of HUNT&HACKETT with analyzing assumptions.
Not everything was blocked as I’ve mentioned with the Ransomware that I’ve tested for example. Therefore, it is absolutely necessary to test before implementing such solutions to make sure, that you don’t block software or drivers that you need or worse, you think that a malware would be stopped because of the hash but it would not be stopped because of a renaming process or dropped files or services created that would be executed.
Nevertheless, imagine how powerful the new EIDs of Sysmon can be in combination with the EID 28 File Block Shredding which is described by Black Hills as follwing:
This is the latest event ID….was designed to deny shredding tools like sdelete from thrashing files on disk. As an example shown below, we see the adversary trying to shred the malicious Firefox Installer.exe file from the downloads directory. Sysmon stepped in here and denied the operation.
In event logs, we see the following. Sysmon blocked the shredding operation.
Conclusion
Sysmon is an excellent telemetry tool that can serve as a backup if security solutions are disabled. I REALLY LOVE SYSMON AND OLAF HARTONGS MODULAR CONFIG!
With EID like 27 or 28, Sysmon can for the first time intervene in the execution of processes and successfully prevent malicious attempt of executing unwanted files. The tool could then serve as a backup, especially in critical infrastructure. However, there are some bypass options and you should test in advance how the blocking of the files behaves, as we saw described above. Although the process can be stopped, many programs can continue to run and various routines are executed before the process is stopped. In addition to artifacts, registry entries can also be generated or the process continues due to a name change.
Nevertheless, I am excited about how effectively a telemetry tool can support security at low cost. Sysmon is not only free, but installation is simple. The configuration can be quickly adapted and rolled out. One can build specific configurations that can perform a specific task in order not to generate too much telemetry, but in an emergency to provide additional valuable information for further investigations. In addition, you can then use the knowledge gained from the tests to create robust detections, such as in the case of artifacts found in the system, which then indicate that an attacker tried to install AnyDesk, but Sysmon prevented this. The hashes and executable are emphemaral i.e. can change at any time. The configuration would have to be kept up to date or, as mentioned, can be used as an emergency tool for the incident expert to prevent further encryption or attacks as quickly and effectively as a backup, for example if EDR is not running on critical infrastructure applications or the software solutions are disabled and you want to make sure you have an effective backup.
