- Dec 27, 2016
- 1,480
That's a nice little test. However, all reputed AVs struggling with the sample might either be silly or a matter of real concern.
@geminis3 did you compile the malware on the same machine/VM image on which you're testing? If yes, likely they're trusting the file because of the origin ... or simply a result of being an object of whitelisting ...
Regardless, I think two comments posted on the WD test for and against - are interesting in this regard
@geminis3 did you compile the malware on the same machine/VM image on which you're testing? If yes, likely they're trusting the file because of the origin ... or simply a result of being an object of whitelisting ...
Regardless, I think two comments posted on the WD test for and against - are interesting in this regard
Heuristics have the issue that ransomware behaviour is not distinguishable from e.g. backup software that saves space by compressing files. Compression looks just like encryption, it raises the entropy. Renaming lots of files at once is not malicious, nor is encryption or compression. These actions only become malicious in context. So most of the time there needs to be something additional like anti-AV features, UAC bypass features, shadow copy deletion, certain ransom note keywords, code injection.
If you create a bare ransomware from scratch just using the encryption portion and no additional features, there is no way to detect it with heuristics without also flagging legitimate software.
Yeah really the main thing you can go by is the idea of a low reputation binary modifying files, especially in My Documents and other user-valuable paths. This is how most behavior blocker identify ransomware and when a low-reputation EXE is doing that work themselves, that is an easy rule to write. Kaspersky and Emsisoft simply halt such an application mid-act and give you a few seconds to answer whether or not you expected them to be doing this. Others automatically terminate the application but give you an option to whitelist and try it again.
This proactive technique breaks down for scripts (difficult to measure reputation) and when you use another binary that's well-trusted to do your dirty work for you.
For the latter, I think the right answer is enhancing behavior blockers to account for "who started this application?" and if it's an untrusted process, consider the child process untrustworthy too.