How To Blow Your Online Cover With URL Previews

Published: January 2, 2019

Updated: January 5, 2019 — Additional testing was performed against Skype that revealed that URL previews were still working. My initial testing methodology just didn’t determine the right circumstances under which it generated previews. Please see the Skype section below. Updates to the Slack section to include a mitigation has been added as well.





URL previews are a nice feature found in most messaging applications. They allow you to paste a URL to a friend or colleague, and have a handy miniature view of the website you are about to view.

The downside is that a lot of applications generate these previews without you knowing what is happening behind the scenes. In some cases this can equate to you disclosing your public IP address in a manner that you likely wouldn’t want.

Don’t forget: when you browse to a website your public IP address is exposed. This is just how the Internet works unless you’re using Tor or a VPN to hide it.

The difference with URL previews in messaging applications is that you are broadcasting to the website owner that you are discussing the website, as opposed to just browsing to it.

This small and subtle change in context is actually quite an important distinction. You’ll see why very shortly…

A Little History





A few years ago I was on a penetration test where I was attempting to spearphish executives at a well known corporation in Europe. They had one of the most brilliant CISOs I had ever met and an absolutely amazing incident response team on staff.

After I sent the initial round of phishing emails I was monitoring my command and control server to look for connections from users, anti-virus, or anything else that might indicate that I was either having some success or was about to be caught.

After a few hours there was not a lot of activity until my web server received a connection from an IP address that resolved back to Skype. This was a WTF moment for me since my phishing server was brand new and there didn’t seem to be a good reason why a Skype server would be touching it.

A few minutes later another hit from a different Skype server. Now I was really wondering what was going on.

Then it dawned on me. Someone was discussing my command and control system during a Skype chat, and Skype was generating previews of the phishing site I had setup.

I performed a couple of quick tests using my own Skype account, and sure enough, I could reproduce the issue easily. I now knew that the incident response team was on to me, and that it was time to switch tactics.

But this also raised a much larger issue in my mind when it came to online investigations, incident response and running covert online operations.

How Does This Apply to Online Investigations?





There are two viewpoints here: one is from an investigative standpoint and the second is from the standpoint of you running a covert operation through a website.

From the investigative standpoint, if you are passing URLs back and forth with a fellow investigator you may end up notifying your target that you are talking about them. This is exactly how I figured out that the incident response team was on to me during my penetration test. You likely don’t want this to happen.

The second standpoint is where you are running a website for a covert online operation. You can monitor for these URL previews and determine that someone is discussing your site, potentially letting you know that your ruse is working or that you might be caught out (again, context is important and mission-dependent here).

Either way, it is a unique set of behaviours that can be observed that is not general browsing activity.

Test Results from Various Platforms





I did some quick testing of various messaging clients and services. The test was to simply setup a Python web server on a Digital Ocean droplet ($5/month plan is sufficient). The Python web server just printed out the IP address and headers of the connecting client.

I also setup a DNS record specific for this testing so that I could try using IP addresses vs. domain names. WhatsApp was the only service tested that responded differently for IP addresses vs. domain names. Every other service was happy to generate previews for an IP address. There was also no difference between using an HTTP vs. HTTPS URL.

Here is a summary of findings:





Slack

We, like many other companies, live on Slack so this was the first test I performed. Slack was happy to generate URL previews and identified itself with the following User-Agent:

User-Agent: Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)

The IP address of the request was from my publicly facing IP address through my office connection in both mobile and desktop versions of Slack.

Update: You can disable previews in Slack by going to Preferences -> Messages & Media -> Inline Media and Links. Uncheck the “Show text previews of linked websites.”

Thanks to Ahmed Eissa for pointing this out.