How Do I Know if My BTR and DAT Files are Affected By CryptoWall virus?
Depend on the variance of the CryptoWall attack, your BTR and DAT files in DATA folder may or may not be affected.  To confirm this, use Windows Explore and browse to your Elliott DATA folder.  If your BTR and DAT files are renamed and show up like following, then they are affected.  See sample screen below:



How Is Elliott Affected by CryptoWall?
Depend on the variance of the CryptoWall ransomware.  Some of the latest one we discoverred, they will crypt all files, including EXE, DLL and Elliott database files like BTR and DAT files.  This render Elliott inoperable.  The older version of CryptoWall only attack on document files and Elliott will continue to run even after being infected by CryptoWall.  If you are hit by one of the older version of CryptoWall, the following is a list of files and folders that will be attacked by CryptoWall. You should restore them from your backup, even though they don't stop you from continuing to run Elliott:

• <ElliottRoot>: *.DOC, *.PDF, *.TXT, *.LOG, *.BAT, *.CSV, *.BMP
• <ElliottRoot>\APINV: *.PDF and all image files
• <ElliottRoot>\CCSig: *.BMP
• <ElliottRoot>\CONTRACT:
• <ElliottRoot>\DATA: *.BMP, *.BTR and *.DAT (for CryptoWall variance discoverred on 7/13/2016)
• <ElliottRoot>\DATA_02 - 99: *.BMP
• <ElliottRoot>\DDF40: *.SQL
• <ElliottRoot>\FIMAGES: all image files
• <ElliottRoot>\FORMS: *.DOC
• <ElliottRoot>\HELP: *.TXT
• <ElliottRoot>\IMAGES: all image files
• <ElliottRoot>\LOG: *.LOG
• <ElliottRoot>\SOUND: *.WAV
• <ElliottRoot>\SPEC: *.PDF
• <ElliottRoot>\WAVE: *.WAV

<ElliottRoot> refers to the Elliott root directory like "M:\Elliott7". Above is a list folders and files installed by Elliott that can be affected by CryptoWall.  If you have created additional folders and files in <ElliottRoot> and its sub-folders, then it is up to you identify those files that become encrypted.

What Can We Do to Reduce the Impact of CryptoWall on Elliott?

Make Sure You Have Good Backup
It is extremely important that you have good backup.  If you don't have a good backup, then you might as well pay the ransom to get your files back. You should review your backup procedure.  Also, you should verify if your backup is complete so when the time comes to restore your files, you will have it.  Don't just take someone's word for it.  We have seen many incidents where when restoration is needed the user finds out either the backup is not done properly, or the backup copy is old. In one incident, even the backup copy is affected by the CryptoWall.  It may be a good idea to seek IT professional help with reviewing your backup procedure.

Use a Hosted Email Service
Hosted Email Services like Office 365 or Gmail may help reduce the risk of attack.  For those who host their own email server, like Exchange, and depend on anti-virus software to catch this virus, that usually is not sufficient.  The CryptoWall virus evolves so quickly that the anti-virus software definition can't be updated quickly enough to be effective. 

Educate Your Users
Educate your users not to open attachments in an email unless it is from someone they know.  Even if the attachment is from someone they know, they have to see if the context of the email makes sense.  If the context does not make sense, don't open it.  Call the party who sent the email and verify if the email is authentic.  You can also forward the email to your smartphone and open the attachment.  From our understanding, CryptoWall does not attack smartphone devices.

We have noticed that ransomware may attack through a remote desktop login by using a "brute force" method.  This makes users with less secure passwords vulnerable.  For those of you that allow remote users to login through a remote desktop, you should set up a password policy that requires a password length of at least 8 digits that mix uppercase, lowercase, numbers, and even special characters.

If you allow users to login through a remote desktop, you should try to limit the source IP address range.  A common mistake is that, since the remote user does not have a static IP address, IT just allows all IP addresses to login through a remote desktop. This makes your network vulnerable a brute force remote desktop attack.  You should consider the following practice:

• Ask your user to get a static IP address so you can limit the remote desktop access to that static IP address.  The negative side of this requirement is that this will increase the cost of your user's Internet connection.
• Even if your user has a dynamic IP address, as long as the user does not shut down the router, the dynamic IP address can be relatively "static" for a few months or more. As the IT, you can input that IP address into your firewall like a static IP address.  The negative side of this is that from time to time, IT will need to revise this IP address when it changes.  If you choose to go this route, make sure the user's Internet router is backed up with a battery so that a power failure will not cause the IP address to be re-assigned.
• Assign a range of IP addresses.  Usually, a user's ISP will be given a range of IP addresses. Often, when the IP address is re-assigned, it is in the same range, or in the group of that range. For example, if your user's IP address is something like: 001.002.003.004, you may consider opening the IP address range to include from 001.002.000.000 to 001.002.255.255. While this is not as secure as a static IP address, this is safer than leaving it wide open for all IP addresses, which allows for possible attack from IP addresses in Eastern Europe.

You should also consider implementing VPN for your remote desktop users.  Most of the complaints we see with VPN revolve around the fact that it makes remote desktop access more likely to break, so some of the users do not like to use it.

Upgrade to Elliott V8.0 and Implement Proper NTFS Security
We recommend that you upgrade to Elliott V8.0 and implement the recommended NTFS security.  See the following Knowledge Base article:
http://support.elliott.com/knowledgebase/articles/654601-elliott-8-0-directory-structure-and-ntfs-rights

If you implement the recommended NTFS security, then the only folder that can be impacted by CryptoWall attack are the followings:

• The *.DAT files in DATA folder.  This may cause the counter in DAT files mismatch with the *.BTR file which are immune from attack if NTFS security is implemented.  To reset the counter back to proper value, please see the following article: http://support.elliott.com/knowledgebase/articles/954019-how-to-reset-the-counter-in-dat-files-after-reco
• The LOG folder, which contains *.LOG files that you can easily restore.
  
• For the user who bring in the Crypto Wall Ransom Wall, its own reports will be attaked in the Reports folder. You will need to restore them.

Will Elliott V7.5, it is possible to implement the same NTFS security.  But it is a lot more difficult due to its directory and sub-directory structure, which is not optimized for NTFS security control purposes.

On 10/31/2017, we witnessed an incident where an Elliott user's workstation was affected by ransomware through a remote desktop brute force attack. The alarming thing about this is that it will attack any share on the network even though the share is not mapped to a network drive. Therefore, we can no longer assume that if we don't map the drive for the share, the share will not be attacked. The only safe way to guard against this type of attack is to implement Elliott NTFS security.  

EMK