MCAS IPv6 Recipient Cache False Positive Impossibile Traveller

[LT22]

Hi all, 

More of an FYI in case anyone is searching. Started noticing some EXTRA (HA) Impossibile Traveller Alerts. Checked them out and found it was actually a Create Email MCAS Event in the US from an IPv6 Block assigned to Microsoft but MCAS didn't seem to know the range or tag it as Azure Cloud/Microsoft/Office 365, etc. Started to see a few more and more in the IPv6 Range so started to look into it further. The alert didn't provide much info other then Device Type : Client=REST;Client=RESTSystem; (In hindsight it was there in the raw data of the app connector but I missed it)

Checked the Audit Log (don't know why I didn't check it sooner) and found that its actually something to do with the Recipient cache inside the Mailbox. 

Thoughts are that it could be something to do with the latest FindTime changes or some kind of new feature for something to do with recipient cache or Calendar Entries based on what the user said they were doing. Might clarify further as I dig into the logs further. If I do i'll post here. Either way MCAS doesn't seem to know the IPv6 range. 

The IPv6 Ranges all seem to start with: 2603:10c6:220:4d:cafe. The bits that stay the same are the cafe and 2603:10, mostly 10c6 but not always. 

Hope this helps someone, or with more information, helps me clarify exactly what it is. 

[#2]

@LT22more FYI 😉

We opened a ticket with MCAS and then with Exchange Online support in early Jan, that confirmed this is a "potential bug"...

Still waiting on a resolution, current recommendation was to add all these IPv6 as trusted. Since these IPs are not listed in the official ranges and constantly change we decided to wait for a proper resolution.

Requested also rationale for the REST client polling customer data with no luck so far

Quite disappointed with the MS support around this

[#3]

@FaustinRoman ,

I wonder if its always been doing this but has now moved this IPv6 and as you said it just doesn't know about it. I also wonder if these servers are actually in our local region but its just a 

I also wondering if this is part of the integration of the 'Outlook for iOS' and 'Outlook for Android' Apps. 

[#4]

@LT22 @FaustinRoman 

We are seeing a near identical event generating impossible travel alerts.

If you hear anything further please let us know.

[#5]

@LT22good questions!

For us the service location generating the alert is in US while our Exchange data is hosted in a very different region.

We requested rationale and details for this process as we are concerned about data sovereignty and privacy.

[#6]

@JKelly9 @LT22 I will send this thread to the team looking after our tickets, hopefully they will reply here or speed-up the resolution.

In any case, thanks for sharing! 😉

[#7]

Ok hope this is resolved soon as we're getting the same issue

[#8]

@jurajlthis was resolved a few months back

I recommend opening a service request

[#9]

@FaustinRoman Hi Faustion

Did you ever get a reply to your question regarding data sovereignty and privacy? If so could I possibly ask if you would be kind enough to post the response in this thread please? I ask because we are in exactly the same situation where our data is hosted in a different region to the US as well and it would be great to try and know the reasoning behind alerts getting generated in the US.

Many thanks in advance.

[#10]

We got an answer, not sure if really addressed all concerns:
"We're informed that the Microsoft Internal IP that's being logged by Microsoft Security Cloud Service/App was a service from the back-end that triggers the audit log events itself. That's why it happens every 00:00 UTC standard time when Microsoft generates an audit log.

We're also informed that the IP was already whitelisted by the MCAS so this should no longer trigger alerts.

As far as data accessed outside of the region, there were none as the event is only for triggering the audit service."

You could ask why this event is not triggered from the same region... I leave that to you, let me know how far you get with MS support and if it was worth your time....

[#11]

Hi Faustin

Thank you very much for replying. I can say that it doesn't ring quite true what they say about the event only triggering at 00:00 UTC as we have observed these events at different times of the day.

I will certainly try to follow this up with Microsoft and if I do get any meaningful updates I will post them to this thread. Many thanks again to you.