Join GitHub today
Support Keepass Windows User Account #1437
Hashcat can currently crack KeePass .kdb and .kdbx files with/without keyfile but there is not support for Windows User Account. This option is readily available to users of KeePass but not supported by Hashcat. Could Hashcat please add support for this feature.
I did some very quick research on this (I hope that everything mentioned below is correct, feel free to independently verify it and correct me):
The main setting file of keepass (.xml) stores this setting as
Some information about WUA is also mentioned here https://keepass.info/help/base/keys.html#winuser and there you can find links to https://sourceforge.net/p/keepass/wiki/Recover%20Windows%20User%20Account%20Credentials/
The concept of this protected data is also known as the Data Protection application programming interface (DPAPI).
Windows saves the WUA Master Key(s) here:
where %APPDATA% is just
The keepass specific ProtectedData (DPAPI) blob is stored in this file:
If we look at the keepass source code, we can find a KeePassLib/Keys/KcpUserAccount.cs file that is responsible to write and read the ProtectedUserKey.bin.
My conclusion is that what we need to do to add support for it is to have the 64-bytes of data from ProtectedData.Unprotect () somewhere within the hash (or command line option). These 64 bytes need to be appended to the sha256 ($pass) + keyfile (optional)
btw: there seems to be also a new jtr issue with the same request of implementing this WUA feature: see magnumripper/JohnTheRipper#2863
update: I was interested enough to give this seemingly minor modification that needs to be done a try and here are some more info and code:
I generateted a new Keepass Database (with newest Keepass 2.37, but the version shouldn't matter to much for now, it just should be at least 2.x I think).
I've used this code to convert it to the unprotected version:
I compiled it like this:
Note: this program needs to be run on the correct windows computer where the DPAPI master key file etc is used to unprotect the content. Also note that DataIn.pbData could easily be read from a file (I just didn't bother too much to add the code for opening/reading the file for now). Furthermore, entropy.pbData seems to be constant/static and doesn't need to be changed. The user only needs to modify DataIn.pbData (or someone could add the code to read these bytes from the ProtectedUserKey.bin file).
Running the protected_data_unprotect.exe program yielded this for me (this of course also depends on your data and windows account, it's different from you, but the length should be always 64):
This seems to be all what we need, i.e. the additional 64 bytes (unprotected version of the bytes from ProtectedUserKey.bin).
I tested to crack my database with keepass2john + hashcat.
The current patch (that was successfully applied to this version fddb66e) is:
there are a couple of todos for now:
for now this is just a POC and those TODOs need to be implemented by choosing a new hash format and implementing the modified parser (and passing the data to the GPU)
I have these 2 hashes for you to test (I used keepass2john to convert the databases, both Databases used the same ProtectedUserKey.bin and therefore my patch with the currently hard-coded 64-bytes work for both):
both crack perfectly fine.
This means it's actually very easy to add support for it.
The only bummers for now are:
referenced this issue
Nov 10, 2017
Here is a slightly modified version of the extraction c++ file that uses the %APPDATA% environment variable and reads the file ProtectedUserKey.bin directly (using stat/fopen/fread/fclose):
Hi there, I have quickly read what you did and nice job @philsmd!
I think that to make any progress here we need to ask @magnumripper / @kholia (and also CC: @Fist0urs ) what we should do about the hash format changes that are needed and what they plan to do to support this in jtr etc.
The algorithm and kernel/code modification should be clear from the examples above. The extraction of the 64 bytes should also be no problem with the code provided above. It's now just a matter of when/if this will be supported also by keepass2john and if so are there several different types of hashes or just one hash format that contains the 64 bytes (or not if wua is not used etc).
This jtr issue might be good to follow too since it might be re-opened in the future (we will see): magnumripper/JohnTheRipper#2555
@philsmd I haven't looked closely at this stuff recently. Can we treat this 64 bytes of "CryptUnprotectData" data like a keyfile? If a keyfile is being used, can we simply append this 64 bytes of data to that keyfile data? If these hacks are not possible at all, we can bump the
I have opened the corresponding JtR issue now. Patches for
yes we could just add the 64 bytes.
so maybe we should add an additional field at the end (always or just when wua is being used).
In theory we could differentiate if the additional data is for keyfile or for wua just depending on the length (keyfile are always 32 bytes, while wua always uses 64 bytes).
An additional question is, does keepass2john plan to add both support for:
I think both cases would somehow make sense because without case number 2 the user might not know how to extract the data (if he didn't read the steps/examples above).
Yes, I think support for both cases (manual specification of "wua" bytes, automatic extraction of those bytes) would be needed.
Yes, we already build JtR Jumbo with MinGW for Windows users. So adding this automatic extraction code (within some
I just realized I didn't answer your question about the additional 64 bytes and if they can be seen as a longer keyfile. Yes this is absolutely true! We could think about it like this if we consider the cases above:
So in theory for the crackers it doesn't matter if the additional data comes from a keyfile of from wua. The crackers just need to support 0 to 96 bytes (at the time of writing this, maybe this will be increased in the future, but I don't think anytime soon), possible values are 0, 32, 64 or 96 bytes for the additional data.
can i manage to reopen my database following any abovementioned method ?
or is any of the prerequesites to still be under the initial Windows installation where the database was created ?
Windows offers a way to "migrate" between profiles that use DPAPI. Unfortunately at some point you will always have to rely on the masterkeys (usually in C:\Users<username>\AppData\Roaming\Microsoft\Protect<SID>, ) so if you've erased/overwritten it it will be quite complicated not to say impossible...
Anw take a look at this blogpost from @HarmJ0y if you want to have a better understanding.
@Fist0urs thanks for your answer !