Windows stores the (NTLM) hashes of local users' passwords in the SAM hive. By booting from a live system (for example), one can not only extract those hashes for offline cracking, but also simply replace the hash with that of a known password (for example, chntpw in Kali Linux is a tool that excels at this task). Similarly, one can turn a normal user into an admin user and enable/disable users. So far, so good.

In a similar, yet different fashion, the password hashes of domain accounts of users that have previously logged in on the computer are stored in the SECURITY hive so that a user can re-login even when they are off the network. Tools like cachedump can extract those hashes for offline cracking. However, due to the different hashing algorithm used, most (all?) tools that can replace hashes in SAM cannot do the same in SECURITY.

Now my question: Is it possible to replace the cached password hash of a domain user with that of a known password, in order to then reboot the system and log in with the known password (bonus points for answers specific to Windows 10, in case there are differences to previous versions)? This of course assumes that the device is off the network so Windows cannot check the password online with the Domain Controller.

  • 1
    @J.A.K. This question is very specifically (and explicitly) not about SAM, but about SECURITY (i.e., about domain users, not local users). I fail to see how this could possibly be a duplicate.
    – TheWolf
    Apr 5, 2018 at 10:14
  • 1
    Ah my bad, I read over that, here's an upvote. It looks like mimikatz's (badly documented) lsadump::cache has the functionality you seek. Have a look at cqureacademy.com/blog/windows-internals/…
    – J.A.K.
    Apr 5, 2018 at 10:19
  • 2
    @TomK. this is exactly what J.A.K. suggested before, and it's still not correct. This question is not about SAM, it's about SECURITY.
    – TheWolf
    Apr 5, 2018 at 10:51
  • 1
    @J.A.K. thanks for the link, that looks very interesting! Do you know whether this functionality is included in stock mimikatz too? Just because they're using their own variant of it...
    – TheWolf
    Apr 5, 2018 at 10:52
  • 2
    @TheWolf the /kiwi switch does work with the latest available release, but you may have to also specify the /user switch. See my answer below.
    – hft
    May 9, 2018 at 20:45

3 Answers 3


Now my question: Is it possible to replace the cached password hash of a domain > user with that of a known password, in order to then reboot the system and log > in with the known password

Yes, this is possible with the latest version of mimikatz (available on the releases page of gentilkiwi/mimikatz github account).

However, I have found that in order to use this functionality on a system with multiple domain users you may actually have to specify two arguments (the username and the kiwi flag)

# lsadump::cache /user:<username> /kiwi

After running this command the cached domain credentials will be replaced with the default mimikatz password (which is "mimikatz")! If you prefer to set a password other than "mimikatz" use the command:

# lsadump::cache /user:<username> /password:<password-to-set> /kiwi
  • 1
    Thanks so much for sharing the still-undocumented /kiwi switch, @hft - very handy! As app data secured by DPAPI (EFS, Outlook, Chrome, etc) remains inaccessible after the modification, it may be worth attempting to recover the password before replacing it. I've assembled a brief guide to the process here. Jan 30, 2019 at 19:04

i think it maybe much easier if you just reset local admin password with some kind NTPASSWORD reset tool ( of course you need to boot up from USB into winpe environment first)


Windows doesn't cache the entire hash of a domain login. Per Windows Internals, Part 1, 6th Edition:

Note MSV1_0 does not cache a user’s entire password hash in the registry because that would enable someone with physical access to the system to easily compromise a user’s domain account and gain access to encrypted files and to network resources the user is authorized to access. Instead, it caches half of the hash. The cached half-hash is sufficient to verify that a user’s password is correct, but it isn’t sufficient to gain access to EFS keys and to authenticate as the user on a domain because these actions require the full hash. ref: page 559

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.