Capturing Authentication from Out of the Office

Get me out of this subnet.

Recently my co-worker and I had an internal assessment where the client plopped our remote device into a subnet with no other hosts except the router. A huge part of internal assessments is capturing NTLM authentication from users and either trying to crack or relay the authentication. Assessments where the tester cannot capture authentication are extremely painful, and often leave the tester no choice but to wave the white flag of surrender.

I am not certain, but my guess is the client did not have other hosts in my subnet because their employees were working from home. We were working remotely, so surely their employees were too, right? In this case, employees were probably using a VPN to connect to the work network. VPN technology typically segments hosts into their own VLAN's, preventing their devices from talking directly to other VPN devices, and preventing us from using our favorite subnet-only poisoning tools.

We "compromised" a printer on the network with default credentials and reconfigured scan-to-folder authentication to our device. When someone tried to scan a document, the printer sent it's credentials to us, and we owned the low-privileged printer account. With this user access we did our regular domain checks: look for misconfigured Active Directory groups, writeable web roots or passwords in shares, misconfigured MSSQL servers, etc. No luck on any of these, but there were many file shares which were configured to give our printer account read-write permissions...

If you're reading this, it's too late.

Last winter I wrote a tool in Powershell I named Invoke-LinkSpray. The concept is not new, and I have to give credit to Mubix for the original research and my co-worker for showing the concept to me.

The idea is this: Windows shortcut files (.LNK or .URL) have icons. These icons can be loaded from SMB or WebDAV shares. When windows accesses these kind of shares, it attempts to automatically authenticate with the current user's credentials. This is a Microsoft feature, not a security issue, according to them at least. Lastly, the icons in a shortcut file are loaded whenever a user opens a folder with one of these shortcuts in it. That's right: a user only has to look at a shortcut to trigger an authentication attempt.

Imagine for a moment you are a normal office employee. You have things to get done -- documents to read, emails to check, and presentations to create. You open up the company-wide file share to grab a document your co-worker sent you. Unbeknownst to you, someone dropped a malicious shortcut in your company's file share, and when you scroll past it, your Windows computer dutifully tries to use your domain credentials to authenticate to the share hosting the icon. You probably don't notice anything strange, with the exception of the "weird file" you haven't seen before, but you have things to do, and don't give it a second thought.

Our beloved attacker, after placing a malicious shortcut on the network, will be listening for authentication using capture or relay tools such as Responder or Ntlmrelayx.

While it might be relatively rare that a user finds the right file share and folder with a single malicious shortcut in it, we can greatly increase these odds by creating as many shortcuts in as many different file shares and folders as we can. Tools already exist to create a single malicious shortcut, but in my research I could not find a tool that would create links en masse like I wanted to. Invoke-LinkSpray is my tool to create SMB and WebDAV links on an enterprise scale -- and as a gift to my clients, clean them up after I'm done with the assessment.

Please don't delete my links.

After exhausting other options, I excitedly suggested to my co-worker we use the Powershell script I wrote. With a list of read-write file shares gathered from CrackMapExec, we sprayed links on every file share we could -- around 500 links in total.

Shortly after, I got an email from my client contact proudly announcing they had found files I created, and that some of their co-workers had deleted other links they found. A while later, we caught and relayed authentication from a Domain Admin, which I choose to believe came from IT trying to delete the links placed on file shares.

Relayed Domain Admin authentication let us take control of a server which did not have SMB signing. We used the relayed session to extract password hashes for local accounts. The local admin account password was shared between a few other servers, including one that had a different Domain Admin logged in. Using built-in Windows tools, we created a memory dump of the lsass.exe process and extracted the Domain Admin's credentials from the dump file. I was ecstatic to take over on a client I didn't think we would be able to -- even better using a tool I wrote.

Here is what the tool looks like in my lab:

Believe in the me that believes in you.

I will be the first to admit nothing in this blog is original or novel in any way. Ideas were taken from other people, code written from StackExchange, and even as a finished product, Invoke-LinkSpray exists as middleware between CrackMapExec's share function and NTLM relay/capture tools. I struggled writing this relatively simple Powershell code, but want to document it for myself and other junior security professionals as they start in this industry. Proficiency takes time, and making something derivative is the first step to creating something amazing.