If your organisation uses Microsoft Exchange On-premise (i.e. Exchange Server 2010/13/16/19), Exchange Online or a third-party Secure Email Gateway then you're likely broadcasting sensitive information through the default Postmaster Non-Delivery Report (NDR). Read on to find out what the impact is and how to detect if this affects you.

Today I want to shine light on an extremely widespread and seemingly unknown security risk that plagues organisations across the globe. This risk is the result of a misconfiguration that allows threat actors to see what spam and malware filtering technologies are in-use, the rules, the actual scoring and the version of said filtering technologies - all without any form of user interaction.

The ability to see this information undermines the very purpose that mail spam and malware filters are used for. With this information, threat actors can deliver custom-built spear-phishing campaigns with the knowledge that their emails will end up in users mailboxes.

How?

Through abuse of the Exchange Postmaster.

Under normal circumstances the Postmaster is used for delivering system-generated messages and notifications to message senders. Most commonly these system-generated messages are created when there's a problem delivering a message. In this instance, Exchange sends a Non-Delivery Report (NDR) to the message sender that indicates there was a problem.

The information included in the default NDR is designed to be useful for both users and administrators. It's important to note this, because its exactly this dual functionality that makes it vulnerable to abuse.

What Information is included in a Postmaster NDR?

The information that's included in an NDR can be separated into two sections:

The Diagnostic information for administrators section included by Exchange has an untampered extract of the Original Inbound Message Headers - including all mail relays and any sensitive headers not for external viewing.

What's the problem with this?

Modern mail filters are designed with interoperability front-of-mind. Because of this, mail headers are typically used as the vehicle to communicate information along the mail relay process. E.g. your malware filter may want to inform your spam filter of its findings. And then your spam filter may want to add additional headers which indicate the message has been scanned against X, Y, Z criteria - and so on all the way to Exchange.

When coupled with the fact that any external user can extract this information through delivery of an email to a non-existent user (e.g. idontexist123@) we have a big issue with the Exchange NDR process that's enabled by default.

Diving into the Message Headers

If we look at a few example message headers that various spam & malware filtering technologies include in the mail relay process (that are visible in the NDR), we can immediately see the issue:

Proofpoint SEG

Cisco IronPort

Sophos PureMessage

Equipped with this data, threat actors can methodically build a custom spear-phishing email with near-certainty that the email will appear in the targets mailbox - bypassing all forms of spam and malware you may have in-place.

Wrapping up

Email phishing is among the most prominent method used to breach organisations today. Often used to harvest user credentials, trick users into sending money to illicit entities and compromise endpoints through delivery of malware. Spam and malware filters are our front-line defence when dealing with this never-ending issue and as such we need to ensure the technologies in-use and the way they operate is fundamentally hidden from threat actors seeking to slip into your perimeter.

f you haven't already, I recommend reviewing your email infrastructure to ensure the default NDR within Exchange On-premise (all versions from 2010 - 2019) or Online is either disabled or altered to include a bespoke message which doesn't include sensitive information (click here for Microsoft guidance on how this can be done).

If you're unsure on whether your email infrastructure is vulnerable, you can use the free Email Supply Chain Scan available within CanIPhish's Domain Tools to identify this for you.

Finally, if you have any questions or need additional advice on how to detect or mitigate this security risk, please feel free to reach out to me directly via Email, LinkedIn or the CanIPhish Contact us page.