?
Solved

Is there a way to 1) bypass XP Pro Syskey that requires a startup passphrase,  and 2) bypass EFS -- in order to access files that were created within EFS-encrypted folders

Posted on 2004-11-29
19
Medium Priority
?
20,010 Views
Last Modified: 2012-06-27
I have edited the original post located here:  http://www.experts-exchange.com/Security/Q_21210532.html
This thread went off topic and deserved it's own dedicated thread with it's own points.

 
Comment from richrumble  feedback
Date: 11/21/2004 05:44PM PST
 Comment  


You could try exporting the syskey to floppy, but it's really of no real use, the SAM is just as vulnerable as it ever was with or without syskey. Syskey only run's when the PC is booted, so if someone used a floppy to read the SAM "offline" while the PC isn't booted with widows, the SAM has no additional encryption from syskey, even in XP, or 2003. Also, using any one of the modern SAM hash readers, Pwdump3, Pwdump3e, Pwdump3v2, or NTDump- syskey has no effect on them.
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_zbxr.asp

Now depedning on what method you encrypted you My Doc's folder with, you may have other issues. if you use M$ EFS, you definatly need to export your encryption key's to floppy or other media.
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_kcef.asp
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx

The problem with the syskey in XP is this, once the password is entered... then there is no more "extra" encryption- it's decoded because you entered the right password.

You might also look at this SID reader program from sysinternals
http://www.sysinternals.com/ntw2k/freeware/psgetsid.shtml
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prnb_efs_jskn.asp

-rich
 
Comment from SAbboushi
Date: 11/21/2004 06:31PM PST
 Your Comment  


Thanks richrumble-

>> the SAM has no additional encryption from syskey, even in XP,
According to the following link, syskey does add additional encryption to sensitive contents of the SAM (mostly master keys): link, http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_zbxr.asp
A startup key (also called the syskey) can be used to protect all master keys as well as a variety of other secrets that are stored on computers. At system startup, the startup key is used to encrypt all of the private keys on the computer, including private keys that are used for EFS. Startup keys are automatically generated and used for computers in a domain but must be manually configured on stand-alone computers. Startup key security can be increased by storing the key on removable media or by requiring a system startup password.

 
Comment from richrumble  feedback
Date: 11/22/2004 05:24AM PST
 Comment  


... despite syskey's intentions- with the tools available today- syskey offers no additional protection from these tools obtaining the information syskey aim's to protect.

That said, http://support.microsoft.com/?kbid=288348 states the the encryption key's for EFS should be exported, then restored to an imaged PC. I'll bet the same might hold true for syskey, it is able to be exported to removable media, and it is possible to restore to the imaged pc. I've not seen this issue with syskey and sysprep, I can test again to see. I assume your using the latest version of sysprep- actually for XP you should use the sysprep from the XP Service Pack1 Deployment tools http://www.microsoft.com/downloads/details.aspx?FamilyID=7a83123d-507b-4095-9d9d-0a195f7b5f69&displaylang=en

...

GL!
-rich
 
Comment from SAbboushi
Date: 11/22/2004 06:59AM PST
 Your Comment  


Hi richrumble-

...
On a separate note, your are stating that the tools today can "obtain the information syskey aims to protect".  That concerns me.  I understood that it would take a few decades to crack EFS using today's supercomputers.  I understand that the only feasible way to access EFS encrypted files is to get the master key.  I understand that syskey encrypts the master key with EFS level encryption.  I looked at pwdump3 and found this:
>> Using this tool, a system administrator can check on the strength of the passwords on his system.
>> Please note: pwdump3 does not exploit a new vulerability; it utilizes
>> existing Windows communications capabilities. To use the program
>> successfully, one must supply a username and password that has
>> administrative-level privileges on the remote system.
This does not seem to support what you are implying.  I would be VERY interested to find out how one could defeat the syskey and EFS encryption on my machine and get access - I would be grateful if you could provide further details (although this is not related to my problem...)

Another observation - the links you have provided in the past couple of posts do not support your position that syskey adds no additional encryption.  

You refer to "exporting" the syskey; I believe you use Syskey to "encrypt" parts of the SAM which then requires a password or startup disk to decrypt parts of the SAM upon startup.  I configured syskey to require a password upon startup instead of requiring a startup disk.  ...

Richrumble - I really appreciate your efforts - I can tell that you have put time into your posts and creating the links.  ...

With Regards-
Sam
 
Comment from richrumble  feedback
Date: 11/23/2004 06:26AM PST
 Comment  


Understood, no problem.
Let me see if I can clarify.
Syskey- Syskey SAM encryption establishes a 128-bit cryptographic password encryption key as opposed to the 40-bit mechanism that ships by default (from NT4sp3-2003)
The failing or short comming of syskey as I see it:
     1) Syskey does not perminatly encrypt the information it is protecting, meaning that using a linux floppy (or NTFS-DOS floppy) to mount the HD and read the SAM will result in someone being able to read the SAM in the default 40-bit LanMan and NTLM hashes, not the 128-bit versions.
     2) While PwdumpX does require admin privleges to run properly, gaining admin is still a trivial process on winblows for the average LAN or user. PwdumpX uses dll injection, which is something that M$ would have to work very hard to re-write their kernel to prevent. While Dll injection isn't used by programs as a typical means-to-an-end, it nonetheless works for pwdumps purposes. http://www.bindview.com/news/display.cfm?Release=/99/1222.txt (only affected nt4)
http://www.microsoft.com/technet/security/bulletin/fq99-056.mspx 

The reason Pwdump works is this, number one the administrator of the PC cannot even access the sam, only the highest account can, which is system. System trust's the admin account a little to much, and allows the dll injection/dll hooking to take place, giving the program system creditnitals to read the SAM. While syskey does encrypt the sam with 128-bit encryption in MEMORY, what is written to the HD is still the 40-bit key- and that's what pwdump reads the HD. http://www.winnetmag.com/Article/ArticleID/14780/14780.html a very good article, with better links.

johnTheRipper makes short work of LanMan hashes, it's the fastest cracker out there for NT, espically if you run it on linux, it's 10x faster than the windows port of john, and if using rainbow crack, passwords are practically instantenious.

...

Also of note, if the SAM is deletedaltogether off the HD, syskey enabled or not, the local admin will be a blank password. If there is a passphrase and even if the key's are stored on a floppy, using chntpw or the linux floppy can get around those just fine.

GL! I hope this helps.
-rich



 
Comment from SAbboushi
Date: 11/23/2004 07:35AM PST
 Your Comment  


richrumble - I certainly admire the depth of your technical knowledge on this matter.

My comments for further understanding
1) You are saying that by enabling syskey, no further encryption whatsoever is made to any of the SAM - that the startup password I have assigned with syskey is stored in the SAM using 40-bit encryption, that enabling syskey (with startup password prompt) results in the following process:
a) read the 40-bit startup password from the SAM
b) re-encrypts it using 128-bit encryption in memory
c) have XP Pro prompt for a startup password
d) encrypts the entered startup password in memory using 128-bit encryption
e) match the two passwords in memory using (b) and (d)
f) continue the XP Pro startup process upon a match?
Did I understand that right?

>> Syskey does not perminatly encrypt the information it is protecting
I am confused - the link you provided (http://www.microsoft.com/technet/security/bulletin/fq99-056.mspx) says "Syskey is designed to prevent password cracking attacks by encrypting the SAM database using 128-bit cryptography."  It goes on to say that the stream-reuse flaw was patched and that "The patch returns the protection to its stronger state by eliminating the key reuse."    It confirms what you said (only affected NT4), and confirms that this was not a problem for Windows 2000.  I am using XP Pro.

Your other 2 links (http://www.bindview.com/news/display.cfm?Release=/99/1222.txt and http://www.winnetmag.com/Article/ArticleID/14780/14780.html) confirms this bug/vulnerability and references the Microsoft bulletin and patch from almost 5 years ago.

Do you still believe that this 5 year old NT vulnerability exists in XP Pro? Or am I somehow missing your point (I do that sometimes...)

Your link http://www.winnetmag.com/Article/ArticleID/14780/14780.html referenced the following link:  http://support.microsoft.com/kb/q143475/ which says:

System Key hotfix: Strong encryption protects private account information by encrypting the password data using a 128-bit cryptographically random key, known as a password encryption key.
Only the private password information is strongly encrypted in the database, not the entire account database. Every system using the strong encryption option will have a unique password encryption key. The password encryption key is itself encrypted with a System Key. Using strong encryption of account passwords adds additional protection for the contents of the SAM portion of the registry and subsequent backup copies of the registry information


>> While syskey does encrypt the sam with 128-bit encryption in MEMORY, what is written to the HD is still the 40-bit key
The pasted text above seems to contradict your statement by stating that the the "information is strongly encrypted in the database".  Again, please let me know if I am misunderstanding what you are trying to tell me or if there is a link that will substantiate this.

...

richrumble - my brain hurts - you make me think!  
With Great Restpect
Sam
 
Comment from richrumble  feedback
Date: 11/23/2004 10:51AM PST
 Comment  


You make me type, i think that's worse... ;p
I understand the porblem. M$ is saying one thing (with the links I am providing), however it's been greatly documented that the protection they are promising isn't a reality. And it's easy to see for your self. using NTFS-DOS or the linux boot floppy/cd-rom. In order for M$'s Syskey to work as "advertised" the sam hashes would have to be the 128-bit versions of the 40-bit hashs- and then write that to disk. However, even in win2k-xp-and 2003 this is not the case. The syskey encryption works the same way NT-Auth works, by comparing hashes.
(from reading your last post, I'm sure you get these basics- but just in case)
When you type in your password to log-on to a pc, the pc looks at what you typed, then contact's the Domain Controler (or GC) and they negotiate another round of encryption called a challenge hash, then the DC/GC uses that challenge to encrypt the password it has in the DC/GC sam hash for that user name. The DC/GC waits to hear from the workstation. The workstation then encrypts what you typed with the LanMan/NTLM hash, then encrypts that NThash with the challenge, once both have been encrypted, that data is sent to the DC/GC. The DC/GC looks to see if that matches what it computed, if it does, your auth'd and you log-in. If not, your asked to try again.
Syskey does the same, it uses the values in the SAM on the HD, then encrypts that hash with the 128-bit algorythim on top of the 40-bit versions in the SAM, and stores that in memory.
If you turn off a syskey enabled PC suddenly (like pulling the power cable out), and you read the SAM off-line using a boot disk, you'll see that syskey doesn't write the 128-bit value to disk at any time.
The startup password is yet another Auth Mechanism, which was not available in the first itteration of syskey btw. I think once M$ figured out that syskey wasn't much of anything, they added the additional password function, this to me seems a lot like a bios boot password.

Now while you cannot reliably disable syskey after it's been enabled- what I would do is recreate the master image, and not enable syskey on the master image. Then when i imaged a PC, i'd turn on syskey after mini-setup finished.
Also, the vulnerability mentioned above did only apply to NT4, and nothing afterwards- so I do not see this affecting anything nowadays.

...

-rich

 
Comment from SAbboushi
Date: 11/23/2004 02:05PM PST
 Your Comment  


Thank Rich-  

I would like to do the test you suggest - I have ntfs-dos on a dos boot disk (I am still "Linux-stupid").  What exactly am I looking for to confirm that the passwords in the sam are NOT encrypted with a 128-bit key and is as vulnerable as you say with syskey enabled?

By the way, I am on a workgroup - no Domain controller.

>>  however it's been greatly documented that the protection they are promising isn't a reality
>>  this to me seems a lot like a bios boot password.
>>  Syskey does the same, it uses the values in the SAM on the HD, then encrypts that hash with the 128-bit algorythim on top of the 40-bit versions in the SAM, and stores that in memory.

Is your position that Syskey does not perform any encryption on the SAM?  Non-microsoft posts are contradicting this.

Would you dispute the following link:
http://www.windowsnetworking.com/kbase/WindowsTips/WindowsNT/RegistryTips/Miscellaneous/Whathappenswhen
syskeyisinstalledandhowtogetridofit.html

When syskey is active, the hashes are encrypted/obfuscated yet
another time before being stored in the SAM registry.
However, they're stored in the old form in memory after boot
(pwdump2 demonstrates this),
since the old form is needed for NTLM authentication on the network etc.


...

 
Comment from SAbboushi
Date: 11/27/2004 06:36AM PST
 Your Comment  


Hi richrumble -

I haven't heard back from you, so I figure I made you type too much...!

Your posts have been of great value to me - as a result, I have disabled LM Hash storage - so LM Hashes for user accounts are no longer available in my registry for cracking

Regarding your statements that syskey is easily defeated:
>>   despite syskey's intentions- with the tools available today- syskey offers no additional protection from these tools obtaining the information syskey aim's to protect.

From my search on the web, SAMInside seems to be the most recognized password recovery utility that can crack syskey.  I am attaching a link to their response confirming that they CANNOT crack syskey unless the key itself is stored in the registry (syskey obfuscation method that I asked you about in my last post).

http://www.insidepro.com/gb/eng/index.shtml

Subject: Re: SAM/SYSTEM files you request in message 158 to analyze

Hello!

Program SAMInside recovers passwords only if
SYSKEY is located in the Windows registry.
If your SYSKEY is entered on OS boot (or if
you store it on separate diskette), you're to
select menu "Import SAM and SYSKEY files...".
At the same time you aren't to use "GetSyskey" utility to get SYSKEY, but:
- manually create 16-byte file containing key (if you enter it manually); or
- use key stored on separate floppy disk (find more about SYSKEY.EXE use on this
page: http://support.microsoft.com/default.aspx?scid=KB;en-us;q143475)

P.S. Other programs (PWSEX + BKHive&SAMDump2)
also not work with your SAM/SYSTEM-files.

Best regards,
InsidePro Support
E-mail: Support@InsidePro.com
Web: http://www.InsidePro.com

...

Comment from richrumble  feedback
Date: 11/27/2004 11:21AM PST
 Comment  


This is my contention: The 40-bit version of this password: "HelloWorld" is
  Admin:500:NO PASSWORD*********************:F37F57A03351C09D237508F14BAB2AE3::: (no syskey- new machine)
admin:1007:NO PASSWORD*********************:F37F57A03351C09D237508F14BAB2AE3::: (syskey- different machine but syskey enabled for a long time now.)
That is the NTLM hash, the case sensitive version. This is a fresh install of winxp- no syskey enabled. It's also the same key I read from the SAM of a syskey enabled machine, and booted using http://home.eunet.no/~pnordahl/ntpasswd/   The cd-rom version is what I preffer. It will read and show you the hash, even reset a password. With NTFS-DOS you have to copy the sam file off and view it, or you can try to use "type" to show you the contents of it. c:\windows\system32\config\sam

I do disagree with the paper linked above, even though he is the author of the very tool I use to dump/change the hash's. Pwdump3 get's the hash's, even with the password protection, and the floppy storage of the syskey... you'll have to try it to verify I suppose. I'll brb, i'm going to see if I remember how to read the SAM file in the system32\config dir.

...

-rich
 
Comment from SAbboushi
Date: 11/28/2004 10:13AM PST
 Your Comment  


Rich- thanks for the link - (http://home.eunet.no/~pnordahl/ntpasswd).  I tried your preferred CD-Rom version.  Really cool - I will have to keep this CD on hand.

This is what I found:
1) Even with syskey (startup passphrase) enabled, I WAS able to blank Administrator and user passwords as you have said; however, I still needed to provide the syskey startup passphrase to startup before I could log into the user account - and sure enough, blanking the password for any account allowed me to then login without a password.
2) I used the utility to remove syskey - and Windows did boot - but then I was unable to log into ANY accounts, even those whose passwords I had blanked either before AND/OR after I had disabled syskey
The author does note (http://home.eunet.no/~pnordahl/ntpasswd/syskey.txt) that
           "VeryBAD: SWITHCHING OFF IN WINDOWS 2000 AND XP NOT PERFECT,
            WILL CAUSE TROUBLE, but you can access the computer
            afterwards."
In my case, I was NOT able to access my computer.  I was unable to get past the logon screen - but it appears from the author's comments that others can login under XP (maybe changes in SP2 closed vulnerability?).  Most of his work seems to have been for NT with some for Windows 2000:  "resetting this mode flag and SecureBoot to 0 is all that's needed to switch off syskey in NT4 (up to SP6 at time of writing). "

A followup e-mail to InsidePro supports my current belief that there is not yet a method to crack syskey (or that he is also unaware of a method to do so):
SA> I was told that syskey was easy to defeat, even with passphrase or
SA> floppy startup.  However, if I understand you correctly, you are
SA> saying that if I use syskey with startup password, then nobody will
SA> be able to crack my system with password recovery software?
Yes.

Best regards,
InsidePro Support
E-mail: Support@InsidePro.com
Web: http://www.InsidePro.com

... I encrypt "My Documents" with EFS.  So even if there is a method to blank passwords and defeat syskey, I believe that my EFS encrypted data will remain uncrackable.

...
 
Comment from richrumble  feedback
Date: 11/28/2004 11:38AM PST
 Comment  


There should be like 3 warnings for that floppy when turning syskey off... it's never worked for me reliably. Sorry you'll have to start over, but that's life with M$ sometimes. Once you have gotten back to the point where your going to run sysprep- Leave syskey off for the time being, make an image that will change the sid's, and test. If that works, keep that image just in case, then turn on syskey on the pc you derive the image from, then re-run sysprep, hopefully you won't have trouble, if you do still, you can roll back to the saved image just before syskey was enabled.

I was reading through my hacking exposed 3rd edition with reguard to syskey, and making sure I'm not crazy. By blanking the passwords, or changing them, in the sam, then writting them to disk- when the PC boot's up, syskey will take those pass's and encrypt them as it's supposed to, but will not write that value to disk, as I've been maintaing. Granted also, that ADMIN Right's and or Physical Access are required to do so.

Cracking syskey has never been in my claim, however bypassing it is. Syskey only run's when windows is running, and never overwrites the sam to disk. The newest version of the linux-boot-reset utility doesn't allow you to view the hash like it used to, I'm going to look for an old version to see if it does. Copying the SAM using ntfs-dos does also reflect the fact that the hash is the same syskey or no for the "HelloWorld" password.

Syskey will no affect M$ EFS- While EFS seems safe from cracking, it too suffers from a fatal flaw, that I exploit on a monthly basis. EFS creates a efsX.tmp file in the directory that the file or folder being encrypted resides. "X" being a number starting at 0 and incrementing. Even if the EFS key's are exported, the data remains in an unencrypted form on the HD. Using over-writters, formatters, disc wipes, are useless if one is using a good low-level reader like the ones you can get from OnTrack software- http://www.ontrack.com/software/
For years I used Tiramisu, with great sucess, and now we have the whole suite of ontrack's tools. They have paid for themselves twice over this year alone. While EFS encrypted files seem pretty safe if the key's are exported, they are not. Even using OnTrack's own Data Eraser, I am able to recover the data, np.
http://seclists.org/lists/bugtraq/2001/Jan/0304.html http://www.ntfs.com/issues-encrypted-files.htm
BTW, despite claims (again) all HD data is recoverable- depends on what level you wnat to take it to, with an electron-tunneling microscope all HD data is recoverable. But even without one, ontrack's tools are great. Altough data that is in a RAID stripe is difficult to recover.

You keep getting me off the subject ;) Anywho, let me know how your rebuild goes...
-rich



0
Comment
Question by:SAbboushi
  • 10
  • 6
  • 3
19 Comments
 

Author Comment

by:SAbboushi
ID: 12697197
rich-

>> Syskey only run's when windows is running, and never overwrites the sam to disk
Am unclear on what you are saying here "and never overwrites the sam to disk":

>> The newest version of the linux-boot-reset utility doesn't allow you to view the hash like it used to, I'm going to look for an old version to see if it does.
Are you referring to the hash for the 'syskey startup passphrase that I am required to type in' on startup?

OK - I think I am understanding something about your helloworld example...  Your contention is that syskey does NOT encrypt the NTLM Hash user login passwords.  OK - I do not know how to confirm this myself, but am willing to accept this based upon 1) the respect you have earned from me in your posts, 2) the NTLM Hashes that you posted earlier and 3) the fact that ntpasswd CD was able to blank user passwords without me having to provide the syskey startup passphrase.


I agree with your contention that EFS can be exploited, but only if the user doesn't read the EFS documentation and is ignorant about how EFS works.  Your link http://seclists.org/lists/bugtraq/2001/Jan/0304.html refers to the way EFS works: if you encrypt a plain text file, a deleted yet recoverable plain text tmp file remains on the disk.  I would agree that it would be nice for XP to prompt for overwriting of the tmp file after the file is successfully encrypted (I understand that the temp file is needed for recovery in case the encryption fails - but once the encryption succeeds, it would be nice to get prompted to wipe the tmp file!)

One of the responses to this post maintains that the ONLY time plaintext copies of an encrypted file are made is if the file was created in an unencrypted folder before encryption.  This is why I encrypt "My Documents" and all subfolders.  Whenever I create a new document under "My Documents", there is never a plain text version that is created.  His humorous response is located here: http://seclists.org/lists/bugtraq/2001/Jan/0407.html

"The fate of original plain text copies of documents we choose to
subsequently encrypt is absolutely the responsibility of the user. This
thread has mutated into a different being from the original issue, which is
that if an unencrypted file outside an encrypted directory is encrypted in
said unencrypted directory, that the .tmp file created in the unencrypted
dir and subsequently deleted is not then securely wiped.

So, yes, if one did encrypt a file in this manner, AND someone breaks in and
rips off your hard drive, AND they don't figure out your password is
"#BrittanySpears" AND you have correctly removed the restore cert AND the
data has not been overwritten AND they decide to go through a
sector-by-sector scan of your drives then they MAY actually see little bits
of text here and there alluding the to secret hiding place of your porno
collection. "


>> Using over-writters, formatters, disc wipes, are useless if one is using a good low-level reader like the ones you can get from OnTrack software- http://www.ontrack.com/software/

One of the responses to the seclists.org link you posted contradicts your assertion that OnTrack software can recover overwritten data:
http://seclists.org/lists/bugtraq/2001/Jan/0340.html
"In case anyone's interested, here's a summary of the responses I received to
my incorrect assertions;

I should say that I was under the honest belief that companies, such as
OnTrack, made available services which could recover overwritten data at a
reasonable price. I called them this morning and asked, they responded that
if the data was overwritten then it was basically not possible to recover.
They wouldn't say whether they did make such a service available, but the
implication is clearly that its not as trivial, or inexpensive, as I
believed it to be. Thanks to Ryan Russell for setting me straight on that. "

I looked at the ontrack website link you provided as well as the comparison of products (http://www.ontrack.com/library/odr_softwarecomp.pdf) and did not see that capability listed...


My contention is that:
1) User passwords can be blanked or cracked, regardless of whether syskey is enabled in any of the 3 syskey configurations  (thanks rich - I did not know this)
2) Using utilities like BartPE, ntfsdos, or other software tools, any files that reside in UNENCRYPTED folders are easily accessible
3) Using utilities like BartPE or ntfsdos, or other software tools, any ENCRYPTED files that were originally created as plaintext files and subsequently encrypted MAY be recoverable as plaintext files (unless unused space is wiped after the plaintext files were encrypted)
4) Any files that were created within an EFS encrypted folder are NOT recoverable.  The only possibility I see to crack files created within EFS encrypted folders within my lifetime is if someone knows how to find the relevant EFS keys in a hibernation file.  That certainly is not me... ; )
5) Still open: blanking user passwords, bypassing syskey, and logging in.  rich - since you tell me you are able to do this, I will try again!

0
 
LVL 4

Expert Comment

by:poseidoncanuck
ID: 12704229
I'll respond to SAbboushi's contentions:
1) SAM (local account) passwords can be blanked or *overwritten* no matter what level of SYSKEY is in place.  Today's tools may or may not do it well, but this is merely on-disk data and there's nothing to prevent someone from editing data on disk.  I am unclear how it is practical to crack SAM (local account) passwords if the computer has been configured with SYSKEY = 2 or 3 (floppy or passphrase), unless you have possession of the SYSKEY well.  Rich, could you explain how you accomplish this step by step?

These attacks are of course not going to work against domain logons (even cached domain logons), though I suspect at some point someone will take up the challenge of brute-forcing the cached domain logon verifiers (much harder than brute-forcing the NT hash, BTW).

2) Yep - it's just data on disk.
3) Yep - the plaintext could be on disk in an untouched sector, and even with the usual disk-wiping tools (e.g. cipher.exe /W), there's always the possibility of some guy from a three-letter agency (or the kind of $$$ budget that a tunnelling microscope would require) who can get at your data.  I am not terribly concerned about recovering overwritten ("wiped") plaintext from the typical commercially available tools e.g. WinHex, but I may not be familiar with the latest tools for recovering the e.g. fourth-layer down of a data bit on a disk sector that's been overwritten three time.
4) Not recoverable, assuming a strong password was used to logon to that account.  Tools like Advanced EFS Data Recovery will try to recover the user's Master Key directly, without having to go through the logon process.  Most of these kinds of tools currently require you to type the password guesses in manually, but eventually you'll probably see tools that automate the password guesses on your behalf.  A good strong password is the best defense against this (e.g. 15-30 character passphrase should be good), but as cryptographers love to say, mathematically it's a matter of time and resources.

If you have the luxury of setting up a domain controller (e.g. W2K3 DC), adding your computer to that domain, creating a domain user account, logging on with that domain account, setting up an Enterprise Certificate Server (CA), installing smart card hardware, configuring smart card logon for the domain user, and using the smart card *only* to logon to the workstation, then you have an even *greater* level of assurance that the Master Key can't be recovered under practical circumstances.  [The logon password used to encrypt the Master Key in a "smartcard-logon only" scenario is extremely long - something like 128 fully random characters - using CryptGenRandom().  A W2K3 DC will automatically set this level of random password when a user account is marked "user must use smart card to logon".]  Setting up a W2K3 DC doesn't have to mean a separate computer - you might wish to try VMWare or Virtual PC to create a virtual W2K3 system, promote it to a DC, install an Enterprise CA, and jump through your hoops.

A lot of work, but it might be preferable for the extra-paranoid in the crowd who don't trust their 30-character passphrase to stand up against the kinds of brute-force attacks being launched against their stolen hard drive.  Personally, I don't think anyone wants my drive contents *that* badly.

5) I'm under the impression, from my recent tests (and the nordahl docs, when last I read them) that this doesn't work with XP SP2.  If someone can show me step-by-step how to make this work (especially on a domain-joined XPSP2 system), I'll...well, I'll be really grateful.
0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 12708396
With reguard to ontrack, the tools we purchsed are great, we use them weekly in my consulting. Overwritten data is recoverable be it from random data, low-level formats etc... there is a limit, however the file/disk/sector wipers I've tested (over 30) do not do an adiquate job.
 With reguard to EFS and an encrypted folder, your statements are true to some degree. I've not done difinitve/conclusive testing on xp and 2003 (which uses ntfs ver5)- but the way EFS works on win2k and prior, EFS does not use the temp directory, but in reality uses the parent directory to store the efsX.tmp file. So in your case, if your in mydoc's and it's an encrypted folder, and your file is in that folder, i will not recover the Plain-Text version of it. However ;p I will get your EFS key's even if exported, they were also on the HD at one time, and I swear, that is all it takes. Now that is quite an involoved process, and never worth the time, but when things are slow and there is nothing better to do around the office, sometimes you make time. It's really not worth it the time/effort and it's not fun.  

>1) SAM (local account) passwords can be blanked or *overwritten* no matter what level of SYSKEY is in place.  Today's tools may or may not do it well, but this >is merely on-disk data and there's nothing to prevent someone from editing data on disk.  I am unclear how it is practical to crack SAM (local account) >passwords if the computer has been configured with SYSKEY = 2 or 3 (floppy or passphrase), unless you have possession of the SYSKEY well.  Rich, could you >explain how you accomplish this step by step?

Sure. I've broken this down before, and it goes a little something like this...
Syskey is only enabled when windows is booted/running. The hash values stored in the SAM on the HD are always on the HD, the syskey encryption of these values is never written to disk, only sent to memory. With that in mind, if one uses the linux-boot util, and blanks the admin or other pass, upon reboot syskey will encrypt that hash (which is aad3b435b51404eeaad3b435b51404ee <--LM /  NTLM -->   31d6cfe0d16ae931b73c59d7e0c089c0   btw) Actually with the reset util we all know and love, it actually BLANKS the pass, meaning wipes out the hash altogether, but upon reboot winblows is happy to create the hash and write it to the sam, thanks!
There is no reason to "crack" syskey perse, since it's doesn't hinder us in anyway what so ever. Granted, when windows is running, admin priv's are required to run tools such as Pwdump3, pwdump3e, or pwdump3v2. Stopping them is easy however, by turning the "Remote Registry" service to manual, or disable and or stopping the service if running. Pwdump2 requires you to have the program on the hd of the machine your attempting to obtain the hashes from. Pwdump3... can be run remotely, and actually I wrote the snort sig's that detect it and NtDump. The coolest thing about pwdump3 is that it encrypts a tunnel between the  admin and the remote pc where the SAM is being read.

Now, something that I will have to do more research on, is the password protection offered by the syskey utility. It's my feeling that it's a registry value that can be reset, and seems to act like more of a "bios boot up password" than anything. In fact I wonder if I export syskey to floppy, on two different machines, and set the boot up password also on both (same pass, then i'll try different), if the floppies are interchangable... I've got some experimenting to do, but sounds like fun.

-rich
0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
LVL 38

Expert Comment

by:Rich Rumble
ID: 12708512
>5) Still open: blanking user passwords, bypassing syskey, and logging in.  rich - since you tell me you are able to do this, I will try again!
To be more clear... syskey isn't by-passed, but infact syskey isn't a factor. The syskey UTILITY offers the "password protection" thingy, which I think is seperate from syskey- and is simply a boot-up password of sorts. I plan on finding out a bit more about the "syskey password protection thingy", i think that is it's technical term.

And of note, you were able to do this, you blanked you pass, and were prompted for the "boot up pass" as I am calling it, which didn't even flinch that one of the passwords in your SAM changed... another reason i think that the boot up pass protection doesn't rely on syskey or the sam at all.

To me when i think of syskey, I think of the service/program that encrypts the sam- I think of the password protection as seperate- and not using syskey for it's authentication, seems like a function built into the syskey utility... I dunno for sure yet.
-rich
0
 
LVL 4

Expert Comment

by:poseidoncanuck
ID: 12710987
Rich, thanks for the responses.
- What products specifically are you using from OnTrack - EasyRecovery Professional?
- the wipers you've tested do not do an adequate job - what do you mean by this?  Do the wipers that claim DoD compliance (3x overwrite) still let you recover all portions of "wiped" files every time?  Do the German military-compliant wipers (7x overwrite) still let you recover *some* portion of the data in any file every time?  Does the OnTrack DataEraser product not even block OnTrack's EasyRecovery Professional product?
- Let me be sure we're talking about the same thing in the 'encrypted My Documents' scenario:
- - - which "EFS key's" are you saying that you *can* get - the AES symmetric key?  The user's RSA private key?  The user's Master Key?
- - - where are you getting the key from - on disk?  In memory?  In some alternative "cache" of the key?
- - - when you say the "EFS key's...were also on the HD at one time", do you mean that the key was stored on disk in plaintext form at some point, or that the key was stored in encrypted form on disk, and you're now performing a brute-force decryption of the key?
- - - I imagine that when you say "that's quite an involved process, and never worth the time", you are qualifying your previous statement "I swear, that is all it takes", since you're probably talking about a significant brute-force attack on the encrypted bits.  What kind of computing hardware are you talking about using here?  Is this commercially available hardware, that most organizations/thieves could have at home/in the office, or are you talking about a significant investment of $$$ (e.g. $100K, $1 M, etc.)?
- - - what versions of Windows are you talking about here?  Have you successfully performed this same "get your EFS key's" on Windows XP?  XP SP1?  XP SP2?  Windows Server 2003?

- the SYSKEY attack you describe is one where you're *changing* the password hash values in the SAM.  Do you have a similar attack to *recover* the unencrypted, existing version of the user's password hashes from the SAM - in both the SYSKEY=1 and the SYSKEY=2 or 3 scenarios?  [This is what I was referring to when I said "unclear how it is practical to crack SAM account passwords if the computer has been configured with SYSKEY=2 or 3?
- if the user has used a domain account, or has used SYSKEY=2 or 3, then can you describe how the same "reset util" can help you get access to the EFS'd data?  AFAIK, SYSKEY=2 or 3 (that the attacker doesn't have - i.e. the user didn't write it down on the computer, or on something stored on the computer, and didn't leave the boot floppy with the computer) *does* hinder the EFS attacker - that is, the OS won't boot, and won't present data for tools like pwdump3, pwdump3e, pwdump3v2 to capture, until the SYSKEY has been presented by passphrase or boot floppy.
- SYSKEY reset through the registry - I myself assume that there must be some registry entry to change the SYSKEY *setting* from 2/3 back to 1 (or even "off" theoretically, though I don't know for sure).  However, that does *not* mean that any data encrypted by SYSKEY would automatically be recoverable with the *new* SYSKEY that would have to be generated.  AFAIK, all it would mean is that you've got a newly-reconfigured OS in which you can store *newly-encrypted* data that is protected by the new SYSKEY key.  It won't do you any good in recovering the data protected by the *old* SYSKEY.
- 5) Still open: blanking user passwords, bypassing syskey, and logging in ==>>> won't get you access to data encrypted on Windows XP, even if it's encrypted under a local account.  Sure, you can logon to the box, but I'm not sure what good that does you in attempting to recover access to the user's data (that attacking from an alternative OS wouldn't do just as well).  I personally don't care whether you can use my OS for some other purposes - but I *do* care whether you use my OS to recover my encrypted data.

To me, when I think of SYSKEY, I also think of the service/program/whatever that encrypts the SAM, cached credential verifiers, LSA secrets, etc.  The password protection of the SYSKEY "Startup key" (as the syskey.exe utility calls it) is there to decrypt the SYSKEY "startup key", if I understand SYSKEY correctly.  Rich, can you clarify what you mean by "password protection" in your last sentence?

Thanks again - I appreciate the ability to clarify these questions for folks like SAbboushi, who I believe are trying to ensure they have the best possible approach to protecting their encrypted files from "attackers" like you or me :)  .
0
 

Author Comment

by:SAbboushi
ID: 12711142
>> With reguard to ontrack, the tools we purchsed are great, we use them weekly in my consulting. Overwritten data is recoverable be it from random data, low-level formats etc... there is a limit, however the file/disk/sector wipers I've tested (over 30) do not do an adiquate job.
I want to know about this Ontrack software tool that can recover data that has been overwritten several times!  Specifically, which tool is it??  If the same sector has been written over by three different files over the course of several weeks, can I recover each of the 3 different 'versions' that have existed on that sector??

>> However ;p I will get your EFS key's even if exported, they were also on the HD at one time, and I swear, that is all it takes
I assume you would do this using the ontrack tool I asked you name for us?


>> Syskey is only enabled when windows is booted/running. The hash values stored in the SAM on the HD are always on the HD, the syskey encryption of these values is never written to disk, only sent to memory. With that in mind, if one uses the linux-boot util, and blanks the admin or other pass, upon reboot syskey will encrypt that hash (which is aad3b435b51404eeaad3b435b51404ee <--LM /  NTLM -->   31d6cfe0d16ae931b73c59d7e0c089c0   btw) Actually with the reset util we all know and love, it actually BLANKS the pass, meaning wipes out the hash altogether, but upon reboot winblows is happy to create the hash and write it to the sam, thanks!
There is no reason to "crack" syskey perse, since it's doesn't hinder us in anyway what so ever.

"Syskey is only enabled when windows is booted/running." "seems to act like more of a "bios boot up password" than anything"
I think there is more to it than this.
a) I disabled syskey with ntpasswd on a new XP Pro install; then rebooted back into ntpasswd.  The Administrator account and user account displayed as *disabled and locked*.  , I was able to BLANK the passwords and login.  I think this shows that syskey is doing something to the user account password hashes (see note from author of ntpassed below)
b) On my fully configured laptop, disabling syskey did NOT result in the Administrator and user accounts being flagged as *disabled and locked*.  I was UNABLE to login regardless of whether I blanked the user account passwords or not.  I am not sure what conclusion to draw from this... other than: disabling syskey with ntpasswd is not always reliable (as you've said rich)
c) The ntpasswd author states that enabling syskey does in fact CHANGE and STORE the hashes in the SAM upon reboot after enabling syskey, and that his utility takes this into account when blanking the passwords.  Also, the author states that disabling syskey will require that the account passwords are reset.  However, although not certain, he may be stating that the only change to the password hashes is that it is expanded by 4 bytes and that the first 4 bytes seem to be a counter and that the original 16 byte hashes are simply located 4 bytes beyond where they used to reside - which may be why you are seeing that the hashes "remain the same" pre- and post-syskey.

http://home.eunet.no/~pnordahl/ntpasswd/syskey.txt
"Then there's the password hashes.
The usual (old) hashlength is 16 bytes, but all hashes are expanded to 20 bytes
with syskey, the first 4 bytes looks like some kind of counter. (maybe
history-counter?).
Strangely, they're not updated at once when syskey is turned on,
update of the hashes happens during next reboot after syskey has been turned on.
And when the key is later updated, the hashes are also updated?
NO!! Strangely it SEEMS like the password hashes REMAINS THE SAME!
(however, the binaries in the 3 keys noted above changes..)
I'll try to dig more into this. Help wanted :)

When syskey has been switched off, all passwords must be reset.
My utility will write and adjust hash-lengths of the users (usually
administrator) that you reset the password for."


>> The syskey UTILITY offers the "password protection" thingy, which I think is seperate from syskey- and is simply a boot-up password of sorts
OK - it seems we've been using different definitions for syskey - hence my confusion.  Yes - I've been talking about the "syskey password protection thingy" - thanks for expanding my technical vocabulary ; )


-------------------------------------------------------------------
http://support.microsoft.com/default.aspx?kbid=310105
"The Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows 2003 Security Accounts Management Database (SAM) stores hashed copies of user passwords. This database is encrypted with a locally stored system key. To keep the SAM database secure, Windows requires that the password hashes are encrypted. Windows prevents the use of stored, unencrypted password hashes.

You can use the SysKey utility to additionally secure the SAM database by moving the SAM database encryption key off the Windows-based computer. The SysKey utility can also be used to configure a start-up password that must be entered to decrypt the system key so that Windows can access the SAM database."
-------------------------------------------------------------------

I am confused by microsoft's 'explanation' above.  It seems to say that the SAM is in fact encrypted by default with a system key, and that the syskey utility (in my configuration: startup password) uses the startup password to encrypt and decrypt the system key (i.e. the system key, encrypted by the startup password, remains on the hard disk).  Alternatively, it seems to say that instead of encrypting the system key, the system key can be relocated from the hard disk  to a floppy instead (which would be required during startup).  

ARGHH - there seems to be a lot of contradiction on whether the SAM is encrypted or not both before AND after syskey is enabled!!

Does anyone have a clear, defensible answer on this - with the steps to prove their answer??

>>5) Still open: blanking user passwords, bypassing syskey, and logging in.  rich - since you tell me you are able to do this, I will try again!
Success - sort of.  I was able to disable syskey AND blank the admin password using ntpasswd as you have said.  How? (this part is for poseidoncanuck - sorry, workgroup, not domain...):  
1) I did a fresh install of MCE2005 (=XP Pro without ability to connect to a domain),
2) created an administrator password
3) enabled syskey for startup passphrase
4) booted using the ntpasswd CD and followed the prompts to disable syskey
5) rebooted using the ntpasswd CD and followed the prompts to blank the admin password
6) Removed the ntpasswd CD and rebooted: Windows started up and dropped me into the Administrator desktop

HOWEVER, these steps will NOT work on my fully configured laptop (also MCE2005).  This makes me concur with the author of ntpasswd: "VeryBAD: SWITHCHING OFF [SYSKEY] IN WINDOWS 2000 AND XP NOT PERFECT,  WILL CAUSE TROUBLE"
-------------------------------------------------------------------------------------
http://home.eunet.no/~pnordahl/ntpasswd/syskey.txt
Try to turn it off. This has one drawback, and one good side:
   Bad: all passwords must be reset, since the old hashes will be invalid.
   VeryBAD: SWITHCHING OFF IN WINDOWS 2000 AND XP NOT PERFECT,
            WILL CAUSE TROUBLE, but you can access the computer
            afterwards. Domain relationships & syskey may be
            impossible to change after this, requiring a reinstall
            (or possibly only an upgrade)
-------------------------------------------------------------------------------------
In my case, I was able to access one OS afterward by disabling syskey and blanking passwords, but I was not able to access the other OS.

The closest explanation I could find on the authors FAQ:
------------------------------------------------------------------------------------------
http://home.eunet.no/~pnordahl/ntpasswd/faq.html
I'm not told that the account is locked out, even Windows says it is. How can I reset it?
Oops, probably more to the lockout stuff than I know about.
You probably can't reset it in the current release.
------------------------------------------------------------------------------------------
0
 

Author Comment

by:SAbboushi
ID: 12711270
sorry rich - it looks like there's now 2 of us 'detail oriented' individuals hitting on your expertise at the same time!

poseidoncanuck - welcome to the party!  It is an honor to have 2 such experienced experts respond to my posts.  You ask many of the questions that I lack the experience to ask - but that I want the answers to!.  Thank you-

>> Do you have a similar attack to *recover* the unencrypted, existing version of the user's password hashes from the SAM
This was one of my earlier questions.  Microsoft claims that Windows XP prevents the use of stored, unencrypted password hashes.  Are there steps you can give me to prove that their statement is bologna?
-------------------------------------------------------------------
http://support.microsoft.com/default.aspx?kbid=310105
"The Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows 2003 Security Accounts Management Database (SAM) stores hashed copies of user passwords. This database is encrypted with a locally stored system key. To keep the SAM database secure, Windows requires that the password hashes are encrypted. Windows prevents the use of stored, unencrypted password hashes.
_________________________________________________

0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 12712170
Wow... me an my big fingers...

To be clear- let's start with syskey, and the password reset utility.
I really should of been much much clearer about this, even though the utility says it can turn syskey off, this is not a step that you need! It's stated somewhere on that guys site also that you do not need to turn it off... and I actually wonder why it's still an option. So if you would like to see for yourself, please get a pc you care nothing for, reset, blank what have you the pass words with that util, before doing so enable the syskey=3 (password to boot- and floppy storage of the keys) You may also consider buying, or borowing the Hacking Exposed Book, hell make a trip to borders and thumb through it. The index in the back will tell you where syskey is... i don't have the book in front of me... but I need more firepower!

Now on to OnTrack. For the majority of our M$ recoveries EasyRecovery Professional, since it has all the main recovery tools anyway. And yes I can get multiple versions of files, and they even have a product for memory sticks and usb HD's that works well. The process takes hours for a few meg's of data, nonetheless it does recover it. I should also mention it has short commings, and the more you mess with a drive the harder it is to recover the data.

I thought the DoD was 7 times random 1's and 0's...(the fact is that these over-write sectors, but the File Allocation Tables and journals in cases like ntfs are seldom erased more than once, and reading where the file "used" to be from the table/journal gives data recovery tools a nice head start.)
Encrypted files give ontrack a hard time, and they take the longest to recover, particularly Steganos files and pgp files. Formats have little effect, unless data is written after the format's, like an ext3 format, then actually loading linux on a hd. But we've recovered some data in our test's. One of the coolest things about the software is buying new hd's and seeing what's on them! I'm not sure how they can all them "NEW" at all. Never found anything of real interest, but they have definatly been used prior, or perhaps it's part of their QC process?

I'll write back when I have a bit more time tomorrow, keeping me on my friggin toes fellas!
-rich rumble rumble rumble...

0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 12712283
Gawd... I can't let it go....
DL pwdump2 for yourself, and look at your own hash's (google for pwdump2.zip it's like 87k or something)
go to cmd prompt
cd to dir_where_pwdump2_is_unzipped
       type: pwdump2.exe (press enter)

If you have a user with the password of "HelloWorld" (no quotes- it is case sensitive big H big W) the hash should look like this:
f37f57a03351c09d237508f14bab2ae3 for the NTLM case sensitive version (the second value[username:SID:LM-HASH:NtLm-HaSh:::)

Used to be that Rdisk /s would back up the sam to a floppy in a compressed form, and all you needed to do was expand it. But now- win2k and after
Look's like syskey encrypts the sam on the floppy if you've set it to export to floppy. The sam on the floppy is different than the one on the HD. The HD STILL contains the sam, "un-encrypted" if you can all it that- (we'll let's just say it's, un-re-encrypted to keep it simple :P ) anyway the sam on the HD remains unchanged (unchanged from the values you see in your pwdump2 output), in win2k,winME, xp, and 2003- even if exported to floppy is selected- the good news is that the floppy sam is encrypted with the syskey, and I know of no cracker's for a "truely syskey encrypted sam". Not sure if the sam being on the HD even after export is a fail-safe or bad coding... even with NT4 it remained, but wouldn't look for it.

bah... i'll be back ;)
-rich
tomorrow
0
 
LVL 4

Expert Comment

by:poseidoncanuck
ID: 12713183
Rich, there's another thread elsewhere that I imagine you'll want to weigh in on:
http://www.experts-exchange.com/Security/Q_21204080.html

Someone's claiming that East-Tec Eraser makes it impossible to recover erased data:
"I use this program and if he/she set the settings high enough, it's impossible to recover the information with either software OR hardware techniques."

Based on your previous statements, I imagine that this cannot be true.

I'll respond to your other thoughts after you've completed your response :)

Cheers,
Poseidon
0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 12715131
Not all data is recoverable with ontrack make no mistake... but enough is. The key to ontrack is filesize's- there isn't much under 5meg's that it won't recover that we've found. I can run that program through it's paces when we get more time, not heard of it before. more to come...
-rich
0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 12729875
Hacking Exposed 3rd edition pages 247-250 have a great section on the syskey and similar descriptions on injecting pass's into the sam that i've gone over.
The hacking Exposed 2nd edition syskey in mentioned on pages 240-249 there abouts. I'm sure the 4th edition (current one i think) wouldn't be to different. In hacking exposed windows 2003 the page is 411-415, Print seems like a better source than the internet sometimes.

These are the registry differences between the password to boot being disable, and then being enabled.
After activation: (changes in the registry keys)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG (a second SEED entry has been entered) This is the Random Number Generator
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa\Data (a second Pattern entry has been entered)
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa\GBG (a second GrafBlumGroup entry has been entered)
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa\JD (a second Lookup entry has been entered)
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa\Skew1 (a second SkewMatrix entry has been entered)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Data (a second Pattern entry has been entered)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\GBG (a second GrafBlumGroup entry has been entered)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\JD (a second Lookup entry has been entered)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Skew1 (a second SkewMatrix entry has been entered)

AH HA! Sweet!
http://studenti.unina.it/~ncuomo/syskey
http://studenti.unina.it/~ncuomo/syskey/syskey.txt
This looks promising...

The password I choose was "1234" for the boot up pass
boot pass    6157b4e709b9d997692f6f58d6791894
1234 md4=  f375f401ddc698af533f16f8ac1e91c1
1234 md5=  81dc9bdb52d04dc20036dbd8313ed055
1234 Ntlm= 7CE21F17C0AEE7FB9CEBA532D0546AD6

I need to look at this fella's code some more- but I think I'm on the right path...

-rich

0
 

Author Comment

by:SAbboushi
ID: 12739410
Hi rich-

as always, I appreciate your efforts - you don't give up easy, do you!
0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 12925706
Forgot to update...
Looking at the code for http://studenti.unina.it/~ncuomo/syskey I can say that he's not getting the boot pass from the right spot. I've also not found the correct spot yet, and softice is giving me headaches- trying to reverse the syskey calls- I've had good luck with sysinternals stuff than the best debugger in the world... http://www.sysinternals.com/ntw2k/utilities.shtml
I am going to "lick" this one- it's my mission for the new year.
-rich
0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 13057450
I've got it, and it's very easily by-passed- I just have to write the app to do this for you. I am able to copy and paste a known hash in the proper location- and boot the pc, then afterward, you can copy and paste the old hash back, and no one is the wiser. Syskey isn't a factor, as usual... more to come very soon
-rich
0
 

Author Comment

by:SAbboushi
ID: 13295318
Thanks rich-
Sorry for my delay in responding - I was in CT for almost 6 weeks during your last 2 posts - dad was in intensive care - but he surprised all the doctors and survived.  He's still in the hospital but stable - so I am back home in IL again.

0
 
LVL 38

Accepted Solution

by:
Rich Rumble earned 1500 total points
ID: 13297731
Glad to hear things are better. Turns out I'm not a great programmer- so we've shared the proof of concept with a few security firms and they have volunteered to help us code the app- when they get time. But were very excited to have such legendary teams take intrest in our shoddy code ;)
-rich
0
 

Author Comment

by:SAbboushi
ID: 13297889
Nice to hear from you again rich-
Also nice to see humility in someone so technologically astute-
0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 14946534
The code is still evolving, it's very interesting work, but I'm in over my head still. Getting close now...
-rich
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

It’s time for spooky stories and consuming way too much sugar, including the many treats we’ve whipped for you in the world of tech. Check it out!
Ransomware - Defeated! Client opened the wrong email and was attacked by Ransomware. I was able to use file recovery utilities to find shadow copies of the encrypted files and make a complete recovery.
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
Is your data getting by on basic protection measures? In today’s climate of debilitating malware and ransomware—like WannaCry—that may not be enough. You need to establish more than basics, like a recovery plan that protects both data and endpoints.…
Suggested Courses

809 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question