MacDefender

Level 4
Verified
As we talked about over in the Emsi vs F-Secure thread (Help Me Decide - Emsisoft vs. Eset Internet Security vs. BitDefender Total Security vs. F-Secure Safe (2020) ), one weakness I've found in F-Secure and other Behavior Blockers is that the most common way to escape the behavior blocker is by using a trusted (but not super well known) process to do your dirty work.

If you use something too popular like Powershell or cmd.exe, behavior blockers are smart, especially thanks to AMSI. However, if you use something just mildly popular like a Node.JS runtime, a copy of Cygwin/MinGW, or in this case, 7-Zip, it seems to be blanket whitelisted by behavior blockers.

This piece of fake "malware", which I'm calling TrojanZipperPOC, does this:
  1. Find a copy of 7-zip. It prefers "C:\Program Files\7-Zip\7z.exe", as long as you have installed a native copy of 7-zip (e.g. 64-bit on 64-bit Windows). Otherwise it uses a 7z.exe in your current folder, which I've bundled as simply a copy of my 7-zip folder on my development machine. Both copies of 7-zip are official shipping versions which means they're both signed as well as considered high-reputation by cloud lookup.
  2. Looks for "My Documents\test" (to restrict it from being ACTUAL ransomware), loops through every file in there.
  3. Runs "7z.exe a -tzip -pransom -sdel FOO.encrypted FOO" for each file you have. This puts it in a zip file with password "ransom" and instructs 7zip to delete the original file.

So far it's worked against both AVs I primarily use. Ouch! I'll spin up additional VMs to test more, but if this is worth testing in the Malware Hub as a special sample, please PM me for the binaries :)


Antimalware ProgramFiles in My Documents\testCommentsTester
ESET NOD32 (all heuristics set to highest, HIPS set to Smart)ENCRYPTED@MacDefender
F-Secure SAFE 17.8 BetaENCRYPTEDRansomware protection is even enabled@MacDefender
Symantec Endpoint Protection 14.x (latest)ENCRYPTED@MacDefender
Windows Defender Controlled Folder Accessintact!CFA blocked anything from happening@MacDefender
Emsisoft AM 2020.2ENCRYPTED@MacDefender

Conclusions:

This is a really really trivial way of commandeering a known process to do your dirty work. It's not hard to trace the fact that 7z.exe was launched directly by an untrusted process, so I consider this to be a solvable vulnerability.

It wouldn't be impossible to distance the untrusted process further from 7z.exe. For example, scheduled tasks or startup items, or using a process to launch a process, etc etc etc. So consider this a dumb "5 minute" approach (that's literally how long it took for me to write this) to replicate a in-the-wild ransomware strategy.
 
Last edited:

Outpost

Level 3
Verified
What a nice thread. This shows, once again, that no product guarantees 100% of the results. It also shows that the use of rules and technologies (Controlled Folder Access) already available in the OS are sometimes better than those of third parties.
 

MacDefender

Level 4
Verified
Great test. Would be nice if you test more products.
Thank you! Yes I do intend on testing more but I've also given this sample to @harlan4096 who is also running tests. I really like having more than just me run the tests, because I could very well be making configuration mistakes with security software I'm not familiar with.

I spend the most time using ESET and F-Secure. I try not to be biased in terms of testing but there's no denying that I understand how these products behave and can troubleshoot them a bit if the initial result is wildly surprising to me. i don't have the same intuition with other software.

What about WD without CFA? did it even detect any malicious behaviour? :unsure: probably encrypted also... I'm performing some tests with WiseVector StopX 2.09 and KTS2020, will post soon...
Someone else should also confirm this because my WD experiments were done late last night....

With CFA turned on, even me at the command line running the "7z" command results in CFA blocking it! Whitelisting 7z.exe also resulted in encrypted files.

Without CFA, WD didn't do anything either, files ended up encrypted. But this VM has a pending Windows Update so maybe WD was a bit out of date too.

My takeaway here is that CFA is super strong and super sensitive. It really means that your protected folders are TOTALLY off limits to almost everything. But if you start adding exceptions to CFA, you have to be very careful about the holes you are punching, not unlike opening ports on a firewall. My recommendation here is that CFA should be turned on if you are purposely running something you don't trust very much, but turned off for general usage. But also I think it's not wise to intentionally run untrusted things outside of a contained environment.
 

Andy Ful

Level 52
Verified
Trusted
Content Creator
...
My takeaway here is that CFA is super strong and super sensitive. It really means that your protected folders are TOTALLY off limits to almost everything. But if you start adding exceptions to CFA, you have to be very careful about the holes you are punching, not unlike opening ports on a firewall. My recommendation here is that CFA should be turned on if you are purposely running something you don't trust very much, but turned off for general usage. But also I think it's not wise to intentionally run untrusted things outside of a contained environment.
CFA is OK, but can be bypassed (like any anti-ransomware). This can be done, for example, by using your method + abusing MS Office applications, or any application added to CFA exclusions. One can use a script or macro to do it.
 

MacDefender

Level 4
Verified
Using the ESET HIPS rules against ransomware: No effect. Unfortunately this executable isn't a script to start with or started by Explorer necessarily, doesn't use rundll32, doesn't use Office, etc etc. Those are good strong rules though because a lot of ITW ransomware do use those attack vectors.

Using the "Protected Folders" technique Discuss - ESET - Implement Protected Folders via HIPS was equivalent to CFA:

1580930382945.png


But note that the HIPS says "7-Zip Console" is trying to perform this action, not my TrojanZipperPOC.exe that started 7z.exe. And you can see from that ESET output that ESET says this is a signed application from 6 months ago with good reputation.

If you click Deny, 7-zip won't be able to access your documents even when you ask it to from the command line. If you click Allow, then anyone can use 7zip to ransom your files.
 

harlan4096

Moderator
Verified
Staff member
Malware Hunter
WiseVector StopX 2.09 (Without Protection Documents -> Missed / Encrypted):

1B.png1B2.png


WiseVector StopX 2.09 (With Protection Documents -> Attack Blocked / Protected):

1A.png


KTS2020G (Defaults Settings + Auto Mode -> Detected & Removed / Encrypted):

1A.png1B.png1C.png


KTS2020G (Defaults Settings + AutoMode + TAM -> Execution Blocked / Protected):

TAM.png


KTS2020G (Defaults Settings + Interactive Mode -> Attack Blocked / Protected):

DEFAULTS + INTERACTIVE.png


KTS2020G (Defaults Settings + Auto Mode + Twaked Application Control & Folder Protection Settings -> Execution Blocked / Protected):


1A.png1B.png1C.png
 
Last edited:

upnorth

Level 39
Verified
Trusted
Content Creator
Brilliant thread! :emoji_beer: :emoji_beer: :emoji_beer:

If I thought F-Secures stable version would show any other result then the Beta version I could always have a run, but I doubt it in this case simply because of the infection description and also the result. The Ransomware protection bypass I know for example member @Lord Ami even officially reported about last year but no feedback.
 

Hindenburg

Level 1
Using the ESET HIPS rules against ransomware: No effect. Unfortunately this executable isn't a script to start with or started by Explorer necessarily, doesn't use rundll32, doesn't use Office, etc etc. Those are good strong rules though because a lot of ITW ransomware do use those attack vectors.

Using the "Protected Folders" technique Discuss - ESET - Implement Protected Folders via HIPS was equivalent to CFA:

View attachment 233299

But note that the HIPS says "7-Zip Console" is trying to perform this action, not my TrojanZipperPOC.exe that started 7z.exe. And you can see from that ESET output that ESET says this is a signed application from 6 months ago with good reputation.

If you click Deny, 7-zip won't be able to access your documents even when you ask it to from the command line. If you click Allow, then anyone can use 7zip to ransom your files.
This is very interesting.

I hope you share the sample with all of the malware hub testers.

Thanks.
 

sepik

Level 3
One thing i came across when testing malwares on my crappy laptops. When testing, some AVs have an ability to set it up to ASK mode.
When pop-up window comes, for example "Trojan Generic", "do you want to allow this". Yes, no, quarantine. Leave that pop-up window alive, dont click anything. Then check, does the AV actually STOP the process, or does it allow it to run background.

Kinda the same with Windows Firewall, in my opinion, some malwares can disable/modify windows firewall setting during early boot stage and after that. Malwares do not "target" 3rd party firewalls, which loads(what i've heard) way before windows own firewall. Yes, windows firewall is a component of the OS itself. Thats why it gets abused. But if you are using 3rd firewall, it can actually block outgoing connections even during deep boot up secuence. One good example of this is Zonealarm. It blocks low level TCP attemps during the boot up process. Someone in Wilders forum even proved this using Wireshark.
-sepi
 

MacDefender

Level 4
Verified
WiseVector StopX 2.09 (With Protection Documents -> Attack Blocked / Protected):

View attachment 233325
Neat -- CFA-like result -- blocked 7z.exe

KTS2020G (Defaults Settings + Auto Mode -> Detected & Removed / Encrypted):

View attachment 233328View attachment 233329View attachment 233330
Curious! Sure enough it didn't like something about the binary, I will have to explore which particular part made it suspicious.

KTS2020G (Defaults Settings + AutoMode + TAM -> Execution Blocked / Protected):

View attachment 233331
Yeah so this refused to run the exploit because it's a binary that's not well known.

KTS2020G (Defaults Settings + Interactive Mode -> Attack Blocked / Protected):

View attachment 233332
Ok neat, so this allowed the exploit to run, but when the exploit tries to start any console based process, KTS asks you whether or not to allow it. This is a fairly good mode of operation that gives expert users a chance to intervene with suspicious behavior.

KTS2020G (Defaults Settings + Auto Mode + Twaked Application Control & Folder Protection Settings -> Execution Blocked / Protected):

View attachment 233333View attachment 233334View attachment 233335
Hmm not sure how this worked, curious to see how KTS blocked this exploit. Also what's up with the 1 detection on VirusTotal? It's SecureAge APEX....

Overall I would say KTS is the only AV that has any sort of meaningful protection against this attack. In some configurations it correctly identified the TrojanZipperPOC binary as the offender, something that no other AV has succeeded at. However, I think this is still poor protection since the default settings left the system encrypted.

It also shows that whitelisting and not running unknown binaries are always great security practices, but that's not what we're trying to test with this POC :)