How are Windows 10 hashes stored if the account is setup using a Microsoft account?

Question

I was testing the integrity of my passwords and noticed that after I dumped the hashes, there was only one account where the NTLM hash was not a "default hash." I also know that that account happens to be my backup user so it is not configured to log into any Microsoft account. It is simply a local user.

On the other hand, my main account is configured to be a Microsoft account and its hash is the default 31d6cfe0d16ae931b73c59d7e0c089c0, which is really an empty password. However, that is not my real password on the account.

So my question is, is that the hash because when I log in using a Microsoft account, is it making a request to the Microsoft servers for the hash/validation or is the hash stored anywhere else.

Also, wouldn't it be more secure for a person to be forced to use a Microsoft account because a hacker would never be able to take advantage of physical access to a machine or tricking the user to click on something that gives them access to the SAM/SYSTEM files?

Answer 1

Windows hashes are saved in SAM file (encrypted with SYSTEM file) on your computer regardless of the fact that you are using Microsoft account. It needs to be done this way to allow you to log in to your computer, even if you are not connected to the internet. If you change your password using account.microsoft.com, you will still be able to log in to your computer with your old password (even if you are using Microsoft account). After logging in to the system, you will be prompted to type new password, but as long as you don't type new password, you will be able to use old password to log in to your computer. After you type new password, SAM (and possibly SYSTEM) file will be updated.

You (wrongly) get 31d6cfe0d16ae931b73c59d7e0c089c0 hash of your password because format of the SAM and/or SYSTEM files has changed since Windows 10 Anniversary update (see: similar problem), thus tools like chntpw, bkhive, pwdump, samdump2 print hash of the empty password (I verified it on my Windows 10). Since this update, Windows uses AES128 to encrypt password's MD4 hash. Because of that, nearly all tutorials regarding Windows password recovery became outdated.

Fortunately there is a tool called mimikatz (Windows-only, but can be ran on Linux by using Wine) created by Benjamin Delpy, that can read passwords' hashes saved in Windows' new format. Note that Windows Defender and Symantec antivirus treats it as a 'Hack Tool' and removes it, so you need to disable them before running mimikatz (run as a administrator).

mimikatz consists of many modules, but you should explore lsadump module, particularly lsadump::sam function.

Excerpt from docs:

If you're not SYSTEM or using an impersonated SYSTEM token, you'll have access denied error:

mimikatz # lsadump::sam
Domain : VM-W7-ULT-X
SysKey : 74c159e4408119a0ba39a7872e9d9a56
ERROR kuhl_m_lsadump_getUsersAndSamKey ; kull_m_registry_RegOpenKeyEx SAM Accounts (0x00000005)

In this case, you can use psexec to begin SYSTEM (or other tools) or elevate with token::elevate command to impersonate a SYSTEM token:

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # token::whoami
 * Process Token : 623884       vm-w7-ult-x\Gentil Kiwi S-1-5-21-1982681256-1210654043-1600862990-1000  (14g,24p)       Primary
 * Thread Token  : no token

mimikatz # token::elevate
Token Id  : 0
User name :
SID name  : AUTORITE NT\Système

228     24215           AUTORITE NT\Système     S-1-5-18        (04g,30p)       Primary
 -> Impersonated !
 * Process Token : 623884       vm-w7-ult-x\Gentil Kiwi S-1-5-21-1982681256-1210654043-1600862990-1000  (14g,24p)       Primary
 * Thread Token  : 624196       AUTORITE NT\Système     S-1-5-18        (04g,30p)       Impersonation (Delegation)

mimikatz # lsadump::sam
Domain : VM-W7-ULT-X
SysKey : 74c159e4408119a0ba39a7872e9d9a56

SAMKey : e44dd440fd77ebfe800edf60c11d4abd

RID  : 000001f4 (500)
User : Administrateur
LM   :
NTLM : 31d6cfe0d16ae931b73c59d7e0c089c0

RID  : 000001f5 (501)
User : Invité
LM   :
NTLM :

RID  : 000003e8 (1000)
User : Gentil Kiwi
LM   :
NTLM : cc36cf7a8514893efccd332446158b1a

You can download x86 and amd64 binaries of the mimikatz here.

As a side note – if you want to make sure that password's hash is hash of your password, you can easily do it using Python:

user@mycompa:~$  python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, binascii
>>> passwd = "password"
>>> hash = hashlib.new('md4', passwd.encode('utf-16le')).digest()
>>> print(binascii.hexlify(hash))
b'8846f7eaee8fb117ad06bdd830b7586c'

Answer 2

To add onto patryk.beza's good answer:

Also, wouldn't it be more secure for a person to be forced to use a Microsoft account because a hacker would never be able to take advantage of physical access to a machine or tricking the user to click on something that gives them access to the SAM/SYSTEM files?

No, the password has to be stored on your computer somewhere. If for some reason you can't access the MS servers when you log in, the OS will still let you login with your credentials. And even though the user didn't click on anything, it's still possible that a potential flaw in the OS will give a threat actor access to the SAM file. One of the major problems that I have with the MS accounts is this: when you link your MS account to your computer, it uses the same password for everything. This can be very bad since a threat actor can change your password if they can get access to the SAM file and break the hashing. If a threat actor has your password, they can start changing all of your passwords to completely lock you out of everything. It's a major risk that MS doesn't tell you about since they like being able to spy on you. And it's only a matter of time before more rainbow tables come out to start breaking Windows 10 passwords. When it comes to security, it's never a question of IF; it's WHEN.