Today I had an interesting case come across my desk. A customer wanted to enforce that all external messages came through their third party cloud gateway. In an effort to prevent bypassing the gateway and having mail traffic come directly into Office 365 the customer wanted to craft a transport rule to catch and quarantine these messages. The rule was created as follows:
Execute the rule on any sender that is external to the organization. Perform the action quarantine on the message. (In this instance though the rule just audited because the customer was testing – an awesome idea by the way). The rule should fire except when the submitting IP address is a dedicated IP address provided by the third party cloud gateway.
In most of all instances the rule looked like it was firing perfectly. Messages that were submitted directly to Office 365 bypassing the primary MX record were captured when an external sender was involved. When reviewing some messages that were captured by the rule the customer noticed something odd – a handful of the messages were sourced from and delivered to Office 365 servers. There were no external servers involved in the transmission. How did an external sender manage to submit messages sourced on Office 365 servers and destined to Office 365 servers. Let’s take a look.
The first thing we did was gather a sample message header from Outlook. Using http://www.testexchangeconnectivity.com and the message header analyzer we had the message header parsed. The first thing we looked at were the transmission hops.
Hop↓
Submitting host
Receiving host
Time
Delay
Type⇒
1
CY4PR0501MB3908.namprd05.prod.outlook.com ([::1])
CY4PR0501MB3908.namprd05.prod.outlook.com ([fe80::70ad:f6a:5ede:2b92%13])
10/13/2017 4:27:46 PM
Microsoft SMTP Server
2
CY4PR0501MB3908.namprd05.prod.outlook.com (52.132.100.162)
DM5PR05MB2938.namprd05.prod.outlook.com (10.168.176.138)
10/13/2017 4:27:46 PM
0 seconds
Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
3
DM5PR05MB2938.namprd05.prod.outlook.com (10.168.176.138)
BY1PR0501MB1223.namprd05.prod.outlook.com (10.160.104.150)
10/13/2017 4:27:47 PM
1 second
Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
4
BY1PR0501MB1223.namprd05.prod.outlook.com (10.160.104.150)
BN3PR0501MB1220.namprd05.prod.outlook.com (10.160.113.28)
10/13/2017 4:27:47 PM
0 seconds
Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
In this instance the situation was exactly as the customer described. The first hop was an Office 365 server and the last hop was an Office 365 server. The rule had fired on a message that did not originate through an external mail system.
The next header entry reviewed were the recipients. The from header shows externaluser@externaldomain.com and the recipient is internalUser@office365domain.com. This validated that the sender was external matching the transport rule apply to for messages originating from senders external to the organization.
So far the conditions for the rule to fire seem to be accurate –> the sender is validated as external, the message did not come from a third party gateway IP address, therefore action should be taken. We still don’t know why though – why did a message that is seemingly completely external originate from an Office 365 server?
As we move through the header investigation we see additional entries that leads us to a conclusion that not everything is as it appears. There were custom X headers that were added by the third party gateway. If the message had originated directly on Office 365 why would there be custome headers stamped by the third party gateway? This would seemingly indicate that the message passed through this third party gateway where actions were performed. For example X-ThirdParty-Virus-Version and X-ThirdParty-Spam-Details were present in the header.
Continuing to move through the header we note the presence of X-MS-Exchange-Parent-Message-ID. This message id has the following value < numberString@google.com >. This reinforces that the message was generated externally – it has an encapsulated original message ID from a remote mail system. The message ID of this message is < fa80351799674b019521923f47ee0125@CY4PR0501MB3908.namprd05.prod.outlook.com >. The message ID being an Office 365 message ID continues to reinforce that this message was generated within Office 365.
Then we come to the following message headers that really crack this case wide open.
X-MS-Exchange-Generated-Message-Source: Mailbox Rules Agent
X-MS-Exchange-Inbox-Rules-Loop: recipient@office365domain.com
In this instance this message was actually generated within Office 365 and the message was actually from an external sender. The reason it was generated is that the recipient listed in X-MS-Exchange-Inbox-Rules-Loop had an Outlook inbox redirect rule established. The redirect rule creates a new message within Office 365, retains the original message headers including the from address, but changes the to recipient to the specified recipient. We were able to track the forwarding rule down using this post – https://blogs.technet.microsoft.com/timmcmic/2015/04/19/office-365-determine-accounts-that-have-forwarding-enabled/. When using this post and the recipient specified in the header the inbox rule containing the TO recipient was located and validated. This confirms the message was redirected.
In this instance the rule did exactly what it was supposed to. The sender was external, the recipient was internal, and the message did not originate from one of the IP addresses provided by the third party gateway.
TIMMCMIC 