CryptoPrevent v2.5 has just been released with a few changes, including a new layer of protection against malicious software.
How often have you seen executable trojan droppers for malware disguised as a document? If you have any experience in the field, the answer should be FREQUENTLY. This particular tactic of malware relies on the fact that file extensions are hidden in Windows by default, so most users will see the normal icon and a filename of Document.docx instead of Document.docx.exe and similar.
Fake File Extension Executables
The new option in v2.5 is called Fake File Extension Executables, and protects against executable files in all locations of the file system with 3 or 4 character fake file extensions, (e.g. Invoice.pdf.exe) specifically the rules are:
*.???.exe and *.????.exe*.???.com and *.????.com*.???.scr and *.????.scr*.???.pif and *.????.pif
- rules changed in v2.5.3 to *.x.y where
- x = pdf, doc, docx, xls, xlsx, ppt, pptx, txt, rtf, zip, rar, 7z, jpeg, jpg, png, gif, avi, mp3, wma, wmv
- y = exe, com, scr, and pif.
I must admit, I didn’t have the original idea myself. I owe this jewel to Steve B at sanesecurity.com, a maker of 3rd party ClamAV anti-virus definitions. Thanks Steve! UPDATE: Unfortunately Steve’s idea of utilizing *.???.exe for example wasn’t working properly, perhaps another bug in Microsoft software protection policy, where the ? wildcard was acting like an * instead and causing any double file extension executable to fail, so the list had to be refined to specific rules e.g. *.pdf.exe instead.
Other Changes
One other change is the “Temp Extracted Executables in Archives”, a function which protects against launching executables from inside archive files, is now unchecked by default, and selecting this option now carries a warning. I personally feel that this option isn’t really necessary, and it is coming to light that it is interfering with other applications, such as the installation of Firefox (which specifically matches the 7zip rule.)
Besides, what is to stop one from simply extracting the archive and then running the executable? It is simply an inconvenience for many people to do so, and the protection provided by this option outweighs the potential to impede legitimate usage. The original concept of this layer of protection was also not my own, and while I didn’t think it necessary for the majority of users, it is all the rage on the interwebs going along with Cryptolocker prevention information, so I included it in the app anyway and I won’t remove the functionality for that reason… On the other hand, what I have to weigh is that there are users of all skill levels downloading CryptoPrevent, and some of those users won’t know why Firefox failed to install – others will realize that it is CryptoPrevent and get annoyed, disabling the protection perhaps even removing the app and protection from their PC permanently as they will blame CryptoPrevent for the failures and the additional hassle (and rightly so!)
So in short, I urge you to consider the fact that if you enable this layer of protection, there may be consequences and you may need to temporarily undo the protection at times.
What I did NOT change was the command line syntax that comes along with enabling this protection, which still enables this protection by default when using the “/apply” or “/silent” parameters, so I strongly urge command line users to apply the “/notempexes” parameter to their CryptoPrevent deployment scripts unless you know for a fact you wish to enable this layer of protection, and are prepared to deal with the consequences. I may yet remove this as a default option in the future, so keep your eyes on my revision history.
If you have already deployed CryptoPrevent
If this is the case, then I urge you to re-deploy CryptoPrevent in the same fashion that you originally deployed it, in order to apply the new layers of protection as provided in v2.5 (and optionally remove the layer for Temp Extracted Executables from Archive Files.) Note that there is no need to remove protection before re-applying it. All layers of protection are removed automatically prior to applying the protection, so there is no need to undo the protection first, even when you are changing the configuration of protection being applied.
4 Comments
Leave your reply.