URL Rewriting, a service used to sandbox and defang malicious URLs by sending users to a portal that displays the URL in the sandboxed environment, has many well-known weaknesses and a few that may not be obvious.

This article aims to identify these weaknesses and offer our thoughts on a different strategic approach for email security. We will cover how URL Rewriting services can undermine a defense-in-depth strategy, limit security culture development, fail technically, and give a false sense of security when dealing with Business Email Compromise (BEC) attacks.

Four Reasons URL Rewriting Doesn’t Work for Email Security

Limits Defense-In-Depth Strategy

The action of rewriting a URL can undermine a defense-in-depth strategy. When downstream systems want to analyze a rewritten URL, they need to either follow or deconstruct the rewritten URL. These capabilities are not typically built into most tools because of the large development effort needed to account for the volume of tools rewriting URLs in the market and the complexity of configurations that can be uniquely applied when implemented by an administrator.

As a result, when a URL has been rewritten, other systems are unlikely to be able to scan the URL. Organizations increase their risk because systems can malfunction or be defeated by a well-crafted sandbox escape. Added layers of defense that may compensate for a technical failure will not be able to supplement URL scanning, and defense-in-depth principles will be undermined.

For example, when accessing a rewritten URL from a server that identifies the URL Rewriting Service an attacker may present a different page than when coming from other IP addresses or origins. Attackers also utilize this information to customize attacks by utilizing company logos and names of the URL Rewriting Service on the malicious landing page. This gives attackers more resources to craft a more effective attack. Instead, we can remove this malicious content altogether and not have the user exposed in the first place.

Removes the user from participating in the security awareness culture

“Hover on your links before you click!” is typical education provided to end users when building a security culture.

When URLs are being rewritten, your users cannot tell the destination of the URL to determine if it is safe to click. Removing this type of training pushes users away from culture and investment made in creating security awareness.

Configuration Drift

Vendors do not always rewrite all URLs for various vendor-specific reasons. These missed rewrites can happen because the administrator could have configured an exclusion due to a certain business process, or vendors may bypass the sandboxing for sites like Google Drive, or SharePoint Online.

The missed rewrites are problematic because they create gaps in the attack surface that can be exploited. Attackers are now using blob storages and common enterprise file transfer services more to deliver their malicious payloads due to the failures of URL rewriting technology.

The administrator is often unaware that their solution has these exclusions until we report our findings as part of a Proof of Value (POV) exercise. Clients learn that the URL rewriting and sandboxing has only partially fulfilled its promise of security.

A significant administrative effort and attack surface analysis does not yield a strong, reliable security service. The URL Rewriting technology can potentially be exploited and take away a security professional’s time. This resource investment could be better allocated to more reliable security capabilities rather than the appearance of security through URL Rewriting, which fails too often in our experience.

The payload is the language itself (BEC)

Business Email Compromise (BEC) is probably the most significant failure of URL rewriting. BEC attacks are usually a social attack or an attack directed toward a business process, and not a file or attachment exploit. URL rewriting within BEC attacks provides the appearance of security to the user.

The appearance of security gives an attacker more validity in the user’s mind because the BEC attack is typically shown to be scanned by the official company security service. The BEC message wasn’t blocked because no malicious code was present, but the user may not understand these subtle details.

URL Rewriting is of little value in this situation because URL Rewriting may not be a service running on their machines. The BEC threat will generally operate unencumbered and appear the same to a user whether or not a URL Rewriting service has sandboxed a URL. For example, let’s assume a URL takes a user to a phony page that purports to be a “Secure Encrypted Message Center.” The content of this fake site usually instructs a user how to change their direct deposit information OR instructs them how to update an important bank wiring. URL Rewriting scanning in this situation makes this site more believable to the victim. The message’s subject contains sensitive information, so accessing via a special “Message Center” is common, and a URL Rewriting service sandboxed the URL and showed users the attack in an assumed secure environment. A company inadvertently opens itself to an attack in this situation, and the security service further helps the attacker appear more genuine than they would if no URL Rewriting took place.

A Different Approach To URL Rewriting

If you rewrite URLs today, are you okay with telling your users that any rewritten links are safe to click on? If not, how should they protect themselves from URL threats when they can’t see where they go and are presented to them in a trusted environment?

A better approach would be to:

• Continually rescan even if the first scan shows no indicators of compromise
• Analyze the content (URLs & attachments), AND the intent of the message
• Treat the entire message as malicious and remove it from the environment in its entirety if anything is found to be malicious