Editing Encrypting File System (section)

===Other issues===
Once a user is logged on successfully, access to his own EFS encrypted data requires no additional authentication, decryption happens transparently. Thus, any compromise of the user's password automatically leads to access to that data. Windows can store versions of user account passphrases with reversible encryption, though this is no longer default behaviour; it can also be configured to store (and will by default on the original version of Windows XP and lower) Lan Manager hashes of the local user account passphrases, which can be attacked and broken easily. It also stores local user account passphrases as [[NTLM]] hashes, which can be fairly easily attacked using "[[rainbow table]]s" if the passwords are weak (Windows Vista and later versions don't allow weak passwords by default). To mitigate the threat of trivial brute-force attacks on local passphrases, older versions of Windows need to be configured (using the Security Settings portion of Group Policy) to never store LM hashes, and of course, to not enable Autologon (which stores plaintext passphrases in the [[Windows registry|registry]]). Further, using local user account passphrases over 14 characters long prevents Windows from storing an LM hash in the SAM – and has the added benefit of making brute-force attacks against the NTLM hash harder.

When encrypting files with EFS – when converting plaintext files to encrypted files – the plaintext files are not wiped, but simply deleted (i.e. data blocks flagged as "not in use" in the filesystem). This means that, unless they for example happen to be stored on an [[SSD]] with [[Trim (computing)|TRIM]] support, they can be easily recovered unless they are overwritten. To fully mitigate known, non-challenging technical attacks against EFS, encryption should be configured at the folder level (so that all temporary files like Word document backups which are created in these directories are also encrypted). When encrypting individual files, they should be copied to an encrypted folder or encrypted "in place", followed by securely wiping the disk volume. The Windows Cipher utility can be used (with the /W option) to wipe free space including that which still contains deleted plaintext files; various third-party utilities may work as well.<ref>{{cite web|url=https://technet.microsoft.com/en-us/library/cc700811.aspx#XSLTsection125121120120|title=The Encrypting File System|website=technet.microsoft.com}}</ref>

Anyone who can gain Administrators access can overwrite, override or change the Data Recovery Agent configuration. This is a very serious issue, since an attacker can for example hack the Administrator account (using third-party tools), set whatever DRA certificate they want as the Data Recovery Agent and wait. This is sometimes referred to as a two-stage attack, which is a significantly different scenario than the risk due to a lost or stolen PC, but which highlights the risk due to malicious insiders.

When the user encrypts files after the first stage of such an attack, the FEKs are automatically encrypted with the designated DRA's public key. The attacker only needs to access the computer once more as Administrator to gain full access to all those subsequently EFS-encrypted files. Even using Syskey mode 2 or 3 does not protect against this attack, because the attacker could back up the encrypted files offline, restore them elsewhere and use the DRA's private key to decrypt the files. If such a malicious insider can gain physical access to the computer, all security features are to be considered irrelevant, because they could also install [[rootkits]], software or even hardware [[keystroke logging|keyloggers]] etc. on the computer – which is potentially much more interesting and effective than overwriting DRA policy.