TrojanZipperPOC and ESET signatures Case Study

[MacDefender]

I noticed something cool when revisiting my fake ransomware that used 7z.exe to ransom data. ESET now detects it as "MSIL/Hoax.FakeFilecoder.FP"

So that begs the question: How is ESET going to respond to some variations in this binary? So here's some quick experiments:

1. Changed just the string I print out at the end. It's now "A Variant Of MSIL/Hoax.FakeFilecoder.FP"

VirusTotal

VirusTotal

www.virustotal.com

2. Changed the file extension from ".encrypted" to ".ransom". Still "A Variant Of MSIL/Hoax.FakeFilecoder.FP"

VirusTotal

VirusTotal

www.virustotal.com

3. Split the arguments to 7zip:
Before:

            string args = " a -t7z -pransom -sdel " + string.Format("\"{0}\" \"{1}\"", dst, src);

After:

            string args = string.Format("{0} {1} {2} {3}",  "a", "-t7z", "-pransom", "-sdel") + string.Format("\"{0}\" \"{1}\"", dst, src);

No Detection:

VirusTotal

VirusTotal

www.virustotal.com

As a bonus test, I just fired up a new VM and created a new project, and copy-pasted the exact same C# code into it. Kind of puzzled: No detection either:

VirusTotal

VirusTotal

www.virustotal.com

It's an interesting look at the signatures that ESET produced for this file. As I expected, it will detect straightforward variations but it seems like they centered the detection around the arguments to 7zip, and if those are broken apart or reordered, even though the application does the exact same thing, a static scanner has a hard time being able to discern that.


This is one of the gripes I have with static scanning. Many tools and methods exist for obfuscating code to make it difficult to statically inspect. What you ultimately cannot hide is the fact that this thing, on execution, will try to run 7zip. I would say a rule around using "7z.exe" with a -p (password) and a -sdel (source delete) argument should be considered highly highly suspicious. While it's normal to use 7zip, using it with those two arguments strongly implies something fishy is going on.


NOTE: As a caveat, perhaps because they labeled this as a hoax, they do not consider it serious enough of a threat to produce high-quality signatures for.

 

[SeriousHoax]

Great analysis

-sdel (source delete) argument

After ESET created a signature when I deleted this source delete argument for the bat sample tested here, ESET don't detect it anymore. So this argument is vital and put into consideration while creating signatures then. https://malwaretips.com/threads/fun-exe-fun-bat-similar-behavior-to-chinese-ransomware.99920/

 

[Wraith2020]

I must say that Wise Vector is showing to be a promising companion tool to run alongside an AV. Considering it to be a newcomer with AI detection it seems to be doing a great job at protecting a system when traditional AV's are failing.

 

[MacDefender]

I must say that Wise Vector is showing to be a promising companion tool to run alongside an AV. Considering it to be a newcomer with AI detection it seems to be doing a great job at protecting a system when traditional AV's are failing.

I should play around with WiseVector a bit and see what ways there are of defeating it. So far I've found with most AVs that if you are trying to target it, you know its weak spot and it becomes easier to tailor an attack against it.

 

[bayasdev]

Changing some code lines and compiling my Ransominator again makes it undetectable for signature based approach
From 18/73 to 0/72 in less than a minute

 

[MacDefender]

Changing some code lines and compiling my Ransominator again makes it undetectable for signature based approach
From 18/73 to 0/72 in less than a minute

Yup that's exactly what I expect out of signature scanning. Whether it's ML or not, you can only tell so much from static inspection, which is why most enterprise and cloud products that claim to protect against APTs will use some sort of virtualization/sandbox-based detonation.

A behavior blocker can simply be thought as an extremely dangerous local version of that -- it's a local malware detonator that runs unprotected on your machine. If it identifies the suspicious behavior you're safe, if it doesn't, your host machine is compromised.

But at least when the malware detonates, there is very little you can do to hide the behavior. Like in your exploit, at some point you have to spawn 7z.exe with a -p and a -sdel argument. You can infinitely hide the code that spawns that, but by the time it turns into a Win32 API call you cannot hide it anymore. That's why I put so much value in a behavior blocker.

 

[blackice]

Yup that's exactly what I expect out of signature scanning. Whether it's ML or not, you can only tell so much from static inspection, which is why most enterprise and cloud products that claim to protect against APTs will use some sort of virtualization/sandbox-based detonation.

A behavior blocker can simply be thought as an extremely dangerous local version of that -- it's a local malware detonator that runs unprotected on your machine. If it identifies the suspicious behavior you're safe, if it doesn't, your host machine is compromised.

But at least when the malware detonates, there is very little you can do to hide the behavior. Like in your exploit, at some point you have to spawn 7z.exe with a -p and a -sdel argument. You can infinitely hide the code that spawns that, but by the time it turns into a Win32 API call you cannot hide it anymore. That's why I put so much value in a behavior blocker.

So which behavior blockers do you like right now?

 

[MacDefender]

So which behavior blockers do you like right now?

Of the ones I’ve personally used extensively, I’ve been most impressed by F-Secure and Emsisoft. They were the most consistent in blocking the behaviors of replication + startup item registration, directly encrypting the user’s files using various techniques, and downloading and executing a secondary payload without showing a UI.

The ones I’ve tested that perform poorly are ESET (which frankly we agree basically has no behavior blocker, but their features descriptions and white papers really make it sound like they do have a behavior blocker) and Norton as well as default versions of SEP. Norton recently (last few months) added a Data Protector which helped against encryption based PoCs but I still had a lot of trouble getting it to trigger on the other potentially malicious behaviors.

Of the ones I haven’t personally tested, Kaspersky and WiseVector stand out. Both of them have been tested by others here against most of my samples and they did as well as or even better than my top choices. I especially am impressed by Kaspersky System Watcher’s rollback mechanism, which gives it a bit more freedom to allow the malware to do more things knowing that it can probably roll back the actions. With that said it’s been shown to not always work perfectly, sometimes even with rollbacks it still loses a half dozen files or so.

I have been choosing AV software for more reasons than just the BB though. Right now I mostly alternate between F-Secure and Norton. Norton’s SONAR reports are really neat and that usually serves as a front line defense for me for determining if I should scrutinize a download more closely. And both of these products tend to go on sale frequently and price is still an important factor.

in the future, I plan on getting a KTS license the next time I see it go on sale in the US. I would like more time testing that product.

 

[SeriousHoax]

I especially am impressed by Kaspersky System Watcher’s rollback mechanism, which gives it a bit more freedom to allow the malware to do more things knowing that it can probably roll back the actions. With that said it’s been shown to not always work perfectly, sometimes even with rollbacks it still loses a half dozen files or so.

Bitdefender has rollback feature too. I don't know how effective it is. Give it a try sometime if you can.

 

[MacDefender]

Bitdefender has rollback feature too. I don't know how effective it is. Give it a try sometime if you can.

I'll definitely give it another shot. The last time I tested the behavior blocker component I had difficulty getting it to trigger.

As an aside, late last year when I tried it, I gave up hope on being able to use it for day-to-day. It had too many components that tried to be "helpful" in unhelpful ways. It would intrusively nag about browsers that didn't have the plug-in installed, or tell me about system updates that it thinks I should've applied, etc. It was a pretty good example of a suite that tried to do too much. That combined with their sales department made it unappealing for me to use as a product.

I'm still willing to test it though, it's just unless there's significant changes I wouldn't consider using it again.

 

[Wraith2020]

I should play around with WiseVector a bit and see what ways there are of defeating it. So far I've found with most AVs that if you are trying to target it, you know its weak spot and it becomes easier to tailor an attack against it.

Keep us updated mate. I am also eager to see if WiseVector can be bypassed. So far it has managed to hold up and fight with the big names out there. Kudos to them.

 

[blackice]

I'll definitely give it another shot. The last time I tested the behavior blocker component I had difficulty getting it to trigger.

As an aside, late last year when I tried it, I gave up hope on being able to use it for day-to-day. It had too many components that tried to be "helpful" in unhelpful ways. It would intrusively nag about browsers that didn't have the plug-in installed, or tell me about system updates that it thinks I should've applied, etc. It was a pretty good example of a suite that tried to do too much. That combined with their sales department made it unappealing for me to use as a product.

I'm still willing to test it though, it's just unless there's significant changes I wouldn't consider using it again.

With BD you definitely have to turn off all those notifications and ignore the ‘vulnerability scanner’. It’s a pretty good product, but lots of bloat as the price tiers go up. The Total Security suite is useless, it optimized my startup items without asking. So I went back to IS.

 

[MacDefender]

With BD you definitely have to turn off all those notifications and ignore the ‘vulnerability scanner’. It’s a pretty good product, but lots of bloat as the price tiers go up. The Total Security suite is useless, it optimized my startup items without asking. So I went back to IS.

That was perhaps my problem -- I went right for the Total Security suite and kept getting surprised by features that caught me off guard one after another. By the time I found all of the switches that needed to be flipped, I lost trust and patience in the software.

ESET suffers this to a smaller degree but installing the NOD32 variant makes it pretty tolerable.

I think it goes to show how much Norton in particular has spoiled me. It has a lot of components that are set up sensibly by default to not annoy the user. It's also better at separating what they feel are "optional" layers of protection (like the browser plugins) where it will not actively alert you about those things not set up, but when you open their UI they do offer reminders.

 

[Hexspeak]

ESET's detection is likely to be based on the combination of API calls and their arguments. Also it will account for other features (strings and other metadata), as stated in its tech whitepaper. This seems to be a standard method most relatively robust detection engines will implement (but the underlying feature representation and pattern match algorithm will vary). My past experience is that it rarely use strings as the unique identifier and in some cases changing strings does not help at all, which makes sense since strings are "weak" features.

To avoid detection, one can change meta features (strings, compiler features, etc.), and can also further replace existing syscalls with their equivalents & obfuscate the parameters, or even rewrite some key routines. My past experiment on this yields somewhat interesting results: by replacing different APIs with their equivalents in a detected ransomware, the detection name will also change accordingly (e.g. from Filecoder.A to Filecoder.AB, and then to Filecoder.CD...). This is a strong indicator that what I have tried have been explored by other people and a good heuristic algorithm caught my "zero-day" sample as long as it is in its known realm.

Of course eventually I managed to produce a sample to avoid the client-side detection. However my personal view on this is that the real malware industry won't do this. For people who sell malware as a service, changing the source code is too expensive and can hardly be automated. Imagine that you spend hours in changing the code to avoid detection, and the cloud blacklist and generate signatures within minutes (note that the client side may flag a sample as benign, but the cloud counterpart may not, because it has better emulation engine, better sandbox, and better AI models, this is a common practice among AV vendors to avoid/delay adversarial trial-and-errors). Thus what the malware authors are likely to do is to obfuscate the existing code with different techniques as much as possible, and will only change the source code every several weeks for example, when existing techniques have been exhaustively "handled" by the majority of vendors. That's why some past reports shows periodic detection rate dip for a certain malware family.

As a side note, it seems that ESET's BB is mainly targeting big families. Thus a hoax program definitely won't catch its attention. This has the advantage of extremely low false positive, and in the realworld case, this is also effective from a probability's standpoint. Many other "strong" BB more or less suffer from FPs in my past testings. Some vendors rely on whitelisting, but it won't help in a corporate environment or more complex situations. For example, many remote desktop apps provides package customization to enterprise users, and AVs may produce FPs. This cannot be effectively whitelisted because it is company specific. Perhaps that's why in AV-C's most recent FP tests, some even flag popular packages such as Teamviewer as malicious.

 

[bayasdev]

ESET's detection is likely to be based on the combination of API calls and their arguments. Also it will account for other features (strings and other metadata), as stated in its tech whitepaper. This seems to be a standard method most relatively robust detection engines will implement (but the underlying feature representation and pattern match algorithm will vary). My past experience is that it rarely use strings as the unique identifier and in some cases changing strings does not help at all, which makes sense since strings are "weak" features.

Deleting a single character from a string and recompiling is enough to bypass ESET signatures

 

[Hexspeak]

Deleting a single character from a string and recompiling is enough to bypass ESET signatures

what's its original detection name?

 

[bayasdev]

what's its original detection name?

Win64/Filecoder.BQ

 

[Hexspeak]

Win64/Filecoder.BQ

From VT's statistics, this seems to be a fairly new signature. I am wondering if you could PM me the original sample and the one that avoids the detection?

Sometimes I indeed found some signature are not strong, and even "dumb". Seems to be heavily dependent on the malware prevalence

Update:

alright I think I've got the sample

After a glance through the PE, I assume the key string features of this sample are these four parts: encryption extension list, hardcoded encryption path, zip routine, and ransomnote. Changing the extension list may compromise the feature, changing the note may be better. Randomly changing things above will still trigger the detection. While changing a combo of those can avoid the detection, the sample is in a nasty situation already.

Of course one can locate the key char that may significantly lower the scoring and avoid the detection upon deletion, or use basic method to concat the string or xor the string. But again, this requires some manual efforts. When manual efforts are involved, all bets are off (at least on the client side). The key here is when the mutated sample gets prevalent again, the detection signature will again be modified to be more robust. Thus I assume it is harder to avoid the detection using such evasion technique on more popular families. In addition, a production ransomware will have more features to be extracted including VSS deletion, key exchange, etc. Once there are more functionalities involved, simply changing a string or an API call won't do the trick.

I remembered my past experiments with a more popular ransomware required me to change 4~5 key strings/functions combos to eventually avoid the client-side detection. I guess applying a packer is more cost-efficient in this case....

 

[MacDefender]

FWIW a few weeks later, every one of the samples in my OP is detected by at least a dozen engines on VT. It's interesting to see the reaction. Yet once again, subtle modification to the code results in evading the detection again.

At the end of the day, the point I was trying to make with these POCs was that this is a test of zero-day suspicious behaviors, not how quickly signatures can be written to flag this. I can find infinite ways to express in code this end result of launching 7zip to encrypt a file. The bulletproof way of stopping this attack is to detect this suspicious invocation of 7zip's CLI tool.