How did the Outlook email breach happen?

According to Microsoft, one of its support agent’s credentials were compromised, allowing individuals to gain unauthorized access to Microsoft email accounts. Initially, Microsoft said the breach might have allowed unauthorized parties to “access and view information” related to affected email accounts (including folder names, subject lines of emails, and names of other email addresses) but not their contents.

Symptoms of a Compromised Office 365 Email Account

Users might notice and report unusual activity in their Office 365 mailboxes. Here are some common symptoms:

• Suspicious activity, such as missing or deleted emails. (This means they can delete inbox messages)
• Other users might receive emails from the compromised account without the corresponding email existing in the Sent Items folder of the sender. (They can send new messages and delete messages from sent folder)
• The presence of inbox rules that weren’t created by the intended user or the administrator. These rules may automatically forward emails to unknown addresses or move them to the Notes, Junk Email, or RSS Subscriptionsfolders. (They had access to forward rules, i.e. they had content view access for the new and old emails.)
• The user’s display name might be changed in the Global Address List. (Had access to update profile)
• The user’s mailbox is blocked from sending email.
• The Sent or Deleted Items folders in Microsoft Outlook or Outlook on the web (formerly known as Outlook Web App) contain common hacked-account messages, such as “I’m stuck in London, send money.”
• Unusual profile changes, such as the name, the telephone number, or the postal code were updated.
• Unusual credential changes, such as multiple password changes are required.
• Mail forwarding was recently added.
• An unusual signature was recently added, such as a fake banking signature or a prescription drug signature.

Here is a list of Outlook features from its API documentation page. Check out the feature-role-mappings we created from the docs for regular user/owner and for the support user we learned from the PR (Note: I didn’t find any online docs for support role).

Here is our 4 Point Analysis

1. Microsoft said the “Support” role had access to only the subject lines. I think they needed access, will give it to them.
2. Microsoft said the “Support” role had no access to the contents – This lowers the risk of leaking email contents. I believe their entire focus was around protecting the email body. But, it seems they had access to create, send, and delete messages
3. Seems “Support” role had access to Rules, Profile, Password-Reset, Signature – I’m not sure why a Support role needs access to these features. Most importantly the Rules access because this negates the advantage of point #2.
4. It seems the support can see folder names. I’m not sure why they needed this access and we’re not sure what else they can do on folders.

How CISO/Security can prevent these kinds of attacks?

1. First, the complexity of the attacks proves the attackers are years ahead of the security industry, especially on the application layer vulnerabilities (APIs and Features etc).
2. Also, real-time detection and protection won’t work for these kinds of attacks. These vulnerabilities are in the code and it took Microsoft over 3 months to discover (January 1 to March 28, 2019) and they may have taken some time to fix these issues in the code before they made the announcements.
3. What security teams needs is 100% visibility into API/Feature and Role mappings. The best approach at this point is to continuously Discover, Track and Fix Role-Based-Access-Control vulnerabilities early in the development cycle and as daily compliance checks.

At APIsec we focus on similar (RBAC) vulnerabilities as a day-1 task. As a first step we auto-discover feature-role mapping then we sort and prioritize overlapped/escalated permissions.