URL Link Rewriting is a technique used by several email security companies to help in the fight against malicious links in emails. Proofpoint's Targeted Attack Protection (TAP), Mimecast's URL Protect, and Microsoft's Safe Links all use similar forms of URL rewriting in their email filters. Many of our own anti-phishing tools offer the same Safe Link feature.
What is a URL Link Rewrite?
URL Link Rewriting is a technique used by several email security companies to detect malicious links in emails. Proofpoint's Targeted Attack Protection (TAP), Mimecast's URL Protect, and Microsoft's SafeLinks all use similar forms of URL rewriting in their email filters. Many of our own anti-phishing tools offer the same 'SafeLink' feature.
When a new email includes a URL, the link is rewritten on the fly to add a prefix to the original web address. For example, in the case of Proofpoint's Targeted Attack Protection:
The rewritten URL-encodes the original URL "http-3A__amazon.com" into a link that will redirect the user to Proofpoint's own servers urldefense.proofpoint.com with some unique codes to track the individual user and their clicks.
The primary purpose of SafeLink-type URL rewriting is to (hopefully) catch malicious URLs that a mail filter might have missed when a filter first scanned an email. For example, if website www.perfectlyfine.com is believed to be safe when it is seen in a new email, but is compromised a few hours or even a few days later, the system can prevent the user from reaching the site because they are first redirected the prefix URL.
Because this is such a common anti-phishing tool, our customers typically ask whether or not they should enable it for their Office 365 or G Suite accounts.
Surprisingly, we typically recommend that they don't. Here's why.
The Overpromise of SafeLinks
Marketing pitches of some email security vendors imply that they are going to perform active link analysis or URL emulation when each email arrives and will know what to block later when the user clicks. As an example, Proofpoint's TAP promotes "Our unique predictive analysis preemptively identifies and sandboxes suspicious URLs". Unfortunately, in most cases, a given URL is not scanned until the first person clicks it.
Here's a typical scenarios as it plays out in the lab.
Test 1: A zero-day phishing link through an anti-phishing applicance.
In this case, the a zero-day link is sent through an appliance while we monitor outbound traffic. The URL is rewritten and passed to the inbox, but no traffic is generated to the URL. It is assumed that the URL was checked against a known list of bad websites, but no active emulation of this zero-day URL was taking place at the time of the first scan.
After 10 minutes, when the URL is clicked for the first time, the link is deemed safe and the user is redirected to the malicious site. Only upon this first click do we traffic from the appliance reaching out to the URL for emulation.
A few minutes later, when the URL is clicked again, it is blocked by the redirect engine.
While this might be beneficial if you are not the first person to click on a given link, more phishing attacks are using customized emails to target specific recipients at an organization.
Test 2: Same process, but waiting 24 hours before clicking the 'safe' link.
The result of this test was exactly the same as the first. There was no outbound request to the malicious site between the incoming email and the first click and the first person to click the zero-day URL was redirected to the malicious site. (Actually, it was anyone who clicked within a few minutes of the original click—between the time the emulation started and when the site was deemed malicious.)
We really did not need to perform this test, because most URL 'Safe' Link systems are designed in this way. For reasons of scalability and email throughput, it is easier to separate the email scanning and emulation processes and only test those links that people actually click on.
Both the inbound filter and the redirect server rely on static filters in order to provide near-instant response times. Because the emulation engine can take time, it is used to scan the unknown URLs and use the results of those scans to populate the static lists of the inbound and redirect filters. Unless a URL has been tested and known to be malicious, the user is redirected. Until the emulator has tested the link and updated the Static List, unknown URLs are considered OK.
The downside of replacing the URLs with a Safe Link is the false sense of security it provides to the end-users. While the process may be well understood by the IT team, the impression of most users is that any 'Safe' Link has been positively tested to be safe. It sounds safe to click on a Safe Link.
This can actually have side effect of making your users even more likely to click on a link. For example, because the SafeLink URL looks like a legitimate Microsoft URL, even the savviest users, who might mouse-over and analyze a URL before clicking, might follow a link that redirects to a fake Office 365 login page.
No matter the vendor—Microsoft, Proofpoint, or Mimecast—every system like SafeLinks can be confusing and undo years of email safety training.
The most common reason that companies choose to not deploy Safe Link-type systems is the fact that users often rebel within the first days. It makes email ugly. it can even make it unreadable. For corporations that have invested in regular security training, for example by sending regular PhishMe or KnowBe4 emails to all of their employees, it has undone years of user education.
"If you've trained your users to look at links to determine whether they might be mailicious (as we have through KnowBe4 training), link rewrites make that training useless. The average user has a hard time deciphering a Proofpoint link. Heck, I'm the CTO and I have a hard time figuring out anything past the real domain it points to."
— Security-savvy CTO who wishes to remain anonymous
For all of these reasons that we do not recommend to not use URL rewriting systems, why do we offer them?
The best use of 'safelinks' is for the post-mortem. When they find a phishing attack was missed or worse, that someone's account was compromised, the IT security team wants to know all the emails that included a particular email and all the users that clicked on them. Replacing the link with a trackable URL allows them to perform this post-attack analysis and determine their exposure.
Summary: What Should You Do?
Replacing the email URLs does not provide much phishing prevention value because it uses static filters to prevent your end-users from going to bad links. It does, however, provide an indication to know who clicked a link if you need to perform a postmortem of an attack. While a benefit, the downsides of most URL rewrite systems outweigh the link-tracking benefits.
While some Avanan partners offer URL-rewrite systems, we typically turn this feature off by default. When customers ask if they should enable it, we typically tell them no.