Here is my current config just for curiosity sake. Spoiler: MZWriteScanner.ini Code: [#INSTALLMODE] [#LETHAL] [LOGGING] [FORENSICS] [#LOGFILETOUCH] [SHA256] [#READBUFFERX16] [FASTHASH] [WHITELIST] # Base System Rules C:\Program Files (x86)\*>C:\Program Files (x86)\* C:\Program Files\*>C:\Program Files\* C:\Program Files\*>C:\Program Files (x86)\* C:\Program Files (x86)\*>C:\Program Files\* C:\Windows\*>C:\Windows\* C:\Windows\*>C:\Program Files (x86)\* C:\Windows\*>C:\Program Files\* C:\Program Files (x86)\*>C:\Windows\* C:\Program Files\*>C:\Windows\* # Default MZWriteScanner Rules C:\Windows\Temp\MPGEAR.DLL C:\Windows\Temp\MPENGINE.DLL C:\Windows\Temp\MPGEAR.DLL C:\Windows\System32\MpEngineStore\*.sys C:\Windows\SoftwareDistribution\Download\* C:\ProgramData\Microsoft\Windows Defender\Definition Updates*\mp* C:\Windows\Temp\*-Sigs\*.vdm C:\Windows\Temp\*-Sigs\mp* C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\mp* C:\ProgramData\Microsoft\Windows Defender\Definition Updates\* C:\Windows\Temp\*-Sigs\GAPAENGINE.DLL # Extra C:\Users\*\AppData\Local\Temp\ALSysIO64.sys C:\Windows\System32\*>C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\* C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\*>C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\* C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\*>C:\Windows\System32\* C:\Windows\System32\MRT-KB??????*.exe>C:\Windows\Temp\????????-????-????-????-????????????\MP*.DLL C:\Windows\*>\\?\Volume{????????-????-????-????-????????????}\EFI\* [BLACKLIST] !D:\RemoteDLL\MZWS-Tests\denied\* [EOF] Please keep in mind that my experience with MZWS is very minimal compared to some of the other users here. I've only been using MZWS for a few days of testing right now. So this is quite preliminary and changing daily still while I learn more and still planning on what to protect and when.
And My config file. Code: [#INSTALLMODE] [LETHAL] [LOGGING] [FORENSICS] [SHA256] [WHITELIST] C:\Program Files (x86)\ASUS\AXSP\1.01.01\PEbiosinterface32.dll C:\Windows\Temp\UDD85A3.tmp C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\Microsoft\UPnP Device Host\upnphost\udhisapi.dll C:\Windows\System32\udhisapi.dll C:\Windows\Temp\UDD*.tmp C:\Users\Pete\AppData\Local\Temp\AJC-*.tmp C:\ProgramData\CyberLink\* C:\Users\Public\Documents\CyberLink\* C:\Users\Pete\AppData\Local\Temp\SNAPSHOD*.sys C:\Users\Pete\AppData\Local\Microsoft\Windows\WebCache\* C:\Users\Pete\AppData\Local\Temp\TMP3E9Ausrtmp C:\Program Files (x86)\Zentimo\Zentim* C:\Windows\SoftwareDistribution\DataStore\Logs\tmp.edb C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorsvw.exe C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe C:\Windows\assembly\NativeImages_v4* C:\ProgramData\Emsisoft\Updates\* C:\Program Files\Emsisoft Anti-Malware\* C:\Sandbox\Pete\Opera\user\current\AppData\Local\Temp\* C:\Sandbox\Pete\Opera\user\current\AppData\Roaming\Opera Software\* C:\Users\Pete\AppData\Local\Temp\{16AA8FB8-4A98-4757-B7A5-0FF22C0A6E33}_1600_*\dbdata16.dll c:\Program Files\Malwarebytes\Anti-Malware\* C:\ProgramData\Malwarebytes\MBAMService\* C:\Windows\System32\drivers\SET*.tmp C:\Windows\Temp\OLD*.tmp C:\ProgramData\NoVirusThanks\EXE Radar Pro\Data\* C:\Windows\System32\drivers\farflt.sys C:\Windows\System32\drivers\MBAMSwissArmy.sys C:\Windows\System32\drivers\mbam.sys C:\Windows\System32\drivers\mbae64.sys C:\Windows\System32\drivers\mwac.sys C:\Windows\System32\drivers\o_Oo_O??.sys C:\Windows\System32\drivers\MBAMChameleon.sys C:\Users\Pete\AppData\Local\Steam\widevine\widevinecdmadapter.dll C:\Users\Pete\AppData\Local\Temp\HitmanPro_x64.exe C:\Windows\System32\drivers\hitmanpro37.sys C:\ProgramData\Intuit\QuickBooks 2017\Components\DownloadQB27\ULIP0\.update\.target\* C:\Program Files (x86)\Intuit\QuickBooks 2017* C:\ProgramData\Microsoft\Search\Data\Applications\Windows\tmp.edb C:\ProgramData\Adobe\ARM\*\ServicesUpdater.exe C:\Windows\assembly\NativeImages_v2.0.50727_64* C:\Windows\assembly\NativeImages_v2.0.50727_32\* C:\Windows\Temp\CS1.tmp* C:\Windows\Installer\MSI*.tmp C:\Users\Pete\AppData\Local\Temp\264dsse3* C:\ProgramData\NoVirusThanks\EXE Radar Pro\Data\* C:\Sandbox\Pete\FireFox\drive\C\Program Files (x86)\Mozilla Firefox* C:\Program Files (x86)\Steam\package\tmp* C:\Program Files\Heilig Defense, LLC\RansomOff\HDSigCheck64.dll C:\Program Files\Heilig Defense, LLC\RansomOff\updates\HDRansomOffDrv.sys C:\Sandbox\Pete\FireFox\user\current\AppData\Roaming\Mozilla\Firefox\Profiles\* C:\ProgramData\Heimdal Security\Heimdal Agent\* C:\Program Files (x86)\Heimdal\Heimdal.AgentLoader.exe C:\Config.Msi\4a* C:\Windows\System32\drivers\OSArmorDevDrv.sys* C:\Program Files (x86)\Steam\SteamApps\common\* C:\Program Files (x86)\Steam\SteamApps\common\RailWorks\RailWorks.exe C:\EEK\* C:\Users\Pete\AppData\Local\Temp\EEK\a2temp\* [BLACKLIST] [EOF]
@WildByDesign @Peter2150 Thanks for these config files, much appreciated. I'll take a look and decide on an approach to my own. I'll probably start from scratch by looking at the logs and building up from there but at least I can see how others have done it. Out of interest does a line like C:\Program Files\*>C:\Program Files\* mean that anything within Program Files can write to Program files? If so is that secure? What if a malware file finds it's way to that folder?
Correct, anything from within Program Files can drop binaries to Program Files. You're right it is not very secure at all. It was just a more permissive baseline that I opted to start with, particularly for the Windows Updates yesterday. I will definitely need to wind down and tighten this ruleset for sure.
This new hidden function is far more interesting than I had initially anticipated. Certainly it is only for a certain subgroup of users for forensics and such but for specific scenarios it is quite interesting so far. I wont use it all the them, but I will turn it on from time to time depending on the situation.
Running ok so far even with very small ini file. Not as many log entries as expected but then windows hasn't tried to update anything yet except virus definitions. Some of the default rules seem to be almost correct but not quite. For example, there's the following rule for virus definition updates: C:\Windows\Temp\*-Sigs\*.vdm However the actual location on my system is: C:\Windows\Temp\78C76GH2-00CA-5634-67S3-5EDD748CFA7E1f90.1d3gh67e2314434c2\mpasdlta.vdm. As you can see the string doesn't contain the -Sigs component. How is this best dealt with? Would you use a * wildcard for this string or multiple ? wildcards. Every time svchost starts a process while installing updates I get a line such as this: C:\Windows\Temp\UDD3422.tmp Problem is the string seems to change each time requiring either multiple entries or wildcards. These wildcards make the system intrinsically less secure but there doesn't seem to be any other way of dealing with these situations. Is this a necessary compromise?
I would consider something like this: Code: C:\Windows\Temp\????????-????-????-????-????????????*\mpasdlta.vdm or Code: C:\Windows\Temp\????????-????-????-????-????????????*\*.vdm I am not too familiar with this particular file though so just a guideline/idea here. Starting with "mp" I assume it is something to do with Windows Defender (I don't use Defender). Anyway, there are many ways in which you can go with wildcards to make things either more lenient / less strict or more detailed and potentially more strict. It all comes down to preference and different usage scenarios. Those ? wildcards will cover for the changing characters/numbers, similar to DISM.
This one is a little bit more generic and in this case I would probably feel more comfortable with a parent rule to make it more strict. You would have to check the logging to be specific, but this is just an example: Code: C:\Windows\System32\svchost.exe>C:\Windows\Temp\???????.tmp If the logs indeed show that svchost.exe is the parent that is dropping that .tmp binary.
Yes, thanks both, I've gone down the road of as restrictive a wildcard definition as I can make for a particular file/path. The less general the better.
Cool share. I like their driver and many other excubit drivers so much better than running package security programs w/ rare exceptions of items like NVT Heilig Defense-Sandboxie-Shadow Defender <--Only when needed actually. (On-Demand) But getting back to the real-time goods, your method Pete seems more convenient instead of trying to pick and choose in another fashion. One file that does the work of many is the way to go. Seems TEMP houses a few important items used for our units. SNAPSHOD*. <-- You too?
Yes svchost is dropping the file. I forgot about parent process rules but that would tighten it up a lot, thanks. Bullet proof almost I would say.
I've got so far creating a whitelist for windows 10 so that things like updates to windows defender, windows apps and windows itself work seemlessy with MZWriteScanner turned on, but it's a rather involved process. Windows keeps throwing up more and more things that need an exception and some of them use GUID strings which don't seem to work with * wilcards and wildcards probably shouldn't be used with them anyway as they are a security feature. I'm wondering if these strings need a special wildcard format. I was trying to think of a better and easier way of using MZWriteScanner and it dawned on me that most of the time we're trying to protect ourselves from threats from specific sources, mostly the browser. I'm not so worried about software I download as it's always from a reliable source and if it was infected MZWriteScanner doesn't help with that kind of threat because we run those installers manually. Anti-virus and programs like OSArmor are more efective in that situation. So why not just whitelist the C drive and put in specific blacklist entries for the browser such as the following for Firefox: C:\Program Files\Mozilla Firefox\firefox.exe>c:\* This means that any file downloaded by a firefox process is automatically hashed and blocked. This would be the case even if malware took over a firefox process or a firefox extension had been infected with malware, because the process would still be seen as a firefox process. Any malware file would therefore be blocked. The malware would have to start a seperate non-firefox process to get a file on to the drive and run it. I'm not sure if that's possible without first downloading a file. If it's not then this would be a very secure way of using MZWriteScanner. It would be necassary to add priority whitelist entries to allow program updates once a program is blacklisted and MZWriter would have to be turned off when installing downloaded software, but it's a much simpler approach than trying to whitelist every windows process that gets blocked by MZWriterScanner.
I got a response by the developer and this idea will be taken into account for the next beta (if no issues arise while implementing it) There will be an option to turn this feature on and using of Hashes would be possible. For example: Code: [WHITELIST] # c:\Program Files\Mozilla Firefox\firefox.exe>C:\Downloads 8019EA7668990E71A123FA93AE410611604F2C73F3BDE0CD70FC6456AA5487EE>C:\Downloads = We allow only a certain hash (this is the hash of firefox.exe) to drop files to C:\Downloads If the file (the file which is allowed to drop files to C:\Downloads) has been modified the hash has also changed and all dropped files are not whitelisted anymore.
Yes this would work if something modified the firefox.exe file but it wouldn't stop an infected firefox extension from downloading something because that would not change the hash of firefox.exe. Neither would it stop a script on a webpage downloading a file and running it. Blacklisting the firefox process with C:\Program Files\Mozilla Firefox\firefox.exe>c:\* would.stop both those attacks because the downloaded files would be blocked.
If i download something with the webbrowser i have the intention to launch downloaded files at a later time. But if every downloaded file is blacklisted, MZWritescanner has to be turned off (it is not protecting now and the driver "forgets" previously hashed files) In addition the user must also remove (legitimate) files from the $FORENSICS-directory. For me, this kind of configuration seems to works against me. if there is some exploit on a website then some other security application must do its job (anti-exploit application, ...) Or, if the browser tries to execute downloaded files then Memprotect is a much better candidate to mitigate this. Preferrably an Anti-Executable (Bouncer for example) can also monitor files. Code: [WHITELIST] # c:\Program Files\Mozilla Firefox\firefox.exe>C:\Downloads 8019EA7668990E71A123FA93AE410611604F2C73F3BDE0CD70FC6456AA5487EE>C:\Downloads If a certain folder is whitelisted (C:\Downloads) downloaded files to this folder will be whitelisted and can be installed without having to turn MZWritescanner off and previously blacklisted files will still be blocked from launching. If files are dropped to other folders they will be automatically blocked. If the file (hash) has been changed, dropped files will be automatically blacklisted. In terms of usability (MZWritescanner doesn't need to be turned off before launching of files; it might even lessen the security if MZWritescanner has been turned off [reminder: the kernel driver forgets previously hashed files]) i think this is a better approach than blacklisting of all downloaded files. If there is some exploit on a webpage, then be it ... In this case some other installed security application intervenes. There are a lot of attack scenarios but MZWritescanner can't mitigate all of them, or shouldn't be used as the only application to mitigate them (other security applications may be more suitable for protecting the browser against exploits and they are able to prevent the attack in a much earlier state)
No, current beta does not "forgets" previously hashed files, the hash is in $FORENSICS-directory - after restart of driver MZW still know the previous hashed file. I think it depend on your user scenario. If you are power user then it is likeley you download files with browser and you will also start them. so MZW configuration in this way is not an option. But if you are "just a office user" MZW and such a config make sense, because in normal browsing session you - as normal office user - dont and shouldnt download and run exeutable. also if you limit Adobe PDF Reader and MS Office (or Libre Office) - all of these dont need to download and run executable in normal use cases. I would bet that if there is any executable downloaed in normal user session it is malware, so here MZW really helps to reduce attack risk. So it highly depends on your use case. I think power user is not happy with MZW, because there are many executables written on disk and started by user, because he really has intentions to start them. There I would suggest more AntiEXE like NVT, AppLocker/SRP or Bouncer/Tuersteher, but there it also depend on how many executable you download. It can also be pain to whitlist new executables all the time, if you are a software tester/programmer, there can be lot of executables you have to whitelist during a week. Here I would even not use any AntiEXE, instead a VM and here creating Snapshots is more secure and easier to make use of. (as said before: depends on user scenario)
Only in a perfunctory way. I installed a download manager extension in firefox just to check that extensions don't bypass the firefox.exe in some way. The downloads were blocked as expected. All extensions in firefox and all plugins like flash run in their own firefox process I believe and therefore anything downloaded by these processes should be blocked. I don't have access to a way of testing more thoroughly, but if you know of any means of testing these senarios I'd be happy to test them. I can re-image my hard disk if it doesn't block as expected.
Well the thing that bothers me is you are assuming any and all bad files will come via Firefox, and I wouldn't want to trust that assumption. I've only white listed that which was logged and as you saw it's a bit, but this way it's alerting on anything. More hassle yes. But I think safer.
@mood, If you read my posts in this thread you will see I'm trying to make MZWriteScanner useable on an active windows 10 system. MZWritScanner blocks huge numbers of files such as windows updates, windows app updates as well as many background processes like cleanmgr.exe. It's therefore necessary to either have a very comprehensive whitelist or turn all updates on the computer off or use a simpler scheme like blocking specific program processes and whitelisting the hard drive. It may actually be impossible to create a whitelist to work with windows updates because many of the update files that come in the format KBxxxxxx write their own files to the disk and these can literally be anywhere on the disk and different for each update, so whitelisting them is not practical unless you use ridiculously wide wildcard paths, which puts huge holes in your security. I'm surprised you haven't noticed this because your updates will likely be corrupted unless you turn MZWriteScanner off and your $FORENSICS file will get larger and larger until it becomes completely unwieldy due to the huge number of hashed system files. The new beta doesn't forget hashed files at all unless you delete them from the $FORENSICS folder. I don't mind switching it off to install a program if it makes using MZWriteScanner practical. In fact I like the way it warns you if you haven't switched it off when you install a program. By doing things this way it hardens your browser considerably.
I did mention that malware would have to start a non-firefox process to download a file and run it, which may well be possible if there was a browesr or extension vulnerability, but it would require a more sophisticated attack than a drive by download through the browser itself.
