MacDefender

Level 11
Verified
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"


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

3. Split the arguments to 7zip:
Before:
Code:
            string args = " a -t7z -pransom -sdel " + string.Format("\"{0}\" \"{1}\"", dst, src);
After:
Code:
            string args = string.Format("{0} {1} {2} {3}",  "a", "-t7z", "-pransom", "-sdel") + string.Format("\"{0}\" \"{1}\"", dst, src);
No Detection:



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:


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.
 
Last edited:

SeriousHoax

Level 29
Verified
Malware Tester

MacDefender

Level 11
Verified
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.
 

MacDefender

Level 11
Verified
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 :ROFLMAO:
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

Level 27
Verified
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

Level 11
Verified
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

Level 29
Verified
Malware Tester
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

Level 11
Verified
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

Level 2
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

Level 27
Verified
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

Level 11
Verified
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

New Member
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.
 

geminis3

Level 13
Verified
Malware Tester
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

New Member
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

hex.jpg

hex2.jpg


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....
 
Last edited:

MacDefender

Level 11
Verified
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.
 
Top