Since the first successful phishing attack, we have trained our email users to read every URL before clicking.
Microsoft’s Advanced Threat Protection (ATP) included a feature called Safe Links that worked against this. Previously, Safe Links obscured the original URL with a rewritten link, belying decades of user education efforts by hiding the visual clues end-users need to identify phishing and other exploits.
A year ago, Microsoft improved Safe Links by adding Native Link Rendering in the Office Web Application (OWA). Now, end users can read the original link. This allows them to make a more informed decision to click. But, is this Safe Links update safe?
When someone clicks on a URL in an email, Safe Links immediately checks the URL to see if it malicious or safe before rendering the webpage in the user’s browser.
Safe Links checks if that destination domain is not on either Microsoft's Block List or a custom Block List created by the organization. If the URL leads to an attachment, the attachment will be scanned by Microsoft for malware.
If the URL is identified as insecure, the user is taken to a page displaying a warning message asking them if they wish to continue to the unsafe destination.
Formerly, Safe Links replaced the URLs in an incoming email with URLs (*.outlook.com) that allow Microsoft to scan the original link for anything suspicious and redirect the user only after it is cleared.
For example, an email containing a link to www.avanan.com, was replaced with: na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.avanan.com
Safe Links made it impossible for the end user to know where the link was going. The link is rewritten as an extremely dense redirect, making it difficult to parse.
Here's an example from real life—look at the two links below and attempt to discern which leads to the real UPS site and which is from a fake phishing attack.
The second link points to a malicious site at webtracking.email.
Additionally, end users were more likely to login to fake Office 365 pages if the domain reads outlook.com. Diligent users who checked where the link led to would see a URL in "*.outlook.com", a Microsoft registered domain name. End users are more likely to enter their credentials into a page that appears to be hosted on a known Microsoft domain.
Previously, SafeLinks cluttered email appearance with rewritten URLs that were illegible. Customers also argued that it is easier to recognize an original bad link than deal with the aftermath of a failed SafeLink.
With this landmark update, the end user can now see the original URL in a window when they hover over the hyperlink. The rewritten URL only appears at the bottom, confirming that Microsoft has still wrapped the link in the back end for analysis.
Enhancing the SafeLinks experience with Native Link Rendering supports efforts to educate end users, and improves overall security posture by giving individuals more information to make decisions.
Although Safe Links is a seemingly logical method of combating phishing, it has major shortcomings that end up making your email less secured from phishing attacks.
Native Link Rendering is unavailable in the Outlook client, which is installed on desktop and mobile devices. This update only runs in Outlook on the Web (OWA) For the large number of organizations using both OWA and the Outlook client, this might cause some confusion among end users.
Safe Links does not offer dynamic URL scanning to evaluate the link for threats on a case-by-case basis. At time-of-click, Safe Links only verifies if the URL is on known Block Lists of malicious sites. This means that ATP struggles to detect zero-day, unknown URLs.
When Safe Links identifies a malicious URL, it does not generate an alert to notify admin of instances of the same link in other user mailboxes. In order to purge malicious URLs from a phishing campaign affecting the organization, admin must run a query and remove the threats via PowerShell.
As mentioned above, Microsoft follows links to determine their risk before allowing the user to navigate to them.
Microsoft follows the Safe Links from special IP addresses that are easily distinguished from end user requests. The hackers created and shared their own Microsoft IP's Block List with those IP addresses here.
So, when the request is coming from a Microsoft IP, it is redirected to a benign page and Microsoft's ATP clears it. But then it redirects the user straight to the malicious URL.
Another weakness of the Safe Links scan is that it doesn’t apply Safe Links to domains that are whitelisted by Microsoft. Popular sites like Google.com are given a pass.
This might sound reasonable, but it opens the door for another common trick named "Open Redirect". For example, this link will not be changed by Office 365 Safe Link since Google search is whitelisted.
https://www.google.com/url?sa=D&q=https://www.evilsite.com
Google will also not check this link for malicious content — they never claim to — and the end-user will be redirected to the malicious site.
Here's a recent phishing attack that used this trick: SiteCloak: Hackers Take Phish Obfuscation to the Next Level.
And here's another example, with the TattleToken Script:
When Safe Links used to rewrite URLs, it created a false sense of security that misled users, and undermined efforts to encourage people to inspect URLs for misspellings or other suspicious indicators. Now that Safe Links leverages Native Link Rendering to preserve the original URL for the end user, Safe Links deserves the name. However, there are still some obscure workarounds that hackers can employ to interfere with the protection available in Microsoft ATP.