X

When Green Is Bad




A few days ago I received a phone call from a person asking for my services to help him recover data from a failed hard disk. I asked the caller whether he had internet access—sometimes the failed disk takes with it the only available computer. The caller explained that he had internet access and that the patient was a removable disk. I pointed the client to our online questionnaire and asked him to fill in the form. A few minutes later the form arrived.

In a nut shell, the disk was a 120GB 3.5” 7200rpm IDE Maxtor drive, two years old. It was housed within an aluminium external drive case. It was hooked up to a standalone Windows XP computer. It was spinning, no unusual noises such as clicks or retry access sounds. The file directory could be read. The client had last successfully placed data on the medium less than 15 days before.

I immediately got a hunch about what the problem was. As long as the word “green” didn’t factor in our conversation a chance of success remained. About 30 minutes later the client arrived at our office with the problem disk. I plugged the disk into one of our recovery units, powered it up and a few seconds later was looking at its contents. All file names were in green rather than the usual black font. This meant that the files had been encrypted using Windows XP’s Encrypted File System (EFS). EFS provides a file system level of encryption that allows files to be transparently encrypted from attackers who gain physical access to the computer.  EFS first made its debut in Windows 2000.

I asked the client whether he had reinstalled or replaced the computer on which he had last successfully accessed the data. He replied that this was an old computer and he had donated the machine to his church about 10 days before. I got a negative reply when I asked whether he had ever backed up this computer or made a copy of its encryption keys and certificates.

Have you ever watched a TV program of a high alert situation? That’s what happened next; I explained to the client that his only chance of getting back the data on that drive was if the computer he had donated was still intact. We looked up the church’s phone number and once found (God bless search engines) the client dialled the number. About half a dozen rings someone picked up at the other end. I won’t bore you with the conversation; when the client hung up we had all the details of the person who had volunteered to format the machine and install it from scratch. The second phone call was answered by this person’s mother. She told us that he had brought a computer home a few days ago. From this lead we got the mobile phone of the person my client was so desperately trying to contact.

The client managed to get hold of our make or break person. When asked whether he had formatted the computer the reply was a yes… but using a different hard disk. The hard disk on the original computer was very small and he had decided to replace it with a higher capacity one. The contents of the original hard disk were intact.

A couple of hours later we had rigged the original hard disk within the donated computer and had successfully copied the contents of the data on the external hard disk to unencrypted storage. Without getting too much into the technicalities what follows is a simple explanation of how EFS works. The first time a user enables the EFS, the system automatically generates a public/private key pair for that user if one doesn’t already exist.  This information is held in the user’s profile. For each file / folder, EFS generates a random number and uses the public key to encrypt the file. In order to decrypt the file, the private key is necessary.

Once the private key is lost decrypting the data is impossible.

I would like to thank the client who offered the entire team as well as the chap who had not formatted the hard disk dinner. As he put it “My life depended on that data”. Sadly not all stories end like this.




John:
Related Post