Jump to content

enhance exception list to allow specific vbscript file names


Recommended Posts

Malwarebytes answer https://forums.malwarebytes.com/topic/223638-need-to-run-vbs-script-specific-permissions/ indicates you can't have a specific exception. Why is it not possible to enhance MB so a specific command line prefix can an exception? 

For example all command lines that begin with "C:\Windows\System32\WScript.exe  C:\cmdpath-redacted\openwith_tc2.vbs " would be allowed to run if listed as an exception. That is these commands would pass:
    C:\cmdpath-redacted\openwith_tc2.vbs file1.ext
    C:\cmdpath-redacted\openwith_tc2.vbs file2.ext
but 
    c:\cmdpath-redacted\openwith_tc.vbs file1.ext 
would be stopped as not the same script.

It is an issue for me I am using Firefox with the downloadstatusbar addon setup to run the command "C:\cmdpath-redacted\openwith_tc2.vbs %1" automatically after each download, and where "%1" is  replaced with the name download file.
 

Link to post
Share on other sites
  • Staff

Greetings,

Unfortunately, due to the way that Exploit Protection works, it is not possible to exclude individual script files because its protection is based purely on behavior, not paths and individual files (it detects malicious behaviors, not malicious binaries, executables or scripts directly and simply blocks/quarantines scripts and other files as the payload), at least that is my understanding of it.  This is also why individual processes cannot be excluded from Exploit Protection (exclusions from other components, such as Malware Protection, do not affect Exploit Protection).  There are also hardening functions built into Exploit Protection which shield vulnerable apps and processes from exploits through closing known security holes in their processes.  You will likely need to disable the setting Disable loading of VBScript libraries for MS Office under the Application Hardening tab of the Advanced settings menu for Exploit Protection, which is located under the Security tab in settings:

VB.png.73401a1a23b893a7e3e2668c7f8f1983.png

You were likely already aware of this given the previous thread you referenced, but just in case anyone else comes across this thread, this should prove helpful to them.

Basically, individual scripts cannot be excluded because individual scripts are never the actual targets of Exploit Protection (it stops/quarantines them as a byproduct of generically blocking certain scripting behaviors and application vulnerabilities/exploits; this is also one reason Malwarebytes has never targeted any script type files using signatures, both because they are well covered by Exploit Protection's behavior based approach, and because attempting to detect scripts is essentially pointless (please refer to this article for more details on exactly why, but the short version is that it is trivial to modify, encrypt, rewrite, pack/compress or do any number of other modifications to a script file to render it invisible to any signatures which previously targeted it, but if you instead focus on the behavior (rather than the payload/script itself), you can nail it with 100% effectiveness simply by shutting down known attack vectors and exploits where scripts would be used).

With all of that aside, I will submit your feedback/request to the Product team for analysis, as there may be something more they can do to make it easier to deal with situations like yours without having to disable any components of protection/behavior blocking in a future release.

Edited by exile360
Link to post
Share on other sites
21 hours ago, exile360 said:

based purely on behavior, not paths and individual files 

I understand you are saying "Exploit Protection" is about hardening specific functions.  I need more detailed  information on how "Exploit Protection"  works to understand why this is not a plausible enhancement request - MB's developers can clarify this. Here is what I do know, the message reported in json log entry file see  https://pastebin.com/gfyHRKiL describes EXACTLY what the command line was that it classified as an "exploit" see  "blockedFileName"  value but in this case for my system it is a false positive. I fail to see why it would be so difficult to enhance the "Exploit Protection" to read an exception table rule like:  "if command line begins with **** then allow". This would occur after detection and before it cancels processes.

You cite untick box "disable loading of VBscript libraries" for "MSoffice" products but the issue is with Firefox browser, so why do I need to allow it for MSoffice products like (Word,Excel,Powerpoint etc)? Why not untick "Non-Chromium browsers" column?

//
// Contents of C:\ProgramData\Malwarebytes\MBAMService\AeDetections\fc9cad20-e17f-11ea-96aa-5cff3502cfcc.json:
//

F8582147D180AE24710978ED66FD29EA3C881AD5DE322FB8A86B6BA225A84478
{
   "applicationVersion" : "3.5.1.2522",
   "clientID" : "",
   "clientType" : "other",
   "componentsUpdatePackageVersion" : "1.0.365",
   "cpu" : "x86",
   "dbSDKUpdatePackageVersion" : "1.0.17626",
   "detectionDateTime" : "2020-08-18T08:47:47Z",
   "fileSystem" : "NTFS",
   "id" : "77d815c0-e12f-11ea-9705-5cff3502cfcc",
   "isUserAdmin" : true,
   "licenseState" : "trial",
   "linkagePhaseComplete" : false,
   "loggedOnUserName" : "System",
   "machineID" : "",
   "os" : "Windows Vista Service Pack 2",
   "schemaVersion" : 9,
   "sourceDetails" : {
      "type" : "ae"
   },
   "threats" : [
      {
         "linkedTraces" : [

         ],
         "mainTrace" : {
            "cleanAction" : "block",
            "cleanResult" : "successful",
            "cleanResultErrorCode" : 0,
            "cleanTime" : "2020-08-18T08:47:47Z",
            "exploitData" : {
               "appDisplayName" : "Mozilla Firefox (and add-ons)",
               "blockedFileName" : "C:\\Windows\\System32\\WScript.exe C:\\Windows\\System32\\WScript.exe C:\\cmdpath-redacted\\openwith_tc2.vbs E:\\redacted.ext",
               "layerText" : "Application Behavior Protection",
               "protectionTechnique" : "Exploit payload process blocked",
               "url" : ""
            },
            "generatedByPostCleanupAction" : false,
            "id" : "7ddf5be0-e12f-11ea-a7da-5cff3502cfcc",
            "linkType" : "none",
            "objectMD5" : "",
            "objectPath" : "",
            "objectSha256" : "",
            "objectType" : "exploit"
         },
         "ruleID" : 392684,
         "rulesVersion" : "0.0.0",
         "threatID" : 0,
         "threatName" : "Malware.Exploit.Agent.Generic"
      }
   ],
   "threatsDetected" : 1
}

 

Edited by AdvancedSetup
Added, inline code
Link to post
Share on other sites
  • Staff

Apologies; I thought the issue was with Excel/MS Office so it would be a different function/option you'd need to disable.

That said, I never stated that the Developers couldn't implement a solution to your issue/request (in fact, I believe it is quite possible as Malwarebytes already allows excluding detected exploits by hash, so doing the same for a specified file/script should be feasible as well, though I cannot speak for them and I'm not a Dev myself; it just seems plausible based on what I do know).  I've already documented your case and the associated feature request, it is up to the Product team to determine whether or not to add it to the backlog to approve it for implementation, and of course then it depends on whether the Developers actually can implement a solution (again, assuming you and I are correct that it should be possible).

Link to post
Share on other sites
  • Staff

You're welcome, hopefully we'll see a solution soon.  FYI, this issue has been around since Exploit Protection and the standalone Malwarebytes Anti-Exploit were first introduced, so while I hope that it is not impossible to solve, it may be, otherwise I would think they would have addressed it by now.  I don't know for certain either way though, so I'm holding out hope that a fix is possible.

With regards to requests for info on how Exploit Protection works, I don't think the Devs will be too forthcoming since it is the company's proprietary technology based on the work of ZeroVulnerabilityLabs which was acquired by Malwarebytes sometime ago (and has been extensively augmented since then through continued development, of course), and they wouldn't want competitors (nor the bad guys who develop exploits and malware for that matter) to have too much technical info on how their various shields and protections are implemented, but they might be willing to provide some basic clarification.  The details I've provided in my posts are just based on my own analysis and experience using the software, so it's possible that it works differently, however just based on seeing what it does in action and the behavior based nature of its detections, it appears that it might stop the detected exploit activity too early to be able to process an exclusion based on the script/payload attempting to be executed, which would also explain why excluding the script/payload doesn't work while disabling the shield itself that triggers the detection does work, as well as why detected exploits can be excluded based on hash (the hash of the exploit, not the payload/script, though that is not even possible with some shields/protections like this one, since it is a generic detection not based on a specific/known exploit).  Again, that's just my own hypothesis based on my limited understanding of it.  If it's a feature the Devs can implement, I'm sure that they will as long as the Product team decides that it would be the best thing for the customers and product.

Either way, I hope it is something they can do, because it would make dealing with scenarios like yours much easier.

Link to post
Share on other sites
  • Staff

Unfortunately this is a hard block for the time being. The anti-exploit component prevents any automated execution of scripting apps from Internet-facing applications. If you save the script to disk and execute it from a command line with a non-browser and non-mailclient parent process, it will be allowed to execute.

We are evaluating some future enhancements to the anti-exploit component to allow more granularity around allowed/blocked dangerous actions.

 

 

Link to post
Share on other sites
  • 2 weeks later...
On 8/25/2020 at 2:45 AM, pbust said:

Unfortunately this is a hard block for the time being. The anti-exploit component prevents any automated execution of scripting apps from Internet-facing applications. If you save the script to disk and execute it from a command line with a non-browser and non-mailclient parent process, it will be allowed to execute.

We are evaluating some future enhancements to the anti-exploit component to allow more granularity around allowed/blocked dangerous actions.

 

 

Ok thanks for clarifying that

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.