Re: cracking Windows 2000 EFS

From: Luv 2 Hack (love2hack@hotmail.com)
Date: 05/24/02


From: "Luv 2 Hack" <love2hack@hotmail.com>
To: "mightyscot ." <mightyscot@hotmail.com>, <security-basics@securityfocus.com>
Date: Thu, 23 May 2002 15:47:46 -0700

I would try this:

Find you PFX key stated by Brian Miller, then try moving the original SAM to
another directory "WinntEFS" and try to do a repair install into that
directory. Log in as Admin and do the directions in the following link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q242296

It appears there's not much you can do without that file/recovery agent
otherwise. You may also want to try Undelete for Win2k. Even after the
data has been deleted you can do an emergency install from CD and launch the
app from CD. The UNdelete software makes some Registry changes and will
attempt to recover lost data which is minimalized by the very small Undelete
install.

You may want to use some type of forensic software or disk-probing software
to attempt to recover that lost key. I would use a disk imaging app like
Ghost or DriveCopy and make a backup copy to my disk before I do "open heart
and triple bypass" on it.

Also, just some helpful information you may find useful that may jog your
memory if you did indeed do any of these procedures in the past:

"Four Simple EFS Hacks
An untrained user of the system can needlessly expose sensitive information
by inadvertently placing unencrypted copies of files on non-NTFS disks, or
copying them to a network share across an unprotected connection. But even
in an environment where all users understand the rules, I can detail several
ways in which EFS encrypted files could be hacked. These hacks all require
that the hacker have physical possession of the computer, and that the
computer NOT be joined in a Windows 2000 domain.

Password Guessing or Cracking

Since the keys which can decrypt the file belong to the user who encrypted
them, or to the Data Recovery Agent, anyone who can guess or crack the
password for either of these accounts can simply log on as that user and
decrypt the files. By using the native Windows 2000 utility 'cipher.exe' you
can discover the user account used to encrypt the file. However, since the
local Administrator account is the Data Recovery Agent, and can therefore
decrypt all files, it would only be necessary to obtain the password to the
local Administrator account in order to decrypt all encrypted files.

The @Stake program LC3, can be used to discover the password of any user
account by running the program against the local password database or SAM.
While the SAM is protected by the operating system when it is running, an
attacker could boot to another OS, copy the SAM of the victim machine and
run LC3 against this copy. While some passwords take longer to crack than
others, given enough time, the brute force mode of the cracker would
discover the password.

Password Insertion

Programs, such as LiNT and Peter Nordahl's 'NT Offline Password and Registry
Editor' claim to allow the user to insert a new password for any account in
the local SAM. (If you decide to test these programs, please read all
warnings and be aware that reports of SAM corruption and other irreversible
problems abound.) In essence, these programs reboot the system to another
operating system and copy a new password to the appropriate location on the
hard disk. Windows 2000, indeed no operating system, can protect its data
when it is not in operation.

If the operation is successful (and doesn't corrupt data), a simple reboot
to Windows 2000 allows the attacker to log on as Administrator (aka the Data
Recovery Agent) and read the files.

Obtaining and Reassigning the Key

While the private key is linked to the user account through the user's
profile, it is possible to link the key with another account. Windows 2000
EFS certificates and keys can be exported and imported to another account.
While the native tools only allow the user account to export its own keys,
an attacker with physical possession of the computer could, using another OS
or specialized tools, potentially recover the key from the disk and then
programmatically associate it with an account he has control of.

Locating unencrypted copies of the data

Three potential locations for the unencrypted copies of the day exist. A
knowledgeable attacker could potential recover the data.

If an unencrypted file is encrypted, it is possible that some or all of the
data still resides on the disk in an unencrypted form because the file is
copied to a temporary file and then encrypted and stored. The cipher tool
can be used to assure that these 'data shreds' are not available.

Likewise, many software products temporarily store data files in temp
folders while they are being processed. Unless these temp folders are also
marked for encryption, the files may still reside in full or in part in the
temp folder in unencrypted form.

Finally, during normal operations, data is constantly being moved from
memory to the pagefile. While the pagefile is protected during operation,
booting to another OS could allow access to the file. If sensitive documents
had recently been accessed, it is possible that an attacker could recover
the data."

=====================================================

Encrypted Data Recovery
You might want to recover encrypted files, for example, when an employee is
terminated for cause or when a user's private key for EFS is damaged. You
can use the command-line tool, Cipher, to recover files on a recovery
computer where a current recovery agent account, certificate, and private
key are located. To recover a file, a recovery administrator must log on to
the recovery computer as the recovery agent account and then use Cipher to
decrypt the file. Cipher only works for the recovery agent accounts that are
listed in the files DRF. Cipher also only works if the private key for
recovery is installed on the computer.

Encrypted Data Recovery Agent Group Policy settings are a subset of Public
Key Group Policy. You can configure Encrypted Data Recovery Agent settings
to designate recovery agent accounts for domains, organizational units (also
known as OUs), or stand-alone computers. Trusted recovery administrators
that you designate can then use the recovery agent accounts to recover EFS
encrypted files for the domains or organizational units where the EFS
recovery settings apply.

When Group Policy is downloaded to computers, the Encrypted Data Recovery
Agent Group Policy settings contain the certificates for each designated
recovery agent account within the scope of the policy. EFS uses the
information in the current Encrypted Data Recovery Agent Group Policy
settings to create and update DRFs. A recovery agent certificate contains
the public key and information that uniquely identifies the recovery agent
account.

By default, the domain Administrator's account on the first domain
controller that is installed in the domain is the recovery agent account for
computers that are connected to the network. On stand-alone computers, the
local Administrator's account is the default EFS recovery agent account. EFS
generates EFS recovery certificates automatically for default Administrator
accounts.

======================================================

Recovery for Encrypting File System
EFS provides for data recovery agents. By default the domain Administrator
user account (the local Administrator account for the first domain
controller installed in the domain) is issued an EFS recovery certificate.
You can use this account to recover files encrypted by EFS users in the
domain. The private key for EFS recovery is stored on the local computer
where the EFS recovery account is located. You must perform EFS recovery
operations on the computer where the private key that is used for recovery
resides.

You can configure Encrypted Data Recovery Agents policy to designate
alternative recovery agents. For example, to distribute the administrative
workload in your organization, you can designate alternative EFS recovery
accounts for categories of computers grouped by organizational units. You
can use Encrypted Data Recovery Agent policy to designate recovery accounts
on computers to be used for EFS recovery operations.

You must deploy a CA to issue EFS Recovery Agent certificates to the EFS
recovery accounts you want to designate by means of Encrypted Data Recovery
Agents policy. You can issue certificates for EFS recovery with an
enterprise CA or a stand-alone CA.

For enterprise CAs, by default, members of the Domain Admins and Enterprise
Admins security groups are granted permissions to enroll for EFS Recovery
Agent certificates. To change the default certificate enrollment settings,
modify the ACLs for the EFS Recovery Agent certificate template. You can
request an EFS Recovery Agent certificate by using the Certificate Request
wizard or by using the Advanced Certificate Request page for an enterprise
CA.

For stand-alone CAs, you can use the Advanced Certificate Requests form to
request a recovery agent certificate by entering 1.3.6.1.4.1.311.10.3.4.1 as
the object identifier in the Usage OID box.

The cipher command-line program is used to recover EFS files. The recovery
operation decrypts the encrypted file to plaintext, which is readable by
others. Therefore, administrators must take precautions when they are
transferring the plaintext back to the user to ensure that the
confidentiality of the information is preserved. For more information about
cipher, see Windows 2000 Server Help.

For EFS encrypted files, the recovery agent information is refreshed every
time the file system performs an operation on the file (for example, when
the file is opened, moved, or copied). However, if an encrypted file is
dormant for a long time, the recovery agents can expire. To ensure that
dormant encrypted files can be recovered, maintain archives of the recovery
agent certificates and private keys. To create an archive, export the
certificate and its private key to a secure medium and store it in a safe
location. When you export private keys, you must provide a secret password
for authorizing access to the exported key. The secret key is stored in an
encrypted format to protect its confidentiality.

To recover dormant files with expired recovery agent information, import the
appropriate expired recovery agent certificate and private key from the
archive to a recovery account on a local computer and then perform the
recovery. To view recovery agent information for an encrypted file, use the
efsinfo tool. For more information about efsinfo, see Windows 2000 Tools
Help.

===================================================================

Encrypted Data Recovery
You might want to recover encrypted files, for example, when an employee is
terminated for cause or when a user's private key for EFS is damaged. You
can use the command-line tool, Cipher, to recover files on a recovery
computer where a current recovery agent account, certificate, and private
key are located. To recover a file, a recovery administrator must log on to
the recovery computer as the recovery agent account and then use Cipher to
decrypt the file. Cipher only works for the recovery agent accounts that are
listed in the files DRF. Cipher also only works if the private key for
recovery is installed on the computer.

Encrypted Data Recovery Agent Group Policy settings are a subset of Public
Key Group Policy. You can configure Encrypted Data Recovery Agent settings
to designate recovery agent accounts for domains, organizational units (also
known as OUs), or stand-alone computers. Trusted recovery administrators
that you designate can then use the recovery agent accounts to recover EFS
encrypted files for the domains or organizational units where the EFS
recovery settings apply.

When Group Policy is downloaded to computers, the Encrypted Data Recovery
Agent Group Policy settings contain the certificates for each designated
recovery agent account within the scope of the policy. EFS uses the
information in the current Encrypted Data Recovery Agent Group Policy
settings to create and update DRFs. A recovery agent certificate contains
the public key and information that uniquely identifies the recovery agent
account.

By default, the domain Administrator's account on the first domain
controller that is installed in the domain is the recovery agent account for
computers that are connected to the network. On stand-alone computers, the
local Administrator's account is the default EFS recovery agent account. EFS
generates EFS recovery certificates automatically for default Administrator
accounts.

==================================

Regards,

Itsme

----- Original Message -----
From: "Brian Miller" <bmiller20@woh.rr.com>
To: "mightyscot ." <mightyscot@hotmail.com>;
<security-basics@securityfocus.com>
Sent: Wednesday, May 22, 2002 11:38 AM
Subject: Re: cracking Windows 2000 EFS

> Try searching for cert.pfx
> ----- Original Message -----
> From: "mightyscot ." <mightyscot@hotmail.com>
> To: <security-basics@securityfocus.com>
> Sent: Tuesday, May 21, 2002 12:43 PM
> Subject: cracking Windows 2000 EFS
>
>
> > Hi,
> >
> > I am hoping that someone can help me save all my personal documents that
> are
> > encrypted with Windows 2000 EFS. I reinstalled my W2K without
unencrypting
> > my documents and I did not back up the key used to encrypt the
documents.
> It
> > was a standalone system so there is no Administrator with a recovery key
> to
> > help. My account was the administrator which got formatted with the
> > reinstall. I recovered the SAM file and tried replacing the newly
> installed
> > system's SAM file with my old SAM file in the hopes that it would think
I
> > was the previous account and allow me to unencrypt my documents but W2K
> did
> > not like the switch and wouldn't let me log in at all. Is there a way to
> > unencypt my documents?? Is there a cracking program available or some
> other
> > method? I have tried searching for *.cer files to recover the
certificate
> > used to encrypt the files but none existed.
> >
> > Thanks for any help,
> > MS
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp.
> >
>