Earlier this year, I presented research at BSides Canberra evidencing that many organisations unintentially broadcast sensitive information in email bounce responses and non-delivery reports. At the time, I spoke about how threat actors could abuse this to ensure that their phishing material was ending up in their target's mailbox.

After presenting, I found myself wondering... If we can see sensitive information from one organisation which exposes the way their email filtering solution reacts to certain phishing material... Then surely we could scale this to many organisations to see how a variety of email filtering solutions react when presented with that same phishing material.

I realised that if done right, we could create a unique capability similar to VirusTotal. However instead of focusing solely on malware analysis, this capability would provide us with insight into how successful a mass-delivered phishing/spam/malware delivery campaign may be.

Note: To better understand email bounce attacks and the resulting issues, please read the following Article or watch the BSides Canberra presentation.

How?

Through orchestration and automation.

Getting a bounce response from an organisation is easy. All we need to do is email a non-existent address and more often than not, we have a non-delivery-report. What's difficult, is analysing the bounce response to identify the sensitive information that's relevant for our attack. When we then scale this from one to many the issue is severely compounded. Manually analysing dozens, hundreds or even thousands of bounce responses, each containing information on differing email filtering solutions could take hours, days or weeks... Just for a single phish.

Creating an automation pipeline

Equipped with this understanding I realised that we would need to create an automation pipeline which allows us to scale the identification, analysis and exploitation of vulnerable mail receivers. If we break this pipeline out, we end up with four distinct phases of execution.

Note: In the interest of providing a proof of concept, I've created various open-sourced and free toolings that assist with the execution of each phase.

Phase 1: Identification of Vulnerable Mail Receivers

Abusing public infrastructure at-scale, first requires us to identify where that vulnerable infrastructure exists. To do this, we need to know what keywords within a bounce response/email header evidence that a certain email filtering solution is in-use.

Through my own research, I've identified that the following keywords evidence where one of atleast 17 different email filtering solutions are in-use. To see the keyword to email filter correlation see the linked GitHub project:

Keywords: "IronPort", "E=Sophos", "E=McAfee", "PerlMx", "Trustwave SEG", "Exchange", "Microsoft SMTP Server", "Proofpoint-Spam", "X-FireEye", "Forcepoint", "X-TMASE-Result", "trendmicro", "Diagnostic information for administrators", "Proofpoint-Virus", "CrossPremisesHeaders", "SYMC-ESS-Spam", "Exchange-CrossPremises", "MS-Office365", "X-Forefront-Antispam-Report:", "Postfix", "X-VirusChecked", "X-StarScan", "FireEye ETP", "FE-ETP", "X-FE-ETP-METADATA", "Mimecast-Spam", "X-Mimecast-Impersonation-Protect", "protection.outlook.com", "X-MailControl", "X-MailControl-Inbound", "x-msw-jemd-malware", "x-msw-jemd-refid", "X-SEA-Spam", "X-Barracuda-Spam-Score"

Now that we know what we're looking for... we have a number of detection/delivery mechanisms available to us:

1. Manually deliver emails to various non-existent addresses at target organisations e.g. Gmail, Yahoo, etc.
2. Programmatically send emails using our own SMTP server or a IaaS/PaaS mail service e.g. Amazon SES. Ensuring bounce responses are forwarded to storage that we control.
3. Manually or programmatically identify vulnerable mail receivers utilising the CanIPhish Supply Chain Scan or Supply Chain API.

Reference: The below image shows the result of a CanIPhish Supply Chain Scan.

Phase 2: Email Filter Priming

Now that we've identified various target organisations who utilise differing email filtering solutions, we need to ascertain the baseline state of each filter. i.e. we need to ensure that certain email filters don't already have a prejudice on the mail domain/address/service we're using.

To do this, we send a single email to a non-existent address at each target organisation. We wait approximately 180 seconds and monitor that a bounce response is received from each target. At this stage it's critical that this single email contains no malicious content and appears innocuous in nature.

Note: To assist with the automation of phases 2, 3 and 4 I've created an open-source/hosted tool called Phishious. Phishious is n MVC .NET Core Web App which can be run locally or through the hosted CanIPhish tool. The tool is designed to automate analysis by allowing users to upload multiple bounce responses and then have those responses inspected for various keywords, regex patterns and unique identifiers which indicate where an email filter has been observed.

Reference: The below image shows the result of Filter Priming in Phishious.

Phase 3: Email Filter Detonation

Now that we've primed the identified email filters, it's time to deliver the malicious spam/phishing material. To do this, we send a single email to a non-existent address at each target organisation. We wait approximately 180 seconds and monitor where a bounce response has been received before proceeding to phase 4.

Reference: The below image shows the result of Filter Detonation in Phishious.

Phase 4: Results Analysis

When analysing our results from both phases 2 and 3, we need to understand that different email filters behave in different ways when delivered with malicious content. Ultimately we can expect to see one of three outcomes:

1. No bounce response received (Email blocked): This is the default behaviour for many email filtering solutions and mail routing setups. Ultimately what's happening here is that the malicious email is inspected and blocked by the email filter prior to an address lookup occuring. Therefore we can infer that since a non-delivery-report was never generated, the email was blocked.
2. Bounce response received (Email blocked): In some circumstances, when email filters classify an email as spam/malicious, they will still generate a non-delivery-report and forward it back to the sender. Equipped with this report, we can analyse the original message headers and determine that based on scoring information the email was blocked, quarantined or sent to a spam/junk folder.
3. Bounce response received (Email allowed): This is what we're hoping for. If we receive a bounce response and analyse the original message headers, we can in most cases see how the email was scored, what rules were hit and where the malicious material could be improved upon (e.g. avoiding certain keywords, URL shorteners, etc.)

This is where an automation tool such as Phishious really speeds up the analysis process. Instead of manually inspecting each bounce response, we can upload the received responses and allow Phishious to perform the variety of keyword, regex and pattern matching lookups needed to identify where the malicious material was undetected or blocked. Obviously, there is still room for improvement on what Phishious currently provides. At current, each phase of execution still has some manual components. Complete orchestration of the execution pipeline is something I'm considering but I also don't want Phishious to become the defacto tool used by threat actors.

Reference: The below images show the detailed analysis of two distinct email filtering solutions in Phishious.

Wrapping up

Email phishing is one of the most prominent methods used to breach organisations today. Cyber criminals will often take advantage of any mechanism they can to get an upper-hand against defenders (e.g. spoofing email domains, bypassing email filters or reducing their operational effectiveness). My aim with this article is to highlight how threat actors can utilise your own defensive technologies for offensive purposes, either then being directed back at your own or other organisations.

If you haven't already, I recommend reviewing your email infrastructure to ensure your organisation isn't unintentially broadcasting sensitive information within email bounce responses. If you're unsure on whether your email infrastructure is vulnerable, you can use the free Supply Chain Scan available at CanIPhish to identify this for you.