Posted by On Thursday the 6th of December 2018 I had the pleasure to co-host a session with Ben Menesi. Ben is head of products at Ytria and they provide great tools for Office 365. Ben’s an ethical hacker as-well, which made our session very interesting.
Ben’s my co-author for this post and please check out his Twitter feed and LinkedIn profile to see what great other stuff he shares and cares about!
Our session was for SharePoint Saturday Geneva (yes, really) and covered the threats to Office 365.
As an ethical hacker, Ben made it quite difficult for me (the security guy) to present mitigation options for the different scenario’s. But I did manage. One of the scenarios was somewhat complicated. The scenario was about illicit consent grants.
The scenario has been around for some time. Here’s one of the first mentions: https://community.spiceworks.com/topic/2104688-heads-up-new-ransomware-strain-encrypts-cloud-email-real-time-video
In this scenario a user is asked to provide consent to an application. After consent has been provided, the application will act on behalf of the user and his/her permissions. In the more frightening scenarios, the users mailbox will become encrypted by ransomware.
More information on this attack can be found here:
- https://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-illicit-consent-grants
- https://blogs.technet.microsoft.com/office365security/defending-against-illicit-consent-grants/
To quickly demonstrate how to simulate this attack and how to set-up an MCAS policy to detect this, I created this video. In the video I use an Azure application, Postman and the Microsoft Graph to get an overview of SharePoint sites within a tenant. A very friendly scenario.
But keep in mind that this scenario is very serious indeed. Also keep in mind that I’m demonstrating this on one machine. You need to realize that in the real-world, the authorization code would fall into the hands of someone with criminal intent…. Well, look and see….
Consent scenario
So. I tested this with two types of apps. One was created in my own tenant. The second one was created in a totally different and non-connected tenant. Both worked. As the video shows, using an app from a different tenant, I was still able to get to the list of SharePoint sites.
Do note that I was using a network sniffing tool. Normally the authentication code would be intercepted by some malicious web server on the net.
Here’s the OAuth flow (as documented in https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow). The authorisation code can be used to obtain the token. In my case, using Postman.
There are several mitigation options for this scenario. Educating your end-users is one of these. Other ones are detailed in the articles as mentioned above. In addition to these, you might want to look at disallowing your users from granting access to Office 365 information (Admin portal | Settings | Services & Add-ins | Integrated Apps) and look at the users settings for your Azure AD. See below.
As an admin you might want to disallow users from consenting to any app. This is an option in the Azure AD Enterprise application user settings. If this is the case, any app will need administrator’s approval before being used. This is pretty secure, but will put certain strain on your administrators.
Besides these, you can use Microsoft Cloud App Security, if available. In the video I created a policy in Microsoft Cloud App Security. And these are the steps I took.
Microsoft Cloud App Security
First of all, in the policy section, create an OAuth app policy.
You can set the permission level of the app (low, medium and high) and if the app is known to MCAS. This is the Community use option. If it is a common app, then it might not be a problem. But I’ve set this policy to Uncommon and Rare – because this should detect any malicious app.
Based on these criteria you can set alerts (even using Flow – see my other blog for that). But more importantly, you can revoke the app.
After having activated this policy, both my little apps were blocked and could not be activated again.
An error-message tells us that the app has been disabled (blocked).
BUT…..
MCAS seems to offer a protection layer against unauthorised OAuth apps. But it took some time for the policy to be activated. This also means that it took some time for the app (from the different tenant) to be blocked. In the meantime you may already have some users which are effected.
But, I must admit, MCAS did block any access by this app from that time on.
Governance, Risk, Security and Compliance 
One comment