Re: VoodooShield v4 STABLE Thread
«
Reply #439 on: April 08, 2018, 11:58:19 am »
Quote from: gorblimey on April 06, 2018, 08:55:42 pm
Quote from: topo on April 06, 2018, 11:13:22 am
how would one know to allow or block the msiexe.exe file? what does it do? attch is info for dan
It's the Microsoft Installer package. It's almost certainly "protected", but in any case just leave it alone.
If you think it might be compromised, exit all of your AV suites: turn them off/disable them, then run an offline scan.
msiexec lives in many locations, this could take time.
I see your security app mentioned the program could be a hijack candidate. The bad news is that almost any exe file is a hijack candidate: notepad, calculator, wordpad...
This sort of thing brings up the subject of
Security 101: "Never assume your box is clean. You must assume it has already been penetrated, and your task is to mitigate the damage." Ideally, you start (over) with a fresh clean offline OS install. Then you add the security system of choice, and only then do you add your productivity apps/suite(s) and maybe register the OS online. At this stage you are desperately hoping the security suite is uncompromised...
Having said all that, assuming VS is installed on a clean box, it will protect you because anything that hijacks msiexec is not on the whitelist. It is possible that msiexec is also not whitelisted but OTOH it is a system file and gets close attention from VS anyway.
My personal experience is that all of these wonderful security suites are a complete waste of time on a good day and a major hazard on all other days. I use ZAM Free and MBAM Free separately to scan the system once a month, after which both are totally disabled (they have services) and VS is re-enabled to hold my hand for the rest of the month. As soon as Glasswire gets multi-user capabilities I'll install it, light up Windows Firewall, and enjoy the best protection on the planet.
Absolutely... I am not going to turn VS into a security suite or a Swiss Army Knife. I just think it would also be cool to add post execution behavior analysis to VS in a very unique way, especially since it is not like we are going to have to redesign VS from the ground up like we did in VS 4.0, which cause a lot of bugs. There will actually be very, very few new bugs introduced. Basically, now that VS is stable, there is not a chance that I am going to put the users or myself through a massive debugging process again.
In general, what I mean by this new feature that implements post execution behavior analysis is this...
First of all, from a high level, computers are machines that essentially perform one function... execute code. The only practical way to keep them safe is to only allow them to execute the code that you knowingly want them to allow. If you consider most or all of the non-Windows operating systems, they pretty much all operate on this principle, and typically require SU rights (e.g. password) in order for new executable code to be introduced / executed. Somehow, the cybersecurity industry as a whole, has abandoned this model in favor of a more user-friendly model, and somehow actually believe that they are able to sufficiently protect the system. This is where the cybersecurity industry went wrong, and the end result has been massive breaches and massive growth in malware in the wild.... 6 years ago there were 15,000 new malware today, now there are 300,000-1,000,000.
For example, have you ever noticed how a lot of the anti-ransomware tools start off as post-execution behavior blockers, and eventually evolve into anti-executables? Well, there is a reason for that
. If you ask me, this is exactly backwards. If all I ever run on my computer is Microsoft Word (to write letters), games, Quickbooks, Photoshop, etc., and never launch a web browser or email client (or USB), the computer is simply never going to become infected. It is only when you are connected to the internet and start browsing the web and checking email, that you are at risk for infection.
And this is exactly what a lot of people do not understand about VS. They do not understand that if you simply block all known and unknown executable code when the user is engaged in risky activity, you have pretty much eliminated the problem. I mean really, why would anyone ever allow new, non-whitelisted executable code when the user is browsing the web or checking email?
So you start with locking the computer when it is at risk. But it would also be nice to monitor post-execution behaviors, such as ransomware, cryptominer, MBR, etc.., in the event the user accidentally allowed something they should not have. Basically, VS will be performing similar post-execution behavior analysis that the anti-ransom tools currently perform, but only after most of the bad items have already been filtered out by our lock.
Here is where things get interesting... if the user introduces new code while they were browsing the web or checking email, because of our initial patent, only VS can offer multiple levels of protection. Basically, if a new item is allowed while the computer is at risk, it will be examined more closely by our post-execution behavior blocker than, for example, medical software that was installed when the computer was not at risk. In OSX, there is warning "This is an application downloaded from the Internet. Are you sure you want to open it?" Well, this new feature will take this one step further... VS will simply mark / flag the item as being introduced while the user was doing something risky, if and only if, the new item actually originated from a web app.
For example, I am sure that most of us have a folder where we store all of our favorite utilities / installers, much the same way SMB and enterprises store these items on a network share. These items, and their associated child process will either not be subject to examination by the behavior blocker at all, or if they are, they will be examined less aggressively.
So basically any new executable code that originated from the internet, and was actively downloaded during the session, will be subject to close(r) examination by VS's post-execution behavior blocker. Essentially what we will have is a behavior blocker that is aggressive when it needs to be, and far fewer false positives than traditional behavior blockers. It is going to be seriously cool. And trust me, there is not a chance that I will do anything to introduce tons of new bugs
.
BTW, I think it is important to elaborate on the distinction between pre-execution and post-execution behavior blockers. Examples of pre-execution "behavior" blockers are technologies like VS on AutoPilot (and when VS is in Smart OFF mode)... and another example is OSArmor. When VS is ON (Always ON, Smart ON), it does not need these "behavior" blockers, simply because all new executable code should be blocked when the lock is on (usually because the computer is at risk). This new behavior blocker feature will all happen post-execution, and will be a similar technology to the other security products that are focused on behavior blocking. The main difference will be VS should have far less false positives, because it will only closely monitor dangerous new items, as described above.
Either way, we will continue to offer the current version of VS until everyone is happy with the end result
. I am going to keep everything extremely simple... that is the whole point of VS
. Thank you!
