This is caching issue. If you have executed eg. Veracrypt, then veracrypt.sys is loaded in kernel. Windows keeps driver there; if you drop the same veracrypt.sys meanwile and then start it, operating system does not load the driver again. Just restart computer (not hibernation reboot etc.) and then drop a driver .sys file, if you then try to start driver it will fail. In example of veracrypt: reboot machine, copy & paste the veracrypt.sys somewhere (must be blacklisted and logged by MZW), then try to start VeraCrypt and mount volume. Should block veracrypt.sys then.
Thanks, logical explanation I have dropped the drivers for showing that MZWriteScanner is able to detect them but i have also made some other tests some days ago and have blacklisted "C:\Windows\System32\drivers\NirSoftOpenedFilesDriver.sys" and also have dropped it (This is a driver from the NirSoft utility "OpenedFilesView") But it has failed. Why? The driver was already loaded into memory before my test and yes that seems to be reason why it wasn't blocked. Edit (begin): "Bouncer, CommandLineScanner and MZWriteScanner are able to block drivers as long as they were not loaded into the kernel before." See: #163 Edit (end) (Sidenote: Today after exiting of OpenedFilesView the driver is always removed from memory. I'm not sure why it wasn't the case the last time i have tested it [=driver is already loaded, MZWriteScanner doesn't block it]). Anyway,... This means that MZWriteScanner is able to block drivers (as long as they were not loaded before) Important: But one thing to note is that it will only function if: a) the driver has been dropped to a blacklisted place before (=it is now blacklisted) Normally ("C:\Windows\System32\Drivers\*") is on the whitelist and if a .sys binary/driver is embedded into the executable as a Resource and is then directly dropped to C:\Windows\System32\Drivers\ after the executable has been launched it will not be detected and blocked. b) the driver is in the $FORENSICS directory. In the case of the driver of "OpenedFilesView": Code: c:\Windows\$FORENSICS\f2b3689832c08a603e8d505982597bd06bec24b48d4f014682f82fa4d06ec6aa = Even if the driver has been dropped to a "whitelisted place" it will be blocked by MZWriteScanner. c) the driver is blacklisted in the [BLACKLIST] section: Code: [BLACKLIST] C:\Windows\System32\drivers\NirSoftOpenedFilesDriver.sys = a driver which is loaded from the above place will always be blocked. This means the driver doesn't need to be dropped to a blacklisted place (a) or need to be in the $FORENSICS directory (b) to be blocked. As a reminder, a) b) and c) has no effect it the driver is already loaded into memory. Demonstration (a driver has been dropped, it is now blacklisted and it can't be loaded): Code: The file has been dropped and is detected: 2018/03/06_11:25 WX C:\Program Files\totalcmd\TOTALCMD64.EXE C:\!driver\NirSoftOpenedFilesDriver.sys f2b3689832c08a603e8d505982597bd06bec24b48d4f014682f82fa4d06ec6aa Launching of the tool (it is then dropping the driver) and MZWriteScanner it: 2018/03/06_11:25 WX C:\test\OpenedFilesView.exe C:\Windows\System32\drivers\NirSoftOpenedFilesDriver.sys f2b3689832c08a603e8d505982597bd06bec24b48d4f014682f82fa4d06ec6aa The driver is blocked (XW) 2018/03/06_11:25 XW (NULL) C:\Windows\System32\drivers\NirSoftOpenedFilesDriver.sys f2b3689832c08a603e8d505982597bd06bec24b48d4f014682f82fa4d06ec6aa
This is great news and also I appreciate the great detail and explanation. So this will be good in situations where a driver .sys file is dropped to AppData/Temp folders or Windows\Temp folder as well prior to the malicious driver being installed/initiated. I suppose we could also consider adding blacklisted hashes for known malicious drivers. This is quite powerful. But as per any of the Excubits' drivers, the power ultimately comes down to the users' own rulesets and specifically creativity with those rulesets.
Here's a good app to check to see if MXWriteScanner can detect on-the-fly kernel mode driver loading - Process Explorer. First make sure it is not whitelisted; suspect it is not. Next, delete from System32/Drivers any file named PROCEXPxxx.sys where, xxx is any number. Reboot. Open Process Explorer. It will write PROCEXPxxx.sys to the System32/Drivers directory and then load the driver. -EDIT- Need someone to verify if Process Explorer driver loading is detected by MXWriteScanner.
Oops. Appears I didn't explain fully. Need someone using MZWriteScanner and Process Explorer to verify what I posted.
It won't block it, because: (Edit (begin): With a proper configuration it could have been prevented. For example the parent-feature can be used: See #162: "If you have blacklisted C:\Users\Public\* to write executables anywhere (parent feature, see current beta) " See #163: "If you (or an application) has loaded a driver, you must have allowed to load it using high privileges beforehand. You have already made a critical decision in terms of your system's security. In general: MZWriteScanner is able to block drivers (as long as they were not loaded into the kernel before). Blog-entry from the developer (mentioned in #163 - Drivers: Kernel Blocking Behavior) Edit (end)) Exception 1) C:\Windows\system32\PROCEXP*.sys has been added to the blacklist. Now it will be blocked (XW): Code: the driver is dropped: 2018/03/06_23:16 WX C:\Users\Public\Downloads\procexp64.exe C:\Windows\System32\drivers\PROCEXP152.SYS 88e2e6a705d3fb71b966d9fb46dc5a4b015548daf585fb54dfcd81dc0bd3ebdc ... and blocked: 2018/03/06_23:16 XW (NULL) C:\Windows\System32\drivers\PROCEXP152.SYS 88e2e6a705d3fb71b966d9fb46dc5a4b015548daf585fb54dfcd81dc0bd3ebdc Exception 2) The file is in the "persistent cache". In this case a driver with the same hash will always be blocked, no matter where it has been dropped to: Code: file: c:\WINDOWS\$FORENSICS\88e2e6a705d3fb71b966d9fb46dc5a4b015548daf585fb54dfcd81dc0bd3ebdc 41.800 bytes -a-- But most probably the user has no blacklist entry for it, and there is also no file in the $FORENSICS-folder = the dropped driver isn't blocked by MZWriteScanner (as expected) ... and the driver is now loaded after launching of Process Explorer (monitored with Driver Radar Pro): Code: Driver: C:\WINDOWS\system32\Drivers\PROCEXP152.SYS Image Base: 0x6E080000 Image Size: 0xC000 Publisher: Sysinternals - www.sysinternals.com Description: Process Explorer MD5: CEC257DCAC9E708CEFB17F8984DD0A70 Signer: Microsoft Windows Hardware Compatibility Publisher
Thanks for the explanation. Sure, depend on how many changes you make. I have a very strict configuration and except for updates there is little to manage in everyday use. I run my system w MZW for some months w/o need to adjust the config, so after having a proper ini, there is not much action to do (in my case, can be different on your system)
Depends on your configuration. If you have blacklisted C:\Users\Public\* to write executables anywhere (parent feature, see current beta) which is okay for normal user, because normaly you do not drop and execute files from there - it will alert you. If you are a power user, download many tools and install many application this is not suitable and then you are right: it can be difficult and pain with MZW. I would suggest to then use [#LETHAL] mode: you can then still track what happens all the time w/o worries on blocked executables and drivers. but it depend on your security need: but I would guess if you install lot of tools and application there is already higher risk, so MZW would not giv extra security: if you allow to start exe, it is already to late. Here MZW can only help tackle what else happened, but wont provide extra security.
How and when our drivers block loading kernel drivers Drivers: Kernel Blocking Behavior March 08, 2018 http://excubits.com/content/en/news.html
@mood Thank you. Since you are more familiar with Pumpernickel/FIDES, would FIDES be another alternative method for catching kernel drivers (.sys) when they are dropped to disk in specific directories? I am just thinking of the different Excubits drivers and seeing how each driver in their own way would block either the disk write, installation, initiation/execution, etc. when it comes to rogue/malicious kernel mode drivers (.sys).
Hi WBD Pumpernickel doesn't detect dropped files. It blocks access to file in a directory that is block listed. For example I have my F and G drives black listed, and the whitelist my imaging programs. So nothing can access those drives either read or write unless the program is whitielisted.
FIDES: You can prevent files from being written to C:\Windows\*, applications can be restricted in a way that they can only write to specific directories, etc. Or this can be used (only for illustration): [BLACKLIST] *>C:\Windows\System32\Drivers\*.sys *>*.sys *\temp\*>C:\Windows\* For MZWritescanner the extension of dropped files doesn't matter. Even if the driver is dropped with a .tmp-extension it will be detected and blacklisted. This is a unique feature of MZWritescanner. But it can't prevent applications from writing of files to directories, FIDES can do it. They complement each other.
Great stuff, @mood . That is what I was thinking. You could prevent, for example, chrome.exe from drive-by-downloads or exploits dropping .sys kernel drivers or other attack vectors at an early stage. These are rules which I have wanted to explore recently but have not had the time yet. The possibilities with the rules are endless and I enjoy that kind of freedom of creativity and such.
Looks like they have released a new beta Did not have issue with network but will try the new version now. Maybe there is performance difference with new release.
New Beta of MZWriteScanner Change of architecture in MZWriteScanner March 12, 2018 http://excubits.com/content/en/news.html
It's been a while since I last tested creating rules for MZWS. I keep mixing it up with FIDES rules. Just to confirm, so when creating rules for MZWS there is no specifying of parent process ">" in these rules? There is no need for parent process rules with MZWS, I assume?
That said, some of us did ask for ability to whitelist at parent level #104 #114. Florian did say he would introduce this #121 (27 Dec 2017): We are happy to announce that we have 'hacked' on a first prototype of MZWriteScanner which supports parent checking. As soon as we feel comfortable with the driver, we will publish a first beta but not sure if it's in the latest beta ... I am still on the old version.
With the beta version of MZWritescanner for example the following rule can be used to "exclude" all executables which are copied with the filemanager: Code: [WHITELIST] C:\Program Files\totalcmd\TOTALCMD64.EXE>* Or applications can explicitely put on the blacklist and all executables which are downloaded by them are automatically blacklisted (even if the file is saved to a whitelisted location): Code: [WHITELIST] C:\Downloads\* [BLACKLIST] C:\Program Files\example\example.exe>* "Example.exe" is dropping a file to C:\Downloads\ = Blocked Firefox (or any other application) is dropping a file to C:\Downloads\ = not blocked.
