Monitor and keep track of Windows executable files (MZ files) which are dropped onto the hard disk. MZWriteScanner is a forensic analysis driver that detects when executable files (containing a MZ header) are written to your hard disk. MZWriteScanner literally turns any Windows PC into an active attack detection probe. Automatically analyze MZWriteScanner's log file periodically to detect possible attacks. Take advantage to defend attacks at an early stage and protect your IT systems. We implemented no black-box design, you can fully peek into the logs and process them as you want and regarding your needs. http://excubits.com/content/en/products_mzwritescanner.html
It's a good tool for tracking files dropped to hard disk. After enabling MZWriteScanner with [LETHAL] and [SHA256] i tried to drop an application to C:\dropped_executable\ Code: *** excubits.com demo ***: 2017/02/16_21:28 > W:C:\Program Files\totalcmd\TOTALCMD64.EXE > C:\dropped_executable\DriveLetterView.exe > a36885e04b3ad2609f36d9095c64d69516ec1981e1b181b0429fa47499270b0c Here we see the path of the application which has dropped the executable, the path of the dropped file and the calculated SHA256-checksum. Now it simply blocks the execution of the dropped file (and the user can see an error message on the screen): Code: *** excubits.com demo ***: 2017/02/16_21:28 > X:C:\Program Files\totalcmd\TOTALCMD64.EXE > C:\dropped_executable\DriveLetterView.exe Before enabling MZWriteScanner, i have copied the same file to different places. Are theses files blocked too? Yes, no matter where the file is, it is blocked (even if it's in a "trusted location") Code: *** excubits.com demo ***: 2017/02/16_21:29 > X:C:\Program Files\totalcmd\TOTALCMD64.EXE > C:\Program Files\Excubits\DriveLetterView.exe As soon as MZWriteScanner has calculated the checksum of a dropped file, all executions of a file with the exact same checksum are blocked. No matter where the file is located. This also means, MZWriteScanner has to calculate checksums for all executables which are about to be executed on the system. If the checksum of the dropped file is the same checksum of the file which is being executed = Execution is blocked. That's the reason why it was able to block the file: "C:\Program Files\Excubits\DriveLetterView.exe" and on all other locations. Not only executables, but dll's are monitored too. Better: All executable files which contain a MZ header (.exe, .dll, .sys, .tmp, ocx, etc.). But the file does not even need an extension to be monitored from MZWriteScanner. Because of performance reasons i switched to [#LETHAL], but i keep MZWritescanner as an additional logging-tool.
Have to tinker with this one. Pete, your comments in the CommandLineScanner thread were meant for MZWriteScanner then?
Yes that is correct. what you have to do is in non lethal mode, look at what's in the log file when you boot, and do stuff. Then whitelist it until you run stuff and the log file is clean. Bingo you are done. A file gets dropped on and you get an alert. And until you delete the log, the sucker won't run for love nor money. I've running malware against it and it's boring. Can't run. And if you let it run the minute the malware drops any file game over. Even most of the scripts end up dropping something, and get shut down. I have to say Florian is amazing.
Can someone help me with whitelisting syntax? First without shortening the line with wildcards. Then with wildcards. Code: *** excubits.com demo ***: 2017/02/17_08:03 > W:C:\Program Files (x86)\Google\Chrome\Application\chrome.exe > R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Temp\4692_22908\software_reporter_tool.exe > b1dd61e68b57a6a50249240dd350a432d6a82dca9597a333d36800729ca0a83d *** excubits.com demo ***: 2017/02/17_08:03 > X:C:\Program Files (x86)\Google\Chrome\Application\chrome.exe > R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Google\Chrome\User Data\SwReporter\16.92.2\software_reporter_tool.exe
Try these. R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Temp\4692_22908\software_reporter_tool.exe R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Google\Chrome\User Data\SwReporter\16.92.2\software_reporter_tool.exe I don't see a way I'd use wildcards. Certainly not in the temp one. If those work I'd call it quits
"X" in the following directories can change from time to time, so it's better to use wildcards: "\Temp\<XXXX_XXXXX>\software_reporter.exe" and: "\SwReporter\XX.XX.X\" Let's begin: Code: 1) without wildcards: R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Temp\4692_22908\software_reporter_tool.exe R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Google\Chrome\User Data\SwReporter\16.92.2\software_reporter_tool.exe 2) with wildcards: R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Temp\????_?????\software_reporter_tool.exe R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Temp\*_*\software_reporter_tool.exe R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Temp\*\software_reporter_tool.exe R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Google\Chrome\User Data\SwReporter\??.??.?\software_reporter_tool.exe R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Google\Chrome\User Data\SwReporter\*.*.*\software_reporter_tool.exe R:\Sandbox\MrX\Chrome_MrX\user\current\AppData\Local\Google\Chrome\User Data\SwReporter\*\software_reporter_tool.exe 3) Some more variations: R:\Sandbox\*\user\current\AppData\Local\Temp\*\software_reporter_tool.exe R:\Sandbox\*\user\current\AppData\Local\Google\Chrome\User Data\SwReporter\*\software_reporter_tool.exe R:\Sandbox\*\user\*\Local\Temp\*\software_reporter_tool.exe R:\Sandbox\*\user\*\Local\Google\Chrome\User Data\SwReporter\*\software_reporter_tool.exe R:\Sandbox\*\Temp\*\software_reporter_tool.exe R:\Sandbox\*\Chrome\User Data\SwReporter\*\software_reporter_tool.exe R:\Sandbox\*\software_reporter_tool.exe
I might see if I can write some code which can bypass this from logging a dropped PE (therefore has the MZ signature) from user-mode next week.. I'll let you know if I can lol
If an .rar-archive (with executables in it) is extracted to a "non-blacklisted place", it is not monitored from MZWriteScanner. So an anti-exe can still be useful.
I had asked a question, and figured it out myself, so I forgot it. One thing Florian told me that does indeed make an AE crucial is that if something is dropped and blocked, that is cached, and on reboot the cache is reset so the block goes away. That makes the AE crucial
Yes, that's important to know about MZWriteScanner. After a simple reboot or a restart of the service, it "forgets" all previous blocked files/hashes.
Sounds like it's worth playing with. re Excubits other products, I think I'll pass on all the configuration required for Bouncer and MemProtect though, and leave that to AppGuard. I do love and rely on FIDES though to protect my external USB backups.
Morning all! Due to a problem I'm having (currently in Florian's capable hands) my confusion abounds with the use of WHITELISTing with this driver. In looking at Mood's example, are you whitelisting specific MZ files that can never be launched, or whitelisting EXEs that can drop anything and have it work when needed. I BLACKLISTed a folder for test purposes and sure enough, when an application dropped an MZ file into the folder, it was logged along with the hash of the MZ, and when the MZ attempted to run, it was blocked. This is what I expected with a BLACKLIST entry. But the purpose of the whitelist entry still confuses me a bit. What is its main purpose?
As I re-read the comments above, it appears MZ is running in a DEFAULT BLOCK MODE if the INI has no specific rules associated with it. Then you add WHITELIST rules to allow those things being blocked, to run when necessary. If that's the case, then I reverse my question, what's the purpose of the BLACKLIST rules? Everything seems to be blocked unless you enable it with a WHITELIST rule... yes?
Of the top of my head, the first example that came to mind would be if you whitelisted a rather large folder that had many sub-folders. Let's assume in this case that there was one of those sub-folders within that whitelisted area that you still wanted specifically blocked. In this case example, the blacklist rule would take priority over the wider whitelist rule. Therefore that larger folder would still be whitelist, yet one of those many sub-folders as specified in blacklist would be blocked. Just adds a bit more granularity with rules, I suppose.
Yes, all is blocked by default, the blacklist can be empty. But you can use Blacklist rules to blacklist white-listed locations. C:\Downloads\ is whitelisted, but dropped files in C:\Downloads\*Firefox\ are blocked. If we want to whitelist the directory 1 within the blacklisted Firefox-directory, we can add a priority whitelist-rule for: C:\Downloads\Firefox\1* But if we don't want to allow directory 2 within the whitelisted 1-directory, we can add a priority blacklist-rule: C:\Downloads\Firefox\1\2* Edit: added priority rules Code: [WHITELIST] !C:\Downloads\Firefox\1* C:\Downloads\* [BLACKLIST] !C:\Downloads\Firefox\1\2* C:\Downloads\Firefox\*
Yea, right... that was really clear in the README The main thing missing in the README was the fact that the entire System was BLACKLISTed to begin with... with that information, your explanation above makes some modicum of sense. Florian and the gang need to take some time off from driver development and put it into some documentation...