If you’ve been in the security community for even a brief time, or you’ve taking training associated with a certification in this field, you’ve likely encountered the concept of password hashes. The “Reader’s Digest” version of password hashes are that passwords are subject to a one-way cryptographic algorithm for storage, and that same algorithm is applied to passwords that are input, and a comparison is made for authentication. The basic idea is that the password is not stored in its original form.
Now, we ‘see’ password hashes being collected by threat actors all the time; grab a copy of the AD database, or of Registry hives from an endpoint. Or, why bother with hashes, when you can use NPPSpy or enable WDigest?
Or, if you wanted to maintain unauthenticated persistence, you could enable RDP and Sticky Keys.
Okay, so neither of those last two instances involves password hashes, so what if that’s what you were specifically interested in? What if you wanted to get password hashes, or continue to receive password hashes, even across password resets? There are more than a few ways to go about doing this, all of which take advantage of available “functionality”; all you have to do is set up a file or document to attempt to connect to a remote, threat actor-controlled resource.
Collecting hashes is nothing new…check out this InSecure.org article from 1997. Further, hashes can be leaked via an interesting variety of routes and applications; take a look at this Securify article from 2018. Also, consider the approach presented in ACE Responder’s tweet regarding modifying Remote Desktop Client .rdp files.
One means of enabling hash leaks across password resets is to modify the iconfilename field in specifically placed LNK/Windows shortcut files, which is similar to what is described in This article has been indexed from Windows Incident Response