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:
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
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.
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:
- 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.
- Looks for "My Documents\test" (to restrict it from being ACTUAL ransomware), loops through every file in there.
- 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 Program | Files in My Documents\test | Comments | Tester |
| ESET NOD32 (all heuristics set to highest, HIPS set to Smart) | ENCRYPTED | @MacDefender | |
| F-Secure SAFE 17.8 Beta | ENCRYPTED | Ransomware protection is even enabled | @MacDefender |
| Symantec Endpoint Protection 14.x (latest) | ENCRYPTED | @MacDefender | |
| Windows Defender Controlled Folder Access | intact! | CFA blocked anything from happening | @MacDefender |
| Emsisoft AM 2020.2 | ENCRYPTED | @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:
