How to make key generation independent of Domain Controller

EFS (Encrypting File System) encryption is an encryption technology based on NTFS disk technology. EFS encryption is based on public key policies. When you use EFS to encrypt a File or folder, the system first generates a FEK consisting of pseudo-random numbers (File Encryption Key, File Encryption Key ), then, the encrypted file will be created using FEK and data extension standard X algorithm, stored on the hard disk, and unencrypted original files will be deleted. Next, the system uses your public key to encrypt the FEK and stores the encrypted FEK in the same encrypted file. When accessing the encrypted file, the system first decrypts the FEK using the current user's private key, and then decrypts the file using FEK. When you use EFS for the first time, if you do not have a public/private key pair (collectively referred to as a key), the key is generated first and then encrypted, so how can we make the key generation independent of the domain controller?

It is very complicated, but it is not so troublesome in actual use. The user authentication process of EFS encryption is performed when you log on to Windows. As long as you log on to Windows, you can open any authorized encrypted file. In other words, the EFS encryption system is transparent to users. That is to say, if you encrypt some data, your access to the data will be completely allowed and will not be subject to any restrictions. When other unauthorized users attempt to access your encrypted data, they will receive an "Access Denied" error message.

Generally, my computer won't be used by others, and I often reinstall the system, so I am too lazy to back up keys. So I have never used Windows 2003 or Windows XP EFS. Today I read some help posts about EFS keys that are not backed up and data cannot be recovered, so I suddenly came up with an idea to try to unlock EFS encryption.

The test environment I constructed is to create a test folder on an NTFS disk in the Windows XP Pro SP2 system and enable EFS encryption. The folder contains a encrypted TXT file. Now I try to read this file with another account, and then try again in the second system (equivalent to reinstalling the system without a certificate.

Step 1: Enable the GUEST account in my system.

In this case, the test folder cannot be accessed from the resource manager.

Open the supervisor, stop the assumer.exe process in the task manager, and enable mongoxec to try to log on with system.

Failed. The system prompts that the process cannot be created. It seems that the county is not enough.

Return to the administrator account, create an administrator account test, and log on to the account.

Run the resource manager in the testaccount to access the testfile folder, but cannot open the 1.txt encrypted file.

At this time, log on to the system using the above method. The file is garbled!

Run icesword.exe and locate the test folder in the file. Select 1.txt on the right and copy it to the desktop. The file name is arbitrary and the suffix remains unchanged.

Double-click to open the file and read it normally! Step 1: The EFS is successfully cracked!

Step 2: log on to Windows Server 2003 SP1 as an administrator ).

Copy 1.txt to the desktop again using the describe scripts. garbled characters are displayed after it is opened, which is consistent with the situation when the system reads data. The second attempt fails.

Summary:

This method has the following meanings:

Currently, it is only applicable to viewing files encrypted by others in the system using EFS. (do not violate laws or endanger others' rights !), Further exploration is required to recover files when the system is reinstalled or the private key is lost.

The two software used in this method:

PsExec IceSword. The former is a very popular remote control software, the command line interface. The latter is the well-known hidden process inspection software ice blade made by PJF.

Conditions applicable to this method:

1. You must have sufficient permissions to run the above two software (if you can combine the net user command, it should not be difficult. This is just a small note, and readers should also be self-disciplined ).

2. The system also has the key corresponding to the EFS encrypted file (this condition is based on my preliminary speculation)

The reason for the success of this method is as follows:

1. Use the kernel-level permissions unique to the system account, which may be a condition for reading the administrator or other normal user keys.

2. Exclusive IceSword Technology for reading encrypted files.