Hello Microsoft ATP Team,

This is to bring to your notice that spammers/phishers have started targeting Office 365 Tenants which creates a mail loop between Office 365 hosted domains and these emails are getting circulated through which accounts gets compromised. We had a lot of incidences happening in our environment, As these emails are getting generated from the actual account hosted in Office 365 the email are considered to be safe and lands in users Inbox. We have ATP safe links policy in place however its not performing the job as expected. ATP is a great feature but we request you all to look in this matter on a larger scale. We have created a case with Microsoft Support for Office 365.

We have had a lot of issues with spam, whether its cryptovirus emails getting through, or good emails getting improperly blocked. Because of this, we need good message tracing (to find the emails), which we do not feel we have with exchange online. We would like to make the following suggestions:

1. Need to be able to trace further than 7 days back without a 4 hour wait per trace. Our previous message tracing system could go back the entire year nearly instantly, but we need at least 30 days without the 4 hour wait per trace. This was pitched as something that could replace our previous tracing system, and this does not do it.
2. UTC time is confusing in message tracing. It uses “AM and PM.” AM/PM in UTC time is ambigious since UTC time it used all over the world. So either use UTC, or fix the timezone to use our timezone automatically. It looks like very little effort was put into implementing message tracing if this made it past QA.
3. We would like more options in message tracing, especially completely basic fields like searching by subject. I would like to know how this was rolled out as an enterprise product without that a "subject" search field when tracing emails. Part of the reason it is so slow is probably because you have very few search fields to refine.
4. Overall speed improvements, even tracing back less than 7 days or less is slow (sometimes "spins" for several minutes", but more than 7 days is 4 hours+). We basically received a poorly formatted spreadsheet after 4 hours.

A premier case was opened for all of this, the features simply do not exist and its not a configuration issue. They did mention compliance center can help search for emails quicker, but does not trace.

Short:

On shared mailboxes in office 365 emails that are flagged by the sender as private are hidden. In OWA they are visible.

Long:

Users having full access to the shared mailbox do not see emails sent with a private flag - and they do not get informed about it. The emails are just silently hidden by outlook without any further notice. Quite stupid, for a shared mailbox (e.g. incoming orders!)

We discovered that by coincidence: Our users were concerned because the number of unread emails was increasing - although there were no unread emails visible for them.

If they open the same mailbox in OWA, they can actually SEE the private email!

Improvement:

1. Get consistent behavior between OWA and Outlook.

2. Let an administrator configure right to see the private messages on shared mailboxes.

Currently, MFA for Azure AD / O365 is useless regarding protection of mailboxes in Exchange Online, as EWS and MAPI clients can still connect to mailboxes using Basic Authentication, even with Conditional Access rules in place to require MFA, and there's no way of denying this server-side on EXO.

The newly-released Client Access Rules feature promises this functionality in its documentation (see https://technet.microsoft.com/library/mt842508.aspx and https://technet.microsoft.com/en-us/library/dn913650(v=exchg.160).aspx), but unfortunately the functionality is crippled. You can only make rules in the following combinations (info from EXO Engineering team):

OutlookWebApp: BasicAuthentication, AdfsAuthentication
ExchangeAdminCenter: BasicAuthentication, AdfsAuthentication
RemotePowerShell: BasicAuthentication, NonBasicAuthentication
ExchangeActiveSync: BasicAuthentication, OAuthAuthentication, CertificateBasedAuthentication
IMAP4/POP3/OfflineAddressBook/PowerShellWebServices/ExchangeWebServices/REST: none

Note there is no mention of OutlookAnywhere (MAPI) in the above list, but from my own testing, it's impossible to create rules around that protocol. EWS is explicitly mentioned as not possible to restrict auth type for.

IMAP and POP are also bypasses for MFA, but it's easier to turn those off, but many things are dependent on EWS (including Outlook mobile apps), and Outlook (desktop) is of course dependent on MAPI (OutlookAnywhere). It would be useful to control REST too, as I understand some mobile apps will use that.

Yes, you can use CAR's to allow only certain IP's and users to connect with certain protocols, insist everyone VPN's in before connecting, and try to force compliance Outlook client-side, using GPO's to turn on ADAL and then lock down the registry, but this doesn't stop a phisher bypassing MFA for one of your users from whom they've phished username and password, and getting full access to their mailbox.

This is a pretty big security hole for us, and I'm surprised there isn't more noise about it across the internet. I just get blank or stock responses from support and escalation engineers on this, so I'm hoping this post helps.

For some error codes related to sending mails, the senders may receive the NDR immediately. However, for some other error codes, the mail server marks the undeliverable messages as a temporary error and the senders doesn't immediately receive an NDR. Instead, Exchange Online repeatedly tries to deliver the message over two days. Only after two days of unsuccessful delivery attempts does the sender receive this NDR.

For some time critical businesses this is not acceptable. The user has to be informed very quickly (<6 hours) that his Mail was not delivered by now. Then the user can phone the recipient or sent the mail to another address. I do not care if exchange online continues trying to send the message after 6 hours, but the user has to be informed.

Exchange Server 2016 an older allowed customization of the Message Expiration Timeout Interval and NDR Settings. Please add this to ExchangeOnline

Dear Microsoft,

OneDrive for Business is one of the useful tools for cloud storage whereby end user should be able to folders (even got files inside) easily even being applied with retention policy.

Retention policy is suppose used on backend which not suppose to affect on OneDrive for Business usage. We are have 500 users getting impact on this. (and i assume all users having this issue as Microsoft support tested having this issue - "behaviour")

I was informed by Microsoft that this is by default preservation policy design behaviour, which I think this is not consider design behavior anymore as is causing the OneDrive for business folder deletion problem.Again, retention policy on OneDrive shouldn’t affect the folder deletion method as there is No Different that user can either delete all the files inside and delete the folder, or delete the entire folder directly.

Please fix this problem as soon as possible, otherwise this issue is serious discourage people to use the retention policy feature. Email me if seriously looking into this issue.

Please re-enable the Exchange Online Activities API that allows for forensic investigation of Business E-mail Compromise incidents.

Business E-mail Compromise is a very serious and active threat for all organizations. By default, Office 365 provides very little auditing capability to investigate this type of incident. Exchange Online mailbox auditing must be proactively enabled by the customer before the breach if they wish to get this level of auditing data.

On June 18, 2018 it was publicly discovered that Microsoft does maintain this audit data even without the customer enabling it. It was available to all Office 365 customers via this API until Microsoft disabled access on July 6, 2018.

Please re-enable access to this API and stop withholding essential audit data from your customers.

References:
https://www.crowdstrike.com/blog/hiding-in-plain-sight-using-the-office-365-activities-api-to-investigate-business-email-compromises/
https://lmgsecurity.com/rip-office365-magic-unicorn-tool/
https://medium.com/@kylebubp/using-o365-activities-api-for-incident-response-d6fb6e1420e0
https://nullsec.us/office-365s-secret-activities-api/
http://o365blog.com/post/exomailactivity/