Executive Summary

Conversations and feedback from partners and prospects about two email protection methods are interesting to discuss from a practical and philosophical perspective. Link detonation and sandboxing are terms we hear when evaluating phishing protection, and sometimes in comparison to other email security competitors that promote such features.

These techniques are not new. Understanding their application and impact is critical to planning technical security controls for a client's network environment. Mailprotector looks at the email security layer from the partners', users', and attackers' viewpoints to focus on the most effective, yet easy to use, email security solutions.

Link detonation protection and sandboxing are methods with merits but have drawbacks when implemented at the email security gateway layer. Just because you can add a function to a security layer, doesn't mean you should, without thoroughly looking at your security capabilities. Protecting users and their environments requires a layered approach that includes user education.

The merits and drawbacks drive much of the decision regarding Mailprotector's philosophy on these two methods of protection.

• Link detonation and sandboxing can identify threats at execution and possibly catch "zero-day" attacks
• The methods are resource and time-intensive causing significant delays to email delivery, which creates a negative impact to the user experience
• Past experience and testing at Mailprotector has shown little success in real protection and relatively high false positive rates
• Employing URL and domain reputation checks, signature-based scans, and algorithms evaluating malicious behavior have proven effective, while also quick and scalable to maintain email experience expectations
• Sandbox and link detonations at the email security gateway can be evaded rather easily by motivated attackers
• The merits of the two methods are typically better applied at other layers of the security stack such as DNS, next-generation firewalls, and end-point protection applications which also reduce the risk of having "all your eggs in one basket"
• Regardless of the effort put into email and network security, the 0.1% of attacks that make it through protections are enough to keep attackers paid and motivated
• Phishing attacks are often misplaced as reasons to include these protections when the attack rarely contains a payload because it is typically a social engineering attempt

Defining the Tool

Link detonation protections, sometimes called sandboxing, are a collection of tools intended to prevent threats from URL links and attached files from succeeding. These tools go by many names, but often a slight variation of similar ideas from vendor to vendor.

The goal is to protect a user and network from the threats delivered through URLs and file attachments. These protections' effectiveness will vary depending on where the tool is deployed and how it interacts with the users' experience.

An isolated test environment is created, hence the term "sandbox," to "detonate" a file or URL. This technique's stated benefit is the prevention of new "zero-day" threats, but this protection's reality is more complicated than that.

Deploying

Sandboxing can be deployed at various layers of network and application security. Implementing from a cloud solution for web or email gateways, perimeter firewalls for local networks, and even closer to end-points with advanced anti-virus and anti-malware solutions.

For our purposes, we'll focus on the concept of link protection and sandboxing for email security.

Email-based Protection

There is almost unanimous agreement that most threats originate with email since it is a universal tool we use for communication and other digital processes. It seems natural to think that deploying link detonation and sandboxing at the email gateway is the best way to go. Stopping the risk at the door saves you from having to deal with the consequences of threats later on.

On the surface, the methodology is sound. Looking at details, the picture isn't so clear.

A Little Background for the Sandboxing Need

Users can get a lot of emails. Some users get enormous amounts of email, and processing all that information can feel like a job in itself. Many users interact with an email quickly and without much care for the what, where, and how a message arrived.

This is what phishing emails bank on. The various phishing methods are the social engineering attack that keeps everyone in the know up at night.

Many organizations have started to implement SPF, DKIM, and DMARC records to help combat phishing attacks. These have to be configured correctly, and they aren't enough to provide a solid solution. Additional techniques that include the content of known malicious emails, links with negative reputations, attachments with known malicious payloads or signatures, and attempts to identify sender domains' permutations are some that round out the security. And still, that's not enough.

Enter link detonation and sandboxing. When in doubt, put the link or file in a safe container and see what happens. Does it just sit there, or does it go boom?

Specific Methods

Link detonation and sandboxing have different methods of performing their intended tasks. Let's call these levels of protection.

Link protections include:

Checking URL and domain reputations, scanning URLs at the receiving gateway, scanning URLs within a user's mailbox, "just-in-time" scans of URLs, also known as proxy links, and link detonation in a containerized environment.

Sandboxing includes:

Scanning file attachments for signature-based matches, scanning compressed file attachments for threats, scanning and replacing file attachments with alternative formats to negate malware execution, and, finally, scanning and evaluation in a containerized environment.

The Pros and Cons

The benefit to link detonation and sandboxing is the possibility of identifying links or files with dangerous content by passing the data through filtering engines. From the perspective of email security and performing this function at the email gateway layer (cloud or otherwise), several protection levels make a lot of sense. Link and attachment scanning can be done quickly and efficiently.

When detonation of links and files is introduced, two significant issues crop up.

First, creating the container or virtualized environment to detonate links and files is very resource-intensive. This drives the cost up considerably. In tandem with the resources, the process is also very time-consuming. The typical delay of these methods can be anywhere from 5 to 30 minutes. From Mailprotector's experience, users start complaining when their email doesn't arrive within a few minutes because of their expectations around instant delivery.

The second drawback is that link and file detonation can be evaded, especially when performed in a well-known cloud environment. We'll talk about how evasion is done in a moment.

Bonus consideration towards phishing attacks. Most do not carry a payload or even take an action from a link. There is nothing to detonate because the attack is a social engineering attempt. These two methods can do little to protect against that kind of phishing message at the email security gateway.

Mailprotector's Philosophy on Detonation and Sandboxing

Mailprotector is not opposed to using any method that will help protect users from threats and phishing attacks. However, it doesn't mean every method will be employed. Email is a ubiquitous communication tool that comes with specific user expectations. The focus Mailprotector has for email security is protection without added friction. In other words, keep it simple.

Users expect emails to be sent and received very quickly. Some even treat it like an instant messaging tool. At the same time, users complain that security gets in the way of doing their jobs. Balancing this dichotomy is tricky on a good day, but it is the reality for all of us in IT.

Methods Employed

Today, Mailprotector is a cloud-based secure email gateway (SEG). Millions of emails pass through the gateway each day. All messages are put through a comprehensive filtering process using a mix of open source and proprietary methods.

Link and file attachment protections include URL and domain reputation checks, signature-based file scans (anti-virus engines), compressed file evaluation, and algorithms that look for permutations of known threats. The methods are effective, can be performed quickly and at scale. Are they perfect? No. But any vendor that tells you they have a perfect solution to a problem, you should be raising an eyebrow.

Rewrites and Proxy Links

The method of rewriting or proxying a link's URL to point to another gateway can be an effective option. However, this slows down the user's experience of getting a website or resource enough that many complain about it typically because it is done in the cloud, introducing additional, noticeable latency.

A benefit of this method is that clicking that link in the future provides the proxy a chance to scan the link with updated information. But, that latency exists forever, and what happens when the proxy service is unavailable? The user's links in emails no longer function as expected.

Drawbacks

The latency and availability problems aside, the rewrite method creates links that appear to be spoofed from the displayed URL in the email. That is a factor to potentially filter a message. So, the user's replies and future correspondence on that thread are less deliverable through other email security solutions.

Link Detonation

Taking the rewrite and proxy method a step further, we examine the detonation of links. This method can be done with or without link rewrites and proxies. The latency and availability are still a consideration but can be exponentially worse depending on the process taken to evaluate the link's behavior.

An email containing URL links will "click" on each one and evaluate the actions taken. The more links in a message, the longer it will take to get through the gateway and on to the user's mailbox.

Drawbacks

An often overlooked function of email is its use as an authentication tool. A user may need to reset a password or confirm a subscription of some sort that relies on a unique URL to acknowledge the action. Link detonation at the gateway will "click" the link before the user receives the email in their mailbox. If that link expires upon use, the user's experience will be a failed link.

The intention of link detonation is solid. But, the execution of this method at the email gateway is problematic.

Sandboxing File Attachments

As mentioned earlier, stripping attachments from an email and evaluating them in a containerized environment is both resource and time-intensive. The method has a lot of merits. The ability to spot a malicious payload and prevent it from getting to a user is "the gold standard."

Drawbacks

Context and user expectation remain important. Sandboxing can delay email delivery significantly, which throws off the user's expectations. A user working with someone on the phone is waiting to receive an email that contains a large Excel file with macros and a few PDF documents. What's that user going to do if it takes 30 minutes to receive the email? Your help desk will be contacted.

Think of context in terms of this famous movie quote:

Performing sandbox protection at the email gateway is largely cost-prohibitive and, more importantly, less effective than deploying the method at a different layer of your security stack. Remember, email is designed around the Simple Mail Transfer Protocol (SMTP). Sandboxing is anything but simple. Using email for file transfer in itself is inefficient and full of drawbacks. The context is informative from a security design standpoint.

Defeating the Protections

There is a white elephant in the room that many email security providers don't want to acknowledge. For all the hype and security promises made around link detonation and sandbox protections, the technical reality is it shouldn't be the first, let alone only, option for handling links and attachments. Especially at the email gateway layer, the protections can be evaded and defeated with some effort.

More importantly, they can create a false sense of security and excessive false positives that unnerve users. Those two factors can undermine end-user education that encourages better email behavior.

Spammers are highly motivated to succeed in delivering phishing attacks to users. It is a multi-million dollar cottage industry that thrives on the complacency of users. Putting a little effort into creating spam campaigns is worthwhile when 0.1% success means several thousands of dollars.

As email security solution providers, we can confidently claim 99.9% effectiveness. But, as mentioned in the previous paragraph, that tiny tenth of a percent is all the spammers need to keep up their shenanigans. Which begs the question, how do they do it?

Evading Link Protections

Link detonations and proxies have to redirect traffic to evaluate the behavior of a page. Redirecting that traffic itself could create challenges to proper detection. Common tactics to evade this methodology are:

• Custom landing pages that do not contain automatic payload execution or mimic a valid URL
• Redirecting away from the proxy based on known IP ranges of link protection servers
• Implementing redirects to trick link scanners

Evading Sandbox Protections

Sandboxing creates a container, usually a virtualized environment, to evaluate a file or executable in more detail. The method can be effective for simple payloads. However, malicious motives have driven an increase in complexity and intelligence with the threats. Common tactics to evade this methodology are:

• Malware that knows it is running in a virtual or sandbox environment stay dormant until delivered to a user
• Identify well-known sandbox environments to change behavior and avoid detection
• Readily available open source tools to handoff benign payloads based on learned networks seen in previous engagements
• Password protecting documents and compressed files preventing proper evaluation of a file

Custom or Spear Phishing Messages

The most successful threats are customized messages from compromised mailboxes or "burner" servers that can pass SPF, DKIM, and DMARC validations with content that looks legitimate to filtering systems. Even when a message may look obviously bad to a human, a computer doesn't have the context to evaluate an email the same way.

Spear phishing is a social engineering attempt for collecting sensitive data or convincing a user to take any action that will eventually lead to an attack. Good luck identifying this threat with link detonation or sandboxing. The truth is, there is nothing threatening to detect other than possibly the user following the call to action. End-user education is the only protection at that point.

Remediating the Threats

Mailprotector believes there is a place for link detonation and sandboxing methods. However, placing it at the email gateway has not garnered meaningful success in our experience, let alone confidence in real protection. We do not, and will not, promote or implement a feature that provides a placebo. That is irresponsible, in our opinion, and downright dangerous from a security perspective. Few things are worse than a false sense of security.

Link protection and sandboxing can be placed in other security stack layers that are better suited for these two methodologies.

• DNS-based security
• Next-generation firewalls with proxy services to perform the detonations and sandbox environments
• End-point security applications to protect against malicious behavior detected at payload execution

These additional layers not only offer a more effective platform for these protections, but they can also alleviate some of the risks of "putting all of your eggs in one basket." Evading the protections becomes more difficult because a malicious payload has to beat each layer to remain viable.

And, finally, the all-important recommendation you're probably tired of hearing - end-user education.

The human element is the most vulnerable portion of all of this. All the security layers and protections can be in place, but that 0.1% will still leak through. It is extremely critical to train users on spotting phishing pages, social engineering tactics, and subtle obfuscations that put them and their organizations at risk.