Did you know that messaging a URL to a colleague can reveal your public IP address—and expose your investigation?
Here’s how to stay covert while sleuthing online.
by Justin Seitz
This article first appeared on the Hunchly blog.
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’s happening behind the scenes. In some cases, this can cause you to disclose 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 instead of just browsing to it.
This subtle change in context is actually an important distinction. You’ll see why shortly.
A Little History
A few years ago, I was on a penetration test, 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 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 still wasn’t much 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, here came 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 set up.
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 onto 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 inadvertently notify your target that you are talking about them. This is exactly how I figured out that the incident response team was wise to me during my penetration test. You most likely don’t want this to happen.
If 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 behaviors outside of general browsing activity which can be observed—to your benefit or detriment.
Test Results from Various Platforms
I did some quick testing of various messaging clients and services. The test was to simply set up 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 set up 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:
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.
Messages was an interesting test that had some pretty unique behaviors. If you post a link from Messages on your desktop/laptop, it will generate the preview directly from your public IP address, as can be expected.
The user agent shows:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.4 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.4 facebookexternalhit/1.1 Facebot Twitterbot/1.0
Pretty interesting that you see the Facebot and Twitterbot pieces in there! This was actually picked up by a Reddit user as well.
Here is where things can get more interesting: If you are sending an SMS phish to a target, you can enhance the URL preview experience a little by ensuring you have a file named:
The Messages app will attempt to retrieve this file once it determines that it can successfully reach the target web page. This file will be used in the preview that is generated and could help to entice your target to click the link. It can also be a way of acknowledging the fact that Messages was the application doing the URL preview in the first place.
Wire is pretty interesting. When you post a URL from the app both on desktop and on your mobile phone, your public IP address will show up in the logs. However, there are no User-Agent headers that show up. In fact the only header that Wire sends is:
So this in itself is interesting because many of your HTTP clients (browsers, crawlers, bots, etc.) will send additional headers. By Wire stomping out all information, this does become a “tell” that perhaps someone is discussing a target site in the Wire application. Further tracking of how often you see this limited set of client headers would have to be done in order to come up with something more statistically relevant than my single observation.
Note that in Wire there is a setting in Preferences -> Options called “Create previews for links you send.” If you disable this it will prevent Wire from doing these URL previews. I recommend you do this. Thanks to Michael Bazzell for assistance with this one.
Facebook also announces itself, but it uses Facebook-owned infrastructure to hit the site for a preview. You will see a User-Agent header of:
User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
It doesn’t use your public IP address but does indicate that someone has posted a link to the target site on their Facebook profile or sent it via Facebook Messenger. The IP address you see will be registered to Facebook, so you can use a site like ipintel.io to look it up.
WhatsApp behaves somewhat differently than the other services. It will not honor IP addresses directly, but if you type in a domain (and any port), it will attempt to do URL previews. Additionally, it will do continuous requests as you type the URL of the target page as well, which generates a lot of traffic.
The User-Agent looks like this:
User-Agent: WhatsApp/0.3.1649 N
The request comes from your public IP address.
Services That Didn’t Generate Previews:
There were some services that didn’t generate any previews or traffic when pasting links or typing URLs. (Of course, you should test this yourself to verify.) Here they are:
- Signal (Desktop/Mobile)
- Skype (Desktop/Mobile)
- Sudo (Mobile)
- Threema (Mobile)
- Twitter DM (Mobile/Web)
- Wickr (Desktop)
All of the mobile testing was done on an iPhone X, so there may be differences with Android that aren’t covered here.
There are probably a ton of other messaging apps out there that you could test, and you absolutely should. Feel free to let me know in the comments. I’ll update this post with your results.
Here are a few things you can do to mitigate the risk of getting “burned”:
1. Defang your URLs .
This is simply the method where you replace the dots and colons with other characters, or use brackets. An example could be:
2. Use a VPN .
This is a secondary suggestion really, as it is isn’t mitigating the original problem. But for the services that are spitting out your public IP address, this will at least obscure it.
I hope these tips help you avoid detection while investigating virtually. Happy hunting, everyone!
About the Author:
Justin Seitz is the co-founder of Dark River Systems Inc., a Canadian security and intelligence company. Justin is a renowned cybersecurity and open-source intelligence practitioner whose work has been featured in Motherboard, Forbes, and other media. Justin has authored two books on developing hacking tools and is the creator of the AutomatingOSINT.com training platform and Hunchly, an open-source intelligence collection tool for investigators. Justin is also a contributor to the citizen journalism site Bellingcat, a member of the International Criminal Court’s Technical Advisory Board, and a Fellow at the Center for Advanced Defense Studies in Washington, DC.