MBAM fails ransomware detection > encrypted

[Telos]

This shows malware encrypting a MBMA "protected machine:

 

Before some say this is "not a real world test", let me ask, why the scan which occurred prior to running the malware failed to detect the threat and declared the executable clean (at 2:55 minutes into the video).

MBAM missed detecting the executable as well as the behavior of the malware. This worries me.

 

[Porthos]

I wish that person used the attachment (script, doc etc.) from the email to test not the payload. A real world user would not have the payload. MB was denied in this test the chance to stop the script from getting the payload from the beginning.

Still not 100% real world.

Not attempting to defend MB but stating a fact.

 

Edited May 17, 2017 by Porthos

[Porthos]

Also, it has been posted before that some files will be encrypted before the protection fully stops it. He only had a few files in that folder so we don't know what would have happened to the rest of the files on an average computer.

56 minutes ago, Telos said:

why the scan which occurred prior to running the malware failed to detect the threat and declared the executable clean (at 2:55 minutes into the video).

 

 

The file was not in the database obviously. Not every payload is in there.

Edited May 17, 2017 by Porthos

[exile360]

37 minutes ago, Porthos said:

I wish that person used the attachment (script, doc etc.) from the email to test not the payload. A real world user would not have the payload. MB was denied in this test the chance to stop the script from getting the payload from the beginning.

Still not 100% real world.

Not attempting to defend MB but stating a fact.

 

Precisely.  Most malware, and especially ransomware these days use exploits to download and execute their payloads.  Our exploit blocking tech is lightyears beyond standard malware file detection or even file heuristics found in our scanner and yes, it's even way beyond the technology in our anti-ransomware protection (our anti-ransomware is pretty good, but it's still nowhere near the effectiveness of our anti-exploit for % of attacks of its type that it's able to stop).

31 minutes ago, Porthos said:

Also, it has been posted before that some files will be encrypted before the protection fully stops it. He only had a few files in that folder so we don't know what would have happened to the rest of the files on an average computer.

 

The file was not in the database obviously. Not every payload is in there.

And yet again, 100% correct.  Just as I mentioned in the other thread where a similar discussion (including a similar video as I recall) took place, trying to detect every payload, especially before it's been seen by our Researchers, is not only tedious, but virtually impossible.  Sure, we do our best to stay on top of every sample and malware family that we can via heuristics, but the bad guys just turn around and specifically scan their new creations with our latest database before deploying the threat to the web to make sure that we don't detect it (and the same goes for the other AV/AM vendors, because not getting detected/caught is the point).  The entire reason our exploit protection is so significant is due to the same two factors I mentioned in the other thread: it's basically the most common means of deploying malware in use today by the bad guys and unlike payloads which can change at the drop of a hat to become completely different, exploits are actually limited to a handful of basic attack methods so covering them is much easier and doesn't require any signatures or even heuristics because it's all behavioral.  Detecting cryptors is obviously behavioral in many ways too, however the potential for FPs is also much higher so we can't be nearly as aggressive, otherwise we'd be detecting backup software, archive software (WinRAR/WinZIP/7ZIP etc.) and manual file deletions performed by users themselves all the time, and that would just be downright frustrating for our customers (you can see evidence of this if you participated in the Malwarebytes Anti-Ransomware Beta before the technology was finally launched/integrated in Malwarebytes 3.0; there were tons of FPs and we had to keep tuning it down/making it less aggressive to avoid them).  Our anti-ransomware tech is good, don't get me wrong, but it is definitely still a work in progress and evolving much more than our anti-exploit tech because it's had to in order to improve its detection rates while safely avoiding FPs.

Fear not however, we have more new tech in store that's going to change things in big ways.  In fact, one such piece of technology shipped with 3.1.2.  It isn't fully activated yet, but once it is, I expect even tests like the one in the above video to go very differently going forward, with Malwarebytes coming out on top, even if our anti-exploit never got the chance to see what would normally be the beginning/first phase of the attack.

[Telos]

Even if MBAM missed identifying the executable as malware during a basic scan (even my heuristics), the malware's behavior when it encrypted the first file should have been flagged by MBAM and isolated/quarantined. This can't bee difficult. On a backup machines I run HitmanPro.Alert and it intercepts even my file wiping program because it detects "encryption" of the first file wiped. Since all ransomware involves encryption, detection of unknown encrypting processes should be standard.

If MBAM doesn't do this, it seems quite limited in scope, IDK.

 

[exile360]

1 minute ago, Telos said:

Even if MBAM missed identifying the executable as malware during a basic scan (even my heuristics), the malware's behavior when it encrypted the first file should have been flagged by MBAM and isolated/quarantined. This can't bee difficult. On a backup machines I run HitmanPro.Alert and it intercepts even my file wiping program because it detects "encryption" of the first file wiped. Since all ransomware involves encryption, detection of unknown encrypting processes should be standard.

If MBAM doesn't do this, it seems quite limited in scope, IDK.

 

The scenario with HMP.A is precisely why we aren't that aggressive.  We don't want all those FPs.  In a real world scenario, this ransomware would have gotten onto the system via some method, and I'd bet at least $1 that the method would be an exploit and that Malwarebytes would have nailed the exploit thus thwarting the infection attempt before that ransomware binary ever got anywhere near the system.

That said, yes, tuning our anti-ransomware to be appropriately aggressive so that no actual ransomers are missed while still avoiding FPs (again, as you described with HMP above) is a tricky process and something that we're constantly working on.  It is getting there though, I assure you.  It isn't up to 100% yet (obviously), however it is constantly improving its capabilities and effectiveness with each update.  We've had a lot of research and dev work on that particular component lately because we know that it still needs to be better, but firing off a block/alert every time any process tries to wipe a file is not acceptable to us, at least not for what we want our product to be.  We're not a HIPS right now, so we don't want to behave like one.  We want our users and customers to feel confident that if we've blocked something claiming it was malware, that it was for a good reason and that we're at least reasonably certain that it actually was malware.  This includes when detecting malicious behaviors.  We want to be just as certain about those so that we aren't arbitrarily flagging benign processes and everyday tasks as potential threats because we feel that if you "cry wolf" too many times, users will grow accustomed to dismissing your alerts as false flags and won't take action the one time a real threat does come along and the same old, everyday alert shows up.  It's the same problem that Microsoft has often had with UAC.  It's a great piece of technology that really can help to make PCs more secure, yet all too often users click "Allow", "Continue", or "Yes" even in cases when they shouldn't (assuming they don't turn it off altogether because it annoyed them too much, which sadly does happen) and let something run with elevated privileges that turns out to be bad news.

[Telos]

2 hours ago, exile360 said:

The scenario with HMP.A is precisely why we aren't that aggressive.  We don't want all those FPs.

I won't deny that. HMP.A isn't for the average user as it requires far too much tweaking. I won't run it on my main machine (VoodooShield, though is quite sweet, but not w/o FPs until it learns your system).

3 hours ago, exile360 said:

We're not a HIPS right now, so we don't want to behave like one.

Yet Ransomware is more than a typical malware nuisance that either bots your system, or feeds you endless ads and redirections. Sites like BleepingComputer can't help ransomware victims. Ransomware prevents access to files that are critical to you... so maybe a bit more FP risk with "approve/deny" user interaction is warranted. Or otherwise, creating a volume where protected files are copied, since the average user doesn't understand imaging or using VMs. 

Hopefully y'all will find the right balance.

[exile360]

I can't say that I don't wish we were doing better against it, but as I've said many times before, as long as exploit protection is active our customers shouldn't get hit by ransomware.  We will continue to work on it though, and in the meantime our signature-less anomaly detection component should be coming online before long (that new component that shipped with 3.1.2 that I've been so excited about).  Once it becomes active for everyone, it should be able to vastly increase our hit rates against malicious files, including ransomware binaries.