We must bear in mind that Windows File Explorer always tries to render the icon of any existing resource within a given location ( i.e. a directory )
Every resource has its own icon, whose location is specified within it
<SNIP>iconFile=<ICON_FILE_PATH><SNIP>
For instance, if we compromises a principal that has WRITE permissions over a certain SMB share, we could try to place a shortcut file within the latter whose iconFile points to a remote SMB server controlled by the attacker
So, when any user accesses the share location where the shortcut file has been placed using the Windows File Explorer, the latter will try to start an SMB session to the target in order to request this resource i.e. the shortcutβs iconFile
Then, it will be asked for authentication, so we will receive an incoming authentication that we can leverage to either relay it to another host or try to crack the Net-NTLMv2 response
Any shortcut file we create should start with the @ character to ensure that it appears on top of the share, and, hence, the file explorer parses it
Requirements
The controlled local/domain user account must have WRITE permissions over a location within an SMB share
Abuse
Verifying if the user account has write permissions over the share