-1

I want to manually get the NT hash from the registry (without any tool). Let's say just for the administrator. I know that it must be stored in the SAM area of the registry somewhere so I tried to extract it from there. I found the location HKLM\SAM\SAM\Domains\Account\Users\000001F4 (1F4=500=Admin) and there the value "V" with some binary content. The only useful documentation for the V binary is this link: http://www.beginningtoseethelight.org/ntsecurity/index.htm but that info is very old and I'm not sure if that is still correct with current Windows 7 and Windows 8. Also, if I extract the NT hash like described there, it doesn't match what I get if I set the password to "123" (I would expect 3dbde697d71690a769204beb12283678, but got 1509c04cb2a3e20eba3fde1ac5f8589f). So the question again: How to manually extract the NT hash from the registry?

http
  • 127
  • 1
  • 1
  • 5
  • 1
    I don't know the internals of how Windows stores the hashes, but a difference in the hash could be [accounted for by a salt](http://security.stackexchange.com/questions/14025/why-is-using-salt-more-secure) – makerofthings7 Jul 07 '13 at 11:53
  • Hi @makerofthings7, best answer so far. Let me know if I should edit the post somehow. Yes, if Windows is now using a salt, that would explain everything. Are you sure about that? It would be new to me that Windows now uses salting. Any source for that? Since what version? And which salt is being used? The username, SID or something completely different? I think Windows is NOT using salting at all (for several reasons), but convince me if you have any reliable source for that. – http Jul 07 '13 at 17:12
  • 1
    An API will be needed to read the hash if the one you located is wrong or incomplete. The premise of this question is that regedit & file browsing tools built into the OS are sufficient to view the hash. That may not be the case, and the value may be stored in binary using a non documented API that is restricted to a specific calling process. Your question seems to think linux-like where you can browse to a ./etc/passwd file. That's not necessarily the case with Windows OSs... but I don't know for sure. – makerofthings7 Jul 07 '13 at 17:57
  • @http You need to challenge your assumptions or else you will dismiss the correct answer because it does not match what you expected. – schroeder Jul 08 '13 at 15:13
  • @makerofthings7 Fully understood. It *is* stored in a binary with an undocumented API. Well not even an API, the Registry API is public, just the format is private. I want to read the binary myself; it's documented in the link I provided, but the documentation there might be outdated. So the idea with the salt was just an educated guess then? – http Jul 08 '13 at 20:38
  • @schroeder I don't know what assumptions you are talking about and what I should "challenge". I'm not aware of making any assumptions. Please explain. – http Jul 08 '13 at 20:42
  • @http the assumption is that the hash you generated must be the same as the one in the Registry. – schroeder Jul 08 '13 at 21:22
  • @schroeder I'm just assuming it is stored somewhere, obviously in the registry, in the SAM area, because it was always there. Where exactly is the question. It might be obfuscated, salted, whatever. So that's the question; how it is stored exactly. Have you read the description in the link? That clearly describes how it worked in XP and is a good start. I don't see any difference in Windows 7/8, but it's just not working for some reason, so maybe it's just XORed with some Windows-installation-ID or something. My question is HOW is it stored there? – http Jul 08 '13 at 21:35
  • This question appears to be off-topic - please rethink what it is you are aiming to get. I have read the extensive comments, and it does look like you aren't paying attention to the answers you are getting. They do answer the question you have written. Once you have a firm question, ask it. – Rory Alsop Jul 09 '13 at 07:06
  • @Rory Alsop: First of all, the question is not off-topic. Why should it be? My question was to find out how to get the hash. Nobody answered that yet. All I got was to boot with other systems and general stuff like that. The question is firm and clear. Let me know if I can improve it in any way. – http Jul 11 '13 at 02:31
  • 1
    Simple answer http: you are not asking a security question. The question you have asked is basic windows OS functionality. It has been perfectly well answered in any case. – Rory Alsop Jul 11 '13 at 10:49
  • @RoryAlsop: How the Windows hash is stored is not a security question? I wonder what is then. And yes, as of yesterday I have an answer in the link that schroeder added in his EDIT, although no answer here on SE. But I would accept that link as answer anyway. But as you closed this question as off-topic, I can't. – http Jul 11 '13 at 18:44
  • You have asked how to get the hash from the registry. Not a security question. Sorry. – Rory Alsop Jul 11 '13 at 19:31

2 Answers2

2

How to extract the hashes from the registry without 3rd party tools

This is the bare-bones answer to the question posed by the OP:

reg.exe save HKLM\SAM MySam
reg.exe save HKLM\SYSTEM MySys

In these files are the local user hashes (not AD). From here, a simple hex script can be written to pull out the individual hashes.

The next question is: are you happy with the just hashes, or do you want to reverse engineer them to the plaintext versions? That question is not asked, so I will assume that it is not desired.

Edit:

This post explains how to script ways to extract hashes.

Community
  • 1
schroeder
  • 123,438
  • 55
  • 284
  • 319
  • I'm interested in this "simple hex script". Well, I don't even need a script, just a description what to get from where exactly. Yes, just the hashes. Only Admin one is sufficient. – http Jul 08 '13 at 21:39
  • @http Then you need to radically alter your question. – schroeder Jul 08 '13 at 23:54
  • I think the question is really clear. I don't know how to improve it. Let me know if you can. I asked how to get the hash. No idea why I should radically alter it. – http Jul 11 '13 at 02:18
  • I just saw your link ("This post") in the edit. That post there is very helpful. It says that SysKey is generating a bootkey that is generated from other values stored in the Class attribute of some other keys etc. I haven't read/understood/verified everything yet. Why don't you give that as an answer? I thought we are not allowed to post a simple link as an answer and all answers have to get copied here. Such an answer would answer my original question. – http Jul 11 '13 at 02:41
  • I finished reading the "This post" and see that the calculation of the 16-byte boot key is missing. Would that be a new question? – http Jul 11 '13 at 02:54
1

The hashes are stored in the Windows SAM file. This file is located on your system (depending on your installation paths) at X:\Windows\System32\config but is not accessible while the operating system is booted up. These values are also stored in the registry at HKEY_LOCAL_MACHINE\SAM, but again this area of the registry is also not accessible while the operating system is booted.

There are known ways (and tools) to reverse engineer the hashes to retrieve the passwords and vice-versa, but I am not going to help you with that because...

Questions asking us to break the security of a specific system for you are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem.

EDIT

Since you have physical access, one of the most effective methods is to boot the computer into a different operating system. If you are comfortable using Linux then this means you can simply boot to a Linux live CD that is capable of reading NTFS drives, mount the Windows partition, and copy the SAM file to external media. Work on that copy by looking at “SAM\Domain\Account\Users”. The rest is up to you.

On a sidenote I would like to warn you about playing with such system areas if you are using Encrypted File System (EFS) on anything released after Windows XP/2003. If you change something in the wrong place there (like resetting passwords or modifying other hashes), it might cause the operating system to lose its EFS keys which introduces a whole new bunch of problems which you don't even want to think about. That's why you'll only want to work with a copy of the SAM file.

EDIT 2

Just found your previous question "https://security.stackexchange.com/questions/37899/how-to-brute-force-nt-hash-to-password" and I'm starting to understand why you keep asking for the "exact hash location" and "hash identification".

Therefore, a little reminder: security.SE is not here to help you hack or crack anything. Please check the rules instead of looping the question in the comments area. Thanks.

Community
  • 1
e-sushi
  • 1,296
  • 2
  • 14
  • 41
  • I understand that the file cannot be read while it's in use, but the registry can be accessed (you just need to change permissions). I do know how to calculate the hashes and what tools to use. Also, my question is not a specific system. I want to know where to get the hash value from the registry; where exactly it is located. If I run Registry Editor as system, *I am* the system and the system must be able to read the values there. So where is it? Is the key I mentioned not correct? I do know pwdump and all these tools, but I want to do it manually, so I need the knowledge. – http Jul 06 '13 at 21:07
  • 1
    @http Please read what I wrote: **not accessible while the operating system is booted**. You will have to use another OS (Windows, Linux) to access the data from the non-booted windows install you want to analyze. Besides that, I think that marking the locations "X:\Windows\System32\config" and "HKEY_LOCAL_MACHINE\SAM" in bold is enough indication where to look? To make sure you get it: even if you would be able to run regedit as SYSTEM, **your OS is booted** and the related areas **not accessible while the operating system is booted** so you will not be able to see the hidden and locked data. – e-sushi Jul 06 '13 at 22:25
  • @http Added an **edit** to my answer to give you a push into the right direction. – e-sushi Jul 06 '13 at 22:43
  • I am not asking how to get the hash by a tool. I know all the other methods. I know I can't access the file while the system is running. But the lsass process has to have access while the system is running, so don't tell me it's not possible to access the hash while the system is booted up. Worst case would be to inject code into lsass process. But lsass also runs only as SYSTEM, which I can do as well. So to repeat my question: Where does lsass read the hash from? Or if you had a copy of the SAM registry, where would you read the hash from? (without any tool) – http Jul 07 '13 at 11:40
  • 1
    @http I can't help you as long as you ignore what I write... I never stated you need *"wizard"* software to help you find the hash locations; I said you need another *"OS"*. Since you keep repeating your "no tool" mantra over and over again, let me remind you that no one can read disk-data with the naked eye. You will need a hex-editor to see the relevant raw bytes. But no special "password crackers" or "hash fetchers" needed. As for the repeated location question, I'll quote my EDIT: *"SAM\Domain\Account\Users"*. You want to do it manually? Use separate OS + HexEdit and get your hands dirty. – e-sushi Jul 07 '13 at 14:42
  • I'm not ignoring anything, I just said I do have access to SAM\Domain\Account\Users already, even in the running system. I don't know why you would need another system when I can open all keys already. But if you feel better, just assume I'm running the regedit from another system started from a boot disk. I still don't know which exactly is the hash. Was the information in my original post correct then? And why is the hash wrong? – http Jul 07 '13 at 17:08
  • 1
    @http Please note that after I post this comment, I won't be replying here anymore to avoid a discussion loop. Besides that, I think time has come to point you to *"Please avoid extended discussions in comments."*, *"Can I get data analysed here? Can I challenge people to decode something? No. Such questions are not helpful."* and http://meta.crypto.stackexchange.com/questions/100/do-we-want-challenge-analyse-this-questions-and-if-so-what-constraints-if-any Have a nice day. – e-sushi Jul 07 '13 at 17:37
  • 2
    @http Let's assume that e-sushi is correct. That means that the relevant hashes are loaded into memory at bootup and the sources are locked. That means that to get what you are looking for, you need to look in the memory, or be outside of the OS to read the hashes and salts. Look at the source code of the tools you know. Where do they look? – schroeder Jul 08 '13 at 15:22
  • @schroeder That's a good answer. (No idea on how I can upvode comments.) But if this would be correct, what happens if I change the password? That can't be just in memory, otherwise it would be the old one on next boot. And I see that the value in that binary changes when I change the password. So the hash must be there somewhere/somehow. – http Jul 08 '13 at 20:50
  • @e-sushi: You're wrong. First (in EDIT2) you make a wrong link to another unrelated question. Don't mix things that don't belong together. Second, I'm not asking to help to crack a specific system. I'm here to get knowledge. I know my passwords. Otherwise *any* pentesting question would be off-topic. – http Jul 11 '13 at 02:36
  • 1
    @http **Please avoid extended discussions in comments.** Security.SE is not a “forum”. Besides, your question was put on hold as “off-topic” two days ago. From my perspective — for a good reason… – e-sushi Jul 11 '13 at 13:29