• Unlock forum

    Guest, you need to be a "Verified" member to post a new thread or reply in this forum.

B

BVLon

Some semi-advanced users may think that anti-exe solutions can protect them without the AV. This is not true. There are some well known methods of bypassing such protection. For example via the email archive attachments that contain the legal but vulnerable EXE file + malicious DLL (DLL hijacking). The anti-exe can check the legal EXE file, but do not check DLLs that are loaded by this EXE.
Same thing can happen with many threats that now put poor AutoIT to a malicious use. AutoIT is a software that allows advanced users to write scripts. I have seen now at least 2000-3000 variants of different threats, not even one, but many (it has become common practice) to put AutoIT executable on the system and load a malicious script. Anti-exes will then be powerless... another example is Java malware, where completely harmless executable (javaw.exe) will be instructed to perform harmful actions and we can keep giving examples till tomorrow. That’s why it’s very important to analyse whole chain of events, and fortify multi-layered security.
 

Andy Ful

Level 62
Verified
Trusted
Content Creator
Same thing can happen with many threats that now put poor AutoIT to a malicious use. AutoIT is a software that allows advanced users to write scripts. I have seen now at least 2000-3000 variants of different threats, not even one, but many (it has become common practice) to put AutoIT executable on the system and load a malicious script. Anti-exes will then be powerless... another example is Java malware, where completely harmless executable (javaw.exe) will be instructed to perform harmful actions and we can keep giving examples till tomorrow. That’s why it’s very important to analyse whole chain of events, and fortify multi-layered security.
Another method would be using the legal installation wrappers like InnoSetup or MSI installers to install the legal scripting engine (Autoit, Python, Ruby, Java, etc.) and automatically run the malicious script. MSI installer has built-in ability to run Windows scripts so it can be easily overlooked by the users.
Another example can be LOLBins. Some anti-exe may use a kind of command-line filtering when running LOLBins, but this can be usually bypassed when applying command-line obfuscation, custom environment variables, etc.
About 7 years ago, I found anti-exe approach very useful. I learned much and after this learning period, using anti-exe was not necessary anymore. The same is probably true for SRP solutions.
 
Last edited:

danb

From VoodooShield
Verified
Developer
@BVLon and AndyFul, you guys are COMPLETELY missing what VS is all about. I have said it a million times, VS is not an anti-executable, it is a toggling computer lock. If there are other protections that we need to implement, we certainly will, as I have done over time.

If you guys have found bugs in VS's code that allow any of your examples (AutoIT, Python, Ruby, Java, etc.) to bypass VS's protections, then I am more than happy to discuss and fix these potential bypassed publicly. But PLEASE do not assume or suggest something can bypass VS without testing it first.

As far as usability goes, I have worked directly with thousands of end users of all skill levels at their actual desks for 20+ years. In short, you guys are taking a wild guess on what you believe or have hunch will work or not as far as usability goes. On the other hand, I have worked directly with the local users, have asked them questions, watched their actions and listened to their opinions on what works for them and what does not, and have refined VS's usability over the years to fit their needs.

Andy suggested "For less advanced users, the VS golden rule will be an illusion of security. Most infections are due to opening email attachments. The less advanced users do not realize what is opening and can be convinced to open anything. The golden rule will not save them." As I was saying before, do you really think ANY user is going to continue to allow something that was suspicious in the first place, after VS has blocked something? Even if this were the case, it is better than the alternative of auto execution. At least VS gives the user a chance and pause.

The potential bypass examples that you guys provided are all a direct result of the user browsing the web or checking email. I believe the best protection is to lock the computer when the user is engaging in this risky activity. If there are better mechanisms to block these attacks, please suggest an alternative. Thank you!
 

danb

From VoodooShield
Verified
Developer
Same thing can happen with many threats that now put poor AutoIT to a malicious use. AutoIT is a software that allows advanced users to write scripts. I have seen now at least 2000-3000 variants of different threats, not even one, but many (it has become common practice) to put AutoIT executable on the system and load a malicious script. Anti-exes will then be powerless... another example is Java malware, where completely harmless executable (javaw.exe) will be instructed to perform harmful actions and we can keep giving examples till tomorrow. That’s why it’s very important to analyse whole chain of events, and fortify multi-layered security.
Specifically (as one example), if you have found a way to bypass VS using AutoIT, please let everyone know. This should be no different than VS blocking powershell globally while allowing certain scripts, and should actually be easier to block since the AutoIT executable is not whitelisted.
 
B

BVLon

@BVLon and AndyFul, you guys are COMPLETELY missing what VS is all about. I have said it a million times, VS is not an anti-executable, it is a toggling computer lock. If there are other protections that we need to implement, we certainly will, as I have done over time.

If you guys have found bugs in VS's code that allow any of your examples (AutoIT, Python, Ruby, Java, etc.) to bypass VS's protections, then I am more than happy to discuss and fix these potential bypassed publicly. But PLEASE do not assume or suggest something can bypass VS without testing it first.

As far as usability goes, I have worked directly with thousands of end users of all skill levels at their actual desks for 20+ years. In short, you guys are taking a wild guess on what you believe or have hunch will work or not as far as usability goes. On the other hand, I have worked directly with the local users, have asked them questions, watched their actions and listened to their opinions on what works for them and what does not, and have refined VS's usability over the years to fit their needs.

Andy suggested "For less advanced users, the VS golden rule will be an illusion of security. Most infections are due to opening email attachments. The less advanced users do not realize what is opening and can be convinced to open anything. The golden rule will not save them." As I was saying before, do you really think ANY user is going to continue to allow something that was suspicious in the first place, after VS has blocked something? Even if this were the case, it is better than the alternative of auto execution. At least VS gives the user a chance and pause.

The potential bypass examples that you guys provided are all a direct result of the user browsing the web or checking email. I believe the best protection is to lock the computer when the user is engaging in this risky activity. If there are better mechanisms to block these attacks, please suggest an alternative. Thank you!
On my tests VS could not be bypassed. We were talking hypothetically with Andy, we didn't say that VodooShield will be bypassed.
 

danb

From VoodooShield
Verified
Developer
Another method would be using the legal installation wrappers like InnoSetup or MSI installers to install the legal scripting engine (Autoit, Python, Ruby, Java, etc.) and automatically run the malicious script. MSI installer has built-in ability to run Windows scripts so it can be easily overlooked by the users.
Another example can be LOLBins. Some anti-exe may use a kind of command-line filtering when running LOLBins, but this can be usually bypassed when applying command-line obfuscation, custom environment variables, etc.
About 7 years ago, I found anti-exe approach very useful. I learned much and after this learning period, using anti-exe was not necessary anymore. The same is probably true for SRP solutions.
If you have figured out how to bypass VS using this method, please post it publicly so I can fix it.
 
B

BVLon

If you have figured out how to bypass VS using this method, please post it publicly so I can fix it.
So far I have tested VS with quite a lot of malware and it does great job at blocking everything.
I know it's not an anti-exe. There is no need for anti-exes anymore, as exes do not pose any threat. All malware that comes as an executable is excellently handled by the regular AV. Problem is non-executable malware.
 
Last edited by a moderator:

danb

From VoodooShield
Verified
Developer
Thank you, I am certain that VS is not perfectly bulletproof and if there are bugs in the code, we need to fix them. I am just not a fan of wild speculation without testing.

A lot of people have tried to bypass VS throughout the years, and here is one example of Black Cipher Security’s opinion on bypassing VS. A lot has changed in VS throughout the years, and sometimes usability tweaks can introduce vulnerabilities, so if anyone finds a bypass for VS, please let everyone know!

Capture.PNG
 

danb

From VoodooShield
Verified
Developer
So far I have tested VS with quite a lot of malware and it does great job at blocking everything.
I know it's not an anti-exe. There is no need for anti-exes anymore, as exes do not pose any threat. All malware that comes as an executable is excellently handled by the regular AV. Problem is non-executable malware.
A couple of things... no traditional or next gen AV has a 100% efficacy for executable files, and they never will. Second, a lot of the times the script will ultimately spawn an exe simply because scripts have limited capabilities. Either way, it is important to block scripts as well.
 
B

BVLon

A couple of things... no traditional or next gen AV has a 100% efficacy for executable files, and they never will. Second, a lot of the times the script will ultimately spawn an exe simply because scripts have limited capabilities. Either way, it is important to block scripts as well.
Some of them are very sensitive to exes and delete it them if they are not on the whitelist, without falling in complicated analysis. They fail however on scripts. Norton is a perfect example.
 

danb

From VoodooShield
Verified
Developer
Some of them are very sensitive to exes and delete it them if they are not on the whitelist, without falling in complicated analysis. They fail however on scripts. Norton is a perfect example.
Yes, and this is an issue because I have experienced on several occasions overly sensitive products quarantine practice management software (for example), and it shuts down the business until the IT dude can come in and remove the file from quarantine. I am not worried about VS's false positives, but I am worried about these kinds of false positives. And typically it is the behavior blocker mechanism that is at fault.
 
B

BVLon

Yes, and this is an issue because I have experienced on several occasions overly sensitive products quarantine practice management software (for example), and it shuts down the business until the IT dude can come in and remove the file from quarantine. I am not worried about VS's false positives, but I am worried about these kinds of false positives.
Yeah, they balanced their approach with the years, but initially when they introduced SONAR and the whole Insight system in june 2009, I remember everyone was screaming... particularly small vendors who can't afford the right digital signature.
 

danb

From VoodooShield
Verified
Developer
Okay, here is a great example. "Someone" ;) just pm'ed me the following item and wanted my opinion.

Razy.PNG


If they were to click the Allow False Positive button, they would then see this...

FP.PNG


There are two other alternatives for security software to handle this file...

1. Let the file auto execute
2. Automatically Block / Quarantine the file

In the interest of refining VS's usability, if there are other ways to handle this file, please let me know.
 
B

BVLon

Okay, here is a great example. "Someone" ;) just pm'ed me the following item and wanted my opinion.

View attachment 235251

If they were to click the Allow False Positive button, they would then see this...

View attachment 235252

There are two other alternatives for security software to handle this file...

1. Let the file auto execute
2. Automatically Block / Quarantine the file

In the interest of refining VS's usability, if there are other ways to handle this file, please let me know.
In my opinion,everything in this alert looks right, except I would not recommend Auto-Quarantine here, as it's only 10 engines (if Bitdefender is one of them with its multitude of forks, in reality it's no more than 2-3)... I would say "Our Analysis (without using VoodooAi) did not find suspicious characteristics, but 10/70 engines detected a threat. We recommend that you keep the file blocked and we'll rescan it again in 12 hours."
if they press "Allow false positive" I would say pretty much what's on the message. I would actually remind them again "10/70 engines detected malware" with bigger letters and then "By allowing this file to run you understand that this could introduce malware".
And then do 2 buttons "I accept the risk" and "Block file"

If they did not click "allow false positive", it would be good to really rescan the file in 12 hours and report changes...
show a message like "+4 engines now detect a threat in this file, so it looks like brand new malware. We recommend that you quarantine this file"

Of course this is just how I would do it...
 

Andy Ful

Level 62
Verified
Trusted
Content Creator
@danb,
You misunderstood my posts. :unsure:
If I wrote that VS can be useful for semi-advanced users, then that was not a critique. I had in mind that for such a group of users, the VS can be a good and efficient solution. As you know well all VS reviews say the same.
There is nothing wrong with VS even if it is often an inefficient solution for the less advanced users.(y)

VS is obviously much more than anti-exe, but it shares with anti-exe some features. For example, if the user executes the EXE file, then VS with all its features will not check the DLLs loaded by this EXE. This can be used to infect the computer via DLL hijacking.
Of course, VS can be configured to block all new files and stop most of such infections. It can be done via Always On Mode, or by blocking all known LOLBins, etc.
So, the problem is not that VS can be bypassed, but that some convenient VS configs can be bypassed. Simply, more convenience always introduces less security. That is a users' choice to find a balance between usability and security. But first, they should know what are the possible vectors of attack. All vulnerabilities mentioned by me can be used in AutoPilot mode. Most of them (except 0-day) will be blocked by the AV.
You should check by yourself if they can be dangerous in the Smart Mode - If you will say that it is not the case then I will believe you.

Nothing that I wrote is new, you said many times that the Autopilot Mode is not as safe as Always On Mode. Furthermore, even Autopilot mode significantly improves the AV protection.(y)
 
Last edited:

danb

From VoodooShield
Verified
Developer
In my opinion,everything in this alert looks right, except I would not recommend Auto-Quarantine here, as it's only 10 engines (if Bitdefender is one of them with its multitude of forks, in reality it's no more than 2-3)... I would say "Our Analysis (without using VoodooAi) did not find suspicious characteristics, but 10/70 engines detected a threat. We recommend that you keep the file blocked and we'll rescan it again in 12 hours."
if they press "Allow false positive" I would say pretty much what's on the message. I would actually remind them again "10/70 engines detected malware" with bigger letters and then "By allowing this file to run you understand that this could introduce malware".
And then do 2 buttons "I accept the risk" and "Block file"

If they did not click "allow false positive", it would be good to really rescan the file in 12 hours and report changes...
show a message like "+4 engines now detect a threat in this file, so it looks like brand new malware. We recommend that you quarantine this file"

Of course this is just how I would do it...
Thank you, yeah... the quarantine threshold is user adjustable in VoodooShield Settings / Advanced. Perhaps we should increase the default to 10 or so. And I totally agree on the BD sigs... our current false positive detection feature does not directly address this issue, but it is an easy fix.

I like your suggestions on the rescanning, and we can certainly do that if we can figure out a way to do it as simply as possible. BTW, the blacklist result should always be current / up to date.
 

plat1098

Level 21
Verified
I think this is getting a little complicated and over-thought, speaking from a basic user's perspective. Has anyone examined how another security software alerts a user to a potential threat? It's not all these messages to contemplate and mull over plus various mechanisms to choose from. It's usually just one, plus a menu of what to do next. Look at HitmanPro. Alert: it's a banner blocking your entire desktop plus a Windows chime. That's about the ultimate in warnings!

I think if Defender is set to give an audible warning, you will get that plus a text warning. This combo would be very difficult to ignore but hard to say whether a given user will proceed regardless. You want to close that hole a little more that a user will proceed regardless of warnings. At some point, the software has to back away and say "OK, you've been warned." This is often a very quick dynamic; people maybe want whatever that is now, not after having leisurely thought about it. This is often my mindset.

Like this would be good if a user somehow ended up on a bogus shopping site or as Andy Ful mentioned, prepared to open an email with a malicious attachment socially engineered to be relevant.
 
B

BVLon

Thank you, yeah... the quarantine threshold is user adjustable in VoodooShield Settings / Advanced. Perhaps we should increase the default to 10 or so. And I totally agree on the BD sigs... our current false positive detection feature does not directly address this issue, but it is an easy fix.

I like your suggestions on the rescanning, and we can certainly do that if we can figure out a way to do it as simply as possible. BTW, the blacklist result should always be current / up to date.
I believe a shield should be put as an overlay on the file's icon, to clearly show the user that this file is blocked by VoodooShield. In 12 hours, the software can re-query the blacklist and see how many engines detect the file now. Yes, BD issue should be addressed. I can do a list of all forks and BD-based solutions... these should be excluded from the result, as they are not useful. Same is with some Kaspersky and Avira-based products.
 

danb

From VoodooShield
Verified
Developer
@danb,
You misunderstood my posts. :unsure:
If I wrote that VS can be useful for semi-advanced users, then that was not a critique. I had in mind that for such a group of users, the VS can be a good and efficient solution. As you know well all VS reviews say the same.
There is nothing wrong with VS even if it is often an inefficient solution for the less advanced users.(y)

VS is obviously much more than anti-exe, but it shares with anti-exe some features. For example, if the user executes the EXE file, then VS with all its features will not check the DLLs loaded by this EXE. This can be used to infect the computer via DLL hijacking.
Of course, VS can be configured to block all new files and stop most of such infections. It can be done via Always On Mode, or by blocking all known LOLBins, etc.
So, the problem is not that VS can be bypassed, but that some convenient VS configs can be bypassed. Simply, more convenience always introduces less security. That is a users' choice to find a balance between usability and security. But first, they should know what are the possible vectors of attack. All vulnerabilities mentioned by me can be used in AutoPilot mode.
You should check by yourself if they can be dangerous in the Smart Mode - If you will say that it is not the case then I will believe you.

Nothing that I wrote is new, you said many times that the Autopilot Mode is not as safe as Always On Mode. Furthermore, even Autopilot mode significantly improves the AV protection.(y)
Yes, I totally agree with your points, and that is why I am saying that if there is a way to bypass VS please let me know. I have tried every way possible that I know of and have actually found several different vulnerabilities that I had to fix. Having said that, there is a zero percent chance that one person thought of everything... so if you find something, please let me know.

BTW, when VS toggles to OFF in Smart Mode, its security posture is almost identical to AutoPilot at this point. So essentially, when VS is in Smart Mode, it is pretty much toggling between AutoPilot and Always On. Thank you!
 

Burrito

Level 23
You misunderstood my posts. :unsure:
If I wrote that VS can be useful for semi-advanced users, then that was not a critique. I had in mind that for such a group of users, the VS can be a good and efficient solution. As you know well all VS reviews say the same.
There is nothing wrong with VS even if it is often an inefficient solution for the less advanced users.(y)
Yeah.

It seems to me that VS is finding a nice niche.

It's impressive how far VS has come. And how the development continues..

And I credit Dan for his willingness to listen to suggestions.

(y)
 
Last edited:
Top