8

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.

TheWolf
  • 1,069
  • 7
  • 12
  • 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 05 '18 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 https://cqureacademy.com/blog/windows-internals/cached-credentials-important-facts – J.A.K. Apr 05 '18 at 10:19
  • Possible duplicate of [Inject hash into sam file. Is possible?](https://security.stackexchange.com/questions/162658/inject-hash-into-sam-file-is-possible) – Tom K. Apr 05 '18 at 10:49
  • 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 05 '18 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 05 '18 at 10:52
  • @TheWolf Could you elaborate (shortly) on the difference that makes, because I at least do not understand it. Then others won't make the same mistake (if it is one ;). – Tom K. Apr 05 '18 at 10:56
  • 1
    @TomK. (underlying reason) SECURITY stores password hashes in a very different format than SAM. (practical, derived from first) Tools that are able to work on SAM usually are not able to work on SECURITY. – TheWolf Apr 05 '18 at 11:00
  • 1
    Alright, you are welcome to edit this into your question. I checked this (briefly) and retracted my close vote. – Tom K. Apr 05 '18 at 11:02
  • @TheWolf I have not tested it myself, but to me it looks like the lsadump::cache was fully integrated in stock Mimikatz from v2.1.1 onward – J.A.K. Apr 05 '18 at 11:55
  • 1
    @J.A.K. lsadump::cache is included, but the "/kiwi" switch does not seem to be :-/ – TheWolf Apr 05 '18 at 12:04
  • 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 09 '18 at 20:45

3 Answers3

5

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
hft
  • 4,910
  • 17
  • 32
  • 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](https://tinyapps.org/docs/domain-cached-credentials.html). – Miles Wolbe Jan 30 '19 at 19:04
0

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)

ikel
  • 129
  • 1
  • 2
0

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

phbits
  • 1,002
  • 2
  • 5
  • 12