tetonbob

Generally speaking, you are correct @Porthos I believe it depends on how quickly one uses the Check for updates function after the service starts. But most customers will be updating a program already running. For example, if you Quit, relaunch and then Check for updates, you should get the installer first, when a full program upgrade is what is available. I just wanted to point out that the offline installer link does not have the latest Component update package 1.0.976 which contains the Office FP fix, so it appears that there will be a 2-step approach either way, unless the steps above are taken.

It looks like the Offline installer build is not up to date with the latest CU 1.0.976? I'm seeing 4.1.2.73-1.0.972 being downloaded. 4.1.2.73-1.0.976 has the fix for Office FPs.

Hello @egrol - yes, this is a false positive. We've released a new version to address this issue. Please see: And > If you don't want to wait for the update to be served automatically please go ahead and retrieve it manually by clicking "Check for updates" under Application Updates in Settings > General.

Please do let us know if you again encounter a detection from Word, or Excel, now that you have the Beta installed. You should not.

Please see Please note we've released a new beta update that corrects this issue. See here for details: https://forums.malwarebytes.com/topic/261368-microsoft-office-blocked-by-ransomware-protection/?do=findComment&comment=1392001

Please see this topic regarding the issue you've reported Also, we released a Beta on Friday, to address this issue

Edit: I see that you mentioned you've installed the latest Beta and are still seeing a detection of Word. Please do provide the requested logs so we can take a look. In all our testing, this issue is resolved with Beta 4.1.2.73-1.0.976

Yes. Please rest assured, this was a false positive. We are working on a code-side solution for this issue.

You're quite welcome! Thanks for your patience, and your help in reporting the issue.

Thanks for that additional detail, I'd seen the mention of macros in your earlier reply, which I'd split to it's own topic. The additional detail is useful for us, for additional reproduction/test steps when verifying the planned fix.

I'm sure this was a false positive. But I like the way you think, and your plan. 🙂 But to be even more sure, you could locate the ArwDetections json file and send it as an attachment. It will (should) have the MD5 and SHA256 of the detected Excel.exe in it, which we can cross check at VirusTotal. That file would be located at: C:\ProgramData\Malwarebytes\MBAMService\ArwDetections

Can you provide more details about what was being performed in Excel at the time of detection?

@SolveMyProblemUK - Thanks for your report. I split your post to it's own topic. Have you been able to resolve the block issue already, or do you require assistance? If necessary, disable the Ransomware Protection component to release any hold on the Excel.exe process. The logs show you added a file exclusion. You may want to try a folder exclusion for Ransomware only, for this folder C:\Program Files (x86)\Microsoft Office\root\Office16 We are on the path towards a solution for this issue, though we don't yet have a solid time frame for a release.

Hi. I thought you had already repaired the Excel installation after following Porthos' instructions? If you re-enable the Ransomware Protection without an exclusion in place for the Excel.exe path, you may trigger a new detection event. You don't really want to do that do you? Or you're interested in testing a theory and are willing to go through all this again? I'd advise against this, but understand if that's your choice. Not simply by re-enabling, but if you trigger a new detection event, then yes, the hold will be placed again.

You're quite welcome, and we apologize for the trouble this caused you, and our other affected customers. We are working to address this issue in the code base of the Ransomware Protection component.