Bug Alert: Malwarebytes

This is not technically a bug.

Rather, it's an aggressive behavior-based malware protection system that flags legitimate VBA code as an exploit.  I know of at least one other person who was affected by this in recent days, so I have to assume there are others.

Read on for the details.

One of our biggest clients runs an Enterprise version of Malwarebytes on their LAN.  On September 2, 2021, some of our Access application users began seeing the following notification:

Here's the text of the message for all you site-indexing robots out there:

Malwarebytes

Exploit automatically blocked
Affected application: 11203901 ????.?if
Protection layer: Application Behavior Protection
Protection technique: Exploit Office spawning batch commands

The Problematic Code

Malwarebytes objected to my use of the VBA Shell function to delete a group of files on disk.  Absent context, that's the sort of behavior I would be blocking, too.

(Incidentally, I'm using Shell with a dynamically created batch file so that I can take advantage of the del command's support for wildcard characters.  It's not an ideal approach, but it's currently the least bad of the alternatives we've considered.)

Client Help Desk Support

The client has the Malwarebytes configuration locked down, so I could not adjust the settings at the workstation.  I contacted the client's help desk to see if they could do anything from their end to address the behavior.    

Attempt #1. Whitelisting

Here's the message I got back from the help desk:

The whitelisting covered both possible locations of my application (32-bit vs. 64-bit), as well as a couple common locations for the Access executable itself.

This did not work in our case, but it may be something for you to consider.

Attempt #2. Change the Malwarebytes Settings

After the whitelisting failed, the client adjusted the behavior matching settings in Malwarebytes.  Here's the second email I received:

Hi Mike,

I made another change to our security settings.  I turned off some behavior and pattern matching features for Microsoft Access applications.

Since I don't have access to the Malwarebytes settings, I can't tell you exactly what he did.

However, it seems I am not the only one who ran across this problem.

Other People Have Reported This Problem

Over on one of the LinkedIn groups to which I belong, John Skolits described a similar situation (used with permission from John):

I recently ran into an issue where Malwarebytes was blocking my ACCDB/ACCDE file whenever I tried to create the WScript.Shell object. I thought maybe if I signed the VBA project, it would not block it. Currently have a support ticket with them.

I've never had any luck code-signing an Access application (though I do sign my installers).  John gave up on that idea and changed the settings in Malwarebytes directly.  Here are his instructions to update the settings:

It seems Malwarebytes has made a recent change. They said they will get back to me. But for now you can do the following for each PC.

1. Open Malwarebytes.
2. Click the Settings icon in the top right.
3. Click the "Security" tab.
4. Scroll all the way down to "Exploit Protection" and click "Advanced Settings".
5. Select the "Application Behavior Protection" tab.
6. Look for the "Office VBE7 abuse prevention" row.
7. Remove the checkmark under "MS Office".
8. Click "Apply".

Malwarebytes Support Page

Here's the official support page from Malwarebytes (as of writing, this Malwarebytes page was last updated on 2021-09-14).  Pay particular attention to the "Application behavior protection" section:

Application behavior protection

Application behavior protection settings prevent the exploit payload from running and infecting the system. This represents the last line of defense if an exploit is able to bypass previous protection layers. This layer also detects and blocks exploits that do not rely on memory corruption, such as Java sandbox escapes or application design abuse exploits.

• Malicious LoadLibrary Protection: Prevents delivery of a payload library from a UNC network path.
• Protection for Internet Explorer VB Scripting: Detects and prevents exploits related to the application design vulnerability known as CVE-2014-6332. For more information on this exploit, see https://nvd.nist.gov/vuln/detail/CVE-2014-6332.
  • If you need to use VBScript for an internal application, see Endpoint Protection's Anti-Exploit protection is blocking Visual Basic 6.
• Protection for MessageBox Payload: Prevents exploits from delivering a messagebox as its payload. This option is off by default; these types of payloads are harmless and usually used only in proofs of concept.
• Protection for Office WMI abuse: Protects against Microsoft Office macro exploits that use Windows Management Instrumentation (WMI).
• Protection for Office VBA7 abuse: Protects against Microsoft Office macro exploits that use Visual Basic for Applications.
• Protection for Office VBE7 object abuse: Protects against Microsoft Office macro exploits that use Visual Basic for Applications.
• Protection for Office Scripting app abuse: Protects against Microsoft Office application scripting exploits.
• Protection for Office loading points abuse: Protects against Microsoft Office loading point exploits when starting applications. 
• Protection for Office spawning batch commands: Protects against Microsoft Office batch command exploits. 
• Protection for Excel macro 4.0 abuse: Protects against Microsoft Office macro 4.0 exploits. 
• Protection for Email client scripting abuse: Protects against client scripting exploits on email applications. 

External references

Image by a_roesler from Pixabay