Exchange Online Content Filtering Bypass: Defeating Microsoft’s URL Sandboxer

Tl;dr SOPHTIX Security Team found a bypass for Microsoft’s phishing and malware content filtering for inbound email in Exchange Online. The bypass allows threat actors to include malicious links in phishing email messages sent to mailboxes hosted in Exchange Online, leaving organizations utilizing Microsoft 365 Business and Enterprise solutions prone to attack. Through the use of an HTTPS proxy server, sandboxing agents’ requests can be differentiated from legitimate users’ and directed accordingly.

Phishing is a type of social engineering attack that targets the human element in the organization, and requires its interaction with an attacker controlled website. The This attack proves to be effective in gaining an initial foothold into an organization and is trending among hackers. According to Techopedia’s statistics, there has been a linear growth in the number of unique phishing domains observed worldwide between Q2 2021 to Q3 2022.

Currently, SaaS directory services such as Azure Active-Directory and Google Workspace provide an all-in-one enterprise solution for identity management. These include employee mailboxes that utilize built-in security features such as spam, malware, and phishing filtering services.

According to Microsoft, Exchange Online Protection (EOP) is the cloud-based filtering service that protects your organization against spam, malware, and other email threats. The following is a flow chart showing the various filtering techniques that an email message goes through once it is sent to an employee mailbox in Microsoft Exchange Online:

This research was triggered by a unique client request in the scope of a phishing simulation. In this specific engagement, the client requested that the naming convention of the hacker’s mailbox resembles a system mailbox that sends notifications on behalf of Microsoft’s services.

Infrastructure Deployment

Initially, we looked for domains that are a combination of keywords appearing in Microsoft products or applications. This ultimately led to SOPHTIX Security being the proud owner of the microsoft-office[.]co domain name. The mailbox created was security@microsoft-office[.]co, and a full name that literally translates to account security notifications.

Next, the configuration of the MX, DMARC, and SPF records – a test email containing no links, a title, and a body passed the confidence threshold and followed through to an employee’s mailbox:

This was done with no changes or exclusions set in either the default inbound anti-spam, or anti-phish policies (which is the case throughout the entirety of this research).

 

Consequently, we further weaponized this email to resemble a notification generated by one of Microsoft’s applications, inducing as many users as possible to click the link in its body.
The HTML layout of a billing notification sent from Microsoft was altered – resulting in a legitimate looking email informing employees that an unusual activity has recently occurred in their account, and prompting them to get more information online by clicking the link.

Finally, the link in the email body was replaced to point to a phishing server that is hosting a credential harvesting landing page on microsoft-office[.]co. The team noticed that once links of the newly acquired domain were embedded in the message body in any form, the email is quarantined due to an advanced filter and are marked as a high confidence phish, probably due to the domain’s resemblance to Microsoft’s (Advanced filter), or low confidence in the age or volume of traffic associated with the domain:

The email was quarantined regardless of the exclusions the team had attempted to make in threat policies in the Exchange Admin Center, when shortening the URL, or when proxying all requests to the phishing server through a more reputable domain name. This was the result of sandboxing-agents visiting the URL and assessing the confidence in the content that is served.

It was at this point that the team decided to research the inner workings of EOP’s sandboxing functionality and its’ requests to webservers, allowing it to distinguish them from end-users’. This allowed for serving EOP sandbox with legitimate looking HTML content and end-users with the phishing landing pages.

Research

Burp Collaborator is a network service hosted by Portswigger that allows an attacker to identify web application vulnerabilities that trigger interaction with 3rd party servers across multiple protocols (DNS, HTTP). It does so by registering unique domain names and allowing an attacker to poll for incoming connections to these domains.

First, we crafted a Burp Collaborator URL that was put in the body of an email sent to a mailbox within Exchange Online:

Then, we noticed that prior to opening the link on the client side, DNS and HTTP interactions are made with our unique Collaborator domain, revealing some properties of the interactions that EOP’s sandboxing agents make with supplied links; DNS lookups and HTTP GET requests to the home route.

Some of the hosts’ public IP addresses were associated with authoritative name servers (ANSs) belonging to Microsoft Corporation:

However, some of the lookups against agent IP addresses revealed varying hostnames (if any), and unpredictable segments – rendering it impossible to differentiate them from end-users’ and serve content accordingly.

Nevertheless, all agents’ requests shared a lack of the Accept header in contrast to non-sandboxed modern browsers that are in use by end-users:

These findings led us to serve connection-contextualized HTML content, ultimately tricking EOP’s sandboxing agents in their assessing of confidence.
This is illustrated in the following routing schema, detailing the flow of serving of HTML content to a link that is included in phishing emails:

Proxy server PoC

The implementation involved the deployment of a flask proxy application that performs the following checks on incoming HTTP requests, to verify their origin:

  1. Missing ‘Accept’ header.
  2. Association of IP address’ DNS records with Microsoft’s authoritative name servers.

If a request falls under the above criteria, the response needs to include legitimate looking HTML content, otherwise, it is an end-user that should be redirected to the phishing server.

The routes in the flask application are decorated by a function that runs the tests discussed above, and serves an HTML page containing a picture of a black and white cat if any are true. If none are, execution flow is returned to the calling function, allowing the application routes to handle end-users’ requests and proxy them to the relevant endpoints that are hosted on the phishing server.
The application was deployed on a local UNIX socket using Gunicorn and served using nginx middleware with shap[.]ltd domain name, which was registered more than 6 months ago.

Email message weaponization

GoPhish is an open-source phishing framework that offers the ability to launch and manage phishing campaigns. It does so by generating unique IDs for each target mailbox, enabling logging of all user interactions (Email Sent, Email Opened, Clicked Link, Submitted Data) through serving of HTTPS endpoints.

The web application that the framework deploys serves two endpoints. These are key to the functionality and transparency of the campaigns; a track route, which is used as an indication for when an email message has been opened on the client side, and a main route that serves with the credential harvesting landing page.

The email body was weaponized to utilize the phishing server’s functionality through our redirection proxy, in the following manner:

  1. Including an element that would be fetched with the load of the HTML content on the client side (email open):
  2. A clickable link to the landing page, by user ID:

 

The campaign was launched against mailboxes in Exchange Online and messages followed through. The rendered result looked as follows:

A link click redirected the end-user to the fake login screen, where victims were sent to the official Microsoft Office website after having their credentials harvested:

The link can also contain a malware dropper with the following modifications to the route, for example:

A click on the button in the email body results in end-user’s browser download of WannaCry.exe ransomeware, effectively entering an organizational perimeter.

Using this technique, our phishing campaign achieved the following results in an organization whose mailboxes are hosted on Exchange Online, with no exclusions or spam threshold modification:

 

The issue has since been fixed by Microsoft Security Response Center:

 

Resources

Sign up for our Newsletter