Go ahead and visit the “Add-in for Outlook” page in Outlook Web Access, then come back to this post.  First, if you did click on that link, and signed in it means that you trusted our post.  Don’t worry, it was a legitimate link, but you should consider how little effort it took to obtain your consent. In fact, exploiting trust is a common tactic for gaining access to Office 365 account.  Known as illicit consent, these attacks are common and may have already been used against you.  While detecting, remediating, and mitigating illicit consent attacks is beyond the scope of this blog, we want to highlight one variant of the method: exploitation of Outlook Add-ins.  What we want to imprint on you here are two things:  this is a serious threat to your infrastructure and this whole article only scratches the surface of it.

Here we will focus on My add-ins for Outlook, their exploitation, and the high-degree of probability that your systems have already been invaded by this less-severe form of compromise. It is our hope that once you understand this simpler example and how vulnerable your systems are, you will use this information to develop a comprehensive strategy for protecting your SaaS applications.

Chances are you have never been to this page. In fact, it is fairly difficult to access.  One way to do it is by going to Outlook, clicking on File and then going to Add-Ins.  Another is to spelunk your way through Outlook Web Access.  Finally, there is that link we provided in the first sentence of this blog — save it.

Let’s dig in…

All of these items could have been installed by you, or your administrator, with as much effort as it takes to click “Accept” to any terms-of-service… think about how often you do that.  The three sections are:

• Store add-ins
• Admin managed add-ins
• Custom add-ins.

The first thing you might notice is that the top two sections of this list feel trust-worthy, since some come from the Microsoft store and others were installed by your administrator. That is what we refer to as normalization of deviance.  Since the two items suggest oversight, you feel you can trust them. Unfortunately, when it comes to exploiting illicit consent, all three are equally vulnerable.

Despite the effortlessness of doing so, any one of these add-ins can access every piece of your mailbox, and if they are admin-level, all of your Office 365 mailboxes.  If you do not have a sudden feeling of a pit in your stomach from learning that, well, we have little advice for you.  However, if you do, keep reading because you already recognize how critical this piece of infrastructure is and how easy it is to exploit.

From there, things get worse.  A lot worse.

All three categories enable installation of software for Outlook written by virtually anyone.  The Microsoft “store” for add-ins allows submissions with minimal vetting. While they routinely remove old add-ins, it is done after the fact.

Have you ever elected to rename a mailbox from one user to the next?  Perhaps you should re-think that strategy.  Any consent and add-ins installed by a user carry over to the next person that takes over that mailbox.  That means malicious add-ins can persist and aggregate over time.

Lastly, there is no admin-level oversight capability to two-thirds of Add-ins for Outlook, meaning every application authorized to interact with the mailboxes is siloed away in this secret options compartment.  The only way to see them is to visit the link as each user or review audit-logs which are optionally enabled by your organization (and thus may not be).

Hello,

I wanted to follow up with you regarding the issue with the Add-Ins you were experiencing a few days ago.

Unfortunately, it seems like the only way to find out when and who was able to install them for that user is by reviewing the audit logs.

However, you do bring up a good point that you should be able to see the details without having the auditing enabled. Please review this uservoice link, where you are able to post ideas that Microsoft will review and attempt to make the changes necessary: https://office365.uservoice.com/

In the meantime, you should be able to delete the Add-Ins that you don’t believe should have been installed. This way, if they get re-installed you will be able to review the audit log since you have enabled it on the tenant.

If you have any questions, please let me know and I will be happy to help. Thank you for choosing Office 365 Support.

Sincerely,
Ala
Microsoft Office 365 Support

Actionable steps…

The immediate solution to this problem is to visit “Add-in for Outlook”  as each user. There is no point in running audit logs, they do not go far enough in time (assuming you have them enabled). Review the page and compare it agains the screen shot at the bottom. Anything other than what you see should be suspicious to you and referred to professionals.

Unfortunately, that doing this today does little to protect your organization.  The problem with illicit consent is that it can affect a series of components in your infrastructure and therefore be a significantly larger issue than Outlook Add-Ins.  This is just one example, and we would be surprised if you did not find a mailbox in your organization that has granted access to something that Microsoft managed to pull “later” from their store. The scope of this problem is exponentially greater than Outlook Add-Ins.

In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data such as contact information, email, or documents. The attacker then tricks an end user into granting that application consent to access their data either through a phishing attack, or by injecting illicit code into a trusted website. After the illicit application has been granted consent, it has account-level access to data without the need for an organizational account. Normal remediation steps, like resetting passwords for breached accounts or requiring Multi-Factor Authentication (MFA) on accounts, are not effective against this type of attack, since these are third-party applications and are external to the organization.

In all cases, the applications are able to bypass all security measures because they authenticate using OAUTH which is enabled on our tenants. While Microsoft Office 365 is highly susceptible to this kind of attack, so are all SaaS applications that support OAUTH. To manage illicit consent you have little choice but to engage your cybersecurity professionals, like us, and spend a few minutes learning about this threat, conducting an inventory, and then developing a strategy for mitigating.  This topic is covered in extensive detail in our support documentation portal.