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" <[EMAIL PROTECTED]> To: "mightyscot ." <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, May 22, 2002 11:38 AM Subject: Re: cracking Windows 2000 EFS > Try searching for cert.pfx > ----- Original Message ----- > From: "mightyscot ." <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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. > > >
