RE: Question about brute forcing EFS...

From: Ed Moyle (emoyleat_private)
Date: Mon Sep 16 2002 - 06:37:20 PDT

  • Next message: InternetSmiths: "try a chkdsk /f Re: Hidden files on NTFS"

    Eoghan,
    
    	OK.  The procedure I used was pretty much identical to yours,
    although it was on 2k rather than XP...  They must have changed the
    key storage methodology in XP.  For more specific details on the
    key mgmt in Win2k, check out the "hacking EFS" series of articles 
    on SANS:
    
    http://www.sans.org/newlook/digests/hacking_efs1.htm
    
    My procedure was as follows:
    
    - log on to win2k as test user "a"
    - apply the "encrypt" attribute to a test file (I used "test.txt" on the
    	c:\ drive by using the command line "cipher.exe" tool.)
    - ensure the encrypt attribute has been successfully applied by right
    	clicking on the file and selecting "properties."
    - log off the workstation and power it down.
    - insert ntpasswd boot diskette in the floppy drive.
    - power up the machine.
    - load the registry file and select the "a" user for password modification.
    - change the password to a different value
    - commit (write) the changes
    - reboot the machine
    - log into the machine using the new password for user "a"
    - decrypt the file using the command line cipher.exe utility
    
    I did this also with the recovery administrator by substituting "Administrator"
    with user a in everything but the first step.
    
    Hope this helps,
    -Ed
    
    
    -----Original Message-----
    From: Eoghan Casey [mailto:eoghan.caseyat_private]
    Sent: Friday, September 13, 2002 17:24
    To: Ed Moyle
    Cc: Eoghan Casey; forensicsat_private
    Subject: RE: Question about brute forcing EFS...
    
    
    Ed,
    
    I have tried this on Windows XP in a lab setting and it does not work. 
    Specifically, I used ntpasswd to change the account password and then 
    booted the machine. The encrypted files were not accessible. If I recall 
    correctly from my reading of the W2K resource kit, a user's password is 
    used to encrypt their private key. Changing the password using ntpasswd 
    undermines this process.
    
    I am suprised that it would work on a Windows 2000 machine - can you 
    explain specifically what you did so that I can replicate it? 
    
    Thanks,
    
    Eoghan
    
    On Fri, 13 Sep 2002, Ed Moyle wrote:
    
    > On Friday, September 13, 2002 08:44, Eoghan Casey wrote:
    > 
    > > If you do not have the user's passphrase or a recovery agent, how do you 
    > > do you get around EFS?
    > 
    > I've gotten a few questions about this, so here is the way to do it.
    > There are a few caveats that should be taken into consideration before
    > doing this on a system, though.  The first (and most important) is that
    > the utility I refence below requires *writing* to the drive, so you 
    > obviously don't want to do this on any drive that can't be written to 
    > (e.g. evidence)... so work with a mirror if you are going to do this in
    > that context.  This type of thing really works best with remote users
    > (e.g. laptops) and you need physical access to the machine.  I've done
    > this on Win2k, but haven't tried with XP.
    > 
    > Briefly, EFS works by encrypting a file with DESX.  Then, the DESX file 
    > key is encrypted with some number of public keys that are in EFS certs 
    > that windows knows about.  These encrypted file keys are stored with the
    > file as part of the file record.  One might assume that some kind of
    > password based key derivation would be used to encrypt the private keys
    > that correspond to those public keys (would seem logical to me,) but that 
    > isn't the case in EFS...  
    > 
    > If you can trick Windows 2000 into logging you in (whether you know the
    > account password or not, you can successfully decrypt the EFS encrypted
    > files.  How do you trick windows into logging you in?  I recommend the
    > excellent pnordahl utility (http://home.eunet.no/~pnordahl/ntpasswd/)
    > for doing this (don't use on a blank password... really important.) This
    > works with local accounts; if you can trick Windows 2000 into logging
    > you in with cached credentials, you can decrypt also with domain accounts.
    > You really need to log in to the domain if roaming profiles are used
    > since the keys are stored with the profile, but using roaming profiles
    > and/or not having cached logins really hampers the ability of most users
    > to do their work, so most users/organizations usually don't do that.  
    > 
    > Hope this information helps somebody out there.
    > 
    > Regards,
    > -Ed
    > 
    > 
    
    
    -----------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see: http://aris.securityfocus.com
    



    This archive was generated by hypermail 2b30 : Wed Sep 18 2002 - 05:49:47 PDT