erwan2212
commented
4 years ago Actually, I have come to believe that the key to decrypt the MK (i.e compute the HMAC) is not the user password when using a microsoft account. There is definitely a key needed but not forcibly the user sha1 password.
Regards, Erwan
Le ven. 13 nov. 2020 à 03:49, Papotito123 notifications@github.com a écrit :
Hello: I were kept doing tests with CREDHIST. For the benefit of this post:
- MA account is MicrosoftAccount
- the guid I referred is the GUID related to decrypt Chrome login
- the term "switched /switch" refers to change from MA user to Local user or Local user to MA user
So some verified useful info.
To retrieve user CREDHIST hashes history with mimi: mimikatz # dpapi::credhist /in:"C:\Users\username\AppData\Roaming\Microsoft\Protect\CREDHIST" /password:actual_user_password /unprotect
It can be also used with /hash:actual_user_password_SHA1
If the account never had other password and is a MA user(like in my Win 10 2004H1) then output will looks like: mimikatz # dpapi::credhist /in:"D:\Users\username\AppData\Roaming\Microsoft\Protect\CREDHIST" /password:Tromelt@nz /unprotect CREDHIST dwVersion : 00000001 - 1 guid : {00000000-xxxx-xxxx-0000-000000000000} dwNextLen : 00000000 - 0
My PROBANDO account is now a MA account user. The CREDHIST hashes history has 7 entry with all different SHA1 because all times I switched the account. From the output I can id ,[entry 7] with user SHA1 of first password set when the user was Local account(first creation) The [entry 2], which indeed is SHA1 of the actual password string when changed from MA account to Local account.
The [entry 3] which can decrypt the GUID dated in Sept and October(I recovered copies with a Volume Shadow copies tool).
Some differences in LinkGUID for CREDHIST. When the guid is in form of : {00000000-xxxx-xxxx-0000-000000000000} ,the SHA1 is associated when MA account user. When the guid is in form of : {f49xxxxc-486e-4xxx-bd4b-9c33xxxx2b2c} ,the SHA1 is associated when Local account.
As Properties(using CredHistView tool): Hash Algorithm is SHA512 , Encryption Algorithm is AES256 , Iteration Count is 8.000(for most). This tool is in dev stage , so it fails to decrypt most of the entries in MA user.But mimi is suffice. For hives, this tools can be of used, Windows Registry Recovery 3.0.0 from mitec.cz
But wait....there's more ... I have the same MA account being used in my Win 10 2004H1 partition(same name, same password of course). And ...the guid in Win 10 2004H1 is decrypted with [entry 3] SHA1, that can decrypt the GUID dated in September and October in my other OS where PROBANDO MA account user resides.
So using a different user SHA1 calculates a different HMAC. But the MKkey sha1 is the same. I can think that every time the MA is set to a user, a new user SHA1 is created(for the MA use) and is same for all user accounts using this MA in same computer despite the windows version.I can see the date of GUID changes every time is switched.
So much thanks.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/erwan2212/NTHASH-FPC/issues/13, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYPMJPA77C3ZFOVCVK74HTSPSNFNANCNFSM4TUBV2ZA .
Papotito123
Hello: I were kept doing tests with CREDHIST. For the benefit of this post:
So some verified useful info.
To retrieve user CREDHIST hashes history with mimi: mimikatz # dpapi::credhist /in:"C:\Users\username\AppData\Roaming\Microsoft\Protect\CREDHIST" /password:actual_user_password /unprotect
It can be also used with /hash:actual_user_password_SHA1
If the account never had other password and is a MA user(like in my Win 10 2004H1) then output will looks like: mimikatz # dpapi::credhist /in:"D:\Users\username\AppData\Roaming\Microsoft\Protect\CREDHIST" /password:mypassword /unprotect CREDHIST dwVersion : 00000001 - 1 guid : {00000000-xxxx-xxxx-0000-000000000000} dwNextLen : 00000000 - 0
My PROBANDO account is now a MA account user. The CREDHIST hashes history has 7 entry with all different SHA1 because all times I switched the account. From the output I can id ,[entry 7] with user SHA1 of first password set when the user was Local account(first creation)
The [entry 1], can't decrypt actual GUID(dated as November).Also can't decrypt GUID dated in Sept and October(I recovered copies with a Volume Shadow copies tool).
The [entry 2], which indeed is SHA1 of the actual password string when changed from MA account to Local account.But this SHA1 is the one that decrypt actual GUID(dated as November) while user is MA user.
The [entry 3] which can decrypt the GUID dated in Sept and October(I recovered copies with a Volume Shadow copies tool).
Some differences in LinkGUID for CREDHIST. When the guid is in form of : {00000000-xxxx-xxxx-0000-000000000000} ,the SHA1 is more associated when MA account user. When the guid is in form of : {f49xxxxc-486e-4xxx-bd4b-9c33xxxx2b2c} ,the SHA1 is associated when Local account.
As Properties(using CredHistView tool): Hash Algorithm is SHA512 , Encryption Algorithm is AES256 , Iteration Count is 8.000(for most). This tool is in dev stage , so it fails to decrypt most of the entries in MA user.But mimi is suffice. For hives, this tools can be of used, Windows Registry Recovery 3.0.0 from mitec.cz
But wait....there's more ... I have the same MA account being used in my Win 10 2004H1 partition(same name, same password of course). And ...the guid in Win 10 2004H1(dated in October) is decrypted with [entry 3] SHA1, that can decrypt the GUID dated in September and October in my other OS where PROBANDO MA account user resides.
So using a different user SHA1 calculates a different HMAC. But the MKkey sha1 is the same. I can think that every time the MA is set to a user, a new user SHA1 is created(for the MA use) and is same for all user accounts using this MA in same computer despite the windows version.I can see the date of GUID changes every time is switched.
So much thanks.