This post will be the first of a series on advanced phishing capabilities and bypassing email security mechanisms.  The focus is on URL analysis and bypassing link scanning capabilities, with Microsoft’s O365 linkscanning filters used for demonstration.  

The phishing techniques discussed here are not new but their continued success demonstrates the need for continued developments in email security.

Though many of the methods discussed throughout the series are not new, the very fact that most of them are successful in our social engineering engagements is an indicator that there is a lot of work to do, and defense teams need to address them.

One key area of any redteam assessment is email phishing or social engineering, and much has been written on the subject.  Although the risk of phishing is well documented, detailed information on how attackers are circumventing these defenses is important to mitigating these attacks.

User training and education is extremely important, and there are many resources online and companies like Rhino that can assist you in putting together a good education program to help deal with the human element of this attack vector. Defense teams can not stop there, as observed in Verizon’s 2018 DBIR report: “4% of people will click on any given phishing campaign”.

Many organizations will opt to use third-party mail exchanges like Google Mail, Office365 and others, and rely solely on those services’ defense mechanisms. Although these services do a good job at dealing with common spam, default configurations may not help you in detecting, stopping or mitigating more sophisticated email attacks. Proper configuration is vital to an effective anti-phishing strategy.

When evaluating email security services, it’s important to understand how malicious emails are identified, and ask questions such as…

• • Does the sender domain have a valid SPF record, and is the connecting IP part of the accepted senders whitelist?
  • Does the sender IP have a valid DKIM record, and is the email authentication or signature valid?
  • Does the sender domain have a valid DMARC record, if so, is there a policy set to deal with bad emails?
  • Does the email content itself match known malicious emails (“Click here to reset your password!”)?
  • Are there links in the email to negatively reputed domains or landing page URLs?
  • Are there links in the email that point to login pages that are detected by link protection scanning mechanisms?
  • Is the attachment in the email known to be malicious? Or is detected or flagged by signature based systems?
  • (custom) Is the sender domain a permutation of the receiving domain?
  • (custom) Is the sender domain a newly created or uncategorized domain?

This list is by no means complete, and I’m sure there is a lot more work being done on the backend for each service respectively. This is especially the case when a customer brings in a third party mail security provider like Proofpoint or Mimecast where they may employ other techniques that would be unseen to the attacker and users.

Our aim with every engagement is to analyze the mail server in use, identifying any security providers and preparing circumvent as many technical controls as possible.

For the sake of brevity for this first article in the series, we will be focusing on link scanning mechanisms employed by Microsoft, although what is discussed can also be applied to other services.

Microsoft’s Exchange Online Protection (or EOP) acts as an add-on to on-prem exchange or cloud-hosted mailboxes.
Below is a list of some of the features it totes:

• Inbound and outbound spam detection.
• Backscatter protection. Note: backscatter are bounce emails generated by destination mail exchanges when an email address is not valid.
• Bulk email filtering.
• URL block list lookups and blocking.
• Known spam and phishing sender and domain filtering.
• Anti-malware scanning and detection.

The actual list of what can be done with the service is more impressive the further you read through it. More importantly, it provides administrators and the security team with configuration options to further enhance how incoming email is dealt with.

Due to the way the EOP servers are positioned in the flow of email delivery, it acts as a middleman, using its built-in scanners and user-defined configurations to filter out emails identified early on as malicious.

The following diagram gives a simplified overview of how emails are processed through the EOP service:

Connection filtering is one of the first phases of filtering that emails will go through as part of the overall email delivery process. Its purpose is to allow or block emails as defined by the respective whitelist or blacklist policies configured by administrators.

Moving forward, the Anti-Malware phase passes attachments through EOP’s scanners looking for signatures that are known to be bad. Similarly to the first phase, once emails are identified as malicious they will be promptly removed.

Transport Policy Filtering offers a lot more options than connection filtering, allowing administrators to fine tune their anti-spam and routing process. Read through the documentation for more information on what kind of changes can be made from the administrator side.

Although most of the previously mentioned phases EOP passes emails through are important, the real chunk of bad emails will be caught during Content Filtering phase, where administrators can really tighten controls around email delivery dependant on their content. There are various options that can counter an active social engineering campaign, some of which include:

• Disabling image links (or ‘bugs’, an indicator used by phishing platforms to determine if targets opened the initial email).
• IP address links, which are commonly used to bypass web proxy filters on an internal network.
• Domain TLD blacklsits.
• Content specific filtering, blocking of sensitive words or other indicators

As a social engineer – whether part of an internal infosec team, or an external pentester – it is important to understand default configurations of email security tools like EOP and their most common changes.

As mentioned previously, content filtering is an important element to any good email security provider. In the case of EOP, and other services, part of the process that is not visible to the client is link and attachment scanning. Although you can configure whether or not attachments can be quarantined, links designated as malicious will usually be handled based on your organizations filtering policy in the background.

According to documentation, EOP’s link scanning process entails:

• Identifying if links within emails point to downloadable content (think binaries and documents) and passing these through their attachment scanning engines.
• Analyzing URL reputation from various partner sources, identifying whether or not the URL is malicious.

Although rudimentary, it can become an important defense asset to mitigate a large scale social engineering campaign in the middle of traction. An attacker can put together a great phishing infrastructure and email template and still be stopped along the way by a known bad landing page URL.

Finally, although EOP does provide an introduction to email security and a decent amount of configuration options, it will fail your organization against campaigns using zero-day methods. Case in point: the service may help identify and block emails with known phishing and attachment signatures, and fail with others that do not.

Beyond the EOP service, Advanced Threat Protection provides protection for more sophisticated attacks with more proactive approaches, like scanning documents for links and objects in sandboxed environments.

Core features of ATP include:

• Safe Attachments protection from unknown (or zeroday) malware.
• Safe Links, a feature that rewrites links in emails and are scanned in real-time for threats. This includes scanning documents for links and rewriting them as necessary.
• More configuration and logging options that security teams and administrators can use for fine-tuning their environment.
• Spoof intelligence, a mechanism in place to detect spoofed email to/from your organization domain.
• Machine learning and other capabilities for detecting phishing emails.

One interesting feature that was introduced by ATP is called Safe Links, where links in emails and documents are actively scanned (by EOP) and rewritten to point to an ATP gateway. Once the link is clicked and it is scanned, it will go through a series of checks before it allows you to navigate to the URL.

Some of the checks taking place during the scan:

• Determine if the link is blacklisted by the organization
• Identify whether the link points to downloadable content (documents, binaries) and scan them
• Has the link been designated as malicious previously?

At this point it will either allow you to continue to the URL or block you from accessing it with a message similar to the following:

At this point the user is warned of the malicious indicators, which drastically lowers the effectiveness of the social engineering campaign.

Although link scanning and the ‘Safe Links’ mechanisms should be respected as great concepts that will attempt to deter sophisticated actors or known campaigns, it is not prone to security failures or misconfigurations. Just like any security tool, it’s functionality can suffer at the hands of “features” (ergo, features which seem dangerous or seem like vulnerabilities) or bugs in the way it handles certain data.

In one finding by Oddvar Moe, he determined that ATP’s ‘Safe Links’ mechanism can be circumvented by sending malicious links in emails without the hyperlink tag present, as in, sending a plaintext URL without making a link using “<a href=URL>”. In this case, it looks like Microsoft considers this a design issue and not an actual vulnerability leaving this method open as a potential vector.

In another interesting finding, the folks at Avanan discovered that if you used the “<base>” tag, you could theoretically split the URL at the base and ATP would not properly process the links for designation. Although this issue was fixed shortly after initially reported, it was an effective method while it lasted.

Our approach to dealing with the aforementioned products (and similar) first starts with taking note of the IP ranges used by the link scanners and sandboxes. With this list in hand, we can now create a strategy on dealing with incoming traffic that we need to trick into thinking our content is legitimate.

We have observed that by redirecting traffic from EOP’s ranges away from our landing pages  and onto a valid URL on our target organization’s domain, our success rates were high while detection remained low

Although creating custom email templates and landing pages help us achieve a good amount of success, the following really gives us an edge over this particular protection:

• Microsoft publishes the full list of EOP IP ranges at this page or via API
• Link scanning for either service (ATP/EOP) is done by EOP alone

Attacking this vector requires configuring your landing page web server to redirect traffic away from EOP and onto a legitimate as described in the following section.

The following instructions are geared towards a phishing platform which uses Nginx, using the geoip module to handle redirects based on IP. There are other ways to do this, and we chose this method for no particular reason other than it simply works. Feel free to tackle this problem however you would like.

If you are using a web server or technology not based on Nginx, you should read through its documentation to give you an idea as to how to replicate the following steps:

Once these four steps are completed, you can restart the server and test out your landing pages. For testing purposes, you should add your IP address/range to the bad_user list to confirm redirections are properly taking place once you hit the landing page.

Using redirects to trick link scanning products is nothing new, and has been observed throughout various APT campaigns or red team engagements.

I recently discovered a great tool by @violentlydave called mkhtaccess_red which is able to generate functional .htaccess files, redirecting traffic to bypass known sandbox and threat protection providers.  Another great tool for your red teaming / phishing toolkit.

The first step for preventing these attacks is to take advantage of ATPs powerful configuration options, ensuring that links are configured to display warnings and never allow users to ‘proceed’ and bypass the prompt.

Integrating DNS security tools – whether locally on the corporate network or as a cloud service – can also help catch web traffic from users clicking phishing links.  Using a service which categorizes and blocks newly created domains will address most malicious links you encounter. Pairing this with a web proxy to inspect the web traffic directly can take this protection even further.

With the human element being the most vulnerable here, social engineering training is extremely important for any organization. Teaching your employees how to spot phishing pages and other indicators, as well as how to properly report the offending payloads will make the difference at the end of the day.

As mentioned previously, these techniques aren’t new but are important to understanding impact if technical controls are circumvented. Going beyond ATP and EOP, almost any other similar service will fall prey to these kind of attacks.

It is important to look at your security capabilities from both the defender and attacker view, as it will provide you a broader insight as to where you stand today.  Defending your users requires a multi-faceted approach, and I am hopeful with articles like these that organizations can advance their email security posture.