Mimecast Targeted Threat Protection (TTP) is a suite of email security tools designed to protect end users from phishing attacks. The URL Protection feature of this subscription can inspect links embedded in emails for malicious content. If a file is deemed safe, Mimecast will allow the user to retrieve it from the linked site. Files categorized as malicious are blocked and cannot be downloaded.
Or so I thought.
root@webserver:/var/www# mv malware.xls not-malware.xls
During a hybrid breach and attack simulation and social engineering penetration test, I discovered a way to bypass Mimecast’s URL Protection and File Inspection features described above.
Though, in the interest of transparency, I’m not sure I can claim that I discovered this issue. I would be surprised if this wasn’t already a known trick. Nevertheless, it was acknowledged by Mimecast and landed me a spot on their Security Researcher Wall of Fame.
This is a great reminder of the importance of defense in depth strategies. In this instance, I was able to bypass, or evade, the email defense in place. When frontline security controls are bypassed, organizations must have back up, layered controls and policies in place to stop or slow down adversaries and prevent further incident escalation.
I worked closely with Mimecast to responsibly disclose and remediate this issue. Let’s take a deeper look at the discovery and disclosure process.
Here’s what happens behind the scenes when an email containing links is sent to an inbox protected by Mimecast.
We will use 2 different files in these examples:
happy.xls – A nearly-empty spreadsheet which only contains text
sad.xls – An Excel file containing a basic malicious macro
The end-user receives an email containing links to retrieve your files.
Clicking one of the links will result in the HTTP requests below. These are issued directly fromMimecast and are the “inspection” part of “URL Protection.” Take note of the timestamps and unique header values, as we’ll revisit these later.
GET /happy.xls HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36
If the file is deemed safe, Mimecast will present the Download button. Clicking this will result in a final request to finally retrieve the file. This request will be issued from your client, not from Mimecast.
However, if the file contents are found to be malicious, Mimecast Targeted Threat Protection will classify the file as harmful and prevent the user from accessing it.
Did anything in that process catch your eye? There are four core concerns I had with this process. Mimecast’s corresponding remediation steps for each of these problems can be found at the end of this article.
1. File content is not served by Mimecast
After clicking the Download button, the end user will retrieve the file directly from the remote link.
2. A Predictable Pattern
HTTP requests generated by Mimecast file inspection follow a predictable pattern. In the workflow above, Requests 1 and 2 will always be issued in that exact order, in the same two-second interval, and with the shown header values.
This means that an attacker can accurately determine when a file has been inspected by TTP. By monitoring for the unique header values in Request 2 (i.e., x-client-ip, x-real-ip, x-client), the attacker can modify the subsequent response to Request 3 to return an entirely different set of file contents. This would allow an attacker to present a clean file to Mimecast, while serving malicious content to the end user.
These two items alone could compromise the integrity of inspection results. Though there’s a much simpler way to achieve the same result.
3. Results are Stored by Filename
That’s right! URLs are only inspected during their first visit by that user. If a URL is previously designated as safe, the content and classification will remain cached for a length of time. An attacker can bypass protections by simply renaming a malicious file to match the filename of a previously categorized safe file. This result remained for up to four hours in my testing; however, Mimecast has shared with me that they will look to address this via risk-based caching.
4. Results are Shared
While you can’t see it in the above screenshots, I found that links rewritten by TTP do not appear to be completely unique. Inspections, and their resulting categories, are seemingly persistent across identical messages sent from two different source addresses. An attacker could send a benign message to the target from Address A, then re-send the same message from Address B after the file has been categorized.
The Problems Combined
Let’s put everything together. To demonstrate the attack workflow, the examples below will pick up immediately after I attempted to click the Blocked file.
On the remote web server, rename the malicious file to match the filename of the safe file. Review the checksum to confirm that the file matches.
Renaming the malicious file to replace the safe file
Return to the email and click the link to the safe file, which now hosts the contents of the malicious file. Review the web server logs and observe that Mimecast does not attempt to inspect the file a second time, resulting in the malicious file being classified as safe. Downloading and reviewing the file confirm that the malicious content was successfully downloaded.
TTPs against TTP
While you can certainly follow the “steps” outlined in the TL;DR, I think we can make this better.
Proof-of-Concept 1: Automatic File Renaming
The Python script below will start a web server on the host and automatically rename a malicious file to an inspected, safe filename. Note that the below code is a basic example and will only function a single time. It is not clean, but it certainly does the job.
# Made from https://stackoverflow.com/questions/42341039/remove-cache-in-a-python-http-server
PORT = 80
count = 1
def send_response_only(self, code, message=None):
resp = super().send_response_only(code, message)
self.send_header('Cache-Control', 'no-store, must-revalidate')
count = count + 1
if count == 2:
print('[*] MIMECAST SCAN 1')
elif count == 3:
print('[*] MIMECAST SCAN 2')
print('[**] MIMECAST SCAN COMPLETE. REPLACING FILE.')
if __name__ == '__main__':
Proof-of-Concept 2: Automatic TTP Evasion
This one will start a web server on the host and serve safe content by default. It reviews each incoming request for the unique HTTP request headers provided by Mimecast URL Protection (x-client, x-client-ip, and x-real-ip). If these headers are detected, it will then automatically alter the response to the subsequent request and serve malicious content, then reset to safe content afterwards.
This process will repeat each time the TTP headers are detected. This allows the attacker to evade future detections while continuing to deliver malicious content to additional victims. And just for good measure, the victim IP can be hardcoded to always serve the payload when they visit.
If results are shared, an attacker could potentially pre-inspect and categorize files by sending messages to their own Mimecast subscription.
How long is the scan result cached? My estimates were around 4 hours. This makes attacks somewhat time-sensitive, but still leaves a large window of opportunity.
Recommendation to Mimecast
Users should be unable to retrieve an inspected file directly from the remote host. Instead, TTP should act as an intermediary and temporarily store a copy of the inspected file to serve to the user. This would address all of the demonstrated evasion methods. Future download attempts by the user should be served from TTP – either the previously cached version or a newly inspected copy.
Disclosure, Feedback, and Timeline
Mimecast has indicated that they will be implementing these suggestions and provided the following comments:
File content is not served by Mimecast Mimecast has committed to implementing a fix.
A Predictable Pattern This issue has been addressed.
Results are Stored by Filename Addressed via risk-based caching on a continuous basis.
Results are Shared Addressed via risk-based caching on a continuous basis.
Unfortunately, without an active Mimecast subscription, I have no way to confirm if this is accurate.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.