---

Abstract

Ransomware is a serious threat to individuals, SOHOs/SMBs and large enterprises. Consequently, many security solutions are now available, which attempt to address the ransomware threat. In this blog post we describe EFS-based ransomware (ransomware which abuses the Windows Encrypting File System), which is a new concept we developed in Safebreach Labs. We put 3 anti-ransomware solutions from well-known vendors to the test against our EFS ransomware. All 3 solutions failed to protect against this threat. We then notified 17 major anti-malware and anti-ransomware vendors for Windows endpoints, provided them our PoC, and discovered that many products were affected. Most affected vendors deployed updates to address this new technique. We conclude that the EFS ransomware is an alarming concept and a possible new threat in the ransomware horizon.

Introduction

“Ransomware is a type of malicious software […] that threatens to publish the victim’s data or perpetually block access to it unless a ransom is paid. [Modern ransomware] uses a technique called cryptoviral extortion, in which it encrypts the victim’s files, making them inaccessible, and demands a ransom payment to decrypt them.” (from Wikipedia – https://en.wikipedia.org/wiki/Ransomware).

Here are several high-profile examples of the damage ransomware has inflicted::

• MUNI (San Francisco Municipal Transportation Agency) was attacked by HDDCryptor ransomware in November 2016 (https://arstechnica.com/information-technology/2016/11/san-francisco-muni-hit-by-black-friday-ransomware-attack/). The ransomware attacked the ticketing system, effectively shutting it down. The train station gates had to remain open for 2 days (thus inflicting a loss of 2 days-worth of income).
• Merck was hit by NotPetya in June 2017 (https://www.beckershospitalreview.com/supply-chain/merck-attributes-135m-in-lost-q3-sales-to-notpetya-cyberattack.html), forcing them to temporarily halt their drug production and thus incur a loss of \$135,000,000.
• In a May 2017 WannaCry attack against the UK health sector, “hospitals, doctor’s surgeries and accident and emergency wards in the UK had been affected by the attack and some were even reportedly turning patients away” (https://www.computerworlduk.com/galleries/security/worst-ransomware-attacks-3641916/).

EFS Ransomware Explained

EFS background

The Windows operating system (starting with Windows 2000) offers a feature called EFS (Encrypting File System) for its business users (the Pro, Professional, Business, Ultimate, Enterprise and Education editions, depending on the Windows version). This feature enables the encryption of specific folders and files, keyed to the Windows user. The encryption/decryption is carried out in the NTFS driver, under the file system filter drivers. Encryption/decryption is transparent to the user – part of the key is stored in a file that is accessible to the user and part of the key is computed from the user’s account password. Thus the user does not need to provide a password for EFS to work.

EFS is not to be confused with BitLocker. BitLocker is a full disk encryption feature, while EFS selectively encrypts folders and files. With BitLocker, the disk needs to be decrypted prior to booting and in order to decrypt the disk, the user needs to type the password (or plug in a USB key or have BitLocker use TPM if the device has one) during the pre-boot stage. .

EFS ransomware basics

EFS can be used to implement the following interesting kind of ransomware:

1. The ransomware generates a key (using AdvApi32!CryptGenKey) to be used by EFS and records the file name used by CAPI for this key.
2. The ransomware generates a certificate for this key, using Crypt32!CertCreateSelfSignCertificate, and adds it to the personal (“MY”) certificate store using Crypt32!CertAddCertificateContextToStore.
3. The ransomware sets the current EFS key to this certificate using AdvApi32!SetUserFileEncryptionKey.
4. Now the ransomware can invoke AdvApi32!EncryptFile on every file/folder to be encrypted.
5. The ransomware saves the key file (whose name was recorded in step 1) to memory and deletes it from the following two folders:
   • %APPDATA% \Microsoft\Crypto\RSA\sid\ (where sid is the user SID)
   • %ProgramData% \Microsoft\Crypto\RSA\MachineKeys\
6. The ransomware flushes the EFS data from memory using the undocumented AdvApi32!FlushEfsCache (available since Windows Vista). At this time, the encrypted files become unreadable to the user (and operating system).
7. Ideally, the ransomware wipes the slack parts of the disk to ensure that data from the deleted the EFS key files and temporary files used by EncryptFile cannot be salvaged. This can also be done before the previous step.

The ransomware can now encrypt the key file data collected in step 5, for example, using an asymmetric (public) key hard-wired into the ransomware and send the encrypted data to the attacker directly (or instruct the victim to do so).

To restore the files, the attacker needs to decrypt the key files using the attacker’s private key and have the malware restore them to their original position. Once this takes place, Windows can once again read the user files.

Note that one of the key files is under %APPDATA%, that is, under the user’s profile. If the user has a roaming profile defined, the files in the user’s profile are merged back to the central network server upon logout (https://msdn.microsoft.com/en-us/library/windows/desktop/bb776892(v=vs.85).aspx). However, the EFS ransomware deletes this key file before logout so the key file is not saved to the network.

The EFS ransomware was tested with Windows 10 64-bit versions 1803, 1809 and 1903, but should also work on Windows 32-bit operating systems, and on earlier versions of Windows (probably Windows 8.x, Windows 7 and Windows Vista).

Benefits

• EFS ransomware works at a very deep level of the kernel. The files are encrypted at the NTFS driver level, and this modification goes unnoticed by file-system filter drivers.
• EFS ransomware doesn’t require administrator rights. It works well in limited user accounts.
• EFS ransomware doesn’t require human interaction.

Shortcomings

• When files/folders are encrypted, a small yellow padlock icon is displayed at the top right corner of the file/folder main icon. Thus, there is a minor visible indication that something is not going as usual.
• If a Data Recovery Agent is defined for the machine (this is not the default for standalone/workgroup machines, but it is the default for domain-joined machines), then recovery is trivial using the Data Recovery Agent.
• EFS can be turned off for a machine by setting the registry key HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\EfsConfiguration to 1. Note: accessing this key requires administrator rights.

EFS-Ransomware vs. Anti-Ransomware Solutions

We tested the following anti-ransomware solutions/features:

• ESET Internet Security 12.1.34.0
• Kaspersky Anti Ransomware Tool for Business 4.0.0.861(a)
• Microsoft Windows 10 Controlled Folder Access on Windows 10 64-bit version 1809 (Build 17763)

We ran our EFS ransomware on virtualized Windows 10 machines, each with a folder of \~600MB of user files (a combination of JPG, PNG, MP4, DOC, XLS, DOCX, XLSX, SQL, CSV files of various names and sizes, with meaningful data in them), which was designated for protection (if relevant for the tested solution/feature).

All 3 products failed to protect the files from our EFS ransomware.

Based on these results, we decided to contact major vendors in the endpoint (Windows) and anti-ransomware (and anti-malware) market. We provided them with our advisory and PoC code, so that they could test their products and ensure they’re providing adequate protection against this new technique. The results are summarized below. Kudos to Avast who decided to award us with a \$1000 bounty, even though we didn’t apply for one.

Workaround

A user with administrator rights for a Windows machine can turn off EFS by setting the registry key HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\EfsConfiguration to 1 (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpef/0382ec4d-bfa9-46c9-a99a-1f2e042938c0). Group Policy can be used for enterprise-wise disabling of EFS.

Of course, this will disable EFS for the entire machine, so if EFS was used (legitimately), it too will be disabled.

Summary

In this research we demonstrated that ransomware can evolve in an alarming direction, including using built-in file encryption features in the operating system – namely abusing Windows EFS. Many security offerings from major Windows endpoint security vendors are affected, and needed updates to address this new technique.

It is clear, therefore, that in the face of the expected evolution of ransomware, that new anti-ransomware technologies need to be developed if the ransomware threat is to be contained and kept at bay. Signature-based solutions are not up to this job, heuristics-based (and even more so – generic technology-based) solutions seem more promising, but additional proactive research is required in order to “train” them against future threats.

Related work

• “Crazy Cat” claimed that RansomCrypt/DirtyCrypt ransomware uses EFS (https://www.bleepingcomputer.com/forums/t/501540/ransomcrypt-dirtydecryptexe-uses-efs/), but this claim was refuted later in the thread by Fabian Wosar (https://www.bleepingcomputer.com/forums/t/501540/ransomcrypt-dirtydecryptexe-uses-efs/?p=3114797).
• Robert Schwass described the concept of BitLocker ransomware (https://www.blackhillsinfosec.com/?p=5023). But unlike EFS malware, BitLocker ransomware requires administrator rights, and thus is limited in scope.
• Symantec reported a malware that makes use of EFS (https://searchsecurity.techtarget.com/answer/Can-Windows-EFS-hinder-malware-detection), but the EFS is used for hiding some malware files, not for ransoming.

Acknowledgements

Many thanks to Itai Browarnik and Peleg Hadar for their help in testing the EFS ransomware against the anti-ransomware solutions/features.