CryptoPrevent Technical Information/FAQ
- v126.96.36.199 (Jan 22nd, 2017)
- Fixed issue where registration may fail when regional settings were changed
- Added limited logging abilities with /debug or /logging CLI
- v188.8.131.52 (Jan 19th, 2017)
- Fixed issue where version 7 White-Label clients may not show as fully registered (should automagically fix at next launch of CryptoPrevent or Tray Icon, and/or start of the services (if installed)
- Fixed issue where v7 Bulk or White-Label clients may have uninstalled if v8 registration failed (client’s where this occurred will need to be reinstalled with the installer)
- Fixed issue where email password may be exposed through System Tray app even when Email Settings have been locked in White-Label editions
- Added fix for possible issue of Bulk or White-Label v8 installers not fully applying settings when reboot after install option is selected in the creator
- v184.108.40.206 (Jan 19th, 2017)
- CryptoPrevent main program and service will ensure correct Uninstall Display Version number in Add/Remove Programs at every start
- Added command line option to force updating Uninstall Display Version (/updateUninstallVersion)
- v220.127.116.11 (Jan 17th, 2017)
- Bulk version release (All versions of CP are now available for purchase)
- Many bugs and additions have been added over this time (too many to list), future revisions will have more detailed release notes.
- v8.0 (Nov 1st, 2016)
- Major additions/changes are available on the main CryptoPrevent webpage.
- More information on will be available in the coming weeks, and as subsequent revisions are released.
For the current SHA256 hash and analysis of CryptoPrevent v7.4.21, visit this VirusTotal.com link. It is possible, though not currently witnessed, that a very few A/V engines on VirusTotal will trigger false positive detections within CryptoPrevent. For a nice little utility to examine and compare file hashes you can download my tool, QuickHash.
- v7.4.21 (Nov 19th 2015)
- Resolved: Mismatched control version relating to all email functionality
- v7.4.20 (April 10th 2015)
- Redesigned: Software Restriction Policy Editor to allow resizing and longer listboxes (previously some longer rules were not displayed entirely due to the short listboxes.) *fonts may appear smaller this is a known issue and will be resolved in a future update*
- Fixed: Block Temp Extracted Executables checkbox in the Advanced interface did not apply this setting when checked.
- v7.4.8 (Nov 14th 2014)
- Added command line option /exefilter to enable the Program Filtering (BETA) setting.
- v7.4.3 (Nov 3rd 2014)
- Corrected a minor bug with the blacklisting rule creation for Max protection.
- v7.4.2 (Nov 1st 2014)
- Resolved an issue with the Program Filtering BETA which caused it to incorrectly flag existing security software as a threat that matched hash definitions.
- Testing resolution of an issue preventing the Program Filtering BETA from logging blocked events to the event logs.
- v7.4.0 (Oct. 21st 2014)
- Vastly improved algorithms for file hash comparisons with the Program Filtering BETA functionality, and enabled a much larger definition set.
- v7.3.5 (Oct. 12th 2014)
- Changed status of Program Filtering from “Experimental” to “BETA” after extensive OS testing, and set enable restrictions on OS/Service Pack level where necessary.
- (Program Filtering is not currently supported on Vista, but works for XP, Win7 with SP1, Win 8.x, and Win 10.)
- Added TLS encryption capabilities to the email configuration, to support a more wide variety of SMTP servers for the email alerts function.
- Tweaked the installation process, no longer prompting to set “default” protections, now showing the full (non-advanced) interface to allow the user to select one of the 4 pre-configured protection levels.
- Tweaked the interface a little, explaining protection levels more clearly, and added a few more advanced options to the top menu of the default non-advanced interface (in an attempt to make the old more complicated advanced interface largely unnecessary.)
- Changed status of Program Filtering from “Experimental” to “BETA” after extensive OS testing, and set enable restrictions on OS/Service Pack level where necessary.
- v7.1 (Aug. 2014)
- Added new misc. protections for known malware processes (specifically dealing with “child porn” related ransomware going around currently) which is applied to Default level of protection and higher, or listed as the “Known malware processes” check in the Advanced interface.
- Fixed two bugs associated with creating custom whitelist policies in the Software Restrictions Policy Editor (Advanced interface.)
- NEW simplified and easy to understand interface, replacing the many obscurely labeled protection option check boxes with a few simple protection “levels” to select from (the old interface still exists in the Advanced menu, and it has been updated as well.)
- Updated to not trigger Malwarebytes Anti-Malware detections with the installed version (thanks to the Malwarebytes research team!)
- Improved Filter Module function.
- Changed recommended defaults slightly.
- Enabled optional “Experimental Protection” level (the Experimental EXE/COM settings in the Filter Module.) NOTE: This setting is not largely tested and is NOT recommended for most people, as there may be side effects which could potentially cause system instability. Please understand I cannot accept responsibility for your usage of this setting. If you do wish to use this setting, I would love to hear your feedback on any issues you suspect may be related to having it enabled.
- v6.1.5 – Added new internal hash definitions for Critroni/CBT-Locker detections and a few other misc tweaks.
- Improved Recycle Bin executable protection.
- Added feature to remove ALL software restriction policies (created by CryptoPrevent or not) from the Advanced > Software Restriction Policies menu.
- Added feature to block %localappdata%* in Advanced menu > Software Restriction Policies (max protection, but this includes a block on %temp% so it may cause issues with legitimate apps; generally not recommended.)
- Added ability to install (or force install) from CryptoPrevent portable and uninstall/force uninstall from the installed version. Force option is only offered if standard methods fail. Not 100% perfect so only use the force option if absolutely necessary (e.g. the installer won’t run due to access denied errors.)
- Bulk Installers now have the option of creating custom whitelist rules during installation.
- Misc tweaks.
- v6.0.3 – Fix for a minor annoyance of mine, not worth mentioning.
- v6.0.2 – Fix for running certain screen savers with .SCR filtering enabled.
- v6.0.1 – Minor UI tweaks and added some additional information and links to the interface.
- v6.0 – CryptoPrevent is no longer based solely on Windows software restriction policies, and now includes a real-time filter and definitions files/updates!
- New ‘Filter Module’ that can filter certain executables against hash based definitions, can also filter based on other criteria using a more complex rule set, and allow user the option to run the file anyway. Enabled for CPL, SCR, and PIF files by default – advanced options allow to enable for EXE/COM files also (experimental!)
- New Policy Editor for software restriction policies, create your own custom path rules (premium feature.) You can also view, search, and selectively delete blacklist policies in effect.
- User defined hash rules for MD5/SHA256 (meaning, you can create your own hash based definitions for the Filter Module.)
- Separated all main protection policies so they may be individually applied or removed.
- Added policy to disable Windows Sidebar/Gadgets due to security vulnerabilities.
- Daily updates are now for the new definitions, and a new weekly schedule will be created for application updates.
- New email options for bulk premium custom installers.
- Easier to install and apply protection with the free version.
- v5.2.2 – Fixed a setting not being remembered correctly on program relaunch. Added some email features for the Bulk Premium custom installers.
- v5.2.1 – separated Prevent BCDEDIT.EXE option from the default protection settings, and put it in the Advanced menu. It was interfering with some backup applications..
- v5.2 – Added automated protection test after reboot if you select to reboot after applying protection. Some UI and usability tweaks. Added a link to the help forums in the Premium Edition’s Information menu. Finally added Steve Basford (Sanesecurity) to the credits!
- v5.1 – Tons of UI and usability tweaks. Added more hash values to internal block lists.
- v5.0 – Added hash based blocking system.
- v4.7.2 – Added bcdedit.exe and vssadmin.exe to the blocked executables action “Prevent system executables from running” along with syskey.exe and cipher.exe (with a new command line parameter /blocksysfiles that covers them all.) Reorganized the interface a bit and added a little description.
- v4.7 – Added blocking of fake file extensions with spaces in them to hide the extension. Added blocking of cipher.exe along with syskey.exe, for the potential abuse. Added ability to create custom block and allow policies with scripting support. (Premium version only; for documentation consult the forums here.)
- v4.4.1 – added ability to block syskey.exe from execution, which is being exploited by some new malware.
- v4.3.3 – updated digital signature on CryptoPrevent executables.
- v4.3.2 – added support for redirected %appdata% directories (Windows folder redirection typically only used on larger networks.)
- v4.3 – separated protection option for %userprofile% / %programdata% / Startup Folder and added whitelisting capabilities for those locations – also removed unnecessary reboot prompt after automatic update on Vista+ OSes.
- v4.2.6 – removed the *.com file rule for %userprofile% as this was causing some issues with user accounts with .com in the path name under certain circumstances.
- v4.2.5 – Fixed a minor bug in that using the /w= command line parameter was also forcing /whitelist whether it was specified or not.
- v4.2.4 – Fixed a recent bug causing email alerts to not be sent properly.
- v4.2.3 – Misc. changes to the White-Label edition. Added IP address / Computer Name to the optional alert email when an application is blocked (Premium edition.)
- v4.2 – Added Start Menu > All Programs > Startup folder protection. Added reboot prompt after automatic update / re-application of protection.
- v4.1.5 – Misc changes to whitelisting functionality and added a link to the Email Setup FAQ inside the program.
- v4.1 – Added RLO (Right to Left Override) exploit protection to Fake File Extension protection function.
- v4.0 – Added Event Log to check event history of blocked applications. In the Premium Edition (formerly Automatic Update Edition), added email alert capability when an application is blocked.
Software Restriction Policies Applied:
CryptoPrevent artificially implants group policy objects into the registry in order to block certain executables in certain locations from running. The number of rules created by CryptoPrevent is up to 350 rules depending on the OS and options selected! Note that because the group policy objects are artificially created, they will not display in the Group Policy Editor on a Professional version of Windows — but rest assured they are still there! NEW!
Executables protected against are *.exe *.com *.scr and *.pif, and these executables are blocked in the paths below where * is a wildcard: (These locations are used by Cryptolocker and other malware as launch points.)
- %appdata% and any first-level subdirectories in %appdata% (e.g. %appdata%directory1, %appdata%directory2, etc.)
- %localappdata% (and on Windows XP, any first-level subdirectories in there.) NOTE beginning with v2.2, any time %localappdata% is referred to on this page, it also refers to %userprofile%Local SettingsApplication data on Windows XP, where %localappdata% is not an actual environment variable.
- The All Users application data and local settingsapplication data paths on XP.
- The Recycle Bin on all drives, and all nested subfolders.
- the %userprofile% and %programdata% paths (no nested subfolders.)
- the Startup folder located in the Start menu > All Programs > Startup
Fake File Extension Executables: (ex. document.docx.exe)
- *.x.y where:
- x = pdf, doc, docx, xls, xlsx, ppt, pptx, txt, rtf, zip, rar, 7z, jpeg, jpg, png, gif, avi, mp3, wma, wmv, wav, divx, mp4
- y = exe, com, scr, and pif.
- with v4.1, now includes RLO (Right to Left Override) exploit protection.
Prevent system executables from running:
- This option prevents SYSKEY.EXE, CIPHER.EXE, BCDEDIT.EXE, and VSSADMIN.EXE from running (in any location,) as it is being exploited by recent malware. NOTE: any software requiring an automated special reboot sequence (e.g. booting AUTOMATICALLY into safe mode, recovery mode, a recovery partition, etc. etc.) may fail with this protection option enabled!
Temp Extracted Executables in Archive Files:
- %temp%\rar* directories
- %temp%\7z* directories
- %temp%\wz* directories
- %temp%\*.zip directories
The final four locations above are temporary extract locations for executables when run from directly inside of a compressed archive (e.g. you open download.zip in Windows Explorer, WinRAR, WinZip, or 7zip, and execute an .EXE from directly inside the download, it is actually extracted to a temporary location and run from there – so this guards against that as well; however this option may interfere with certain program installations (e.g. Firefox) and for this reason this option is NOT recommended for most people.)
CryptoPrevent Filter Module:
In v6+, the new real-time CryptoPrevent Filter Module seeks to block malicious executables, not blindly using Windows Software Restriction Policies, but rather it uses both a hash definitions based check and some logic based on certain attributes of the executable, in order to determine whether or not the executable should be launched. It can optionally prompt the user with a choice to run it or cancel. The Filter Module can also log to the Windows Event Logs and send emails both on blocked applications AND in situations where the user may choose to allow the blocked application.
There are two types of filtering:
- Suspicious – A file is examined and it is determined whether or not it is “suspicious” by certain characteristics. If the file isn’t suspicious, (and of course it passes the definitions comparison) then the block is not applied. Suspicious files will trigger the configured action (e.g. inform the user but do not allow execution, prompt the user to choose to execute the file, or block without prompt.
- Constant – As it implies, this always applies the filtering to that file type, triggering the configured action, regardless of the file characteristics and definitions comparison.
Notes and Recommendations:
- CPL files – the filtering is NOT applied to these files when launched as part of control.exe (Control Panel) so you can use constant or suspicious filtering with this file type without crippling Control Panel.
- SCR files – recommend to apply suspicious filtering, not constant, as that will block any configured screen savers.
- PIF files – recommend to apply constant filtering, because PIF files haven’t really been legitimately used since Windows 3.x, and if you read the history and behavior outlined below, you’ll want to block them constantly!
- The PIF file was originally a ‘shortcut’ like a modern LNK file, except it was used to launch DOS programs from within Windows, while allowing certain environment options to be configured for the console in the PIF file’s properties.
- Oddly enough, modern versions of Windows still consider a PIF file a default file type, and an executable one at that! In other words a PIF file doesn’t have to be a shortcut, it can be an actual executable and execute code just like an EXE file!
- Also Windows Explorer permanently hides the file extension, like LNK shortcuts, so you could rename “program.exe” to “program.pif” and all you will ever see in Explorer is “program” even with ‘show file extensions’ enabled in Explorer options. Renaming the file back from .PIF to .EXE would need to be done from a command prompt at that point, since you cannot interact with the file extension from within Explorer.
Program Filtering (BETA) in v7.3 and above:
Program Filtering, which is the EXE/COM component in the CryptoPrevent Filter Module described above, operates in exactly the same way, except it is specifically enabled for .exe and .com file types. This compares executables to a hash based definitions system which is updated frequently, and contains thousands of hashes for newer CryptoLocker variants, copycats, and similar ransomware.
- This option is always filtered as “suspicious” in the CryptoPrevent Filter Module. Constant filtering for these two file types is not available.
- Note that when enabling and disabling this feature the change takes place instantly, you don’t even need to click the “Apply” button.
- Program Filtering may not be initially available in the initial CryptoPrevent v8 release (at least until it is entirely compatible with all systems/software) in favor of using the same detection database with a different technique that is more compatible with all systems.
Windows Event Log Entries:
- Software restriction policies will log a blocked application to the Windows Application event log with Event ID: 866
- The CryptoPrevent Filter Module including Program Filtering log to the Application event log with Event ID: 10177 and Source: CryptoPreventFilterMod
- Whitelisting in CryptoPrevent currently applies to Software Restriction Policies only, it does NOT apply to the Filter Module including Program Filtering.
- A whitelist rule may contain environment variables native to Windows, such as %userprofile% or %appdata%
- Windows will ignore a whitelist rule containing wildcards if a more specific blacklist rule is in effect, which with CryptoPrevent rules is almost always the case.
Automation / Scripting
CryptoPrevent when run by itself will display a user interface, but command line parameters may be utilized (in v1.1 and above) for optionally silent automation. Command line parameters accepted are:
NOTE: command line parameters and syntax has changed since v6+ Most importantly, the /apply switch no longer applies all default protections, they must each be specified individually now.
- /apply – this option applies the settings specified by additional command switches.
- /silent – forces silent operation.
- /reboot – executes a forced mandatory reboot after applying protection silently.
- /undo – this option obviously removes all protection policies (but does not remove whitelist policies or the disable Sidebar policy,) and can be combined with the /silent parameter.
- /undoall – this option removes all protection policies AND any whitelist policies defined as well (except the disable Sidebar policy; the /enablesidebar switch must also be specified to remove that policy.)
- /nogpupdate – skip the group policy update after modifications are made.
Location based protection switches:
- /appdata – %appdata%
- /appdatadeep – %appdata%* (covers any first-level subdirs of appdata)
- /appdatalocal – %localappdata%
- /localappdatadeep – Protect subdirs in %localappdata% (also blocks %temp% as a consequence, not recommended)
- /programdata – %programdata%
- /userprofile – %userprofile%
- /startup – Startup Folder (in the Start Menu)
- /bin – Recycle Bin
- /fakeexts – Fake file extension executables and RLO exploit protection.
- /tempexes – Temp Extracted Executables block. (NOT recommended – may interfere with some app installations!)
- /known – Blocks several known malware processes in certain locations.
Individual file execution prevention switches:
- /bcdedit – bcdedit.exe (NOT recommended – may interfere with backup apps)
- /syskey – syskey.exe
- /cipher – cipher.exe
- /vssadmin – vssadmin.exe (Prevents Crypto malware from deleting shadow copies/previous versions of files after encryption.)
Misc protection switches:
- /disablesidebar – Creates a policy to disable the Windows Sidebar and Gadgets in Vista+ (recommended practice, by Microsoft themselves.)
- /enablesidebar – Removes the disable policy on the Windows Sidebar and Gadgets. This switch is necessary as /undo or /undoall do not perform this function!
Filter Module switches: (Note these have no effect on the portable version as the program must be installed for the filter module to function properly.)
- /fc=[ext] – where [ext] = a file extension (CPL, SCR, or PIF) enables CONSTANT filter module protection for that file type.
- /fs=[ext] – where [ext] = a file extension (CPL, SCR, or PIF) enables SUSPICIOUS filter module protection for that file type.
- /exefilter – Enables new Program Filtering (BETA) for EXE/COM files.
- /whitelist – whitelist all EXEs currently located in %appdata% / %localappdata% and their first level subdirectories.
- /w=[pathfilename.exe] – whitelist a specific file in %appdata% or %localappdata%.
- The path/filename may not contain wildcards.
- If no path is specified (e.g. /w=foo.exe ) then both %appdata%foo.exe and %localappdata%foo.exe will be whitelisted.
- If a path is specified it should be only one first level subdirectory from either %appdata% or %localappdata% (e.g./w=FooBar.exe ) which will actually whitelist both %appdata%FooBar.exe and %localappdata%FooBar.exe
- /p=[filename.exe] – whitelist a specific file in %programdata%
- /u=[filename.exe] – whitelist a specific file in the %userprofile%
- /s=[filename.exe] – whitelist a specific file in the Start menu > Startup folder
Premium version switches:
- /b=[custom block policy rule] – (Premium version only, see this thread for syntax and examples.)
- /a=[custom allow policy rule] – (Premium version only, full path/filename required, no wildcards!!)
These parameters may be used in most any logical combination, e.g.
- CryptoPrevent.exe /whitelist /reboot
- CryptoPrevent.exe /undoall /silent
- CryptoPrevent.exe /apply /appdata /appdatadeep /silent /whitelist /w=FooBar.exe /w=FooBar2.exe
Apply default protections and whitelist existing items, no reboot:
- CryptoPrevent.exe /apply /appdata /appdatadeep /appdatalocal /programdata /userprofile /startup /bin /syskey /cipher /vssadmin /fakeexts /whitelist
IMPORTANT NOTE: If you are pushing out CryptoPrevent.exe through Labtech’s RMM tool, there may be a problem with the /whitelist parameter not working as intended. You must use the ‘Process Execute as Admin’ or ‘Shell as Admin’ option to deploy properly. This is confirmed to work properly when running under the local system account as deployed via Kaseya. I do not have any feedback on other RMM deployment tools or methods.
- Protection does not need to be applied while logged into each user account, it may be applied only once from ANY user account and it will protect all user accounts on the system, even protecting accounts created after protection is applied.
Find knowledgeable professionals, using the best tools in the industry, who proudly stand behind their top quality work.