What is an illicit consent grant attack?
An illicit consent grant attack in Office 365 is when a person is tricked into giving extensive rights to the data they can access or the configuration of their Office 365 applications to a third-party application external to their organization.
Most of the time, the user receives a phishing email prompting them to follow links that seem legitimate in the context of Office 365 and through which they end up granting, without realizing it, rights to the malicious third-party application.
Once the rights are granted, the malicious application has access to the user’s security perimeter without needing to know its username and password.
This means that this type of attack does not require the theft of the user’s login credentials and the implementation of a multi-factor authentication does not protect against it.
Typical scenario of an illicit consent grant attack
Here is a typical scenario from real-world experience:
- A user receives a phishing email indicating that a document is being shared with them. The link looks correct and ends with “.web.core.windows.net”.
- The user follows the link, then is asked to grant permissions to an application with a name that seems to match the Office 365 context such as “SharePoint Docs.”
- This is usually the first time the user has used this sharing method and since they are often asked to grant consent to access and use online resources (the GDPR effect), they are unsuspecting and think it’s normal. The user does not look in detail at the permissions he grants and would not be able to understand them anyway since they are too technical for him.
- Finally, after granting the permissions, the document no longer seems to be available. The user concludes that the manipulation did not work or that the document has been removed and eventually blames the system.
- The application has meanwhile obtained the permissions to modify the configuration of the employee’s mailbox. The details of the “grant” look like this:
{ "Name": "ConsentAction.Permissions", "NewValue": "[] => [[Id: AAAAAAAAAAAAAAAAAAAAACixwiL_JOBBqHOre3PNTOWljA2RvrSiSrbwsMJWDGBP, ClientId: 00000000-0000-0000-0000-000000000000, PrincipalId: XXXX-XXXX-XXXX-XXXX-XXXX, ResourceId: XXXX-XXXX-XXXX-XXXX-XXXX, ConsentType: Principal, Scope: offline_access Contacts.Read User.Read Mail.Read Notes.Read.All MailboxSettings.ReadWrite Files.ReadWrite.All openid profile]]; ", "OldValue": "" },
- The application can then create an email forwarding rule that looks like this:
If the message:
the message includes specific words in the subject or body ‘fund’ or ‘Wire’ or ‘transfer’ or ‘iban’ or ‘capital call’ or ‘cash’ or ‘agreement’ or ‘purchase’ or ‘shares’ or ‘dividend’ or ‘Contribution’ or ‘bic’ or ‘swift’ or ‘Payment’ or ‘wiring info’ or ‘Bank’or…
Take the following actions:
forward the message to ‘User’ as an attachment
- The rule is hidden under a label that may make the user think it is a technical rule created by their organization such as an “Anti Spam Rule”
- All the user’s messages that match the rule’s criteria are then sent to an external recipient.
- After 12 hours Microsoft detects the suspicious activity related to the malicious application, removes the rights granted and disables the third party application. But thee mail forwarding rule is still in place as long as no action is taken. The tenant’s administrators receive a message from Microsoft that looks like this:
The above scenario represents a successful illicit consent grant attack that will remain successful until the person who was impacted is located and the email forwarding rule is removed.
Fortunately, Microsoft provides a set of measures to detect, correct and counter this type of problem.
How to detect these attacks?
Microsoft propose des outils pour chercher les activités de consentement des utilisateurs. Un des premiers outils que référence Microsoft est d’utiliser les logs d’audit sous https://protection.office.com section « Search > Audit log search ».
Here’s what it looks like. Since unfortunately at the time of writing this article, the “Consent to application” activity type is not available in the search options on the right side of the screen, it is quite common to miss events using this method.
It should be noted, however, that if you do not know the exact period of attack, it is complicated to find the entries with the proposed interface. Indeed, for the “consent to application” filter to work, the event must have been loaded in the page. You therefore have to scroll through all the results in the list before applying the filter.
The screenshot above shows the sequence of events with the update of the Outlook rules.
A more industrial approach is to use a PowerShell script that searches for this type of event in the audit logs. Microsoft offers the “Search-UnifiedAuditLog” command to perform this operation. We will not detail here the PowerShell script to perform this operation, but if you really want to trace this type of event and inject it into your SIEM, this approach is necessary.
Another approach is to make a regular inventory of applications and their permissions in the Office 365 ecosystem.
To do so, the most industrial approach is to use a PowerShell script that lists all applications and their permissions and look for any user data access rights, data modification rights or application configuration access rights. Microsoft offers a script Get-AzureADPSPermissions.ps1, available on their “GitHub” to perform this operation.
If you have a sufficient license level it is also possible to use “Microsoft Cloud App Security” to set up an OAuth application anomaly detection strategy. A detailed documentation is available from Microsoft for the implementation of detection and alerting: https://docs.microsoft.com/en-us/cloud-app-security/app-permission-policy
However, the latter option is most likely not available under your Microsoft Cloud App Security instance. Your only option is to use PowerShell scripts and manage your detection and alerting yourself.
This is not the easiest or most straightforward thing to do. In addition to the detection methods detailed above, it is also strongly recommended to set up alerts on all activities related to the implementation of email forwarding rules at the domain or user level and to work on the implementation of DLP (Data Loss Prevention) to be warned in case of exploitation of data leakage paths to the outside from Microsoft Office 365 tools and applications.
How to stop and correct the impacts of these attacks?
As we have seen before, you need to be able to detect the granting of abusive rights to third-party applications and to be able to identify the actions they have taken to remedy this.
The first thing to do is to remove the permissions, or even to remove the link between the application and the users.
To remove the application you need to log into the Azure Active Directory portal, and for each affected user:
- Access the user’s control panel
- Select “application”
- Select the illicit application
- Click on “remove”
If many users are concerned, this operation is tedious and can take quite some time.
Again a PowerShell scripting approach is preferable and requires the use of the “Remove-AzureADOAuth2PermissionGrant” PowerShell command.
Depending on the actions that have been performed with the rights of the impacted user, it is also necessary to remove any forwarding, transfer or information sharing rules that may have been set up. The inspection of audit logs proves to be crucial to identify all activities that may have been carried out through the malicious application.
How to protect your organization against it?
The only effective method is to disable the ability for users to grant rights to a third-party application.
Either through the Office 365 administration panel in “Services & add-ins” (https://go.microsoft.com/fwlink/p/?linkid=2053743):
Or through the “Azure Active Directory” console in the “Enterprise applications” section under “User settings”
If you need to give your users the ability to grant rights to third-party applications, then it is highly recommended to be alerted by “Microsoft Cloud App Security” as described here: https://docs.microsoft.com/en-us/cloud-app-security/app-permission-policy and to set up a process for analyzing and handling the alerts raised to avoid any undesirable activity in your applications and data.
References:
- https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants
- https://docs.microsoft.com/en-us/cloud-app-security/manage-app-permissions
- https://docs.microsoft.com/en-us/microsoft-365/admin/misc/integrated-apps?view=o365-worldwide
- https://gist.github.com/psignoret/41793f8c6211d2df5051d77ca3728c09
Thanks to our
Author
