Your global information security experts

Search for Vulnerabilities via
The National Vulnerability Database

A Primer to Syskey in Win2K


by Russ Rogers - 1/18/01

Let's face it. If an intruder has physical access to any server in your business, it's not your server anymore. It's that simple. You can yip and holler and pretend that they didn't mess anything up, but you will never be totally sure. And what's even worse, you never quite know what information that person had access to during their stay.

Microsoft's solution involves an encryption product called Syskey. Syskey is not new to Windows 2000. It's been around since Window NT 4.0. The entire goal of this product is to encrypt files (i.e. SAM database) in the operating system and in user directories. When physical access is gained to the box, your data is supposed to remain safe.

Syskey is utilized by the Encrypted File System (EFS) within Windows 2000 to encrypt specified files. The user that encrypts the file chooses an EFS key (passphrase). A Recovery Agent is specified within the system that has access to decrypt all user files in case a user forgets or loses their own key. The local administrator is the Recovery Agent for local users (by default). The domain administrator is the Recovery Agent for domain users (by default).

Now, back to our attacker. This person has physical access to our server and holds in their hand a Linux boot up disk that can mutate data on a Windows disk. Linux doesn't give a rat's butt about what security Windows 2000 has tried to implement. So on a system that is not currently running EFS/syskey, all files on that disk can be altered or changed.

On a system that HAS been protected with Syskey, some files (some default and some specified by the users) are encrypted and cannot be read without attempting to brute force the key. The time required to brute force a syskey-encrypted file is thought to be so time consuming that it's a worthless effort. User keys are stored in the LSA_Secrets registry key.

However, improper configuration of Syskey can result in a system that isn't as secure as you'd like to believe. This is a CONFIGURATION issue, not necessarily a security flaw within Windows 2000, itself. Syskey operates in 3 modes. Each mode is progressively more aggressive in where it stores the decryption key.

Mode 1 is the least secure because it stores the decryption key on the local box. When a valid user logs in to the box, Windows 2000 knows where to find the syskey. It locates the Syskey and decrypts LSA_Secrets. This allows an intruder to view user's EFS keys and view the encrypted files.

Mode 2 is slightly more secure because it requires the syskey to be entered as a password when the machine is booted up. This means that the syskey is NOT stored on the local machine. But as with all other passwords, a weak Syskey password is only slightly better than not having Syskey at all.

For Mode 3, the Syskey is kept on a floppy disk that must be inserted when booting up the machine. So even if the attacker boots up into a new OS and mounts the Windows 2000 file-system, they won't be able to read the EFS files without the keys contained on the boot floppy.

As a final note, it should be noted that the recommended method for utilizing EFS/syskey involves running it on a Domain, not the local machine. That limits the number of weak links in the encryption chain. The domain server becomes the primary point of interaction with EFS and the domain administrator becomes the primary Recovery Agent. All user created EFS keys are stored strictly in the domain controller registry, NOT on each local machine.

For more information on EFS, we recommend you read the article by the authors.