A potential ransomware process using EFS was discovered by researchers at SafeBreach. This approach entirely uses Windows features — and can consequently be defined as a form of ‘living off the land’ — although the primary difference with traditional ransomware is that this process uses different Windows features that are less likely to be monitored. Eight steps are required for attackers to use EFS ransomware.
Firstly, the ransomware will generate the key to be used by EFS, using AdvApi32!CryptGenKey. It then generates a certificate using Crypt32!CertCreateSelfSignCertificate, and adds it to the certificate store. It sets the current EFS key to this store, and then invokes AdvApi32!EncryptFile on every file to be encrypted.
The ransomware saves the key file (whose name was recorded in step 1) to memory, and deletes it from the two folders %APPDATA% MicrosoftCryptoRSAsid (where sid is the user SID), and %ProgramData% MicrosoftCryptoRSAMachineKeys.
The attacker then flushes the EFS data from memory leaving the files unreadable to either the user or the operating system; and wipes the slack parts of the disk to ensure that no temporary files can be salvaged. Finally, the ransomware can encrypt the key file data, and send the decryption key to the attacker. If asymmetric encryption is used for this, the only way to decrypt the files will be through use of the attacker’s private key.
“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),” state the researchers.
They tested the methodology against ESET Internet Security 12.1.34.0, Kaspersky Anti Ransomware Tool for Business 4.0.0.861(a), and MS Windows 10 Controlled Folder Access on Windows 10 64-bit version 1809 (Build 17763). None of these solutions would detect this form of ransomware; however, it should be stressed that this is not a flaw in any security product, nor even a vulnerability in Windows (the Windows code works exactly as it was intended to). It is possibly best described as a potential adversarial manipulation of designed logic — or a form of living off the land.
The researchers sent their findings to 17 of the major vendors of Windows endpoint protection, anti-malware and anti-ransomware. The majority, ten of the 17, accepted the issue and have developed workarounds for their products. A few did not accept the argument. Avira, for example, replied, “We believe that this potential bypass which is dependent upon a customized use scenario is not a realistic ‘failure point’.”
Microsoft replied, “We assessed this submittal to be a moderate class defense in depth issue, which does not meet the Microsoft Security Servicing Criteria for Windows (https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria…).”
One vendor — Panda — said that its own protection methodology would or could block the approach. “Only processes classified as goodware at our Panda detection cloud can modify the included/protected files,” it said.
Only one of the vendors, F-Secure, said ‘thank you, we already detect this’. Anthony Joe Melgarejo, service owner in F-Secure’s tactical defense unit, gave SecurityWeek further details. “In July 2019,” he said, “we were contacted by a researcher at SafeBreach regarding a potential security bypass technique in multiple anti-ransomware vendors’ products. SafeBreach had not specifically tested against F-Secure SAFE, but had found that the ‘vast majority’ of competing products it had tested were vulnerable.”
When F-Secure tested the technique, it found that its product already detected and blocked it (detection name Trojan.TR/Ransom.Gen) through its backend AI and heuristic file analysis. However, his colleague, principal security consultant Antti Tuomi, pointed to the importance of SafeBreach’s research. “By using tools that exist on the target, such as the Windows EFS in this case, you are more likely to avoid the logistics and potential compatibility issues of bringing in your tooling without getting caught. Seeing the same concept used by more manual attackers be successfully used in more automated malware is an interesting (although not completely unexpected) development. On the defensive side,” he continued, “and from an incident response/detection tooling point-of-view, this underlines the need for detecting not just potentially malicious software and tools, but malicious behavior regardless of what tools are used.”
The threat from EFS ransomware is greater for individual users than for corporations. “Machines that are joined to a domain,” Amit Klein, VP security research at SafeBreach, told SecurityWeek, “have the EFS key automatically backed up to the domain controller, and the domain controller could restore the key without reference to the attacker.”
There is also a relatively simple workaround for individual users. If EFS is not required, explain the researchers, “A user with administrator rights for a Windows machine can turn off EFS by setting the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionEFSEfsConfiguration to 0. Group Policy can be used for enterprise-wise disabling of EFS.”
The Windows OS developers, as opposed to the anti-ransomware app developers, could solve the problem entirely by adding a new feature to stand-alone Windows. It would simply require the EFS keys to be backed up safely — similar to backing up to the domain controller — in a place or manner that is inaccessible to the ransomware attacker.
In the meantime, individual users should check with their anti-ransomware vendor that their product will detect this type of EFS attack, and use the registry solution if it does not.
Silicon Valley-based SafeBreach was founded in 2014 by Guy Bejerano and Itzik Kotler. It offers a breach and attack simulation platform. It raised $15 million in a Series B funding round in May 2018, bringing the total raised to $34 million.
Tags:
