Updated lockpicker to force loading UNC for NLTMv2 auth #311
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change drastically increases the success rate for getting NTLMv2 hashes. The gist of it is, the img file I added contains a single windows shortcut (.lnk) file with an icon pointing at \172.0.6.1\Share. Windows attempts to load this icon from the network share at \172.0.6.1, and in the process will authenticate using the default credentials of the current user to render the icon. Windows will do this whenever it sees one of these files. It will also generally open a folder when a new mass storage device is attached, causing it to render icons for all files within a folder. This will happen even if the screen is still locked.
These two "features" allow for forcing NTLMv2 authentication, which means responder will get a hash much more quickly and more frequently. This also seems to work for most modern versions of windows, versus the existing method, which only works reliably for older versions.
You can find some more details here: https://dylankatz.com/NTLM-Hashes-Microsoft's-Ancient-Design-Flaw/