- Mar 29, 2018
Hey Guys, sorry I have been away, I have been finishing up the CommandLineCloud feature, and it is fully up and running now, so command line blocks should be few and far between now.
In this version, the MpSigStub.exe issue is fixed, along with a fix for when a firewall was blocking WLC and VoodooAi.
Thank you guys!
Hey guys, here is 6.06b. Just a few small bug fixes.
BTW, since we are almost finished working out all of the last few bugs in VS 6.0, and since that is the only thing we discuss on this forum, I was thinking we might want to close the forum and if you guys have any issues, you can just email me directly? What do you guys think? Thank you!
Here is a version that should fix the AutoPilot bug that @harlan4096 found, and actually it probably affected other file types than just .jar. The bug was related to when I recently replace VT with WLC in VS's Rules (similar to the bug that @Lenny_Fox recently encountered). It's funny, you can actually disable the one default rule in VS then the .jar file is blocked, so if we would not have had the one default rule, it probably would have been a very long time before we discovered this bug.
I did not have the same .jar file that @harlan4096 tested with, so I used a different sample, but if it is okay with @harlan4096, it might be a good idea to test the first .jar sample again... because if for some reason the bug is not fixed then I would probably need to debug with the actual sample to make sure the bug is completely fixed before we continue testing. Thanks again!
Thank you Andy, that is a great idea! We might want some kind of work around like maybe a captcha (even though they are a real pain) just in case a file needs to be allowed right away. But either way, creating an additional obstacle of some kind for unknowns would increase VS's overall security dramatically. Maybe we can brainstorm and see what everyone can some up with for an additional obstacle for unknowns.Hi guys,
What do you think about adding to VS the autoblock feature for some cases (the custom non-default setting)? For example:
View attachment 250254
View attachment 250255
The number of days can be also configured. A similar defense for unsafe files (unknown classification) is applied in Comodo and WD (ASR rule) for EXE files. But in VS it could be applied for cases with unknown classification.
There was discussion about it in the thread:
(1) Q&A - Windows Defender Delay Protection. | MalwareTips Community
One does not exclude another. Every proactive detection has some space between "probably malicious" and "probably safe". This space is usually the largest for scripting attacks (generally for non-PE executables).For me a working way to get possible false positives reported and fixed would be more important. Seeing an "unsafe" for a file for days doesn't help me when I consider it a fp.
How funny .This hurted my soul Luckily I have a premium license
They won't overwrite the default rule, and actually, you can delete the default rule if you want, and add 3 of your own. I really just added the default rule as an example.@danb
Regarding the 3 rules in free, I have a question.
Do they overwrite the default rule or are they applied before the default rule?
In the latter (the default rule as a catch all last rule to be applied) drop through logic errors are prevented (e.g. user not defining a rule for certain folders)
Thanks to be sure I could write three rules in this orderHow funny .
They won't overwrite the default rule, and actually, you can delete the default rule if you want, and add 3 of your own. I really just added the default rule as an example.
You can also move rules up and down with the little arrow icons to the right. I hope that answers your question, but if not just let me know!
Interesting suggestions, thank you! This is kind of how AutoPilot and Smart OFF modes already work, and it gets pretty complicated, but I would like to try to understand the rules you created a little better to see if we can optimize your rules or AutoPilot / Smart OFF better.Thanks to be sure I could write three rules in this order
1. Allow rule for Microsoft Windows signed system wide
2. Block rule for C:\Users with low AI rating (effectively the default rule reversed: block everything above AI score of 33)
3. Allow rule for C drive
This would have the effect that
a) All Microsoft Windows signed will be allowed everywhere
b) All programs in C:\Windows, C:\ProgramData, C:\Program Files and C:\Program Files (x86) will alows be allowed
c) All programs in C:\Users will have to meet VoodooShield's default
d) All other programs in my other data partitions will also have to meet VS default rule (e.g my F, M and R drive)
Remember I have ConfigureDefender running on MAX (with ASR rules and Cloud level on Zero-Tolerance) and SimpleWindowsHardening blocks execution of scripts in all user folders (C:\Users and other data partitions).
As posted earlier, it would be interesting to see when DanB would launch a zero config VS-variant which is specially tuned as companion for Microsoft Defender. It would be interesting to see whether a mobile app like micro-licensing scheme would work on the desktop market also.
Question to MT-forum users: would you pay for a zero config VS-version which would only cost 1,95 (the price of a hamburger only) yearly?
For a small company like your's Dan selling half a million 2 dollar licenses annual would be a nice extra on top of your VS pro generated licenses? In the mobile market small (often one man band) company's are able to generate enough income using micro-licensing (1 to 5 dollar licenses are also called micro-licenses because the below 5 dollar licenses are paid with micro-payment systems).
For your first rule, VS already auto allows Windows System files, except for example we do not want to globally allow wscript (along with many other vulnerable processes). So I guess what I am asking... is VS blocking something in Windows that it should not be blocking? Windows System files are signed with a special catalog (catroot) signature, which is why when you right click on most Windows System files to check the digital signature, that tab is missing. So Windows System files are actually signed, even though they do not have digital signature that you can see in the file properties. I think Microsoft does it this way to make signing of Windows System files easier... they basically sign all of the files when they build Windows.
Yes, but I now read that programs with same signer of already whitelisted programs are allowed also. So what I had in mind is already realized, no need to auto allow everything from C and exclude C:\Users wth a blockHaving said that, there are a lot of downloadable Microsoft products, such as Process Explorer that is signed by Microsoft with a standard digital signature. Are these the types of files that your first rule is intended to cover?
For your second and third rules, this happens automatically with VS in AutoPilot and Smart OFF modes, even if you delete the one default VS Rule. But if there is a way we can optimize it, please let me know! Please keep in mind that certain folders such as AppData and ProgramData are common hiding spots for malware, so these require special attention.
Maybe the best thing to do is to run VS on AutoPilot for a while, and if blocks anything that it shouldn't, we can figure out if it really should have been blocked or not, and if not, I can fix the block for AutoPilot and Smart OFF modes (these two modes act almost identical to each other). Either way, this should be a lot of help to optimize AutoPilot and Smart OFF and your custom VS Rules. Thank you!
Very cool! Yeah, there are tons of hardcoded rules that makeup AutoPilot and SmartOFF modes that we have tweaked and optimized over the years, and they have become a little complex under the hood. But basically the goal was to essentially do what you were doing with the 3 rules. It would be impossible to recreate everything that AutoPilot does in 3 rules, but if someone really wanted to, they could create 20-30 or so rules to emulate AutoPilot and customize it to their liking. That would take a lot of work though.Nope, this is exactly what I had in mind, thanks for the educational explanation
Yes, but I now read that programs with same signer of already whitelisted programs are allowed also. So what I had in mind is already realized, no need to auto allow everything from C and exclude C:\Users wth a block
Well than I will be using the three rules to tighten up my F (files) M (Media) drives, I will keep the default as last. On the F file no execution should ever appear (an slower SSD drive for my Office documents) and on the M-drive also no execution should appear, only with some large updates Microsoft sometimes used the M drive (it is a 2 TB HDD) because it is the drive with the most free space.
User request: maybe you could add a block execution for NON-OS partitions excluding Microsoft Windows and Microsoft hardware/driver co-signing
Marketeer remark: you are bonkers when you implement above request, because VS Free would be a near perfect whitelist solution.