False Positive Malwarebytes mdm.exe

On September 13, 2016, I discovered approximately 100 emails from my Malwarebytes Management Console, where I run Malwarebytes Anti-Malware and Anti-Exploit for my end users.  

They were entries such as the following:

9/13/2016 11:15:22 AM <client> <ip> Ransom.Petya Quarantined C:\Program Files (x86)\Common Files\microsoft shared\VS7DEBUG\mdm.exe

or

9/13/2016 10:40:22 AM <client> <ip> Ransom.Petya delete-on-reboot C:\Program Files (x86)\Common Files\microsoft shared\VS7DEBUG\mdm.exe

9/13/2016 10:40:22 AM <client> <ip> Ransom.Petya Quarantined HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\MDM

The entries began at 6:53AM ET and ended at 11:15am ET.

The volume and location within seemingly legitimate operating system locations made me think I had a false positive on my hands.  Some research promptly confirmed that.

By good fortune, one response already identified the resolution from Malwarebytes support.

https://community.spiceworks.com/topic/1823976-ransomware-or-false-positive

Log onto the Malwarebytes Management Console

Click the Client Pane

Select the computer affected from the list of clients

Click the Security Logs Tab along the bottom

Right click the item you wish to restore, then click either: 

Restore this Object... to restore to the computer selected

Restore this object on all clients... to restore this item to all clients

Whew!  I was able to restore the object on all impacted systems with a few quick clicks from the console.  What a relief!  

As an aside, I was not overly familiar with mdm.exe.  It is apparently the Machine Debug Manager.  So it probably wouldn't affect end users terribly, but would thwart people in IT trying to do any troubleshooting on a system potentially.

I'll update this post with any fallout or any further issues.  I wanted to get it up quickly in case anyone else was similarly impacted and panicked like I was.

P.S. Please be careful with reports of viruses in mdm.exe.  It is apparently a known problem, but typically the file is not in its default location I outlined above.  

UPDATE 9/16/2016:
We had a SECOND round of this occur 9/15/2016 from 2:42pm ET to 4:31pm.  I called support myself shortly after 4pm (on the first go-round, above, I relied on the experience in that link provided).  

Support confirmed unofficially that it was a false positive, and collected data from me.  At 5:03pm they let me know it would be fixed in the next update.  

I connected remotely during the off hours,  I saw my definition time stamp had moved from 4:xxpm to 9:xxpm, so I again did the Restore this object on all clients and hopefully can put this to bed.