Tuesday, October 10, 2017

Less than 50% detections

Today's ransomeware score... six missed (one detected stuff, but the malware encrypted the drive anyway, so that's a miss), five blocked, but with sigs... none with behavior detections.

Today's md5 is c50b81f99269bd05299df41dee8844da.

F-Secure is added to the test.

Missed were Webroot, Windows Defender, Panda, Avira, Trend.

Eset detected stuff, and removed what it saw, but the malware got away, so it's a miss.

Kaspersky, Sophos, Symantec and F-Secure blocked it with a sig.

Avast blocked it, but also blocked my software, so that's a false positive. False positives are anathema in a corporate environment, otherwise we could all use Solly's Perfect.bat, which never misses anything...

(Perfect.bat is "Echo %1 is malware"... never misses anything bad, but has a few false positives. This can be fixed, as well, which we can talk about later)

Guys... the malicious behavior with ransomware is obvious. We shouldn't be missing any of these. Please step up. I know we can do it.

Stay tuned.

Monday, October 9, 2017

Who caught today's ransomware?

So, as readers of my blog will know, I am trying to find out who can trap malware, without having a signature for it, and without false positives. In other words, as it executes.

For today's test, I had a piece of ransomware, that had arrived in a buddies inbox yesterday. A quick check of its md5 on VirusTotal showed just a few sig detections.

I currently have ten products under test. They are the end-point versions of WebRoot, Kaspersky, Sophos, ESet, Avast, Symantec, Windows Defender, Panda, Avira, and Trend. I would have installed McAfee, except that it keeps barfing on one of the files it installs. It says mcmscins.dll, in the McTemp directory, is either not designed to run on Windows, or it contains an error. I tried calling their tech support about it, but the guy said he could find no record of that error. I expect this will sort itself out sometime soon, and I'll be able to add it to the test set, but that's a story for another day.

Five products missed it completely. One found a sig in memory, but it still got away, so that's really a miss. Two blocked it with a sig. Two found it with heuristics. I'll get to the names in a bit, but here's how the test works.

(1) I first run the malware on an unprotected Win7-32bit vm, and see what it does.
(2) All products are installed with default features. It is important to note that some products have extra features that can be turned on specifically to block ransomware by protecting some folders, but I am running with defaults.
(3) I don't update the signatures. The vms are only up for a minute or two, so most of the products don't have time to update, and I do that deliberately.
(4) Windows Defender is switched off in all vms, except, obviously, it's own test vm.
(5) To be fair, products could also have blocked the initial downloader, or even the website that it tried to reach for the ransomware. I did not test that, as it was outside the scope of this test.

Please remember that I am not knocking signature scanners, as they are an absolutely vital layer of defense, but with greater than a million new and unique samples every day, it's not possible to add sigs for them all. Remember also that, although within a few days most scanners will have had sigs added, some malware is changing every day, and only exists for one day. The real threat is not what was around a week ago. It's what's around today.

The MD5 of the malware under test is BE499852672E9A1E5D222427978EA421.

Please also remember that just because a product misses something today, it doesn't mean it's weak. Now, if it consistently misses, day after day, that might be a different story, but the world is a safer place if everyone gets stronger. The five that missed were Webroot, Windows Defender, Avira, Panda and Trend. The one that found a sig in memory (it named it Kryptic, iirc), but it still got away, was ESet. Two two that blocked it with a sig were Sophos and Avast. The two that caught it with behavior and/or heuristics, were Kaspersky and Symantec. Well done, lads. And lasses.

Let's see what tomorrow brings.

Cheers all.

Sunday, October 8, 2017

This is probably important

So, last week, I was looking at a bit of malware that was posting to gmail.com/upload.php. This was obviously a non-existent url, so I was wondering ... why?

In the fulness of time, with a bit of help from some friends, I came to understand that it was only pretending to write to gmail.com/upload.php, and it was just trying to cover its tracks. This was a Dimnie variant, with a great write-up here. (Thanks Kevin. You know who you are.)

There was this write-up, and another by Symantec at about the same time, and the nub of the matter are these points:

(1) Dimnie had been around for a few years by the time it was finally noticed in March of 2017. This means it is subtle.
(2) Dimnie achieves persistence by injecting itself into running processes. It would probably go away if the computer was rebooted, but that doesn't happen often.
(3) The versions that Paloalto and Symantec saw seemed to surveil the target. They looked for what processes were running, possibly for extra vulnerabilities, that might be used later. This means nothing, right?
(4) Initial versions installed a keylogger, but the framework was sufficiently flexible that anything could be installed. The bottom line here is that if ever you let malware loose on your computer, it is no longer yours. It belongs to someone else.
Think about this...
In my initial tests, only one product blocked it by behavior.
It took three years to be noticed the first time, in March 2017. It doesn't seem to have been seen much since then, and I stumbled on it by accident.
This either means that there have been no new versions since March, or ... given that we know they are subtle, could it be that they are simply changing it every day, as with the other bit of malware that I blogged about earlier? We could well have been missing them since March.

In my opinion, given also that its primary objective sure _feels_ like surveillance, this proves that we must start focussing on non-signature malware detection. Again, I'm not knocking signature scanners... they are vital.... we simply have to do more, and it's up to us testers to focus on testing that, rather than just sigs.

Stayed tuned, folks.

Wednesday, October 4, 2017

A first "generic detection" test

So, anyway, this is interesting...
As I mentioned in an earlier blog post, I'm interested in finding out who can detect malware "generically", as opposed to signature detection.
To achieve this, I find a pretty new bit of malware, something with low scanner detection, and run it against an unprotected machine, to see what it does. I then run it, in turn, against each of my protected machines, and see who blocks it.
Currently, I have just six products installed, but they are major av products. The malware sample is almost certainly a new variant of a trojan generally named Dimnie, but here's the interesting thing...
Only two of the six products detected it, and they detected it with a signature. They got the name wrong, but that's irrelevant. No one detected it "generically".
I'm not naming products (at this point), and I'm not knocking signature scanners. They are an absolutely vital layer of defense, and, with greater than a million new and unique, samples every _day_, it is not possible for them to catch all samples every day. (Unless we use Dr Solly's Perfect.bat, of course, but that's story for another day)
This simply proves how vital it is that we testers start looking at "generic" detections.
A White-lister would have stopped it, of course, but they have their own set of issues, especially in a corporate environment, or when confronted with macro or scripted malware.
Now I need more products installed, and more new samples.
Watch this space some more.