MCAS IPv6 Recipient Cache False Positive Impossibile Traveller

Question

Hi all,&nbsp;&nbsp;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 :&nbsp;Client=REST;Client=RESTSystem; (In hindsight it was there in the raw data of the app connector but I missed it)&nbsp;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.&nbsp;&nbsp;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.&nbsp;&nbsp;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.&nbsp;&nbsp;Hope this helps someone, or with more information, helps me clarify exactly what it is.&nbsp;

faustinroman · Answer

JKelly9&nbsp;LT2024 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! 😉

faustinroman · Answer

LT2024more 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 farQuite disappointed with the MS support around this

jkelly9 · Answer

LT2024&nbsp;FaustinRoman&nbsp;We are seeing a near identical event generating impossible travel alerts.If you hear anything further please let us know.

faustinroman · Answer

LT2024good 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.

faustinroman · Answer

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....

Forum Discussion

MCAS IPv6 Recipient Cache False Positive Impossibile Traveller

10 Replies

Resources